Multi-agents : quand c'est utile, quand c'est de la complexité gratuite

En 2026, construire un système IA, c'est souvent construire plusieurs agents. Un orchestrateur, des sous-agents spécialisés, un agent de validation, un agent de mémoire. Les frameworks ont des noms qui vendent du rêve : CrewAI, AutoGen, LangGraph, Google ADK. Les démos montrent cinq agents qui collaborent sur un problème complexe et produisent un résultat impeccable en quelques secondes.

Le problème : la réalité de production ressemble rarement à la démo. Les équipes qui ont déployé des systèmes multi-agents en 2024-2025 reviennent avec des retours nuancés. Coût en tokens trois à dix fois supérieur à ce qui était budgété. Latence qui rend le système inutilisable pour les utilisateurs finaux. Debugging qui prend deux fois plus de temps parce qu'on ne sait plus dans quel agent la dérive a commencé. Et des cas où un agent unique bien prompté aurait fait exactement le même travail.

Cet article part d'une question simple : quand un système multi-agents apporte-t-il une valeur réelle, et quand est-il de la complexité ajoutée sans bénéfice mesurable ? On donne les critères concrets, on démonte quelques mythes, et on propose un arbre de décision qu'on applique nous-mêmes en mission.

Pourquoi le hype multi-agents existe (et pourquoi il est partiellement justifié)

Il y a deux limitations réelles des agents LLM qui ont rendu les architectures multi-agents attractives.

La première est la fenêtre de contexte. Même avec des contextes de 200 000 tokens aujourd'hui, certaines tâches dépassent naturellement ce qu'un seul agent peut tenir en mémoire active : analyser des milliers de documents, parcourir un code source d'un million de lignes, agréger des recherches web sur cent sources en parallèle. Distribuer ce travail entre plusieurs agents avec des contextes distincts est une solution légitime à ce problème structurel.

La deuxième est la parallélisation. Certains problèmes ont des sous-tâches indépendantes qu'on peut exécuter en même temps. Si vous avez cinq marchés à analyser et que chaque analyse est indépendante des autres, cinq agents parallèles terminent cinq fois plus vite. C'est du bon sens d'ingénierie.

C'est là que s'arrête la justification solide. Le reste est souvent du hype ou de la sur-ingénierie.

Ce que la recherche dit vraiment

En décembre 2025, des chercheurs de Google et du MIT ont publié Towards a Science of Scaling Agent Systems, la première tentative sérieuse de dériver des lois d'échelle quantitatives pour les systèmes d'agents. Ils ont mené 180 expériences contrôlées sur quatre benchmarks agentiques (Finance, BrowseComp, PlanCraft, Workbench) avec trois familles de modèles (OpenAI, Google, Anthropic).

La conclusion principale : la coordination multi-agents n'améliore pas systématiquement les résultats et peut les dégrader. Le papier quantifie quatre effets empiriques, à savoir l'efficacité de coordination, l'overhead, l'amplification d'erreurs et la redondance. Leur modèle prédit la meilleure architecture pour environ 87% des configurations de tâches, avec un R² de 0,513. La variable clé est ce qu'ils appellent le "tool-coordination tradeoff" : plus une tâche nécessite d'outils nombreux et variés, plus la coordination entre agents devient un frein plutôt qu'un accélérateur. Google a commenté ces résultats dans un billet de recherche dédié qui souligne que "l'ajout d'agents ne produit pas d'amélioration monotone des performances".

Anthropic a documenté un constat similaire dans son guide Building Effective Agents : les systèmes multi-agents consomment environ 15 fois plus de tokens que les interactions single-agent standard. Ce n'est pas un détail de facturation : c'est la conséquence directe de la façon dont l'orchestration fonctionne. Chaque appel d'agent dans une chaîne transporte l'historique de la conversation jusqu'à ce point. Un débat de quatre agents sur cinq tours représente au minimum vingt appels LLM complets, avec des contextes qui grossissent à chaque étape.

La recommandation d'Anthropic est directe : trouver toujours la solution la plus simple possible. Un agent unique bien outillé est le point de départ par défaut. On monte en complexité uniquement quand une contrainte réelle l'exige.

Les trois situations où le multi-agent est justifié

1. Parallélisation de sous-tâches véritablement indépendantes

C'est le cas le plus solide. Vous avez un problème décomposable en N sous-problèmes qui n'ont pas besoin de se parler pour avancer. Chaque sous-agent fait son travail en parallèle, un orchestrateur agrège les résultats.

