État de l'art : orchestration multi-agents avec Claude Code (2026)

En bref

En 2026, Claude Code propose quatre mécanismes distincts pour faire collaborer plusieurs instances d’un LLM sur une même tâche. Chacun a un modèle de coordination différent, des garanties différentes, et des limites différentes. Comprendre ces distinctions, c’est la différence entre un pipeline qui tient en production et un qui échoue silencieusement.

En clair : l’orchestration multi-agents en 2026, c’est comme choisir entre quatre formations de team building : une vague de stagiaires indépendants qui livrent en parallèle (Agent Tool), une équipe avec liste de tâches partagée (Agent Teams), des spécialistes dans des bureaux séparés (Session Agents), ou des observateurs qui surveillent sans intervenir (Hooks MCP). Chacune résout un problème différent — les confondre, c’est se tromper de structure.

Les quatre mécanismes

Agent Tool — le dispatch parallèle

L’Agent Tool (aussi appelé Task Tool dans la documentation) est le mécanisme de base pour lancer des sous-agents indépendants. Le parent formule N tâches atomiques, lance N instances en parallèle, attend leurs résultats, et consolide.

Chaque sous-agent tourne dans son propre contexte, avec ses propres outils, ses propres permissions. La documentation officielle est explicite : “Each subagent invocation creates a new instance with fresh context.” Il n’y a pas de pool de tokens partagé — des mesures sur le terrain montrent que deux agents parallèles consomment 135K tokens combinés sans compaction mutuelle.

Paramètres actuels (mars 2026)

Le paramètre model accepte les alias sonnet, opus, haiku, inherit, ou un identifiant complet (claude-opus-4-6). La borne supérieure du contexte par sous-agent est passée à ~128K tokens avec Opus 4.6 et Sonnet 4.6 (v2.1.77). La limite de sortie a été multipliée par 8 : 64K tokens au lieu de 8 192 pour Opus 4.6.

