Multi-agents avec Claude : patterns d'orchestration

Un agent Claude bien configuré résout la plupart des tâches qu'on lui confie. Alors pourquoi en assembler plusieurs ? Parce qu'il existe trois moments précis où un seul agent, même avec Opus 5 et 1M tokens de contexte, cale : quand les sous-tâches sont indépendantes et pourraient tourner en parallèle, quand le contexte utile dépasse ce qu'un agent peut garder propre, et quand deux rôles cognitifs différents (produire vs critiquer) se marchent dessus dans la même conversation.

Cet article décrit les quatre patterns d'orchestration multi-agents qui reviennent en production, avec Claude comme moteur. Chacun a un coût, un cas d'usage, et une façon de casser. Si tu débutes sur la question des agents, commence par le guide complet pour apprendre Claude avant de multiplier les têtes.

Pourquoi passer de 1 agent à N agents

La bonne question n'est pas « combien d'agents » mais « quel gain justifie la complexité ajoutée ». Trois déclencheurs concrets rendent le multi-agents pertinent.

Premier déclencheur : la parallélisation. Auditer 40 pages d'un site, comparer 12 fournisseurs, résumer 30 rapports trimestriels. Un agent seul les traite en séquence, un orchestrateur lance 10 workers et divise le temps par 8 ou 9. Deuxième déclencheur : la séparation des contextes. Quand un rédacteur, un fact-checker et un SEO partagent la même conversation, chacun voit le raisonnement de l'autre et se laisse influencer. Séparés, ils gardent leur angle. Troisième déclencheur : la spécialisation par rôle. Un agent avec accès à ta base clients, un autre avec accès à ton catalogue produit, sans mélanger les permissions.

Le contre-exemple : produire un post LinkedIn à partir d'un article. Un seul agent avec le bon prompt et deux outils suffit. Ajouter un « éditeur » et un « validateur » multiplie les appels API sans améliorer le résultat. La règle pratique : si tu ne peux pas expliquer en une phrase ce que chaque agent apporte que les autres ne pourraient pas faire, tu n'as pas besoin de plusieurs agents. Pour un cadrage plus large sur construire des agents IA autonomes avec Claude, la page pilier détaille les prérequis.

Pattern 1 : Orchestrateur-Workers

Un agent central (typiquement Claude Opus 5, 5 $ / 25 $ le million de tokens) reçoit la tâche, la décompose en sous-tâches indépendantes, et délègue à N workers Claude Sonnet 5 (2 $ / 10 $ le million) qui tournent en parallèle. L'orchestrateur récupère les résultats, synthétise, renvoie.

Cas concret : audit SEO d'un site de 60 pages. L'orchestrateur récupère le sitemap, découpe en lots de 5 pages, lance 12 workers en parallèle. Chaque worker analyse ses 5 pages (title, meta, structure Hn, maillage interne) et retourne un JSON structuré. L'orchestrateur agrège, priorise, produit le rapport final. Sur ce cas, tu passes de 45 minutes séquentielles à environ 6 minutes réelles, pour un coût dominé par les 12 workers Sonnet (input court, output structuré).

Le pattern casse dès que les sous-tâches sont interdépendantes. Si le worker 3 a besoin du résultat du worker 1 pour démarrer, tu n'as plus de la parallélisation, tu as un pipeline mal déguisé. Autre limite : la synthèse finale par l'orchestrateur devient elle-même un goulot dès que tu remontes plus de 20 000 tokens de résultats agrégés.

Pattern 2 : Pipeline séquentiel

Agent A produit, Agent B critique ou enrichit, Agent C finalise. Chaque étape a son propre system prompt, ses propres outils, sa propre température. La différence avec un agent unique qui ferait tout : chaque agent démarre avec un contexte propre, ce qui l'oblige à s'appuyer sur ce que le précédent lui transmet explicitement.

