Tu as déjà un agent Claude qui tourne sur un cas précis. Veille, qualif de leads, génération de specs, peu importe. Maintenant tu te demandes si en faire collaborer plusieurs entre eux vaut le coup. Cet article répond à ça : pas une intro sur le multi-agents en général, des patterns nommés, illustrés, et une grille pour décider. Si tu débutes encore sur les fondamentaux, le guide complet pour apprendre Claude couvre la partie amont. Ici on assume que tu sais déjà ce qu'est un prompt système et un outil.
Honnêtement : la majorité des cas tient en mono-agent bien prompté. Avant de multiplier les agents, demande-toi si ton problème est vraiment un problème de découpage, ou juste un prompt mal écrit.
Pourquoi passer au multi-agents (et quand ne pas le faire)
Trois signaux qui justifient le passage. Un, ta tâche a des sous-domaines hétérogènes : un agent qui lit du juridique ET rédige du marketing ET interroge ta base produit, ça finit par bavarder sur tout, mal partout. Deux, tu as besoin de parallélisation : 5 fiches concurrents à analyser, lancées en même temps, c'est 5x plus rapide qu'en séquentiel. Trois, ton contexte sature : un seul agent qui doit charger 200 pages de doc plus l'historique client plus le brief du jour, tu atteins les limites pratiques avant le 1M tokens théorique de Sonnet 4.6.
Trois signaux contre. Un, ta tâche est linéaire et courte : un seul agent fait le job. Deux, ton budget est serré : multi-agents = multiplication des appels API, donc des tokens facturés. Sur l'API Anthropic, un workflow à 4 agents qui s'échangent du contexte peut coûter 6 à 10x un mono-agent équivalent. Trois, personne dans ton équipe ne suit les logs : un système multi-agents qui dérape sans monitoring, c'est de l'argent qui brûle en silence.
Pour aller plus loin sur les fondations, vois aussi construire des agents IA autonomes avec Claude, qui pose le cadre général avant l'orchestration.
Le vocabulaire de base : orchestrateur, sous-agents, outils
Trois mots à fixer une fois pour toutes.
L'orchestrateur : l'agent qui reçoit la demande de l'utilisateur et décide quoi faire. Il découpe, dispatche, agrège. C'est le chef d'orchestre, jamais lui qui exécute le détail.
Les sous-agents : des sessions Claude indépendantes, chacune avec son prompt système, son contexte propre, sa spécialité. Dans l'API Anthropic, un sous-agent est techniquement appelé comme un outil (via tool_use) depuis l'orchestrateur. L'orchestrateur ne voit que la sortie du sous-agent, pas son raisonnement interne.
Les outils : fonctions, API, serveurs MCP que l'agent peut invoquer. Un outil n'a pas de raisonnement. Tu lui passes des arguments, il rend un résultat. Un sous-agent, lui, a un cerveau : il interprète, prend des décisions, peut lui-même appeler d'autres outils. C'est la différence clé. Si ton besoin est juste "appeler une API météo", tu fais un outil, pas un sous-agent.
Pattern 1 : orchestrateur-workers (le plus courant)
Un Claude principal reçoit la demande, la découpe en sous-tâches indépendantes, dispatche en parallèle à des workers spécialisés, agrège leurs sorties.
Cas concret : agent de veille concurrentielle. L'utilisateur tape "compare moi Notion, Linear et Asana sur leur positionnement 2026". L'orchestrateur lance 3 workers en parallèle, un par concurrent. Chaque worker a accès à des outils de scraping et au site de la marque. Ils rendent chacun une fiche structurée. L'orchestrateur reçoit les 3 fiches et produit la synthèse comparative.
Quand l'utiliser : tâches décomposables avec sous-tâches qui ne dépendent pas les unes des autres. C'est 80% des cas business intéressants. Tu trouveras un exemple proche dans l'agent commercial Claude où la qualif d'un lead se décompose en plusieurs angles évaluables en parallèle.
Pattern 2 : pipeline séquentiel (chaînage)
Sortie de l'agent A devient entrée de l'agent B, puis C. Chaque agent a un prompt court, un contexte propre, une responsabilité unique.
Exemple : traitement d'emails entrants. Agent extracteur lit l'email et sort un JSON (expéditeur, intention, urgence). Agent classifieur prend ce JSON et décide de la file (commercial, support, spam). Agent rédacteur prend la file et le contenu et produit la réponse type à valider.
Avantage : chaque agent est trivial à débugger, son prompt tient en 30 lignes. Limite : pas de parallélisme, une erreur en amont casse toute la suite. Quand l'utiliser : process métier avec étapes ordonnées non négociables, où la sortie de chaque étape est un artefact propre que tu peux logger et inspecter.
Pattern 3 : routeur (un agent qui aiguille)
Un agent léger (Haiku suffit) classe la demande entrante et la redirige vers l'agent spécialisé.
Cas typique : support client. Le routeur reçoit "ma facture du mois dernier ne correspond pas à mon usage". Il classe : facturation. Il route vers l'agent facturation qui a accès au CRM et au système de billing. Sans routeur, tu aurais un agent généraliste avec un prompt système de 4000 tokens qui tente de tout couvrir.
Bénéfice : chaque agent spécialisé a un prompt court et des outils ciblés. Tu économises des tokens à chaque conversation. Piège : si le routeur se trompe, l'utilisateur ne le voit pas, il pense juste que l'agent est mauvais. Prévois un fallback : quand le routeur n'est pas sûr (confiance basse), il passe à un agent généraliste ou demande une clarification.
Pattern 4 : agent critique (auto-évaluation)
Un agent produit une sortie, un second agent (le critic) l'évalue selon une grille, l'orchestrateur boucle si l'écart est trop grand.
Exemple : génération de propositions commerciales. L'agent rédacteur produit la propal. Le critic vérifie ton (corporate mais pas raide), conformité (mentions légales présentes, prix cohérents avec la grille), structure (intro, livrables, calendrier, prix). S'il détecte un écart, il renvoie un feedback structuré à l'auteur, qui réécrit. L'orchestrateur plafonne à 2 itérations max.
Quand l'utiliser : la qualité de sortie est critique (clientèle exigeante, doc engageante juridiquement). Coûteux en tokens, à ne pas généraliser. Sur du run quotidien à volume, c'est trop cher.
Pattern 5 : agents en débat (rare mais utile)
Deux ou trois agents avec des perspectives différentes débattent avant qu'un arbitre tranche. Exemple de casting : un avocat du diable (cherche les failles), un défenseur (argumente pour), un juge (synthétise et tranche).
Cas concret : décision stratégique ponctuelle. Tu hésites entre lancer un produit B2B ou rester pure B2C. Tu fais débattre trois Claude sur ton brief, chacun joue un rôle, le juge sort une recommandation argumentée. Tu lis le débat complet, pas juste la conclusion. C'est l'intérêt : forcer ton outil à exposer les contre-arguments que toi seul aurais peut-être passé sous silence.
Limite honnête : coûteux, lent, pas adapté à du run quotidien. Surtout utile en aide à la décision ponctuelle où tu veux éviter le biais de confirmation.
Choisir son pattern : grille de décision
Quatre questions, quatre patterns. Tu peux les combiner (routeur en entrée, puis orchestrateur-workers derrière, puis critic en sortie sur les cas sensibles).
| Question | Si oui | Pattern |
|---|---|---|
| Tâche décomposable en parallèle ? | Sous-tâches indépendantes | Orchestrateur-workers |
| Ordre métier strict ? | Étapes non négociables | Pipeline séquentiel |
| Utilisateur entre par plusieurs portes ? | Demandes hétérogènes | Routeur |
| Qualité de sortie critique ? | Second passage justifié | Agent critique |
| Décision stratégique ponctuelle ? | Éviter biais de confirmation | Débat |
La combinaison la plus fréquente que je vois en prod : routeur en entrée (Haiku, pas cher), orchestrateur-workers ensuite sur les cas complexes (Sonnet), critic seulement sur les sorties qui partent au client final (Opus si vraiment critique).
Implémentation pratique avec l'API Anthropic et MCP
Côté technique, le pattern de base est toujours le même : l'orchestrateur a une liste d'outils dans son appel API, certains de ces outils sont en réalité des sous-agents Claude. Quand l'orchestrateur décide d'appeler le sous-agent, il fait un tool_use, ton backend intercepte, lance une nouvelle session Claude avec le prompt système du sous-agent, récupère la sortie, la renvoie comme tool_result à l'orchestrateur.
// Pseudo-flow côté backend
orchestrator = claude.messages.create({
system: "Tu es l'orchestrateur veille...",
tools: [analyse_concurrent, synthese_finale],
max_iterations: 5
})
// Quand l'orchestrateur appelle 'analyse_concurrent' :
worker = claude.messages.create({
system: "Tu es analyste concurrentiel...",
messages: [{role: "user", content: tool_input}]
})
return worker.content // devient tool_resultTrois règles non négociables. Sépare les prompts système (un fichier par agent, versionné). Donne un budget de tokens ET un nombre max d'itérations à l'orchestrateur (sinon tu découvres ta boucle infinie sur la facture). Logge chaque appel avec son ID de session, son coût en tokens, sa latence : sans ça, débugger est impossible.
Pour les détails d'intégration, vois l'API Anthropic et le tool use. Et si tes sous-agents doivent attaquer des outils tiers (Notion, Slack, HubSpot, GitHub), connecter vos agents avec MCP évite de réécrire les connecteurs à la main.
Pièges à éviter quand on lance un système multi-agents
Boucle infinie. L'orchestrateur appelle le critic, le critic dit "refais", l'auteur refait, le critic dit "refais". Plafond dur sur le nombre d'itérations, point.
Explosion du coût. Un workflow qui semblait à 0,10€ en test à 1 utilisateur passe à 800€ par jour en prod à 50 utilisateurs. Track les tokens par agent dès le jour 1, sors un dashboard simple par type d'agent et par jour.
Agents qui se renvoient la patate. Personne ne décide vraiment, chacun délègue. Symptôme : ton workflow tourne sans jamais sortir de réponse. Cause : tu n'as pas écrit explicitement "l'orchestrateur tranche, point" dans son prompt système.
Prompts système qui dérivent. Trois personnes modifient les prompts dans Claude.ai sans versionner. Une semaine plus tard, plus personne ne sait pourquoi l'agent rédacteur a changé de ton. Versionne en git.
Absence de logs. Quand un client te remonte "votre agent m'a dit n'importe quoi mardi à 14h", tu dois pouvoir rejouer la session complète, voir chaque sous-appel, chaque sortie intermédiaire. Sans ça, tu navigues à l'aveugle.
Passer à la pratique
Si tu démarres, prends un cas réel limité (un workflow, pas dix), implémente d'abord en mono-agent, mesure ce qui coince, et seulement là, choisis le pattern qui résout exactement ton blocage. Ne construis pas un système multi-agents "au cas où".
Pour structurer ta démarche et éviter les erreurs des trois premiers mois (coûts qui explosent, agents qui dérivent, équipe qui ne suit plus), tu peux piloter vos agents autonomes avec Ottho : 5 semaines pour designer, builder et opérer un système multi-agents qui tourne en production sans te ruiner.