Au chapitre précédent, nous avons vu comment relier des outils externes à un seul agent via MCP. À ce stade, vous avez un agent autonome — doté d'un cerveau, d'outils, de mémoire et d'une boucle — qui fonctionne. Mais dès que la tâche grandit, l'idée de tout entasser dans un seul agent finit par se briser quelque part. Ce chapitre organise, au niveau conceptuel et indépendamment de tout framework, la « conception multi-agent » qui résout en répartissant les rôles entre plusieurs agents et l'idée de leur coordination (A2A : Agent-to-Agent).
L'objectif : savoir juger « quand et comment répartir renforce le système »
Quand un seul agent ne suffit plus
Un agent unique est simple, lisible et facile à suivre — c'est bien pour cela qu'il faut commencer par un seul. Le problème survient quand on lui ajoute rôle sur rôle. Dès qu'on entasse dans un même prompt « enquêter, rédiger, relire, traduire, et publier aussi… », à partir d'un certain point la précision se met soudain à chuter.
Il y a principalement 3 causes. ① Les instructions deviennent longues et floues (plus on écrit « ceci et cela », plus le modèle hésite sur ce qu'il faut prioriser). ② Le contexte enfle (il embarque jusqu'à des infos sans rapport, et l'instruction essentielle se dilue). ③ Il y a trop d'outils (plus les options augmentent, plus il est facile de choisir le mauvais). Un agent trop chargé, c'est en somme « un lieu de travail où une seule personne cumule tous les rôles et s'y perd ».
💡 Un changement de perspective. Plutôt que de rendre un seul agent toujours plus intelligent, basculer vers l'idée « faire coopérer plusieurs petits agents, chacun concentré sur un seul rôle ». C'est le point de départ de la conception multi-agent. Comme dans la division du travail au sein d'une organisation humaine, plus la responsabilité de chacun est étroite et claire, plus l'ensemble est stable.
Cela dit — répartir n'améliore pas forcément les choses. La division du travail s'accompagne toujours d'un coût de coordination. C'est pourquoi le vrai sujet de ce chapitre n'est pas seulement « comment répartir », mais « discerner s'il faut répartir du tout ». Voyons d'abord les 3 formes représentatives, puis passons aux critères de décision.
Les 3 patrons de base
On peut dessiner d'innombrables configurations multi-agents, mais les ossatures qui reviennent en pratique se ramènent à 3. En les combinant, on peut décrire la plupart des configurations. Saisissons-les une à une, avec leur rôle et leurs (in)adéquations.
Le parent (l'orchestrateur) établit le plan d'ensemble, répartit les tâches aux enfants (ouvriers) pour exécution, puis rassemble et intègre les résultats. Les enfants s'ignorent mutuellement et ne voient que le parent. Sa force : centralisé, donc facile à contrôler.
Quand l'utiliser : quand on peut découper la tâche et vouloir la paralléliser.
On aligne les étapes et on passe la sortie de l'agent précédent en entrée du suivant. Par exemple « recherche → rédaction → relecture ». Chaque maillon n'assumant qu'une étape, les responsabilités sont nettes et la vérification facile.
Quand l'utiliser : quand la procédure est linéaire et les étapes fixées.
Comme « chargé de recherche », « chargé du code », « chargé de la revue », on prépare des agents spécialisés, chacun dans son domaine, et on les sollicite selon la situation. Chacun ayant instructions et outils resserrés, l'expertise monte.
Quand l'utiliser : quand les capacités requises diffèrent fortement d'un domaine à l'autre.
Ces 3 ne sont pas exclusifs. Un système réel prend souvent une structure imbriquée — par exemple « un orchestrateur pilote des ouvriers de type experts, dont l'un est lui-même un pipeline ». Fixer d'abord une ossature extérieure, puis n'employer un autre patron à l'intérieur qu'aux endroits nécessaires — cette façon d'empiler est la plus maniable.
📊 En cas de doute, partez de ①. Le plus polyvalent des 3 est l'orchestrateur + ouvriers. Le parent tenant au centre planification et intégration, il est facile à contrôler et sert de forme de base à beaucoup de configurations multi-agents. Pour l'organisation d'ensemble des patrons, voyez Qu'est-ce que le multi-agent ; pour l'approche « système », Qu'est-ce qu'un système multi-agent.
Quand répartir, quand ne pas répartir
À connaître les patrons, on est vite tenté de tout répartir. Mais la division du travail a toujours un « coût de coordination » — la peine de se passer l'information entre agents, de l'ajuster et de s'attendre. Le multi-agent n'est le bon choix que lorsque le gain de la répartition dépasse ce coût. Mettons d'abord les deux côtés côte à côte.
- On peut paralléliser : faire tourner en même temps des sous-tâches indépendantes et gagner du temps
- De l'expertise est requise : resserrer instructions et outils par domaine augmente la précision
- L'exploration est large : chercher à plusieurs des points de vue ou des pistes distincts
- On veut isoler le contexte : cloisonner le contexte par rôle évite les interférences
- C'est simple à la base : on complexifie inutilement un traitement qu'un seul agent suffit à faire
- Le coût augmente : plus il y a d'agents, plus s'accumulent appels au LLM et tokens
- La coordination est lourde : la peine des passages de relais et des attentes dévore le gain de la répartition
- Forte dépendance séquentielle : tout dépend fortement du résultat précédent, sans presque de marge de parallélisme
⚠️ D'abord se demander « un seul agent suffit-il ? » Le multi-agent est puissant, mais ce n'est pas ce qu'on choisit d'emblée. La règle d'or : monter par paliers — un seul agent → peaufiner le prompt → ajouter des outils → si ça ne suffit toujours pas, répartir. N'ajoutez de la complexité qu'après avoir vérifié « si le seul agent actuel est vraiment à sa limite ». La répartition peut se faire plus tard.
Comme repère pratique, imaginez : « quand j'explique ce rôle à un collègue humain, tient-il naturellement sur une seule fiche de poste ? ». Si un seul intitulé suffit, un seul agent suffit encore. Le moment où l'on a envie d'en faire deux personnes distinctes — « celui-ci est le chargé de recherche, celui-là le rédacteur » — c'est le moment d'envisager la répartition. Pour la vue d'ensemble du jugement, voyez aussi Comment construire un système multi-agent.
La coordination entre agents (A2A)
Une fois décidé de répartir, le défi de conception suivant est « comment les agents s'échangent-ils l'information ». Pour une équipe humaine, cela revient à fixer le format des fiches de passation et les règles de compte rendu. Si c'est flou ici, l'ensemble ne s'emboîte pas, même si chacun est excellent. Deux points sont à maîtriser dans la coordination.
Décider quoi passer, et sous quelle forme. Faire de « l'instruction de la tâche, l'entrée requise et le format de sortie attendu » un contrat explicite évite au destinataire d'hésiter. Un passage structuré est plus stable qu'un texte libre balancé en vrac.
L'étape qui réunit plusieurs sorties en une. Fixer d'avance qui porte la responsabilité finale de l'intégration. Inclure aussi dans la conception l'ordre de priorité en cas de résultats contradictoires et la méthode de synthèse (résumé, recoupement, vote majoritaire).
Cette idée de « faire coopérer des agents en répartissant les rôles », il existe un mouvement pour la traiter de façon plus standardisée : A2A (Agent-to-Agent). Là où le MCP du chapitre précédent était une convention reliant « agent ↔ outils / données », A2A est une convention reliant « agent ↔ agent » — voyez-la comme les règles communes pour savoir ce que l'agent d'en face sait faire, lui confier une tâche et en recevoir le résultat.
💡 Retenir MCP et A2A par contraste. En gros : MCP = relier des « mains » à un agent ; A2A = « relier » des agents entre eux. Le premier est la connexion aux outils et données, le second les règles de coordination. Il suffit de les saisir comme concepts pour l'instant ; les protocoles concrets seront évoqués dans les chapitres suivants. Pour plus de détails, voyez Qu'est-ce que le protocole A2A. Le comparer au MCP et connexion d'outils du chapitre précédent en clarifie la différence.
L'important n'est pas de retenir le nom des protocoles, mais l'attitude de conception : « la coordination exige des contrats explicites ». Qui porte quelle tâche, avec quelle entrée elle commence, quoi elle renvoie, et à qui la renvoyer en cas d'échec — fixer ces contrats à l'avance forme le socle d'un système qui ne s'effondre pas quand l'échelle grandit.
Gérer le contexte et le coût
Le plus grand risque pratique du multi-agent est l'explosion du contexte et du coût. Plus les agents se multiplient et s'échangent de l'information, plus le contexte que chacun porte grossit, et plus s'accumulent le nombre d'appels au LLM et le volume de tokens. Laissé sans surveillance, le système devient lent, coûteux et instable. Tenez les rênes dès la phase de conception.
Ne passer à l'enfant que ce qui est nécessaire à sa tâche. Ne pas déverser tout l'historique tel quel. Un contexte sans rapport fait aussi baisser la précision.
Résumer les longs résultats en points clés avant de les passer. L'idée : transmettre « conclusion et justification », pas les logs bruts.
Fixer un plafond au nombre d'enfants tournant simultanément. Les multiplier sans limite mène à la rupture par le coût et les limites de débit.
Doser la taille du modèle entre un parent au raisonnement lourd et des enfants aux tâches simples. Ne pas tout mettre sur le modèle le plus haut de gamme.
« Restreindre l'info passée » est particulièrement une décision de conception à fort effet. En orchestrateur + ouvriers, le parent a la vue d'ensemble, mais on ne passe à l'enfant que la tâche découpée et l'entrée minimale. Plus le contexte que porte l'enfant reste petit, plus la précision monte et le coût baisse. Voyez cela comme l'extension à plusieurs agents de l'idée de context engineering évoquée aux chapitres précédents.
⚠️ Le coût pèse en « nombre d'agents × nombre d'étapes ». Ajouter un agent ajoute d'autant d'appels, à raison du nombre de tours de la boucle. Attention : plus le nombre d'agents augmente, plus le gaspillage par agent se démultiplie sur l'ensemble. Fixez dès le départ le plafond de parallélisme et le plafond d'étapes de chaque agent (le moment de s'arrêter). Ce sujet de « mesurer combien on consomme » mène à l'observabilité du chapitre suivant.
Écueils et prévention par la conception
Le multi-agent connaît des échecs propres qui ne survenaient pas en solo. Dans tous les cas, la base est de les prévenir à l'avance par la conception, sans s'en remettre au hasard de l'exécution. Maîtrisons les 3 plus représentatifs et leurs parades.
Plusieurs agents font le même travail en double, ou bien « à qui la charge » est flou et personne ne le fait.
Prévention : découper les responsabilités sans chevauchement ni lacune, jusqu'à pouvoir énoncer chaque frontière en une phrase.
A à B, B à A… ils se repassent le travail sans cesse, sans jamais finir, ou répètent le même échange.
Prévention : mettre impérativement une condition de fin et un plafond d'allers-retours / d'étapes. Confier la décision finale au centre (le parent) limite le dérapage.
L'échec ou la sortie erronée d'un agent s'écoule tel quel vers le suivant, bloquant l'ensemble ou fabriquant un résultat faux.
Prévention : vérifier la sortie avant le passage, et fixer un repli en cas d'échec (nouvel essai, alternative, escalade vers un humain).
La leçon commune aux trois : fixer « frontières, condition de fin, vérification » avant d'écrire du code. Qui prend en charge quoi (frontières), quand cela s'arrête (condition de fin), et quoi vérifier avant de passer (vérification). En tissant ces 3 points dans la conception, on prévient la plupart des ennuis propres au multi-agent.
📊 « On ne corrige que ce qu'on voit ». Ces échecs ne se remarquent que si l'on est en mesure de retracer après coup quel agent a fait quoi. Quand plusieurs agents s'entremêlent, « où et quoi s'est passé » devient encore plus difficile à voir qu'en solo — c'est justement pourquoi l'évaluation et l'observabilité du chapitre suivant comptent d'autant plus en multi-agent.
- Trop entasser dans un seul agent fait baisser la précision. On résout par la coopération de petits agents aux rôles étroitement répartis.
- Trois patrons de base — orchestrateur + ouvriers, pipeline, répartition des rôles. Ils peuvent s'imbriquer.
- On répartit quand parallélisme, expertise ou large exploration sont requis. Si c'est simple, un seul agent. D'abord se demander « un seul suffit-il ? ».
- La coordination se fait par contrats explicites (A2A = règles reliant les agents entre eux). Gérer contexte et coût en restreignant.
- Les pièges propres (chevauchement, renvoi de balle, cascade) se préviennent en fixant d'avance frontières, condition de fin et vérification par la conception.
Une fois plusieurs agents en marche, la nécessité suivante est de « mesurer s'ils fonctionnent vraiment bien, et rendre visible leur comportement ». Au chapitre 5, « Évaluation et observabilité », passons aux méthodes pour mesurer la qualité de l'agent et pouvoir suivre son fonctionnement interne.