Multi-agents 2026 : coordination, rôles, arbitrage

Multi-agents : ce que ça résout (et ce que ça casse)

Le multi-agents a un super pouvoir : rendre explicite l’organisation du travail.

Et un effet secondaire : rendre explicite votre désorganisation.

Une bonne analogie : un agent unique, c’est un “généraliste” très rapide.
Une équipe multi-agents, c’est un organigramme.

Si votre problème est simple (extract → vérifier → écrire), l’organigramme vous donnera… un comité de pilotage.
Si votre problème est réellement complexe (documents + outils + exceptions + conformité), l’organigramme vous donne quelque chose de rare : des responsabilités.

Dans la pratique, on bascule vers le multi-agents pour 4 raisons :

1. Spécialisation
   Un agent “extracteur” ne doit pas avoir la même personnalité, le même contexte et les mêmes outils qu’un agent “exécuteur de paiement”.

2. Confinement du risque
   Vous pouvez donner des permissions minimales par rôle (principe de moindre privilège) et éviter “l’agent tout-puissant”.
   (Voir notre article sur les outils et permissions : /blog/agents-ia/outils/mcp-tools-design-permissions.)

3. Qualité par design
   Un “critic”/“verifier” peut relire et bloquer, au lieu de compter sur le bon vouloir d’un monolithe.

4. Évolutivité
   Vous ajoutez un agent spécialisé sans refaire tout le système… à condition d’avoir une coordination propre.

Mais voici la partie moins instagrammable : chaque agent est un multiplicateur de coût, de latence, et de bugs.

Le multi-agents n’est pas “plus intelligent”.
C’est “plus structuré”… si vous structurez.

Les primitives de coordination : messages, état, arbitrage, budgets

Quand on lit les démos, on croit que “multi-agents” = plusieurs prompts qui se parlent.

En prod, multi-agents = quatre primitives :

1) Un protocole de message (sinon c’est du bruit)

AutoGen formalise des patterns comme le group chat, où plusieurs agents échangent et un orchestrateur gère le tour de parole.¹²

LangGraph, lui, traite souvent les agents comme des nœuds dans un graphe et pousse l’idée “qui parle à qui, quand, et pourquoi”. La doc décrit notamment des architectures avec un supervisor qui route vers des “workers”.³⁴

Traduction : un message n’est pas juste du texte.
C’est une intention, un rôle, un contexte, un état.

2) Un état explicite (sinon vous “réinventez” le passé)

Sans état, chaque agent relit tout… et improvise le reste.

LangGraph met en avant la notion de state et de persistance via des checkpointers (écrire l’état à chaque étape).⁵

Cet état sert à trois choses :

• savoir où vous en êtes (workflow),
• éviter de refaire deux fois la même action,
• et rendre le système rejouable (debug, audit).

3) Un arbitrage (sinon vous avez une démocratie sans constitution)

Multi-agents sans arbitrage, c’est un débat permanent :

• un agent propose,
• un autre critique,
• un troisième propose une alternative,
• et personne ne signe le chèque.

La coordination multi-agents “supervisor” existe précisément pour ça : une entité décide du prochain pas, pas juste “le meilleur argument du moment”.³

4) Des budgets (sinon vous payez des discussions philosophiques)

Ce point est sous-estimé.

Une conversation multi-agents peut être “qualitative” et parfaitement inutile :
un très beau raisonnement, une très belle prose, et zéro action.

En prod, vous fixez des budgets :

• max tours de discussion,
• max tool calls,
• max tokens,
• max durée,
• max “révisions” par critic.

Sinon vous finissez avec un agent “perfectionniste” qui optimise… votre facture.

Catalogue de patterns (ceux qui marchent hors démo)

On peut “inventer” des architectures multi-agents à l’infini.
En vrai, on retombe souvent sur 6 patterns.

Pattern A — Router + spécialistes (le plus rentable)

Un routeur (petit modèle, rapide) :

• identifie l’intention,
• choisit un agent spécialisé,
• et lui passe un contexte minimum.

