Système multi-agent : architecture et modèles pratiques pour des agents LLM qui fonctionnent

Un système multi-agent fait bel effet sur une slide. En pratique, c'est une série de compromis : plus d'agents peut vouloir dire des rôles plus clairs et de meilleurs résultats, ou plus de coûts, plus de points de défaillance et plus d'occasions de tourner en rond. Je construis ces systèmes au quotidien, dont un qui produit des vidéos YouTube finies avec 14 agents. Voici ce que j'ai appris sur la façon de les structurer.

Cet article parle d'architecture : comment organiser les agents, comment ils partagent l'information, et où l'humain intervient. Si vous en êtes encore à choisir quoi automatiser, commencez par que faut-il automatiser en premier.

Ce qu'est (et n'est pas) un système multi-agent

Un agent LLM, c'est un modèle qui tourne en boucle : il lit un objectif, choisit une action, appelle un outil, regarde le résultat, puis décide à nouveau. Un système multi-agent en réunit plusieurs, chacun avec ses instructions, ses outils et son contexte, au service d'un même résultat.

Le but n'est pas d'avoir beaucoup d'agents. Le but est que chaque agent ait une tâche étroite et un contexte réduit et propre. Un modèle à qui l'on demande de chercher, rédiger, vérifier et monter en même temps fait les quatre moins bien que quatre agents spécialisés, surtout parce que son contexte se remplit d'éléments sans rapport avec l'étape en cours.

Quatre modèles d'architecture de système multi-agent

La plupart des systèmes que j'ai vus ou construits combinent quatre formes.

1. Orchestrateur et spécialistes