Exemples concrets : analyse parallèle de plusieurs marchés ou segments, veille sur plusieurs sources d'information simultanément, génération de variantes de contenu, tests de régression LLM distribués. Dans ces cas, le gain de latence est réel et le coût supplémentaire est justifié.

Le critère de test : si les sous-tâches ont besoin de se passer des résultats intermédiaires les unes aux autres, elles ne sont pas vraiment indépendantes. Si elles peuvent s'exécuter dans n'importe quel ordre sans que le résultat change, elles le sont.

2. Dépassement de la fenêtre de contexte sur des tâches de traitement intensif

Pour une tâche qui demande à l'agent de traiter un volume de données qui dépasse ce qu'un seul contexte peut tenir, la distribution sur plusieurs agents avec des contextes distincts est la seule option. Un agent qui indexe et résume cent rapports de quarante pages, un autre qui synthétise les résumés : c'est une architecture raisonnée.

À distinguer des cas où la fenêtre de contexte est confortable et où on pourrait tout faire en un seul appel. Dans ce cas, la distribution est de la sur-ingénierie.

3. Isolation réglementaire ou de sécurité

Dans certains contextes, deux niveaux de confiance différents ne peuvent pas partager le même contexte d'exécution. Un agent qui traite des données sensibles et un agent qui communique avec un système externe doivent être physiquement séparés pour des raisons de conformité (RGPD, AI Act haut risque, secteur financier). Ce n'est pas une décision architecturale IA : c'est une contrainte réglementaire qui impose la séparation.

Hors de ces trois cas, la présomption devrait être en faveur d'un agent unique bien conçu.

Les cinq pièges où le multi-agent est de la complexité gratuite

Piège 1 : la spécialisation qui ne spécialise rien

Le pattern CrewAI classique : un agent "Chercheur", un agent "Analyste", un agent "Rédacteur". Trois rôles bien nommés, trois prompts distincts... mais si les trois agents utilisent le même modèle de base et les mêmes outils, la spécialisation est cosmétique. Le "Chercheur" ne cherche pas mieux qu'un seul agent avec un bon prompt de recherche. La structure existe pour la démo, pas pour la performance.

La vraie spécialisation a lieu quand chaque agent a un accès outillage différent (base de données distincte, API propriétaire, modèle fine-tuné pour son domaine) ou quand il a besoin d'un contexte radicalement différent incompatible avec les autres.

Piège 2 : les tâches séquentielles déguisées en pipelines

Un pipeline où l'agent B attend systématiquement l'agent A avant de commencer, qui attend lui-même l'agent C, n'est pas du parallélisme. C'est un workflow séquentiel avec une complexité de coordination supplémentaire. La latence totale est la somme des latences individuelles plus les overhead d'orchestration, soit pire qu'un seul agent qui ferait le tout.

Reconnaître ce pattern : si votre graphe d'agents n'a aucune branche parallèle, c'est un pipeline séquentiel. Un seul agent avec plusieurs étapes dans son prompt est plus simple, plus rapide et plus facile à débuguer.

Piège 3 : le debugging opaque et la dérive invisible

Dans un système multi-agents, quand la sortie finale est mauvaise, localiser la cause est un problème en soi. L'agent A a-t-il mal compris la tâche ? L'agent B a-t-il reçu un contexte tronqué ? L'orchestrateur a-t-il mal agrégé ? La dérive peut s'amplifier à chaque étape de manière invisible. Le papier Google/MIT mesure précisément cet "error amplification" dans les architectures décentralisées, où les erreurs se propagent et s'amplifient d'un agent à l'autre.

Un seul agent avec des logs structurés est auditable. Une chaîne de cinq agents nécessite une instrumentation explicite à chaque noeud pour être débuggable. C'est faisable, mais c'est du travail supplémentaire qui n'est pas gratuit.

Piège 4 : le coût qui explose en production

Environ 18% d'overhead de tokens pour une crew CrewAI basique sur des tâches bien définies, 200% ou plus pour des systèmes AutoGen conversationnels avec beaucoup de tours de débat. Pour un usage interne à faible volume, c'est gérable. Pour un agent qui répond à des milliers de requêtes par jour, la différence de coût entre un agent optimisé et une crew à cinq agents peut représenter plusieurs dizaines de milliers d'euros par an.

L'évaluation économique doit être faite avant l'architecture, pas après.

Piège 5 : la latence qui brise l'expérience utilisateur

