Systèmes multi-agents : quand plusieurs agents valent mieux qu'un

Un agent, plusieurs agents : de quoi parle-t-on

Un agent IA autonome tourne seul, avec ses propres outils, sa mémoire et son objectif. Un système multi-agents, lui, met plusieurs agents au travail sur la même tâche, chacun avec un rôle précis. L'idée n'est pas nouvelle en informatique distribuée, mais elle prend un sens concret depuis que les modèles de langage savent utiliser des outils et enchaîner des étapes sans supervision constante.

Le terme recouvre des réalités différentes. Il y a le système "orchestrateur plus sous-agents", où un agent principal découpe le travail et délègue des morceaux à des agents plus spécialisés. Il y a aussi des agents pairs, qui communiquent entre eux pour partager des résultats sans hiérarchie stricte. La nuance à retenir, c'est que "plusieurs agents" ne veut pas dire "plusieurs instances identiques qui font la même chose en parallèle" : chaque agent a un périmètre. Le glossaire d'Atako détaille cette distinction plus en profondeur.

Le principe d'orchestration

Ce qui distingue un vrai système multi-agents d'un simple lot de scripts qui tournent en parallèle, c'est l'orchestration : la logique qui décide qui fait quoi, dans quel ordre, et comment les résultats se recombinent. Anthropic a documenté en détail l'architecture qu'elle utilise pour sa fonction de recherche approfondie : un agent "lead" analyse la demande, définit une stratégie, puis crée des sous-agents chargés d'explorer chacun une piste en parallèle avant de faire remonter leurs résultats (source : Anthropic, "How we built our multi-agent research system", https://www.anthropic.com/engineering/multi-agent-research-system, consulté le 2026-09-04).

Ce modèle orchestrateur/travailleurs revient dans presque toutes les implémentations sérieuses. L'agent principal ne fait pas le travail lui-même : il planifie, distribue, vérifie, et assemble. C'est ce qu'on appelle l'orchestration d'agents. Le sous-agent, de son côté, est pensé pour être court et jetable : il existe le temps d'une sous-tâche, puis disparaît.

Pourquoi plusieurs agents font parfois mieux qu'un seul

Le résultat le plus cité sur le sujet vient justement d'Anthropic. Sur son évaluation interne, un système composé d'un agent Opus en chef d'orchestre et de sous-agents Sonnet a dépassé de 90,2 % les performances d'un agent Opus seul sur les mêmes tâches de recherche (même source que ci-dessus). L'explication tient en un mot : la parallélisation. Un agent seul explore les pistes une par une, dans une seule fenêtre de contexte qui finit par saturer. Plusieurs agents peuvent explorer plusieurs pistes en même temps, chacun dans son propre contexte, avant de recombiner ce qu'ils ont trouvé.

Cet avantage n'est pas universel. Il se manifeste surtout sur des tâches "en largeur" : recherche documentaire, exploration de plusieurs hypothèses, traitement d'un grand volume d'informations disjointes. LangChain, dans un article de référence sur le sujet, résume bien la condition : les systèmes multi-agents excellent sur les tâches à forte valeur qui se parallélisent bien, et perdent leur intérêt dès que le travail est fortement séquentiel ou dépendant d'un contexte partagé (source : LangChain, "How and when to build multi-agent systems", https://www.langchain.com/blog/how-and-when-to-build-multi-agent-systems, consulté le 2026-09-04).

Anthropic est allé jusqu'à décomposer statistiquement ce qui explique les écarts de performance entre configurations. Trois facteurs expliquent à eux seuls 95 % de la variance observée : la quantité de tokens utilisée, le nombre d'appels d'outils effectués, et le choix du modèle. L'usage de tokens, à lui seul, explique 80 % de cette variance (même source). Autrement dit, ce n'est pas "avoir plusieurs agents" qui fait gagner en performance, c'est la capacité que ça donne à consommer plus de calcul en parallèle sur un problème qui s'y prête. Sur un problème qui ne s'y prête pas, cette même capacité ne sert à rien, elle coûte simplement plus cher pour un résultat comparable à un agent seul.

Le prix de la coordination

Ce gain de performance a un coût, et il est loin d'être marginal. Selon Anthropic, un agent seul consomme déjà environ 4 fois plus de tokens qu'une conversation de chat classique. Un système multi-agents, lui, en consomme environ 15 fois plus (même source). Ce n'est pas un détail comptable : à ce niveau de multiplication, seules les tâches dont la valeur métier est réellement élevée justifient l'investissement.

Le coût de coordination ne se limite pas aux tokens. LangChain pointe un problème plus structurel : les écritures concurrentes posent bien plus de problèmes que les lectures concurrentes. Deux agents qui lisent la même base de données en parallèle, ce n'est pas grave. Deux agents qui modifient le même document, le même ticket ou la même ligne de code en même temps, ça produit des conflits qu'il faut ensuite réconcilier, souvent à la main. Plus il y a d'agents, plus la surface de défaillance augmente : chaque agent supplémentaire ajoute une couche d'état partagé, un protocole de communication, et un nouveau point où le système peut planter sans que personne ne comprenne pourquoi tout de suite.

Il faut aussi compter le coût de debug. Suivre le raisonnement d'un seul agent, avec sa timeline d'actions, est déjà un travail en soi. Suivre l'enchaînement de décisions entre plusieurs agents qui se répartissent une tâche, avec leurs échanges de messages et leurs éventuelles divergences, demande une observabilité bien plus poussée. C'est un chantier à part entière.

Quand ne pas se lancer dans le multi-agent

Le réflexe "plus d'agents, plus de puissance" est une des façons les plus sûres de faire exploser un budget IA sans gain proportionnel. Gartner l'a chiffré durement : le cabinet prévoit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, notamment à cause de coûts qui dérapent, d'une valeur métier mal définie et de contrôles de risque insuffisants (source : Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027, consulté le 2026-09-04). Une bonne partie de ces échecs vient de projets qui ajoutent de la complexité d'orchestration sans que la tâche le justifie.

Concrètement, mieux vaut rester sur un seul agent quand la tâche tient dans une seule fenêtre de contexte, quand elle est fortement séquentielle (chaque étape dépend strictement de la précédente), ou quand le volume de travail ne justifie pas la facture en tokens. LangChain cite justement le codage comme exemple : contrairement à la recherche, une tâche de développement contient rarement du vrai travail parallélisable, ce qui rend le multi-agent moins pertinent qu'on ne le pense pour ce cas d'usage précis.

La bonne question à se poser avant d'ajouter un deuxième agent n'est donc pas "est-ce que ça peut aider ?", c'est "est-ce que cette tâche a une vraie ligne de séparation naturelle ?". Si une partie du travail a besoin d'un accès fichiers, une autre d'un accès base de données, et une troisième d'un appel à une API externe, il y a un vrai découpage possible. Si tout dépend du même fil de raisonnement, ajouter des agents ajoute surtout de la friction.

Une check-list simple avant de se lancer : la tâche génère-t-elle plusieurs pistes indépendantes à explorer en parallèle ? Le volume de travail justifie-t-il une facture en tokens plusieurs fois supérieure ? Les sous-tâches écrivent-elles dans des systèmes différents, ou risquent-elles de se marcher dessus sur la même donnée ? Si la réponse est non à l'une de ces trois questions, un seul agent bien outillé, avec de bons accès et des instructions claires, ira probablement plus vite et coûtera moins cher qu'une architecture à plusieurs agents.

Ce qu'Atako change concrètement

Chez Atako, cette logique orchestrateur/sous-agents existe nativement : un agent peut déléguer une sous-tâche complexe à un sous-agent éphémère, dont le travail remonte comme des étapes dans la timeline d'activité de l'agent principal, sans consommer de slot supplémentaire. Ça évite l'écueil le plus courant : multiplier les agents "pleins" (et leur coût) alors qu'un simple sous-agent temporaire suffirait. Si vous voulez creuser le sujet du côté budget, l'article suivant détaille les postes de coût réels d'un agent IA en entreprise, et celui sur la mesure du ROI vous aidera à vérifier, une fois en place, si l'investissement en valait la peine.