Systèmes multi-agents IA : comment des agents spécialisés collaborent

Un système multi-agents est un ensemble d'agents IA qui collaborent pour atteindre un objectif, en se répartissant le travail, en échangeant des informations et en se coordonnant selon une architecture explicite. Après des années d'expérimentations éparpillées, le sujet est en train de trouver son vocabulaire commun : Anthropic a publié cinq motifs de workflow canoniques, LangChain formalise quatre architectures multi-agent, et des protocoles comme Agent2Agent (A2A) de Google émergent pour standardiser la communication entre agents de fournisseurs différents.

Cet article synthétise les architectures multi-agents reconnues, explique quand elles sont justifiées pour une PME, et quand elles ne le sont pas. C'est le prolongement de notre article sur les sous-agents ; lisez d'abord la définition de l'agent IA si le sujet est nouveau pour vous.

TL;DR

• Un système multi-agents, c'est plusieurs agents qui collaborent selon une architecture explicite.
• Anthropic identifie 5 motifs de workflow (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer).
• LangChain en identifie 4 architectures multi-agent (subagents, skills, handoffs, router).
• Pour les PME : 90 % des cas se résolvent avec un agent unique. Le multi-agent n'a de sens que sur des cas complexes et volumineux.
• La règle d'or d'Anthropic : *"find the simplest solution possible, and only increase complexity when needed."*

D'abord : workflow vs système multi-agent

Anthropic fait une distinction que beaucoup de vendeurs brouillent. Il y a deux familles :

• Les workflows : des chemins prédéfinis orchestrant des appels de LLM et des outils. Le développeur code la séquence. Prévisibles, faciles à déboguer.
• Les agents vrais : des LLM qui dirigent dynamiquement leur propre processus et leurs outils, en décidant au fil de l'eau de la prochaine action. Autonomes mais moins prévisibles.

Un "système multi-agent" peut être soit l'un, soit l'autre. Beaucoup de ce qu'on vend comme "multi-agent" est en réalité un workflow à plusieurs étapes, codé. Ce n'est pas un défaut — c'est souvent plus fiable — mais il faut savoir de quoi on parle.

Les 5 motifs de workflow (Anthropic)

Anthropic, dans son article *Building Effective Agents*, a posé le vocabulaire de référence pour orchestrer plusieurs appels de LLM. Les voici, avec leur usage PME.

1. Prompt chaining (enchaînement séquentiel)

Le LLM est décomposé en une séquence d'étapes où chaque appel traite la sortie du précédent, avec éventuellement des étapes de contrôle (vérification, gate).

• Exemple : génération d'un document — 1) produire le plan, 2) vérifier le plan contre des critères, 3) rédiger selon le plan validé.
• Idéal pour : tâches décomposables en étapes fixes, où chaque étape est plus simple que l'ensemble.
• Pour les PME : génération de contenu structuré, onboarding multi-étapes, génération de devis.

2. Routing (aiguillage)

Un classifieur dirige l'entrée vers un handler spécialisé. Sépare les préoccupations et permet des prompts ciblés.

• Exemple : le service support route vers "questions techniques" vs "facturation" vs "litiges", chacun avec son propre prompt et ses outils.
• Idéal pour : catégories distinctes qui se traitent mieux séparément.
• Pour les PME : tri de tickets, catégorisation de leads, dispatch support.

3. Parallelization (parallélisation)

Plusieurs appels de LLM tournent en parallèle pour le même input, puis les résultats sont agrégés (sectioning) ou votés (voting).

• Exemple : un agent qui analyse plusieurs parties d'un document en parallèle puis synthétise ; ou plusieurs revues d'un même output qui votent.
• Idéal pour : gains de vitesse, ou robustesse par consensus.
• Pour les PME : reporting multi-sources, revues de qualité multiples.

4. Orchestrator-workers (orchestrateur/travailleurs)

Un LLM central décompose dynamiquement la tâche, l'assigne à des workers, et synthétise leurs résultats. C'est le motif subagents détaillé dans notre article dédié.

• Exemple : un agent qui doit modifier du code dans plusieurs fichiers — l'orchestrateur décide quels fichiers, les workers font les changements ciblés.
• Idéal pour : tâches non prévisibles à l'avance, où la répartition ne peut pas être codée en dur.
• Pour les PME : tâches de recherche, modifications distribuées, projets complexes.

5. Evaluator-optimizer (évaluateur-optimiseur)