Un agent (l'orchestrateur, ou directeur) porte le plan. Il découpe l'objectif en tâches, confie chacune à un spécialiste, vérifie ce qui revient et décide de la suite. Les spécialistes ne se parlent pas entre eux : ils parlent à l'orchestrateur.

C'est le modèle le plus souple, adapté aux travaux où l'étape suivante dépend du dernier résultat. Son point faible, c'est l'orchestrateur lui-même : s'il planifie mal, chaque spécialiste fait du bon travail sur la mauvaise chose.

2. Pipeline

Les agents s'enchaînent dans un ordre fixe, chacun prenant la sortie du précédent : recherche, puis rédaction, puis relecture, puis mise en forme. Personne ne décide de l'ordre à l'exécution, puisqu'il fait partie de la conception.

Un pipeline est prévisible, facile à déboguer et mesurable étape par étape. Utilisez-en un dès que le processus est vraiment le même à chaque fois. Beaucoup de projets « multi-agents » seraient mieux servis par un simple pipeline.

3. Agents en parallèle

Plusieurs agents font des morceaux de travail indépendants en même temps, puis quelque chose assemble les résultats : des éclaireurs qui explorent des pistes différentes, ou des développeurs qui traitent des tickets séparés.

La règle ici, c'est l'isolement. Des agents en parallèle ne doivent jamais écrire au même endroit. Dans mon workflow de développement, chaque agent implémenteur travaille dans son propre git worktree, pour que deux tickets avancent en même temps sans collision.

4. Relecteur ou critique

Un agent produit, un autre cherche ce qui ne va pas. Le relecteur doit avoir des instructions différentes, idéalement un autre angle (« trouve le défaut »), et ses remarques doivent s'appuyer sur des preuves. Sans ça, il produit du bruit assuré. J'en parle dans pourquoi tout relecteur de code IA a besoin d'un test qui échoue.

Un exemple concret : un pipeline vidéo autonome

VidForge est mon propre système, qui transforme un sujet en vidéo YouTube finie de 10 à 15 minutes. Il combine les quatre modèles :

Des agents en parallèle au départ. Deux agents éclaireurs cherchent en parallèle et reviennent avec une vingtaine d'idées de vidéos, chacune avec son accroche et une recommandation.
Une seule décision humaine. Je choisis l'idée. C'est le seul choix dont il a besoin.
Orchestrateur et spécialistes. Un agent Directeur pilote ensuite la production à travers 13 spécialistes : script, vérification des faits, narration, images d'archives, images générées, présentateur à l'écran, motion design, montage et miniatures.
Des points de contrôle optionnels. Au script, au premier montage et au montage final. En mode nuit, il les saute et la vidéo est prête au matin.

Une contrainte a façonné l'architecture plus que n'importe quel choix d'agent : l'essentiel du travail lourd tourne sur des modèles locaux, sur une seule carte graphique grand public de 16 Go. Les tâches de génération passent donc par une file d'attente et un seul modèle tourne à la fois. Bien concevoir un système multi-agent, c'est souvent une affaire de ressources et d'ordonnancement, pas seulement de prompts.

État partagé et passages de relais

La façon dont les agents se transmettent le travail décide si le système reste débogable.

Transmettez des livrables, pas des conversations. Chaque agent doit produire un fichier ou un enregistrement structuré (un script, une liste de plans, une spécification JSON), pas une transcription que l'agent suivant devra interpréter.
Gardez une seule source de vérité. Un état de projet partagé (un dossier, une ligne en base, un document structuré) que chaque agent lit et modifie à des endroits définis.
Validez à chaque frontière. Si l'agent suivant attend une liste de scènes avec des durées, vérifiez-le avant de transmettre. Attraper une sortie mal formée au passage de relais coûte bien moins cher que la découvrir trois agents plus loin.
Journalisez tout. Entrées, sorties, appels d'outils et coûts par agent. Quand quelque chose déraille, il faut savoir quel agent a commis la première erreur.

Quand un seul agent vaut mieux

Plus d'agents ne veut pas dire mieux. Préférez un seul agent, ou un simple script avec un appel au LLM, quand :

la tâche tient sans difficulté dans un seul contexte et n'a pas besoin d'outils différents selon les étapes,
la latence compte (chaque passage de relais ajoute du temps),
le budget est serré (chaque agent relit du contexte, et ça coûte des tokens),
vous ne savez pas encore mesurer la qualité. Découper un système non mesuré en plus de morceaux rend seulement les problèmes plus difficiles à voir.

Commencez par le plus simple qui marche, mesurez, et ne découpez que là où un agent fait clairement trop de choses.

Les défaillances à prévoir

L'accumulation d'erreurs. Si chaque étape est juste la plupart du temps, une longue chaîne l'est beaucoup moins souvent. Des chaînes courtes, une validation à chaque relais et des relecteurs aux étapes risquées aident.
Les boucles. Deux agents peuvent se renvoyer le travail indéfiniment. Plafonnez les tentatives et les itérations, et passez la main à un humain quand le plafond est atteint.
La dérive des coûts. Un orchestrateur qui replanifie sans cesse, ou des relecteurs lancés à chaque petite modification, multiplient la consommation de tokens. Suivez le coût par exécution dès le premier jour. Voir comment réduire les coûts d'API LLM.
Des rôles flous. Si deux agents peuvent raisonnablement faire la même tâche, tôt ou tard les deux la feront, ou aucun. Chaque agent a besoin d'une fiche de poste qu'on pourrait donner à un nouvel arrivant.

La place de l'humain

Les systèmes les plus fiables que je construis gardent un humain là où une mauvaise décision coûte cher : choisir quoi produire, valider avant tout envoi ou publication, et approuver le résultat final. Dans mon pipeline de développement, l'approbation se fait commit par commit et la validation finale m'appartient, comme je l'explique dans comment je livre du code de production avec des agents IA. Les points de contrôle peuvent devenir optionnels une fois que les données montrent qu'ils changent rarement quelque chose.

Travailler ensemble

Je conçois et construis des systèmes multi-agents de bout en bout, des rôles et passages de relais jusqu'au logiciel de production, à la journalisation et aux modèles locaux qui les entourent. Voyez VidForge et mes autres études de cas.

Si vous avez un processus qui semble demander plusieurs agents, envoyez-moi un court descriptif. Je vous dirai honnêtement si c'est le cas, ou si une conception plus simple fera l'affaire.