Cas concret : pipeline éditorial pour un article de blog. Rédacteur (Sonnet 5, température 0.7) produit un premier jet à partir d'un brief. Éditeur (Sonnet 5, température 0.3) reçoit uniquement le jet et le brief initial, retourne des annotations structurées. Rédacteur-v2 applique les corrections. SEO (Haiku 4.5, très bas coût) passe en dernier pour meta title, meta description, maillage interne. Chaque étape écrit dans un JSON dédié.

Le point critique : le format de passage entre agents. Si tu passes de la prose libre, tu perds en fidélité à chaque étape. Si tu forces un JSON structuré avec des champs nommés (draft_body, revision_notes, seo_meta), tu gardes la précision. Prévois aussi un champ blocking_questions qui permet à un agent de signaler qu'il ne peut pas continuer sans clarification, plutôt que d'halluciner. Pour la brique éditoriale complète, voir aussi le cocon sémantique piloté par IA.

Pattern 3 : Agents pairs collaboratifs

Deux ou trois agents dialoguent sans hiérarchie, souvent avec des rôles adversariaux : proposeur / challenger, avocat / procureur, bull / bear. Le but n'est pas de trancher tout de suite mais de faire émerger les angles morts d'une décision.

Cas concret : évaluer un investissement dans un nouveau canal d'acquisition. Agent A (« défenseur du projet ») construit la meilleure version possible du business case. Agent B (« challenger ») attaque hypothèses, coûts cachés, risques d'exécution. Un troisième agent (« arbitre ») ne prend pas parti mais liste les 5 points de désaccord factuels qui restent après 3 tours.

Les risques sont réels et connus : boucles infinies (les deux agents se renvoient des variations sans converger), convergence artificielle (le challenger finit par acquiescer par politesse implicite), coût qui explose (chaque tour double les tokens facturés). Trois règles pour borner : nombre maximum de tours (5 en général suffit), critère d'arrêt explicite formalisé dans le prompt système (« stop dès que tu identifies moins de 2 nouveaux points par rapport au tour précédent »), et un budget en tokens hard-capé côté code. La recherche récente d'Anthropic sur les conflits entre agents en interaction non supervisée montre que ces dynamiques peuvent vite déraper sans garde-fous explicites.

Pattern 4 : Architecture hiérarchique

Un manager en haut, des leads au milieu, des workers en bas. Ce pattern devient pertinent quand la tâche a plusieurs niveaux de décomposition qui exigent chacun un contexte différent. Cas typique : migration complète d'un site web (audit, refonte de contenu, refonte technique, redirections, monitoring post-lancement).

Le manager (Opus 5) découpe la mission en 4 chantiers. Chaque chantier a un lead (Sonnet 5) qui à son tour décompose en tâches concrètes et pilote 3 à 6 workers (Sonnet 5 ou Haiku 4.5 selon la tâche). Le lead audit-contenu ne voit jamais les workers du chantier technique, et inversement. Chaque niveau agrège vers le haut.

C'est ici que le protocole MCP devient central : chaque niveau se voit exposer un jeu d'outils calibré (le manager voit un outil « lancer_chantier », les leads voient leurs outils métier, les workers voient uniquement leurs fichiers). Tu évites ainsi que le manager ait accès aux 40 outils cumulés de la hiérarchie, ce qui polluerait son contexte et dégraderait ses décisions. Attention cependant : chaque niveau ajoute une latence de 15 à 40 secondes et un coût de coordination. Sous 3 niveaux de complexité réelle, un pattern orchestrateur-workers plat fait généralement mieux.

Choisir son pattern : arbre de décision

La grille qui fonctionne en pratique :

Les prix sont indicatifs, basés sur les tarifs Sonnet 5 (2 $ / 10 $ le million de tokens, tarif standard confirmé le 10 août 2026) et Opus 5 (5 $ / 25 $). Un même livrable de veille concurrentielle voit son coût multiplié par 5 entre le pattern le plus léger et le plus lourd. La complexité doit payer.

Implémentation concrète avec l'API Anthropic

