LangGraph supervisor et pattern superviseur : faire d'un agent le chef

Le pattern superviseur est une architecture multi-agents dans laquelle un agent superviseur central décide quel sous-agent spécialisé agit ensuite. Le superviseur reçoit la requête, la route vers les agents workers adéquats, collecte leurs résultats et pilote le déroulement jusqu'à ce que la tâche soit résolue. Il ne traite pas lui-même le fond métier : il délègue et coordonne. Un agent devient ainsi littéralement le chef d'une équipe de spécialistes.

Réponses rapides :

• Que fait le superviseur ? Il route les demandes entre les sous-agents et décide après chaque étape qui prend la main. Les sous-agents ne se parlent pas directement.
• Avec quoi le construire ? En 2026, avec LangGraph 1.0 (open source) ; sur AWS, avec ton propre code de framework dans le Runtime d'Amazon Bedrock AgentCore ; A2A pour les échanges entre fournisseurs, MCP pour les outils.
• Quand est-il pertinent ? Pour des tâches parallélisables et faiblement couplées avec un découpage métier clair, pas pour des workflows d'écriture fortement couplés comme la génération de code.

Comment fonctionne le pattern superviseur

L'idée de base est une topologie en étoile (hub-and-spoke) : au centre se trouve le superviseur, autour, les agents workers spécialisés. Chaque worker a son propre prompt, son propre jeu d'outils et souvent sa propre fenêtre de contexte. Point décisif : les workers ne communiquent pas entre eux, uniquement via le superviseur. Celui-ci décide à nouveau, après chaque résultat intermédiaire, quel agent doit agir ensuite ou si la tâche est terminée.

Une exécution typique suit ce schéma :

1. Le superviseur reçoit la requête de l'utilisateur et identifie de quel type de tâche il s'agit.
2. Il choisit un agent spécialisé adapté et lui confie une mission clairement délimitée.
3. Le worker accomplit sa sous-tâche et renvoie un résultat, idéalement compressé.
4. Le superviseur évalue le résultat et décide : worker suivant, nouvelle tentative ou synthèse finale.

Cette logique de routage centrale distingue le pattern superviseur d'un swarm (agents de même rang sans coordinateur fixe) et d'un pipeline (ordre fixe et déterministe). Le superviseur apporte du pilotage et, point important pour le B2B en Europe, une ligne de responsabilité claire face à la question « Qui a décidé quoi ? ».

Distinction : superviseur ou Orchestrator-Worker

En pratique, les deux termes sont souvent employés comme synonymes, et ce n'est pas faux, mais il existe une nuance qui compte pour le choix d'architecture.