Les appels LLM prennent deux à six secondes en moyenne selon le modèle et la longueur du contexte. Une chaîne de cinq agents séquentiels cumule dix à trente secondes. Pour un outil interne utilisé par des experts qui attendent une réponse profonde, c'est acceptable. Pour un assistant utilisateur en temps réel, c'est rédhibitoire. Les systèmes single-agent répondent 30 à 50% plus vite dans les configurations comparables.

CrewAI et AutoGen : ce qu'ils font bien, ce qu'ils cachent mal

CrewAI et AutoGen sont les deux frameworks multi-agents les plus répandus en 2025-2026. Ils ont du mérite, mais ils vendent aussi une abstraction qui peut masquer les problèmes sous-jacents.

CrewAI a un vrai point fort : le time-to-prototype. En moins de deux heures, vous avez une crew fonctionnelle avec des rôles bien définis, un orchestrateur, des outils. C'est utile pour valider rapidement si le paradigme multi-agents apporte quelque chose sur votre use case. Le problème : si la démo fonctionne mais que les benchmarks de tokens explosent, la migration vers une architecture plus sobre est coûteuse parce que la logique métier est encapsulée dans les abstractions CrewAI.

AutoGen est plus flexible et plus puissant pour les cas conversationnels complexes, à savoir les feedback loops et les débats multi-agents. La contrepartie est un overhead opérationnel élevé : l'instabilité des APIs a affecté environ 20% des bases de code legacy lors des mises à jour 2025, et le coût moyen par requête documenté sur des projets de production tourne autour de 0,35 dollar pour des conversations à plusieurs tours, ce qui exclut l'usage à fort volume.

LangGraph, moins dans le hype mais plus mature, reste l'option la plus recommandable pour les équipes qui veulent du contrôle : graphe d'états explicite, debugging clair, pas d'abstraction qui masque les appels LLM.

L'arbre de décision opérationnel

Avant de construire un système multi-agents, répondre à ces six questions dans l'ordre.

Question 1 : le problème peut-il être résolu par un seul agent bien outillé et bien prompté ? Si oui, commencer par là. Ajouter des agents plus tard si une contrainte concrète l'exige.

Question 2 : y a-t-il des sous-tâches vraiment indépendantes et parallélisables ? Si non : rester sur un agent unique avec un workflow séquentiel. Si oui : passer à la question 3.

Question 3 : le gain de latence ou de débit justifie-t-il le surcoût en tokens et en maintenance ? Calculer le coût en tokens du scénario multi-agents contre le scénario single-agent sur un volume représentatif d'un mois. Si le différentiel annuel dépasse le bénéfice métier mesurable, réexaminer.

Question 4 : la fenêtre de contexte est-elle le facteur limitant ? Si oui et que les sous-tâches peuvent tenir dans des contextes distincts : architecture multi-agents justifiée. Sinon : une seule fenêtre suffit.

Question 5 : y a-t-il une contrainte réglementaire qui impose la séparation des contextes ? Si oui : l'architecture est imposée, non choisie.

Question 6 : votre équipe a-t-elle l'instrumentation pour débuguer et monitorer plusieurs agents en prod ? Si non : la complexité opérationnelle risque de bloquer le projet. Investir d'abord dans l'observabilité, ou rester sur un agent unique instrumenté.

Ce qu'on fait en mission chez GettIA

Quand un client arrive avec un brief "on veut du multi-agents", notre première réponse n'est jamais "d'accord, on code". C'est "montrez-nous le use case en détail et on vérifie ensemble si c'est la bonne réponse".

Sur les projets menés en 2025-2026, environ un tiers des cas où le client demandait du multi-agents ne l'exigeait pas. Un agent bien outillé avec un prompt structuré et quelques outils métier répondait exactement au besoin, avec moins de latence, un coût prévisible et un debugging trivial.

Les deux tiers restants justifiaient effectivement une architecture distribuée : traitement parallèle de sources hétérogènes, agents spécialisés avec des bases RAG distinctes par domaine métier, séparation entre un agent de collecte et un agent d'action pour des raisons de traçabilité.

Notre process est systématique : preuve de concept en single-agent d'abord, benchmark de la qualité de sortie sur un jeu de cas représentatifs, évaluation du coût à l'échelle, identification des sous-tâches qui bénéficieraient vraiment d'un agent distinct. Si après ce test le multi-agents apporte un gain mesurable sur au moins un des trois axes (qualité, latence, coût), on valide l'architecture. Sinon, on simplifie.