Le battage disait : décomposez chaque tâche, lancez des spécialistes, laissez-les collaborer, débattre et synthétiser. Puis les études contrôlées sont arrivées : 260 configurations, sept articles, budgets de calcul appariés. Le verdict est sans appel. La coordination n'aide que sous des conditions structurelles étroites, et l'essentiel de « l'intelligence » n'était qu'un réarrangement redondant de la même information. Voici le bilan, chiffres à l'appui.
« Plus d'agents, plus d'intelligence. »
Pendant deux ans, l'instinct architectural dominant en conception d'agents a été de multiplier. Décomposer la tâche, confier chaque morceau à un agent spécialiste, les laisser collaborer, débattre et synthétiser. L'adoption en entreprise a suivi l'instinct : une plateforme a rapporté une hausse de 327 % de l'usage des workflows multi-agents en quatre mois, sur la base de la télémétrie de plus de 60 % du Fortune 500. Le patron s'est répandu plus vite que quiconque ne l'a validé.
Puis les études contrôlées sont arrivées, et elles sont brutales comme seules les expériences à budget apparié peuvent l'être. Le résultat phare, tiré d'une étude Google Research / MIT couvrant 260 configurations sur six bancs d'essai agentiques et trois familles de modèles, avec des systèmes mono- et multi-agents recevant un calcul total égal : la coordination multi-agents n'aide que sous des conditions structurelles précises, et hors de ces conditions, elle va du neutre au catastrophique. La performance sur les 260 exécutions s'étalait de −70 % à +80,8 % selon la structure de la tâche et la topologie.
La partie « calcul égal » est ce qui rend tout ça crédible. La plupart des affirmations antérieures de supériorité multi-agents comparaient un système multi-agents à un agent seul sans normaliser le total des tokens dépensés. Donnez au système multi-agents l'équivalent de cinq budgets d'agents et, évidemment, il paraît meilleur : il avait cinq fois le budget de réflexion. Un suivi en théorie de l'information l'a dit crûment : beaucoup d'avantages multi-agents rapportés s'expliquent mieux par du calcul non comptabilisé et des effets de contexte que par un quelconque bénéfice architectural inhérent. Quand vous donnez à un agent seul le même budget total que brûle le système multi-agents, l'agent seul l'égale ou le bat souvent.
Cinq topologies, mesurées.
La façon la plus propre de lire les données, c'est par topologie de coordination. Chacune est une variation structurelle sur deux questions : y a-t-il un orchestrateur, et les agents se parlent-ils entre eux? Les chiffres ci-dessous viennent de l'étude à calcul apparié : performance moyenne, amplification des erreurs (à quel point une seule faute se compose) et surcoût en tokens par rapport à une base mono-agent.
| Topologie | Ce que c'est | Amplif. d'erreur | Surcoût en tokens | Verdict |
|---|---|---|---|---|
| Mono-agent | Un seul agent, aucune coordination. La base de référence. | 1,0× | s.o. | Par défaut |
| Centralisée | L'orchestrateur décompose, assigne, synthétise. Goulot de vérification. | 4,4× | Conditionnel | |
| Décentralisée | Débat entre pairs tous-à-tous, rondes d'échange vers un consensus. | 7,8× | Étroit | |
| Hybride | Orchestrateur + communication entre pairs. La plus flexible, la plus chère. | 5,1× | Rarement | |
| Indépendante | Agents en parallèle, aucune communication, sorties fusionnées. Les erreurs se dupliquent sans correction. | 17,2× | À éviter |
Deux choses sautent aux yeux. D'abord, la topologie multi-agents la moins chère est aussi la plus dangereuse. Le MAS indépendant n'ajoute « que » 58 % de surcoût en tokens, mais sans orchestrateur pour attraper les fautes, l'erreur d'un seul agent se duplique à travers la flotte et s'amplifie par 17,2×. C'est le pire performeur moyen de l'étude. La chose vers laquelle les équipes se tournent en premier parce qu'elle est simple est celle que les données disent d'éviter.
Ensuite, l'orchestrateur gagne sa place comme goulot de vérification, pas comme coordonnateur. Le MAS centralisé contient l'amplification des erreurs à 4,4× précisément parce qu'un seul agent révise tout avant que ça se propage. Mais ce confinement coûte 285 % en tokens. Vous payez près de 3× le calcul pour vous acheter un vérificateur. Que ça en vaille la peine dépend entièrement de la tâche.
Décomposabilité, pas complexité.
Le constat le plus utile de toute la littérature, c'est ce qui sépare les tâches où le multi-agents gagne de celles où il s'effondre. Ce n'est pas la difficulté. Deux bancs d'essai de l'étude avaient des scores de complexité de domaine presque identiques (0,41 et 0,42) et ont produit des résultats opposés. L'un a gagné +80,8 % grâce à la coordination. L'autre a perdu jusqu'à 70 %.
La règle qui en découle : la coordination multi-agents ne paie que lorsque la tâche se décompose naturellement en sous-tâches indépendantes. Si le travail est une chaîne séquentielle où chaque étape a besoin de la sortie de la précédente, le répartir entre agents introduit un surcoût de coordination qui fragmente ce qui devrait être une seule trajectoire propre. La modularité conceptuelle ne suffit pas non plus : si chaque sous-agent a encore besoin de l'essentiel du même contexte et que l'étape de synthèse coûte cher, vous avez modularisé le diagramme sans paralléliser le travail.
C'est la même leçon que notre note sur pourquoi nous avons arrêté les orchestrateurs custom, qui arrive d'une autre direction. Là-bas, l'argument était que construire un runtime sur mesure échange du contrôle contre de la surface de maintenance. Ici, l'argument est qu'ajouter des agents échange une trajectoire propre contre de la surface de coordination. Les deux sont des versions d'un même principe : la complexité que vous ajoutez à l'architecture doit mériter sa place face à une base simple et solide, et elle n'y arrive habituellement pas.
Ce que coûte un seul point de précision.
Même là où le multi-agents gagne en précision, la victoire a un prix, et le prix est souvent toute l'histoire. Les gains aux bancs d'essai doivent franchir une barre économique, et la barre est haute.
Ce gain de 2,1 points à environ 2× le coût est la forme récurrente dans la littérature, et ça empire avec le temps, ça ne s'améliore pas. Une implication à long terme contre-intuitive se cache dans les données : à mesure que les modèles de pointe s'améliorent, la barre pour que le multi-agents ajoute de la valeur monte. La coordination donne des rendements décroissants dès qu'une base mono-agent dépasse environ 45 % sur ces bancs d'essai. Au-dessus de ce seuil, le modèle est déjà assez capable pour que le surcoût de coordination dépasse le bénéfice. Chaque nouvelle version de modèle pousse plus de tâches au-dessus de la ligne où ajouter des agents cesse d'aider.
Et le coût en tokens n'est que la partie visible. Les systèmes multi-agents élargissent la surface de débogage d'une façon facile à sous-estimer. Quand une sortie est fausse, vous devez reconstituer quel agent a vu quel état, quel transfert a introduit l'erreur, et si l'échec vient du raisonnement, du routage ou d'un instantané de contexte périmé. La coordination devient un problème de systèmes distribués (synchronisation, fidélité des transferts, rejouabilité) par-dessus le problème de raisonnement. Ça se rattache directement à notre note sur le coût comme métrique prioritaire : chaque agent qui coordonne, ce sont des étapes de plus sur la trace, et le surcoût d'orchestration est exactement le genre de dépense invisible que la trace de coûts existe pour faire remonter.
Trois principes qui ont tenu d'une famille à l'autre.
L'étude a extrait trois principes d'échelle constants à travers les familles de modèles OpenAI, Google et Anthropic : coefficient de variation sous 0,02, ce qui veut dire que ce sont des faits structurels sur la coordination, pas des bizarreries d'un seul modèle.
Ce n'est pas un seul article.
Une seule étude, aussi bien contrôlée soit-elle, est un point de donnée. Ce qui en fait un bilan plutôt qu'un résultat, c'est que six efforts de recherche indépendants ont atteint des conclusions complémentaires dans la même fenêtre. La convergence, c'est le signal.
Lus ensemble, le patron est sans ambiguïté : les bénéfices multi-agents sont hautement conditionnels, la normalisation du calcul est essentielle à une évaluation honnête, l'architecture compte plus que le nombre d'agents, et les bases mono-agents sont plus fortes que le battage le supposait. Le constat sur le débat est celui qui pique le plus. Toute la justification des architectures de revue multi-agents était la vérification indépendante, et les données disent que les agents se contentent surtout d'être d'accord entre eux.
La règle de décision qui reste.
Rien de tout ça ne veut dire que le multi-agents est mort. Ça veut dire que le défaut a basculé. La règle de production de 2026 : partez d'un agent seul solide, et faites en sorte que l'architecture mérite chaque agent ajouté. « Agent seul solide » porte tout le poids. Ça veut dire usage des outils optimisé, bon retrieval et bonne ingénierie de contexte, mise en cache, boucle de vérification locale et routage par compétences déjà en place avant d'aller chercher un deuxième agent.
La migration par phases que la littérature recommande est exactement la discipline que la note sur les orchestrateurs custom défendait pour les runtimes : établir une base mono-agent, piloter le multi-agents sur votre seul workflow au meilleur ROI, mesurer le coût marginal contre la précision marginale, et n'étendre que si la valeur franchit clairement le coût. L'échec courant, c'est d'adopter le multi-agents à l'échelle de l'organisation avant d'avoir validé qu'il aide sur ne serait-ce qu'un workflow.
Si vous fixez un diagramme multi-agents en vous demandant s'il devrait être une seule boîte, le formulaire de contact est la voie la plus rapide. Nous faisons des revues de 30 minutes pour les piles d'agents en production, gratuitement.