Un LLM génère, un autre évalue et renvoie un feedback, en boucle jusqu'à satisfaction.

• Exemple : rédaction d'un document avec boucle de relecture, où le critique identifie les faiblesses et l'auteur itère.
• Idéal pour : valeur claire à l'évaluation, itérations significatives, tâches de raffinage.
• Pour les PME : rédaction commerciale itérative, traduction avec QA, génération avec contrôle qualité.

Le tableau de synthèse d'Anthropic

Les 4 architectures multi-agent (LangChain)

Au-delà des workflows, LangChain formalise les architectures multi-agent quand on passe à l'échelle. Ce sont les mêmes familles que nous avons détaillées dans Sous-agents IA :

1. Subagents : orchestrateur + travailleurs, sans état. Idéal multi-domaines.
2. Skills : un agent charge des compétences à la demande. Idéal nombreuses spécialisations.
3. Handoffs : transition pilotée par l'état. Idéal flux séquentiels.
4. Router : dispatch parallèle et synthèse. Idéal verticals distincts.

La traduction entre les deux vocabulaires : Anthropic parle de *patterns de workflow* (le comment de l'orchestration), LangChain parle d'*architectures* (la structure des agents). En pratique, on combine : une architecture subagents qui utilise en interne des motifs prompt chaining et evaluator-optimizer.

Les topologies de coordination

Au-delà des motifs, il existe trois grandes topologies de coordination entre agents, documentées dans plusieurs analyses de référence :

Hiérarchique

Un agent superviseur commande des subordonnés, qui peuvent eux-mêmes avoir des subordonnés. Arbre de décision clair, contrôle centralisé. C'est l'orchestrator-workers d'Anthropic.

Avantage : prévisible, auditable. Inconvénient : goulot d'étranglement au superviseur.

Mesh (réseau pair-à-pair)

Les agents communiquent directement entre eux sans superviseur central. Chacun peut appeler n'importe lequel.

Avantage : flexible, robuste à la perte d'un agent. Inconvénient : imprévisible, difficile à déboguer, risque de boucles.

Swarm (essaim)

Coordonnation décentralisée émergente : aucun plan central, le comportement global émerge des interactions locales. Inspiré de la biologie.

Avantage : scalability extrême. Inconvénient : quasi impossible à auditer, adapté surtout à la simulation et à la recherche.

Pour une PME, la topologie hiérarchique est de très loin la plus recommandée. Mesh et swarm relèvent de la recherche ou de cas très spécifiques.

Les protocoles de communication inter-agents

Historiquement, chaque framework (LangGraph, AutoGen, Swarm) avait son propre format d'échange. Cela change en 2026 avec l'émergence de protocoles ouverts :

• Agent2Agent (A2A) — porté par Google, ce protocole vise à standardiser la communication entre agents de fournisseurs différents. L'enjeu : qu'un agent Claude puisse parler à un agent GPT ou à un agent Gemini via un protocole commun.
• MCP (Model Context Protocol) — proche parent, plus orienté connexion agent → outils/sources de données.

Pour une PME, l'intérêt de ces protocoles est la portabilité : un agent construit aujourd'hui sur un fournisseur reste utilisable demain sur un autre. C'est une forme d'assurance contre le lock-in.

Le cas multi-agent de référence (Anthropic)

Anthropic a partagé un chiffre qui fait référence dans le milieu : une architecture multi-agents avec Claude Opus 4 en superviseur et Claude Sonnet 4 en workers a surpassé un agent Claude Opus 4 unique de 90,2 % sur leurs évaluations internes de recherche. La raison est structurelle : la distribution du travail sur des agents au contexte séparé permet un raisonnement parallèle qu'un agent unique, fût-il plus puissant, ne peut pas atteindre.

Important : ce chiffre porte sur la recherche à grand volume (parcourir de nombreuses sources, synthétiser). Il ne se transpose pas à toutes les tâches. Mais il illustre le moment où le multi-agent devient pertinent : quand le volume d'information à traiter dépasse ce qu'un agent unique peut gérer efficacement dans son contexte.

Quand le multi-agent est justifié pour une PME

Reprenons la grille de décision pratique :

Le multi-agent est pertinent si vous répondez OUI à plusieurs de ces critères :

1. Plusieurs domaines fonctionnels distincts (RH, IT, finance, support) doivent coexister dans un même système.
2. Le volume d'information par interaction dépasse ce qu'un agent unique gère bien (fenêtre de contexte saturée).
3. Vous avez besoin de parallélisme réel (interroger plusieurs sources en même temps).
4. Plusieurs équipes doivent faire évoluer leurs compétences indépendamment.
5. Vous avez atteint les limites claires d'un agent unique (prompt illisible, coût en tokens qui explose).

Restez sur un agent unique si :

• Vous débutez (commencez simple, c'est la règle d'Anthropic et de LangChain).
• Le périmètre est ciblé (un cas d'usage précis).
• Le volume est modéré.
• La maintenance d'un système multi-agent serait disproportionnée.

Coûts et risques spécifiques au multi-agent

Le multi-agent n'est pas gratuit. Voici les surcoûts et risques à anticiper :

• Coût en tokens : chaque interaction multipliée par le nombre d'agents impliqués. Voir Budget agent IA PME.
• Latence : la coordination ajoute des étapes.
• Complexité d'observabilité : il faut tracer chaque agent, sinon le debug est impossible.
• Risque de boucle : des agents qui s'appellent mutuellement sans fin. Limite d'itérations obligatoire.
• Surface d'attaque : plus d'agents = plus de points d'entrée pour un attaquant. Voir Sécurité des agents IA.
• Gouvernance : qui est responsable de quelle décision quand plusieurs agents collaborent ? Question clé pour la conformité. Voir Agents IA et RGPD.

Frameworks pour implémenter

Le choix importe moins que la clarté de l'architecture. Un système multi-agent bien dessiné sur papier, codé simplement, vaut mieux qu'un framework sophistiqué mal maîtrisé. Voir aussi Agents IA open source vs propriétaires.

Un schéma de décision pratique

Quand on nous demande "faut-il du multi-agent ?", voici l'arbre de décision que nous appliquons :

1. Un agent unique avec de bons outils suffit-il ? → Si oui, rester simple.
2. Le contexte devient-il trop chargé ? → Considérer des sous-agents (motif subagents).
3. Plusieurs équipes doivent-elles évoluer indépendamment ? → Subagents avec un superviseur clair.
4. Y a-t-il du parallélisme naturel ? → Motif parallelization ou router.
5. Le flux est-il séquentiel avec transitions ? → Motif handoffs.
6. A-t-on besoin d'itération qualité ? → Motif evaluator-optimizer.

Dans 90 % des cas PME, la réponse est l'étape 1. Le multi-agent est un outil pour les 10 % restants — mais pour ces 10 %, il fait une vraie différence.

Exemple complet : un système support multi-agent en production

Pour rendre tout ça concret, voici à quoi ressemble un vrai système support multi-agent que nous déployons chez des PME, en combinant plusieurs motifs.

Architecture en 4 agents :

1. Agent routeur (motif routing) — reçoit chaque ticket entrant, le classe en 4 catégories (technique, facturation, litige, information).
2. Agents spécialisés (motif subagents) — un agent par catégorie, avec ses propres outils :

• Agent technique : accès à la base de bugs, GitHub, logs
• Agent facturation : accès au ERP, historique de paiement
• Agent litige : accès au CRM, historique des échanges
• Agent information : accès à la base de connaissances

1. Agent rédacteur (motif prompt chaining) — prend le résultat de l'agent spécialisé et rédige une réponse dans le bon ton et la bonne langue.
2. Agent critique (motif evaluator-optimizer) — vérifie la réponse (clarté, exactitude, conformité) avant envoi. Si insuffisant, renvoie à l'agent rédacteur pour itération.

Supervision humaine : tout ticket de litige ou à enjeu financier exige validation humaine avant envoi. L'agent propose, l'humain valide.

Résultat typique : 70 % des tickets traités sans intervention humaine, délai de première réponse divisé par 3, satisfaction client en hausse. C'est l'exemple de Support client IA transposé en architecture multi-agent.

Les anti-patterns à éviter

L'expérience nous apprend à reconnaître les erreurs classiques :

1. Le "tout multi-agent". Tout transformer en système multi-agent alors que la plupart des sous-tâches pourraient être de simples appels de fonction. Résultat : complexité explosive, coûts qui montent, debug impossible. Règle : ne pas faire d'agent ce qui peut être une fonction.

2. Le "mesh sauvage". Laisser tous les agents se parler librement. Ça marche en démo, ça casse en production (boucles, contradictions, explosion de tokens). Règle : structurer la communication, pas la laisser émerger.

3. Le "superviseur omniscient". Donner au superviseur trop d'outils ou trop de contexte. Il devient un monolithe déguisé en multi-agent. Règle : le superviseur orchestre, les workers font.

4. Le "multi-agent sans observabilité". Sans traçage fin de chaque agent, le système devient une boîte noire. Un bug devient introuvable. Règle : tracer chaque appel, chaque décision, chaque transfert.

5. Le "multi-agent sans limites". Pas de budget maximal, pas de limite d'itérations, pas d'escalade humaine. Le système peut boucler indéfiniment. Règle : toujours borner.

Le piège de l'observabilité en multi-agent

C'est probablement le sujet le plus sous-estimé. Un système multi-agent sans observabilité est ingouvernable : quand quelque chose tourne mal (une réponse incohérente, un coût qui explose), identifier *quel* agent a fauté devient un cauchemar.

Les pratiques de production consistent à :

• Tracer chaque appel (entrée, sortie, durée, coût en tokens) pour chaque agent.
• Conserver la chaîne de causalité : quelle décision du superviseur a mené à quel sous-agent, avec quels arguments.
• Alerter sur les dérives : un agent qui boucle, un coût qui dépasse un seuil, une latence anormale.
• Faire des replays : pouvoir rejouer une interaction à partir des logs pour comprendre et corriger.

Des outils comme LangSmith, Langfuse, ou des stacks d'observabilité LLM open source sont conçus pour ça. L'investissement dans l'observabilité doit être fait dès le prototype, pas après la mise en production. C'est une composante essentielle de la gouvernance IA.

La maturité multi-agent d'une PME

Où se situe votre entreprise sur l'échelle de maturité multi-agent ? Voici les quatre niveaux que nous observons :

• Niveau 0 — Aucun agent. L'automatisation repose sur des scripts et de la RPA legacy. L'IA, si elle existe, est ponctuelle (un outil de transcription, un chatbot basique).
• Niveau 1 — Agents isolés. Un ou deux agents IA ciblés, chacun dans son coin (un chatbot support, un assistant de rédaction). Pas de coordination, pas de mémoire partagée.
• Niveau 2 — Sous-agents coordonnés. Un superviseur orchestre plusieurs sous-agents spécialisés. Architecture lisible, bénéfices mesurables, gouvernance en place. C'est le niveau cible pour la plupart des PME ambitieuses.
• Niveau 3 — Écosystème multi-agent. Plusieurs systèmes d'agents qui collaborent, protocoles inter-fournisseurs (A2A), mémoire partagée, apprentissage continu. Réservé aux organisations matures technologiquement.

La plupart des PME sont au niveau 0 ou 1. Le saut vers le niveau 2 est celui qui débloque le plus de valeur pour un effort raisonnable. Le niveau 3 n'a de sens que si le niveau 2 est maîtrisé.

FAQ

Un système multi-agent est-il forcément "plus intelligent" ? Non. Mal conçu, il est moins intelligent qu'un agent unique bien conçu. La valeur vient de la bonne décomposition, pas du nombre d'agents.

Combien d'agents pour commencer ? Si vous passez au multi-agent, commencez par 2 ou 3 (un superviseur + 1 à 2 workers). Au-delà, la complexité grimpe vite.

Les agents de différents fournisseurs peuvent-ils collaborer ? Oui, de plus en plus, grâce aux protocoles comme Agent2Agent (A2A) de Google. C'est un sujet en maturation en 2026.

Le multi-agent est-il plus cher ? En général oui, à cause de la multiplication des appels. Mais sur les cas où il brille (multi-domaines volumineux), il peut être moins cher en tokens qu'un agent monolithique au contexte saturé. Voir Budget agent IA.

Le multi-agent est-il plus risqué en sécurité ? La surface d'attaque augmente avec le nombre d'agents. Chaque sous-agent doit avoir un périmètre d'outils restreint. Voir Sécurité des agents IA.

Pour aller plus loin

• Comprendre les sous-agents en détail → Sous-agents IA
• La mémoire, composant critique → Mémoire des agents IA
• Déployer concrètement → Déploiement en 14 jours
• Cadrer votre architecture → Demander un audit IA

Le multi-agent est une réponse à un problème de complexité, pas une fin en soi. La discipline consiste à reconnaître quand la complexité le justifie — et surtout quand elle ne le justifie pas. Les meilleures architectures multi-agent que nous déployons sont celles qui restent lisibles : quelques agents, des rôles clairs, un superviseur explicite, des garde-fous vérifiables.