Contrainte active à surveiller : un bug non résolu (#29231) fait que le suffixe [1m] est supprimé lors du spawn des sous-agents — un parent qui tourne sur 1M tokens spawne des enfants limités au contexte standard (~200K). Le bug est ouvert, sans réponse Anthropic à ce jour.

Signal d’échec exploitable : quand un sous-agent échoue, le parent reçoit un retour textuel analysable. C’est la propriété la plus utile de ce mécanisme — contrairement à Agent Teams, l’échec est visible.

Contrainte structurelle : pas de nesting. Un sous-agent ne peut pas spawner ses propres sous-agents. La hiérarchie est plate : un niveau de profondeur maximum.

Rate limits : 12 agents Opus en parallèle consomment environ 168K tokens par minute. En Tier 1 (30K ITPM), c’est 5,6 fois la limite. Le parallélisme massif requiert Tier 2 minimum.

En clair : le budget de tokens par sous-agent est généreux (≈ 100K Sonnet, ≈ 128K Opus), mais le rate limit, lui, est partagé entre tous les agents simultanés. À 12 Opus en parallèle, on dépasse 5× la limite Tier 1 — soit on est en Tier 2+, soit on étale les lancements dans le temps. Sinon, les agents échouent en cascade.

Agent Teams — la coordination avec état partagé

Agent Teams est un mécanisme différent : un agent “lead” coordonne des “teammates” qui partagent une task list commune et peuvent se communiquer des messages.

Ce qui distingue Agent Teams de l’Agent Tool :

• Task list partagée : le lead dépose des tâches, les teammates se les attribuent (y compris en auto-assignment après complétion d’une tâche précédente).
• File locking : évite les race conditions quand deux teammates tentent de réclamer la même tâche simultanément.
• Mailbox bidirectionnelle : via SendMessage, lead et teammates peuvent s’envoyer des messages. Depuis v2.1.77, un SendMessage vers un agent stoppé en arrière-plan le relance automatiquement.
• Plan approval mode : un teammate peut être contraint en lecture seule jusqu’à approbation du lead.

Bugs actifs qui limitent son utilisation

Trois bugs sérieux sont ouverts sur le dépôt GitHub en mars 2026 :

Éphémère par conception : les tâches sont purgées après complétion. /resume ne restaure pas les teammates — après une reprise, le lead peut tenter de contacter des agents qui n’existent plus.

Coût : la documentation officielle estime qu’Agent Teams consomme environ 7x plus de tokens qu’une session standard en mode plan, parce que chaque teammate maintient son propre contexte. Le broadcast (envoyer un message à tous les teammates) coûte N×M injections de contexte — déconseillé à l’échelle.

Session Agents — l’isolation par worktree

La troisième approche consiste à lancer des instances Claude Code dans des worktrees git séparés. Chaque instance opère sur une branche isolée, avec ses propres fichiers, sans risque de collision avec les autres.

Ce mécanisme est pertinent quand l’isolation est structurelle : plusieurs agents qui travaillent sur des parties différentes d’un codebase, avec une revue humaine avant merge. C’est le pattern utilisé par Anthropic pour son projet de compilation C — 16 agents parallèles sur ~100K lignes, sans interférence mutuelle.

Contrainte documentée : ce mode fonctionne de façon fiable uniquement avec Opus. Les retours terrain montrent que Sonnet et Haiku ne maintiennent pas la cohérence de comportement sur les sessions longues en contexte d’isolation worktree.

Hooks MCP — l’observabilité de l’orchestration

Les hooks ne sont pas un mécanisme de coordination à proprement parler, mais ils rendent l’orchestration observable et contrôlable. En mars 2026, Claude Code expose 22 événements hooks.

Deux événements sont particulièrement pertinents pour l’orchestration :

• SubagentStart : se déclenche immédiatement après le spawn d’un sous-agent via Agent Tool. Asynchrone. Permet d’injecter du contexte supplémentaire via additionalContext.
• SubagentStop : se déclenche après la complétion du sous-agent, avant que le résultat soit retourné au parent. Synchrone et bloquant — peut empêcher l’arrêt et forcer une continuation. Payload riche : chemin du transcript, dernier message.

Ces deux hooks étaient documentés mais non confirmés pour l’Agent Tool jusqu’à début 2026. Ils sont maintenant explicitement documentés comme se déclenchant pour les sous-agents spawned via Agent Tool.

Autres hooks pertinents pour l’orchestration : StopFailure (avec matcher sur le type d’erreur : rate limit, authentification, billing, etc.), PreCompact/PostCompact, TeammateIdle, TaskCompleted.

Ce que la littérature dit sur la fiabilité

L’architecture prime sur le modèle

La recherche MAESTRO (arXiv 2601.00481, janvier 2026) a évalué 12 systèmes multi-agents avec des traces framework-agnostiques. Sa conclusion : l’architecture du système est le facteur dominant pour la reproductibilité, le coût et la précision — devant le choix du modèle. La variance run-to-run est substantielle même à système et tâche identiques, et cette variance s’explique par les choix structurels.

Princeton University et Berkeley Klein Center publient en février 2026 (“Towards a Science of AI Agent Reliability”, arXiv 2602.16666) une évaluation de 14 modèles sur 12 métriques de fiabilité : consistance, robustesse, prédictibilité, sécurité. Résultat : les gains récents de capacité n’ont produit que de faibles améliorations de fiabilité. Passer au modèle d’au-dessus ne résout pas les problèmes de fiabilité structurels.

La racine des pannes : le mismatch probabiliste/déterministe

“Characterizing Faults in Agentic AI” (arXiv 2603.06847, mars 2026) a analysé 13 602 issues et pull requests sur 40 dépôts de systèmes agentiques. Sa conclusion centrale : la majorité des défaillances provient d’un mismatch entre des sorties générées probabilistiquement et des contraintes d’interface déterministes.

Le modèle génère du texte probabiliste — il ne produit jamais deux fois exactement le même output. Le reste du système attend des entrées déterministes : un JSON valide, un nom de fichier exact, une réponse dans un format précis. Quand l’interface entre les deux est mal conçue, le système casse. Des validations de format explicites entre agents — pas un modèle plus puissant — sont ce qui corrige ce problème. 83,8% des praticiens interrogés confirment que cette taxonomie couvre leurs cas réels.

Les silent failures

“Silent Failures in Multi-Agent Systems” (arXiv 2511.04032, novembre 2025) formalise un mode d’échec particulièrement difficile à détecter : les agents qui dérivent, tournent en boucle, ou omettent des détails critiques — sans générer d’erreur explicite. Ces défaillances silencieuses sont détectables par apprentissage automatique (XGBoost à 98% de précision sur un corpus annoté), mais pas par simple inspection du résultat final.

Les taux d’échec mesurés

MASFT (UC Berkeley/CMU, arXiv 2503.13657) reste la référence pour les taux d’échec des systèmes multi-agents en conditions réelles : entre 41% et 86,7% selon le type de tâche et le système. Aucun papier récent ne contredit ces chiffres. Princeton/Berkeley (2602.16666) les confirme indirectement en montrant que les gains de capacité ne les réduisent pas significativement.

Ce qui fonctionne, ce qui ne fonctionne pas encore

Validé

• 12 agents Sonnet en parallèle sans dégradation de qualité ni rate limit, sur un compte Tier 2. Des tests empiriques montrent un temps total d’environ 16 secondes pour une tâche de recherche documentaire parallèle.
• Dispatch par type cognitif : le choix du modèle sur la nature de l’opération (extraction mécanique vers Haiku, analyse nuancée vers Sonnet) est plus efficace que le dispatch sur la “taille” ou la “complexité” perçue de la tâche. Trois sources indépendantes convergent sur ce point (MAESTRO, Princeton/Berkeley, observations de terrain).
• Output par fichier : écrire dans un fichier plutôt que retourner par texte contourne la limite d’output et permet la vérification post-exécution. Avec Opus 4.6, la limite est passée à 64K tokens — le pattern reste recommandé pour les outputs dépassant cette borne.
• SubagentStart/Stop hooks : confirmés comme exploitables pour l’observabilité et l’injection de contexte dynamique.

En cours ou instable

• Agent Teams : le mécanisme existe et les primitives fonctionnent (task list, mailbox, self-claim), mais trois bugs actifs (#32368, #27555, #24316) en réduisent la fiabilité. À utiliser avec prudence en production, et uniquement avec des endpoints standards.
• Agents spécialisés comme teammates : la feature permettant d’utiliser des agents avec des profils définis (outils restreints, modèle spécifique) n’est pas encore implémentée (issue #24316 ouverte, 27 commentaires actifs). En attendant, tous les teammates sont des instances génériques.
• 1M context pour sous-agents : le parent peut utiliser 1M tokens, mais les sous-agents sont limités au context standard (~200K) à cause du bug #29231. Non résolu.

Quel mécanisme pour quel besoin ?

Ce qu’il faut retenir

• Quatre mécanismes distincts : Agent Tool (parallélisme stateless), Agent Teams (coordination avec état), Session Agents (isolation worktree), Hooks MCP (observabilité). Chaque mécanisme a un domaine d’application différent.
• L’Agent Tool est le mécanisme le plus fiable : signal d’échec exploitable, budgets indépendants, parallélisme jusqu’à 12 agents (Tier 2). Agent Teams ajoute de la coordination mais avec des bugs actifs en mars 2026.
• La littérature converge : trois équipes indépendantes (MAESTRO, Princeton/Berkeley, Berkeley/CMU) montrent que les gains de capacité ne produisent pas de gains proportionnels de fiabilité. L’architecture prime.
• Les pannes viennent des interfaces : mismatch format entre agents, échecs silencieux, non-conformité aux instructions sans erreur explicite. Les validations de sortie entre agents sont plus efficaces qu’un modèle plus puissant.
• Tier 2 est le minimum pour du parallélisme au-delà de 5-6 agents Opus.