Pourquoi ça marche ?

• coût réduit : vous n’activez pas tout le monde,
• permissions réduites : chaque spécialiste a son coffre d’outils,
• observabilité : vous tracez la décision de routage.

Avec LangGraph, cette logique de routage s’exprime naturellement via un graphe avec un nœud supervisor/routeur.³⁴

Pattern B — Planificateur → Exécuteur (plan-then-execute)

Un agent planificateur écrit un plan structuré, puis un exécuteur suit le plan.

Avantage : vous pouvez valider le plan avant les actions.

Inconvénient : si le plan est mauvais, l’exécution devient un accident bien organisé.

Ce pattern est particulièrement efficace si l’exécuteur est “bête mais fiable” : outil calling strict, validations, idempotence.

Pattern C — Producer / Critic (qualité par friction contrôlée)

Un agent produit. Un agent critique.

Le critic ne doit pas “réécrire”. Il doit :

• pointer les problèmes,
• proposer des corrections ciblées,
• et surtout : exécuter des checklists.

Si le critic est un écrivain frustré, vous vous retrouvez avec 12 drafts et un lancement “la semaine prochaine”.

Pattern D — Débat + juge (arbitration)

Deux (ou trois) agents proposent des solutions.
Un juge arbitre.

Ça peut aider sur :

• décisions d’architecture,
• synthèses contradictoires,
• choix de route (actions vs escalade).

Mais attention : ce pattern est un aimant à tokens. Il doit être rare, réservé aux cas à fort enjeu.

Pattern E — Swarm / stigmergie (utile… si vous avez une infrastructure)

Ici, pas de chef. Les agents travaillent sur un tableau partagé (“blackboard”), déposent des artefacts, et d’autres agents s’en servent.

Ça marche quand :

• les tâches sont parallélisables,
• vous avez un espace partagé versionné,
• et un critère clair de “done”.

Sans ça, c’est juste du chaos organisé.

Pattern F — Human-in-the-loop comme “agent” (le pattern adulte)

On rêve d’autonomie totale.
On shippe de l’autonomie gouvernée.

Un humain peut être un “agent” dans le système :

• validation d’action sensible,
• arbitrage sur les cas flous,
• correction sur dataset,
• et audit.

Ce n’est pas un échec. C’est une stratégie.

Frameworks 2026 : LangGraph, AutoGen, CrewAI (et comment les lire)

Il y a deux façons de choisir un framework :

1. “Celui qui a le plus de stars GitHub.”
2. “Celui qui correspond à mon modèle mental de prod.”

Je vous conseille la #2. Votre CFO aussi.

LangGraph : le multi-agents comme un graphe d’états

LangGraph se positionne comme un framework pour construire des applications stateful avec des LLMs, souvent via des graphes d’états. La doc propose des architectures multi-agents avec un supervisor qui délègue à des agents spécialisés.³⁴

Ce qui est “différent” (et utile) :

• vous voyez vos transitions,
• vous persistez l’état (checkpointers),⁵
• vous pouvez imposer des règles (budgets, branches, validations),
• et vous évitez le côté “agent qui improvise son propre workflow”.

LangGraph n’est pas “anti-LLM”.
Il est anti-flou.

AutoGen : le multi-agents comme conversation programmable

AutoGen se décrit comme un framework pour programmer des applications agentiques et multi-agents.¹

Le papier AutoGen présente l’idée de multi-agent conversation comme primitive pour construire des applications LLM plus complexes.⁶

Et la doc illustre des design patterns comme le group chat (plusieurs agents, tour de parole, orchestration).²

Ce qui est “différent” :

• mental model “dialogue entre agents”,
• patterns conversationnels,
• et une approche assez naturelle pour “faire collaborer” des rôles (expert métier, expert data, rédacteur…).

Risques :

• si vous n’avez pas d’état + arbitrage strict, vous pouvez vous retrouver avec des discussions… très polies, très longues, et très inutiles.

CrewAI : rôles + tâches + process (la métaphore “équipe”)

