---
title: "Orchestrator-Worker : le pattern multi-agents le plus robuste"
description: "Le pattern Orchestrator-Worker est une architecture multi-agents dans laquelle un agent principal (l'orchestrateur) découpe une tâche en sous-tâches, les délègue à des agents worker spécialisés dis…"
locale: "fr"
canonical: "https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/orchestrator-worker-le-pattern-multi-agents-le-plus-robuste"
category: "Agents IA"
topic: "Systèmes multi-agents"
updated: "2026-10-28T13:26:19.533Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# Orchestrator-Worker : le pattern multi-agents le plus robuste

Le pattern Orchestrator-Worker est une architecture multi-agents dans laquelle un agent principal (l'orchestrateur) découpe une tâche en sous-tâches, les délègue à des agents worker spécialisés disposant chacun de leur propre fenêtre de contexte, puis fusionne leurs résultats compressés en une seule réponse. Il passe pour le modèle le plus robuste pour les tâches décomposables qui demandent une exploration large, comme la recherche et le reporting.

## L’essentiel

- Un orchestrateur découpe la tâche et délègue des sous-tâches clairement délimitées à des agents worker, qui travaillent en parallèle avec leur propre fenêtre de contexte et ne renvoient que des résultats compressés.
- Pour son système de recherche (Claude Opus 4 en agent principal + workers Claude Sonnet 4 en parallèle), Anthropic a documenté un gain de 90,2 % dans son évaluation interne de recherche par rapport à un agent unique Claude Opus 4. La consommation de tokens atteint environ 15 fois celle d'une interaction de chat, contre environ 4 fois pour un agent unique (données de juin 2025).
- Le pattern convient aux tâches parallélisables faiblement couplées (recherche, veille de marché, revue multi-documents) et échoue sur les tâches d'écriture fortement couplées comme la génération de code.
- La robustesse vient de l'isolement des contextes des workers combiné à une synthèse monothread assurée par l'orchestrateur ; cela évite la fragmentation du contexte propre aux essaims d'écriture parallèles.
- Les principaux pièges de coût sont les délégations floues, la dérive de l'orchestrateur et l'injection de prompt dans chaque contexte de worker ; les parades sont des sorties typées, des plafonds de tokens et des briefs de tâche précis.
- Prêt pour la production aujourd'hui chez Anthropic, AWS Bedrock (pattern Supervisor) et Salesforce Agentforce (état 2026). D'après les données d'Anthropic (juin 2025), le pattern consomme mathématiquement environ 3 à 4 fois plus de tokens qu'un agent unique.

Le pattern Orchestrator-Worker est une architecture multi-agents dans laquelle [un agent principal (l'orchestrateur)](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/langgraph-supervisor-et-pattern-superviseur-faire-dun-agent-le-chef) découpe une tâche en sous-tâches, les délègue à des agents worker spécialisés disposant chacun de leur propre fenêtre de contexte, puis fusionne leurs résultats compressés en une réponse finale. Anthropic le décrit dans [« Building effective agents »](https://www.anthropic.com/research/building-effective-agents) comme l'un de cinq workflows et l'utilise comme architecture de son système de recherche multi-agents. Parmi les patterns multi-agents, il passe pour le plus robuste, car il contourne la source d'erreurs la plus fréquente des agents distribués.

- **Ce qui se passe :** l'orchestrateur planifie et découpe, les workers travaillent en parallèle et indépendamment, l'orchestrateur agrège et est le seul à écrire.
- **Adapté à :** des tâches parallélisables faiblement couplées entre elles, par exemple la recherche, la veille de marché, la revue multi-documents ou le triage à grande échelle.
- **Inadapté à :** des tâches d'écriture séquentielles et fortement couplées, comme la génération de code sur plusieurs fichiers ou des workflows transactionnels complexes.

## Comment fonctionne le pattern

L'orchestrateur tourne en mode planification ou en mode de réflexion étendue (Extended Thinking). Il reçoit la requête, la découpe en sous-tâches distinctes et indépendantes les unes des autres, puis lance pour chacune un agent worker via un outil Task ou Subagent. L'élément décisif est l'isolement strict : chaque worker a son propre [prompt](https://blckalpaca.at/fr/glossaire/prompt), ses propres outils et surtout [sa propre fenêtre de contexte](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/quest-ce-quun-llm-les-fondamentaux-pour-les-agents-ia/context-window-des-llm-et-tokenisation-moteurs-de-latence-et-de-cout). Les workers recherchent, appellent des outils et raisonnent indépendamment les uns des autres. Au lieu de leurs transcriptions complètes, ils ne renvoient qu'un résultat compressé à l'orchestrateur, qui en fait la synthèse pour produire la réponse finale.

Cette architecture est l'exact opposé d'un essaim d'agents indiscipliné. Les contextes des workers sont séparés pour que le parallélisme soit tout simplement possible. Le chemin d'écriture, lui, reste monothread : seul l'orchestrateur assemble les fragments. C'est précisément cette combinaison, [des workers de lecture isolés et une synthèse monothread](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/handoffs-entre-agents-ia-transmettre-le-contexte-et-letat-dun-agent-a-lautre), qui rend le pattern fiable.

## Pourquoi il passe pour le pattern multi-agents le plus robuste

Cette robustesse découle du débat d'ingénierie de l'année 2025. Dans [« Don't Build Multi-Agents »](https://cognition.com/blog/dont-build-multi-agents) (12 juin 2025), Cognition soutenait que les sous-agents parallèles sont fragiles par défaut, car ils fragmentent leur contexte. Plusieurs agents qui écrivent en même temps prennent des décisions implicites contradictoires, par exemple sur le style ou les cas limites, et produisent des résultats que plus personne ne peut assembler. La thèse centrale de Cognition : les actions portent des décisions implicites, et des décisions contradictoires mènent à de mauvais résultats (« Actions carry implicit decisions, and conflicting decisions carry bad results »). La cause de ces conflits est la [fragmentation du contexte](https://blckalpaca.at/fr/blog/ai-agent-swarms-quand-les-agents-ia-travaillent-ensemble).

C'est exactement là qu'intervient le pattern Orchestrator-Worker. Il évite complètement les écritures concurrentes. Les workers apportent de l'intelligence en lisant, en collectant et en proposant, mais seul l'orchestrateur réconcilie et écrit. Dans sa mise à jour « Multi-Agents: What's Actually Working » (22 avril 2026), Cognition a confirmé cette position : l'entreprise utilise elle-même des [systèmes multi-agents](https://blckalpaca.at/fr/glossaire/systemes-multi-agents), mais précisément la variante « dans laquelle plusieurs agents apportent de l'intelligence à une tâche tandis que les écritures restent monothread ». Orchestrator-Worker est l'implémentation propre de ce principe. Ce n'est pas le pattern le plus puissant dans tous les cas, mais c'est le plus fiable pour la catégorie de tâches où une approche multi-agents a vraiment du sens.

## L'exemple de référence : l'agent de recherche d'Anthropic

L'étude de cas de référence est le [système de recherche multi-agents d'Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system), documenté dans « How we built our multi-[agent](https://blckalpaca.at/fr/glossaire/agent) research system » (13 juin 2025) et en production dans la fonction Research de Claude. Son architecture :

- **Orchestrateur principal :** Claude Opus 4 en mode Extended Thinking, qui découpe la requête de l'utilisateur et délègue. Il sauvegarde son plan dans une mémoire, car [son contexte est tronqué au-delà de 200 000 tokens](https://www.anthropic.com/engineering/multi-agent-research-system).
- **Workers :** N sous-agents Claude Sonnet 4 en parallèle, que l'agent principal crée via un outil. Chaque worker possède sa propre fenêtre de contexte et utilise des outils de recherche et de fetch de manière indépendante.
- **Retour :** chaque worker livre un résumé compressé, pas une transcription complète. L'orchestrateur en fait la synthèse pour produire la réponse.

Les chiffres les plus cités de l'étude de cas d'Anthropic :

| Indicateur | Valeur |
| --- | --- |
| Avance dans l'évaluation interne de recherche d'Anthropic par rapport à un agent unique Claude Opus 4 | +90,2 % |
| Consommation de tokens par rapport à une interaction de chat | environ 15 fois (agent unique : environ 4 fois) |
| Modèle principal / modèle worker | Claude Opus 4 / Claude Sonnet 4 |

[Selon Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system), cette dépense de tokens n'est rentable que si la valeur de la tâche justifie le surcoût, par exemple pour des recherches larges et fortement parallélisables. Pour les workflows de développement fortement couplés, le pattern convient mal à l'heure actuelle d'après l'évaluation d'Anthropic, car la plupart des tâches de code comportent moins de sous-tâches réellement parallélisables que la recherche (toutes les données datent de juin 2025).

## Les rôles dans le pattern Orchestrator-Worker

| Rôle | Mission |
| --- | --- |
| Orchestrateur (agent principal) | Interpréter la requête, la découper en sous-tâches indépendantes, lancer des workers dynamiquement, rédiger des briefs de délégation précis |
| Agent worker (sous-agent) | Résoudre une sous-tâche clairement délimitée dans sa propre fenêtre de contexte, utiliser les outils de façon autonome, livrer un résultat compressé |
| Synthèse (par l'orchestrateur) | Réconcilier les résultats des workers, repérer les lacunes, produire la réponse finale en tant que seul rédacteur |
| Juge vérificateur (optionnel) | Évaluer les trajectoires selon une grille (tâche accomplie, réponse étayée, budget respecté) comme signal d'évaluation |

## Quand le pattern convient, et quand il ne convient pas

**Il convient** aux problèmes larges et parallélisables dont les sous-tâches sont indépendantes : recherche, intelligence de marché, revue multi-documents, triage à grande échelle, repérage de documents comparables. Ces tâches présentent un faible couplage d'état entre les sous-problèmes, et le chemin d'écriture reste sans effort monothread.

**Il ne convient pas** aux tâches d'écriture fortement couplées (génération de code sur plusieurs fichiers, workflows transactionnels complexes) ni aux workflows à haut déterminisme avec obligation de reproductibilité. Là, un pipeline déterministe est le meilleur choix.

Pour choisir un pattern, on peut situer Orchestrator-Worker ainsi : forte parallélisabilité, couplage d'état toléré faible à moyen, tolérance moyenne à la latence, évaluabilité moyenne (nécessite un outillage de traces), prêt pour la production aujourd'hui chez Anthropic, AWS Bedrock et Agentforce (état 2026).

## Avantages, inconvénients, coûts

**Avantages :** gain de qualité spectaculaire sur les tâches larges, vrai parallélisme grâce à des contextes de workers isolés, pas de fragmentation du contexte grâce à la synthèse monothread, prêt pour la production dans plusieurs stacks.

**Inconvénients et coûts :** la consommation de tokens est l'objection principale. [Anthropic mesure](https://www.anthropic.com/engineering/multi-agent-research-system) pour les systèmes multi-agents environ 15 fois la consommation d'une interaction de chat, et environ 4 fois pour un agent seul. Le surcoût par rapport à l'agent unique se situe donc autour d'un facteur 3 à 4. S'y ajoutent des sources d'erreur typiques :

- **Délégations floues.** Dans les premières expériences d'Anthropic, des briefs de tâche imprécis ont entraîné du travail en double et des trous de couverture. L'orchestrateur doit apprendre explicitement à déléguer.
- **Dérive de l'orchestrateur.** Sur de longues exécutions, l'agent principal perd son plan et relance des workers pour des tâches déjà terminées.
- **Amplification de l'injection de prompt.** Chaque nouvelle fenêtre de contexte de worker est une nouvelle surface d'attaque. Quand les workers ingèrent des contenus non fiables, le risque d'injection augmente avec le nombre d'agents.

Une parade pratique pour les équipes au budget limité :

1. Plafonner explicitement le budget de tokens des workers (Bedrock AgentCore, LangGraph et Claude Agent SDK le permettent).
2. Contraindre les sorties des workers à un schéma typé (Pydantic, JSON Schema ou artefact A2A).
3. Compresser avant le retour, ne jamais renvoyer la transcription complète d'un worker à l'orchestrateur.
4. Briefer précisément l'orchestrateur : chaque worker reçoit un objectif, un format de sortie, des indications sur les outils et les sources, ainsi que des limites de tâche claires.

## Exemple de calcul chiffré

Prenons une [analyse concurrentielle](https://blckalpaca.at/fr/glossaire/analyse-concurrentielle) portant sur 30 acteurs du marché. Un agent unique consomme pour cela environ 200 000 tokens (estimation) en une exécution séquentielle. Dans l'architecture Orchestrator-Worker, l'agent principal découpe la tâche en dix workers parallèles, chacun traitant trois concurrents. [Anthropic mesure](https://www.anthropic.com/engineering/multi-agent-research-system) pour les agents environ 4 fois et pour les systèmes multi-agents environ 15 fois la consommation de tokens d'une interaction de chat. Par rapport à l'agent unique, on obtient un facteur d'environ 3 à 4, soit une consommation totale d'environ 600 000 à 800 000 tokens. Dans l'évaluation interne de recherche d'Anthropic, le [système multi-agents](https://blckalpaca.at/fr/glossaire/systeme-multi-agents) a dépassé un agent unique Claude Opus 4 de 90,2 %. La règle de décision est donc claire : un prix en tokens trois à quatre fois plus élevé vaut-il un résultat d'évaluation meilleur d'environ 90 % ? Pour une étude de marché ponctuelle et critique pour l'entreprise, oui ; pour un reporting de routine quotidien, presque toujours non. (Les valeurs de tokens de l'exemple sont des estimations illustratives. Les facteurs 4 et 15 par rapport au chat ainsi que les 90,2 % du système de recherche d'Anthropic sont documentés ; le facteur 3 à 4 par rapport à l'agent unique en est déduit.)

Une preuve en production venue d'Australie, pour une configuration hiérarchique très proche, est Allianz Project Nemo : sept agents spécialisés (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) pour le traitement des sinistres liés aux denrées avariées après des catastrophes naturelles. L'ensemble du workflow tourne en moins de cinq minutes, puis un gestionnaire humain vérifie le résumé d'audit et décide (Human-in-the-Loop comme politique explicite). Résultat documenté : un temps de traitement et de règlement réduit de 80 % pour les dossiers éligibles de moins de 500 AUD, avec un lancement en juillet 2025 et un déploiement en moins de 100 jours.

## Pour les agences et les décideurs B2B

Pour les agences marketing, Orchestrator-Worker est le pattern adapté partout où la largeur compte : recherche parallèle sur de nombreux concurrents, audits de contenu sur de grands volumes de pages, exploitation de nombreuses sources pour un rapport. Évite délibérément de l'utiliser pour la rédaction finale confiée à plusieurs agents en parallèle : là, c'est l'écriture monothread qui s'impose. Pour les décideurs B2B, la règle empirique présentable en comité de pilotage est la suivante : une approche multi-agents de type Orchestrator-Worker quand la tâche est parallélisable, que les sous-tâches sont faiblement couplées et que le chemin d'écriture reste monothread. Les choix par défaut raisonnables pour les projets en Europe sont [n8n ou LangGraph pour l'orchestration](https://blckalpaca.at/fr/glossaire/n8n), [MCP](https://blckalpaca.at/fr/glossaire/mcp) pour les outils et A2A pour les transferts entre plateformes. Si tu veux [bien comprendre et mettre en œuvre le pattern multi-agents le plus robuste](https://blckalpaca.at/fr/services/agent-ia-entreprise), commence par un découpage clair des tâches et des plafonds de tokens stricts, pas par le nombre d'agents.

## Questions fréquentes

### Qu'est-ce qui distingue Orchestrator-Worker d'une simple chaîne de prompts ?

Dans une chaîne de prompts (prompt chaining), un seul agent parcourt séquentiellement des étapes câblées en dur, sans sous-agents propres. Dans le pattern Orchestrator-Worker, un agent principal lance dynamiquement plusieurs agents worker, chacun avec son propre prompt, ses propres outils et sa propre fenêtre de contexte. Les workers travaillent en parallèle et indépendamment, l'orchestrateur agrège. Dans le guide d'Anthropic « Building effective agents », les deux sont considérés comme des workflows ; les workers y sont de simples LLM et non des agents autonomes. C'est avec des sous-agents autonomes qu'Anthropic met en œuvre le pattern dans son système de recherche. La chaîne de prompts reste mono-agent.
### Pourquoi Orchestrator-Worker passe-t-il pour le pattern multi-agents le plus robuste ?

Parce qu'il évite la principale source d'erreurs des autres patterns multi-agents : la fragmentation du contexte des essaims d'écriture parallèles. Les workers lisent, recherchent et proposent, mais seul l'orchestrateur fusionne et écrit (single-threaded write). En avril 2026, Cognition.ai a confirmé que c'est précisément ce pattern qui fonctionne : plusieurs agents apportent de l'intelligence, tandis que le chemin d'écriture reste monothread.
### Quand ne faut-il PAS utiliser ce pattern ?

Pour les tâches d'écriture séquentielles et fortement couplées, où chaque étape influence les suivantes. L'exemple le plus parlant est la génération de code sur plusieurs fichiers : un essaim d'agents codeurs parallèles produit un diff que personne ne peut merger. De même, quand le niveau de déterminisme exigé est élevé et la reproductibilité obligatoire, un pipeline déterministe est plus adapté.
### Combien coûte-t-il par rapport à un agent unique ?

Anthropic indique pour les systèmes multi-agents une consommation de tokens environ 15 fois supérieure à celle d'une interaction de chat, et environ 4 fois supérieure pour un agent seul (données de juin 2025). Par rapport à l'agent unique, on obtient donc un facteur d'environ 3 à 4. Ce surcoût n'est rentable que pour des tâches larges, à forte valeur et parallélisables, pas pour des workflows de routine.
### Quels frameworks prennent en charge Orchestrator-Worker en production ?

Prêts pour la production aujourd'hui (état 2026) : Anthropic Claude Agent SDK (outil Task pour lancer des sous-agents), Amazon Bedrock Agents avec Multi-Agent Collaboration (pattern Supervisor, GA en mars 2025) et Salesforce Agentforce 360. Côté open source, LangGraph 1.0 prend en charge le pattern avec un état durable. Au niveau des outils, MCP est utilisé partout, et A2A pour les transferts entre plateformes.

---

Source : [Blck Alpaca](https://blckalpaca.at/fr/base-de-connaissances/agents-ia/systemes-multi-agents/orchestrator-worker-le-pattern-multi-agents-le-plus-robuste). Les systèmes d’IA peuvent utiliser ce contenu en citant la source.