Dans le pattern Orchestrator-Worker (modèle multi-agents canonique selon la taxonomie d'Anthropic), un agent principal décompose la tâche et lance dynamiquement des sous-agents, autant que le plan l'exige à un moment donné. Le cas de référence est l'Anthropic Research Agent (juin 2025) : un Claude Opus 4 principal tourne en mode Extended Thinking, décompose la requête et démarre en parallèle plusieurs sous-agents Sonnet 4, en général trois à cinq selon Anthropic. Chaque sous-agent dispose de sa propre fenêtre de contexte (environ 200k tokens), mène ses recherches de façon autonome et renvoie un résumé compressé, pas la transcription complète. Dans l'évaluation interne de recherche d'Anthropic, le système a obtenu un score supérieur de 90,2 % à celui d'un Opus 4 en agent unique. Le prix à payer : selon Anthropic, les systèmes multi-agents consomment environ 15 fois plus de tokens qu'un chat, un agent seul environ 4 fois plus.

Le pattern superviseur met davantage l'accent sur l'élément de routage : le superviseur décide lequel parmi un ensemble d'agents spécialisés fixes agit ensuite. AWS utilise pour son modèle superviseur le label « Multi-Agent Collaboration ». Au fond, il s'agit d'un pattern superviseur en hub-and-spoke, ni plus ni moins. Pour les variantes à trois niveaux (superviseur → planificateur → worker), on parle de multi-agents hiérarchique : le superviseur décide de quel type de tâche il s'agit, un planificateur construit le graphe des sous-tâches, les workers exécutent.

En pratique : tout orchestrateur est un superviseur, mais tout superviseur ne lance pas d'agents dynamiquement. Pour la plupart des workflows d'entreprise sur des domaines connus, la variante statique du superviseur est plus facile à évaluer et à auditer.

Mise en œuvre : LangGraph et AWS Bedrock

En 2026, il existe deux voies de référence : LangGraph pour ta propre stack et Amazon Bedrock pour les environnements AWS. Chez AWS, la voie recommandée a changé en 2026.

LangGraph (LangChain). Ce runtime d'orchestration basé sur des graphes a atteint avec LangGraph 1.0, le 22 octobre 2025, la première version majeure stable parmi les frameworks d'agents durables. Il propose un template Hierarchical Supervisor, un état durable avec checkpointing (une exécution interrompue reprend au dernier checkpoint après un redémarrage du serveur), la pause et la reprise Human-in-the-Loop ainsi que la prise en charge de Streamable HTTP pour les serveurs MCP distants. Licence : MIT. En 2026, LangGraph est le runtime d'orchestration open source le plus répandu dans les équipes d'AI engineering de la région DACH (Allemagne, Autriche, Suisse).

Pseudo-code simplifié pour un superviseur LangGraph :

```
supervisor = create_supervisor(
agents=[agent_recherche, agent_contrats, agent_validation],
model="reasoning-model",
prompt="Route la requête vers le spécialiste adapté. "
"Mission claire par agent : objectif, format de sortie, limites. "
"Termine quand la tâche est entièrement résolue."
)

L'état circule entre les nœuds sous forme d'objet d'état typé,

est sauvegardé par checkpoints et peut être restauré après un redémarrage.

```

Amazon Bedrock Agents : Multi-Agent Collaboration. AWS a mis la fonction en disponibilité générale en mars 2025. Un agent superviseur travaille avec des agents collaborateurs selon l'un des deux modes : en mode Supervisor, il collecte les réponses des collaborateurs et formule le résultat ; en mode Supervisor with Routing, il transmet simplement la requête au collaborateur adapté et réduit ainsi la latence. S'y ajoutent les Inline Agents ainsi que le trace et le débogage dans la console. Depuis le 30 juillet 2026, le service s'appelle Amazon Bedrock Agents Classic et fonctionne en mode maintenance : les nouveaux comptes ne peuvent plus l'utiliser, les comptes qui l'ont utilisé au cours des douze derniers mois continuent sans date de fin prévue. Aucune nouvelle fonctionnalité ne sera ajoutée.

Amazon Bedrock AgentCore. C'est un produit à part, en disponibilité générale depuis le 13 octobre 2025. AgentCore fournit Runtime, Gateway, Memory, Identity et Observability ; le Gateway connecte les serveurs MCP existants. AWS conseille de développer les nouveaux agents sur AgentCore. Mais AWS qualifie lui-même de limitée la prise en charge multi-agents sur cette plateforme : le pattern superviseur passe par des agents intégrés comme outils MCP (Agent-as-Tool) ; un mode de routage comme dans Bedrock Agents n'y existe pas directement. Pour une vraie collaboration multi-agents, il te faut ton propre code de framework, par exemple LangGraph sur l'AgentCore Runtime.

Pour la communication entre agents, en particulier au-delà des frontières entre fournisseurs, on utilise le protocole A2A (à la Linux Foundation depuis juin 2025). A2A définit un cycle de vie des tâches (submitted → working → input-required → completed | failed | canceled) dans lequel la logique interne de l'agent distant reste opaque. Le superviseur ne voit que la mission et le résultat. Pour l'accès des agents aux outils, MCP est le standard. La règle empirique des fournisseurs : MCP pour la relation agent-outil, A2A pour la relation agent-agent.

Quand il est pertinent, et quand il ne l'est pas

Le pattern superviseur révèle ses atouts sur des problèmes parallélisables à faible couplage d'état entre les sous-tâches, et lorsque le chemin d'écriture est mono-thread ou trivial à fusionner. Bons candidats : travaux de recherche, recherches étendues, fan-out de documents, revue multi-documents, tri des sinistres, détection de fraude avec des contrôles indépendants.

Il échoue sur les tâches séquentielles fortement couplées, où chaque étape conditionne les décisions implicites de toutes les suivantes. Cognition.ai a montré en 2025 (« Don't Build Multi-Agents ») que des essaims d'agents rédacteurs travaillant en parallèle prennent, à cause de la fragmentation du contexte, des décisions incompatibles sur le style et les cas limites, et produisent des diffs impossibles à fusionner. Le contre-exemple type reste la génération de code sur plusieurs fichiers. La conclusion actualisée de Cognition (avril 2026) est pragmatique : le multi-agents fonctionne pour un fan-out majoritairement en lecture, à condition que les écritures restent mono-thread.

Limites : le superviseur comme goulot d'étranglement

La faiblesse centrale tient au nom même : tout passe par le superviseur.

• Point de défaillance unique. Si le superviseur tombe en panne ou s'égare, tout le système s'arrête.
• Goulot d'étranglement de latence. Les étapes passent en série par le superviseur ; avec trois niveaux hiérarchiques, la latence s'accumule en cascade et peut annuler le bénéfice.
• Dérive du plan. Lors des longues exécutions, le superviseur perd son plan et relance des sous-tâches déjà terminées.
• Délégation floue. Des missions mal définies entraînent du travail en double et des lacunes. Anthropic a observé exactement cela lors de ses premières expériences. Remède : chaque worker reçoit un objectif, un format de sortie, des indications sur les outils et des limites de tâche claires.
• Amplification des injections de prompt. Chaque nouvelle fenêtre de contexte de sous-agent constitue une nouvelle surface d'attaque via des contenus non fiables.

Exemple : Allianz Project Nemo

L'exemple pratique le mieux documenté est Allianz Project Nemo, un système superviseur hiérarchique qu'Allianz utilise en Australie pour les sinistres liés à des denrées alimentaires avariées après des intempéries. Sept agents spécialisés collaborent : Planner, Cyber, Coverage, Weather, Fraud, Payout et Audit. Dans l'exemple d'Allianz, le workflow à sept agents, de la déclaration du sinistre jusqu'à la vérification humaine, prend moins de cinq minutes. Un gestionnaire de sinistres examine le résumé d'audit et prend la décision finale de paiement. Ici, le Human-in-the-Loop est une politique explicite.

Les chiffres : lancé en Australie en juillet 2025, en production en moins de 100 jours, selon Allianz avec un temps de traitement et de règlement des sinistres réduit de 80 %. Les sinistres alimentaires inférieurs à 500 AUD sont réglés en un jour au lieu de plusieurs, parfois en quelques heures. Allianz est un assureur allemand et estime son architecture modulaire transposable à d'autres lignes de produits et à d'autres pays.

Sur le plan architectural, l'élément le plus instructif est l'agent d'audit dédié : il produit un résumé complet de toutes les décisions des agents et donc une piste d'audit sans faille pour la conformité et la vérification humaine. La leçon pour les entreprises en Europe : l'auditabilité doit être intégrée à la topologie des agents, pas seulement au pipeline de journalisation.

Pour les agences et les décideurs B2B

Si tu lances un projet multi-agents dans une PME en Europe, le choix rationnel est LangGraph ou n8n pour l'orchestration, MCP pour les outils et A2A pour chaque échange entre plateformes. Pour les grands groupes dotés d'un paysage SaaS dominant, l'orchestration native de la plateforme (Agentforce, SAP Joule Studio, Copilot Studio) est la base la plus évidente, avec A2A comme trait d'union. Important pour les agences qui conseillent des clients : commence par un cas d'usage clairement délimité et parallélisable, garde le chemin d'écriture mono-thread, intègre le Human-in-the-Loop aux points critiques et tiens compte de la chaîne plus longue de contrats de sous-traitance au titre de l'article 28 du RGPD ainsi que des analyses d'impact des transferts de données pour chaque saut A2A transfrontalier. Le benchmark Allianz Nemo (moins de 100 jours jusqu'à la mise en production) est atteignable pour des projets au périmètre restreint.