CrewAI met l’accent sur l’idée de crew : des agents spécialisés + des tâches + un process d’exécution.⁷⁸⁹

Ce qui est “différent” :

• vocabulaire très orienté “organisation” (agents, tasks, process),
• une façon assez directe de modéliser “qui fait quoi”.

CrewAI est particulièrement séduisant quand vous voulez :

• une pipeline claire (task 1 → task 2 → task 3),
• une spécialisation par rôle,
• et des sorties structurées.

Le piège : confondre “tâches” et “produit”. Le framework vous aide à orchestrer. Il ne valide pas votre définition de “done”.

Et les SDK provider-first ?

Les SDK de fournisseurs (ex. OpenAI Agents SDK) mettent en avant :

• tool calling,
• handoffs entre agents,
• streaming,
• et une traçabilité (“full trace”).¹⁰

Ils sont souvent excellents pour aller vite, surtout si votre infra est déjà sur ce fournisseur.
Ils sont moins “neutres” si vous visez du multi-provider ou un besoin très spécifique de gouvernance.

Cas d’usage : assurance, marketing faceless, prospection commerciale

On va rendre tout ça moins abstrait.

Cas 1 — Assurance : instruction de sinistre (documents + conformité)

Vous recevez :

• un mail,
• 5 pièces jointes,
• une déclaration incomplète,
• et un client qui veut une réponse “hier”.

Un multi-agents utile ici :

• Agent Ingestion : récupère mails + pièces, normalise, hash, trace.
• Agent Document : OCR/parsing + extraction de champs.
• Agent Vérification : checklists (pièces manquantes, cohérence, plafonds).
• Agent Décision : propose une décision + justification + citations (sources).
• Agent Exécution : crée ticket, met à jour le SI, envoie notification, avec idempotency keys.

Remarquez l’intérêt : ce n’est pas “plus intelligent”.
C’est “plus gouvernable”.

Et surtout : vous pouvez isoler les permissions.
L’agent “document” n’a pas à avoir accès au paiement.

Cas 2 — Marketing : faceless TikTok / YouTube (la factory, pas la démo)

Le fantasme : “un agent crée 30 vidéos par jour.”

La réalité : une chaîne faceless qui dure, c’est une supply chain :

• idées,
• scripts,
• hooks,
• voix,
• montage,
• publication,
• analytics,
• itérations.

Multi-agents = spécialiser :

• Agent Trend : récupère signaux (tendances, commentaires, watch time).
• Agent Script : écrit scripts courts, calibrés, avec variantes.
• Agent Voice : génère voix (TTS/S2S) + contrôle qualité (prononciation).
• Agent Montage : assemble assets (templates, sous-titres).
• Agent QA : vérifie politique plateforme, claims, droits, brand safety.
• Agent Publish : schedule + tags + A/B tests (si autorisé).

Le point non négociable : les garde-fous. Les plateformes adorent les contenus, beaucoup moins le spam automatisé.

Cas 3 — Prospection : SDR augmenté (pas un spammer)

Un multi-agents “sain” :

• Agent Research : enrichit (site, ICP, signaux publics).
• Agent Copy : écrit un message court, personnalisé, sans inventer.
• Agent Compliance : check RGPD, opt-out, et politiques internes.
• Agent CRM : log proprement dans le CRM (sans duplicats).

Le gain n’est pas “envoyer plus”. Le gain est “envoyer mieux”, et surtout mettre à jour le CRM sans douleur.

Anti-patterns (et comment les éviter)

Anti-pattern 1 — “Tout le monde est premium”

Si chaque agent utilise votre meilleur modèle, vous allez :

• exploser les coûts,
• augmenter la latence,
• et réduire la stabilité.

Pattern robuste :
petits modèles pour router/extract, gros modèle pour les décisions rares et à fort enjeu.

Anti-pattern 2 — “Le supervisor est un manager toxique”

Un supervisor qui micromanage :

• demande des détails inutiles,
• relance des tâches déjà faites,
• et dégrade tout.

Il faut lui donner :

• un état fiable,
• des sorties structurées,
• et des règles de delegation simples.

