Multi-agents ou agent unique ? Le benchmark qui change (vraiment) les architectures IA en entreprise

Le chiffre qui a fait basculer les DSI

90,2 %. C'est l'écart de performance mesuré par Anthropic entre son système multi-agents (un orchestrateur qui pilote des sous-agents) et un agent unique Claude Opus 4, sur une évaluation interne de recherche complexe. Le chiffre est publié, daté du 13 juin 2025, et il circule dans toutes les directions techniques.

Ce n'est pas un benchmark marketing. C'est un retour d'ingénierie, avec sa contrepartie assumée : environ 15 fois plus de tokens consommés qu'un chat classique. Autrement dit, le multi-agents gagne, mais il coûte.

Gartner a déjà rangé le sujet dans les tendances stratégiques

Le 21 octobre 2024, Gartner a classé les systèmes multi-agents parmi les dix tendances technologiques stratégiques pour 2025, aux côtés de l'IA agentique. Gene Alvarez, Distinguished VP Analyst chez Gartner, y voit l'un des mouvements majeurs de l'année.

Derrière la tendance, des projections qui parlent aux comités d'investissement : d'ici 2028, 33 % des applications d'entreprise incluront de l'IA agentique (contre moins de 1 % en 2024), et au moins 15 % des décisions de travail quotidiennes seront prises de manière autonome par des agents IA.

Ce que « multi-agents » veut dire concrètement

Un agent unique, c'est un modèle qui reçoit une demande, réfléchit, agit, répond. Un système multi-agents, c'est un orchestrateur qui découpe la demande, confie chaque sous-tâche à un agent spécialisé, récupère les résultats et les assemble.

McKinsey décrit cette architecture comme une évolution clé de l'IA générative en entreprise : plusieurs agents spécialisés collaborent sur des workflows complexes, là où un agent seul sature.

La différence n'est pas cosmétique. Elle change la façon dont on conçoit un processus métier.

Pourquoi les éditeurs ont déjà tranché (pour eux)

Microsoft a introduit des patterns multi-agents dans AutoGen (group chat, orchestration) et pousse les agents dans Microsoft 365 Copilot via Copilot Studio. Google Cloud a lancé Agent Development Kit et Agent Engine pour orchestrer des agents en entreprise. SAP intègre Joule dans ses processus métier avec une orchestration multi-agents entre applications SAP et non-SAP. Salesforce a bâti Agentforce autour d'agents autonomes orchestrés. IBM travaille l'orchestration et la gouvernance via watsonx.

Le message est clair : les plateformes d'entreprise ne vendent plus un agent, elles vendent une couche d'orchestration. Le choix d'architecture devient un choix de plateforme.

Le benchmark ne dit pas « multi-agents partout »

C'est là que la lecture rapide se trompe. Anthropic est explicite : le multi-agents est rentable pour des tâches à haute valeur, pas pour tout. Les 15 fois plus de tokens rendent l'arbitrage économique incontournable.

LangChain documente la même réalité sous un autre angle : complexité accrue, besoins d'observabilité renforcés, debugging plus difficile. Un système multi-agents, c'est plus de pièces mobiles, donc plus de points de défaillance.

La conclusion opérationnelle tient en une phrase : agent unique pour les tâches simples et déterministes, multi-agents pour les tâches complexes et ouvertes.

Les trois questions à poser avant de choisir

• Quelle est la valeur unitaire de la tâche ? Si le coût en tokens dépasse le gain métier, l'architecture multi-agents n'a pas de sens.
• Quel niveau de traçabilité exige le métier ? Un système multi-agents doit être observable, sinon il devient inauditable.
• Quel cadre de gouvernance s'applique ? L'AI Act européen (Règlement UE 2024/1689, publié le 12 juillet 2024) et le NIST AI RMF Generative AI Profile (AI 600-1, juillet 2024) imposent transparence et gestion des risques sur les systèmes autonomes.

La citation qui résume l'arbitrage

« Les systèmes multi-agents surpassent un agent unique sur des tâches de recherche complexe, mais à un coût en tokens significativement plus élevé (~15x). » — Anthropic Engineering, « How we built our multi-agent research system », 13 juin 2025.

Cette phrase est le cœur du sujet. Elle ne dit pas « faites du multi-agents ». Elle dit « faites-le là où ça vaut le coup ».

Ce que ça change pour un dirigeant

Le débat n'est plus technique. Il est budgétaire et organisationnel. Un projet agentique mal cadré peut consommer 15 fois plus de tokens que prévu, sans que la valeur métier suive.

À l'inverse, un agent unique bien conçu reste la bonne réponse pour 70 à 80 % des cas d'usage simples : qualification, extraction, réponse standard, routage. Le multi-agents se justifie quand la tâche est ouverte, longue, et que l'erreur coûte cher.

La vraie compétence qui émerge en DSI n'est donc pas « savoir faire un agent ». C'est « savoir arbitrer une architecture ».

Le piège de la course à l'orchestration

Les frameworks se multiplient : AutoGen chez Microsoft, ADK chez Google, Agents SDK chez OpenAI (mars 2025), LangGraph chez LangChain. Chacun promet l'orchestration clé en main.

Mais un framework ne remplace pas une décision d'architecture. Il l'accélère — dans le bon ou le mauvais sens. Sans gouvernance, un système multi-agents devient une boîte noire distribuée, difficile à auditer et à corriger.

Le Stanford AI Index 2025 documente d'ailleurs l'essor des benchmarks agentiques : la mesure progresse, mais elle reste jeune. Se fier à un seul chiffre serait une erreur de dirigeant.

Notre position

Le multi-agents n'est pas la prochaine étape naturelle de tout projet IA. C'est une réponse à un problème précis : des workflows complexes, ouverts, à forte valeur, que l'agent unique ne peut pas traiter seul.

Pour tout le reste, l'agent unique reste plus simple, moins cher, plus traçable. Le benchmark d'Anthropic ne dit pas le contraire : il donne le chiffre qui permet de trancher au cas par cas.

La bonne question n'est donc pas « multi-agents ou agent unique ? ». C'est « quel processus, quelle valeur, quel risque, quel coût ? ». Une fois ces quatre réponses posées, l'architecture se déduit.