Squelette pour un orchestrateur-workers, en pseudo-code lisible. L'idée : l'orchestrateur produit une liste de sous-tâches, tu lances les workers en parallèle via async, tu récupères les résultats et tu renvoies à l'orchestrateur pour synthèse.

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def worker(task):
    r = await client.messages.create(
        model="claude-sonnet-5",
        max_tokens=2000,
        system=WORKER_PROMPT,
        messages=[{"role": "user", "content": task}],
    )
    return r.content[0].text

async def orchestrate(mission):
    plan = await client.messages.create(
        model="claude-opus-5",
        max_tokens=1500,
        system=ORCHESTRATOR_PROMPT,
        messages=[{"role": "user", "content": mission}],
    )
    subtasks = parse_json(plan.content[0].text)
    results = await asyncio.gather(*[worker(t) for t in subtasks])
    synth = await client.messages.create(
        model="claude-opus-5",
        max_tokens=3000,
        system=SYNTH_PROMPT,
        messages=[{"role": "user", "content": json.dumps(results)}],
    )
    return synth.content[0].text

Trois points d'attention : le system prompt de chaque rôle doit contenir un exemple de format de sortie attendu (sinon les workers dérivent), le parse_json doit tolérer les erreurs (un worker peut retourner du texte hors format, prévois un fallback), et tu veux un timeout par worker pour éviter qu'une lenteur ne bloque l'ensemble. Pour les intégrations aux outils métier, le protocole MCP te permet de brancher tes workers sur Notion, Slack, GitHub ou ton CRM sans réimplémenter chaque connecteur. La documentation de l'API Anthropic couvre les détails du streaming et des tool_use si tu veux aller plus loin.

Les 3 pièges qui tuent un système multi-agents en prod

Premier piège : le contexte qui gonfle exponentiellement. Naïvement, chaque agent reçoit l'historique complet des échanges précédents. Sur un pipeline à 5 étapes, l'étape 5 se retrouve avec 40 000 tokens de contexte, dont 90 % lui sont inutiles. Symptôme : les factures API explosent sans que les livrables s'améliorent. Correctif : chaque agent reçoit uniquement les champs nommés dont il a besoin, jamais l'historique brut. Le cache de prompt (10 % du tarif input en lecture) aide sur les parties fixes du system prompt, mais ne résout pas le fond.

Deuxième piège : les erreurs silencieuses en cascade. Un worker hallucine un chiffre, l'orchestrateur ne le vérifie pas, la synthèse finale reprend l'hallucination comme un fait. Symptôme : des rapports plausibles mais faux, découverts après livraison. Correctif : chaque sortie de worker doit inclure un champ sources ou confidence, et l'orchestrateur doit avoir une consigne explicite pour marquer comme « non vérifié » toute donnée sans source. Un agent challenger optionnel qui relit avant synthèse rattrape beaucoup de ces cas.

Troisième piège : les coûts imprévisibles. Une seule tâche utilisateur déclenche 40 appels API en cascade, dont personne n'avait le compte. Symptôme : découverte du problème sur la facture du mois. Correctif : instrumentation systématique (compter les tokens par tâche, pas seulement par appel), budget maximum en dur dans l'orchestrateur, et alerte au-delà d'un seuil. Sur Claude Code en usage entreprise, la commande /cost affiche désormais un détail de cache par session, mais côté API tu construis ta propre télémétrie.

Passer à la pratique

Le multi-agents n'est pas un objectif, c'est une réponse à un problème précis. Commence toujours par un agent unique bien outillé. Si tu butes sur une des trois limites (parallélisation, contexte, séparation de rôles), choisis le pattern le plus léger qui débloque, orchestre-le sur une tâche réelle, mesure le coût et le temps. Puis itère.

Si tu veux structurer ce travail sur un cas business concret et livrer des agents autonomes en production plutôt que des prototypes, la formation Claude Agent d'Ottho couvre l'assemblage complet, de l'architecture au monitoring, en 5 semaines. Piloter vos agents autonomes avec un accompagnement en cohorte évite les six mois d'essais-erreurs que la plupart des builders traversent seuls sur ces sujets.