Anti-pattern 3 — “Les agents se passent des données non fiables”

Si un agent reçoit des docs non fiables (web, e-mails, pièces jointes) et les transmet “tels quels” à un autre agent… vous propagez le prompt injection.

La mitigation la plus rentable reste la séparation :

• données non fiables → parsing + extraction + validation,
• instructions système → immuables,
• et outils → permissions minimales.

(Voir : /blog/agents-ia/securite/securite-agents-prompt-injection-dlp-secrets.)

Anti-pattern 4 — “Pas de traces”

Sans observabilité, un multi-agents est un cauchemar :

• impossible de savoir quel agent a “décidé”,
• impossible de rejouer,
• impossible d’évaluer.

LangGraph et les SDK modernes mettent justement l’accent sur l’observabilité (traces, debug),⁵¹⁰ mais la règle reste la même : tracez comme si vous deviez expliquer ça à un auditeur.

Méthode pratique : passer de 0 à multi-agents sans se brûler

1

Écrivez le workflow en français (oui, en français)

Listez : étapes, entrées/sorties, outils, permissions, critères d’escalade. Si vous ne pouvez pas l’expliquer à une personne non-tech, le multi-agents ne vous sauvera pas.

2

Commencez mono-agent + traces + budgets

Un bon agent outillé + observabilité vous donnera déjà 70% du gain. Le multi-agents est une optimisation structurelle, pas une rustine.

3

Découpez par responsabilités incompatibles

Exemple : extraction doc vs exécution SI. Chaque responsabilité devient un agent spécialisé, avec ses outils et ses permissions minimales.

4

Ajoutez un arbitrage explicite

Supervisor (central) ou juge (arbitration) : choisissez une autorité. Sans arbitrage, vous fabriquez une discussion sans fin.

5

Évaluez sur des traces réelles

Capturez 50 cas, rejouez, scorez les décisions d’outils, et mesurez le coût/latence. Sans evals, vous optimisez au ressenti.

FAQ

Questions frequentes

Multi-agents = forcément meilleur ?+

Non. Multi-agents = plus de structure. Si votre problème est simple, vous ajoutez surtout des coûts. Si votre problème est complexe, vous gagnez en gouvernance (permissions, vérification, arbitrage).

Supervisor central ou swarm décentralisé ?+

En entreprise, le supervisor est souvent plus simple à gouverner : un point d’arbitrage, des transitions explicites. Le swarm devient intéressant quand vous avez de la parallélisation et un état partagé robuste.

Je peux faire du multi-provider avec ces frameworks ?+

Oui, en général : LangGraph, AutoGen et CrewAI sont utilisables avec différents fournisseurs de modèles, tant que vous contrôlez les appels. En pratique, le vrai sujet est la traçabilité, la latence et la gouvernance (policies, logs, ZDR).

Quel est le garde-fou le plus important ?+

Les budgets + l’observabilité. Sans budget, vous payez des boucles. Sans traces, vous ne débuggez pas : vous devinez.

Je commence par quoi pour un assureur ?+

Mono-agent outillé + pipeline documents solide (OCR/parsing) + vérifications, puis ajoutez un agent de vérification et un agent d’exécution. Le multi-agents doit réduire le risque, pas augmenter l’ego technique.

Sources et references

1. [1]GitHub, Microsoft, “AutoGen: A programming framework for agentic AI”.
2. [2]Microsoft AutoGen docs, “Group Chat” (design pattern).
3. [3]LangGraph (tutorial), “Agent Supervisor / Multi-agent supervisor”.
4. [4]LangGraph JS (concepts), “Multi-agent Systems”.
5. [5]LangGraph docs, “Persistence” (checkpointers/state).
6. [6]Wu et al., “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation”.
7. [7]CrewAI docs, “Crews” (concept).
8. [8]CrewAI docs, “Agents” (concept).
9. [9]CrewAI docs, “Tasks” (concept).
10. [10]OpenAI API docs, “Agents SDK” (handoffs, tracing/full trace).