Architecture hiérarchique d'agents : quand les équipes d'agents passent à l'échelle

Les agents hiérarchiques sont une architecture multi-agents dans laquelle un agent superviseur décompose une tâche complexe, délègue des sous-tâches à des sous-agents spécialisés et fusionne leurs résultats. Au lieu d'un agent unique qui fait tout lui-même, une instance de pilotage de niveau supérieur coordonne plusieurs exécutants subordonnés et agrège leurs sorties en une solution globale. Ce pattern correspond à ce qu'Anthropic appelle « Orchestrator-Workers » et que CrewAI implémente sous le nom de « Hierarchical Process ».

• Superviseur : planifie, décompose, délègue, agrège, mais n'effectue lui-même aucun travail métier de détail.
• Sous-agents : exécutants étroitement spécialisés, avec leur propre prompt et leurs propres outils, qui résolvent chacun une sous-tâche.
• Passage à l'échelle : rentable lorsque les tâches sont clairement décomposables et parallélisables ; sinon, un agent unique coûte moins cher.

Comment fonctionne une architecture hiérarchique

Au fond, la hiérarchie est une extension de la logique orchestrateur-exécutants, dans laquelle un LLM coordinateur décompose dynamiquement une tâche en sous-tâches et les répartit entre des unités subordonnées. Anthropic décrit le pattern correspondant dans « Building Effective Agents » (décembre 2024) sous le nom « Orchestrator-Workers », comme l'un des cinq patterns de workflow canoniques. Sur le plan conceptuel, il est apparenté au pattern Plan-and-Execute, tel que l'implémente par exemple LangChain/LangGraph : là aussi, un modèle établit le plan et des étapes distinctes l'exécutent. Comme usage typique d'Orchestrator-Workers, Anthropic cite les outils de développement qui, à chaque tâche, apportent des modifications complexes à plusieurs fichiers.

Le déroulement suit une boucle récurrente :

1. Le superviseur reçoit la tâche et établit un plan, c'est-à-dire une décomposition en sous-tâches.
2. Il choisit pour chaque sous-tâche un sous-agent adapté et délègue avec le contexte nécessaire.
3. Les sous-agents exécutent leur sous-tâche, généralement en tant qu'agents ReAct autonomes dotés de leurs propres outils, et renvoient un résultat partiel.
4. Le superviseur agrège les résultats partiels, vérifie qu'ils sont complets et décide : nouvelle délégation ou réponse finale.

La séparation des rôles est essentielle. Le superviseur prend les décisions de planification et de coordination ; il n'effectue pas lui-même le travail métier de détail. C'est précisément ce découplage qui permet un choix de modèles économique, un enseignement qui vient directement du pattern Plan-and-Execute : un grand modèle pour la tâche difficile de planification, des modèles plus petits et moins chers pour l'exécution étape par étape dans les sous-agents.

Le diagramme en mots

Imagine un arbre à trois niveaux. À la racine se trouve la requête de l'utilisateur. Un niveau plus bas se tient le nœud superviseur, qui divise la requête en plusieurs branches. Chaque branche aboutit à un nœud sous-agent, par exemple « chercheur », « analyste de données » ou « rédacteur », qui parcourt à son tour sa propre petite boucle ReAct (Thought → Action → Observation) avec ses outils. Les résultats remontent le long des branches jusqu'au superviseur, qui les fusionne en une réponse à la racine. C'est exactement l'image que décrit aussi le pattern de recherche ReAcTree (Choi et al., arXiv:2511.02424, AAMAS 2026), qui étend ReAct à un arbre hiérarchique d'agents et obtient sur le benchmark WAH-NL environ +30 points de pourcentage par rapport au ReAct simple.

Quand la hiérarchie passe à l'échelle

La hiérarchie n'est pas une fin en soi. Elle est payante lorsque la structure de la tâche s'y prête :

• Décomposabilité : la tâche se décompose en plus de trois étapes largement indépendantes.
• Spécialisation : les étapes exigent des connaissances métier différentes ou des outils différents.
• Horizon long : un agent unique perdrait de vue l'objectif initial au fil de nombreuses étapes (en pratique, la limite d'une boucle ReAct se situe souvent entre 10 et 25 étapes, avant que la perte de contexte ou le « reasoning drift » ne prennent le dessus).
• Parallélisme : plusieurs sous-tâches peuvent être traitées simultanément.

La ligne directrice la plus importante pour les systèmes en production vient de Cognition (l'équipe derrière Devin). Dans « Don't Build Multi-Agents » (juin 2025), l'équipe avertissait que des agents parallèles prennent des décisions implicitement contradictoires et que le résultat devient fragile, et recommandait des agents linéaires à fil unique. Comme exemple d'un usage délibérément simple des sous-agents, elle citait Claude Code (situation en juin 2025) : ses sous-agents ne travaillaient alors jamais en parallèle de l'agent principal et se contentaient le plus souvent de répondre à une question au lieu d'écrire du code. Dans « Multi-Agents: What's Actually Working » (avril 2026), Cognition a précisé sa position : les systèmes multi-agents fonctionnent au mieux lorsque les écritures restent sur un seul fil d'exécution et que les agents supplémentaires apportent des connaissances au lieu d'agir eux-mêmes. Résumé en une formule : read-parallel, write-single-threaded. Par ailleurs, chez Devin, un Devin manager peut décomposer une tâche plus large, faire exécuter les sous-tâches par des Devins enfants et coordonner leur progression via un MCP interne. Selon Cognition, cela fonctionne déjà en production, mais il a fallu plus de context engineering que prévu pour que cette délégation devienne cohérente. Pour la pratique, nous en tirons la conclusion suivante : un agent solide doté d'outils par défaut, des sous-agents parallèles pour collecter des informations, mais jamais plusieurs agents qui modifient en parallèle le même état. Les sous-tâches d'écriture, tu ne les délègues que sous forme de lots de travail clairement séparés, sous la responsabilité d'un manager.

Avantages et risques

Le principal inconvénient est la surcharge de coordination. Chaque agent supplémentaire implique des appels LLM en plus pour la planification, la délégation et l'agrégation, ainsi que le risque de perdre des informations lors de la transmission du contexte. D'où la règle empirique générale tirée de l'essai d'Anthropic et du blog de Cognition : commencer par le pattern le plus simple qui fonctionne (généralement un agent ReAct unique) et ne passer à la planification, à la réflexion ou à la hiérarchie que lorsque des modes de défaillance mesurés l'imposent. Anthropic avertit en outre que les frameworks introduisent des couches d'abstraction supplémentaires qui masquent les prompts et les réponses et incitent à une complexité inutile.

Différences avec les systèmes multi-agents plats

Dans un système multi-agents plat, des agents de même rang communiquent directement entre eux ; il n'existe pas d'instance de pilotage centrale qui délègue et agrège. C'est flexible, mais sans instance de coordination, les agents prennent facilement des décisions implicitement contradictoires, car aucun ne dispose du contexte global. Un superviseur seul ne règle pas le problème : dans l'exemple Flappy Bird de « Don't Build Multi-Agents », un agent principal décompose la tâche, et les sous-agents livrent malgré tout des résultats partiels incompatibles, parce que le contexte leur manque et qu'aucun ne voit ce que construit l'autre.

Dans le système hiérarchique, le superviseur concentre la responsabilité. Il est le seul acteur à avoir une vue d'ensemble, attribue des missions partielles claires et intègre les résultats. Cela réduit le risque de décisions contradictoires, à condition que le superviseur transmette le contexte complet et que les écritures restent sur un seul fil d'exécution. Le prix à payer : un goulot d'étranglement central et des étapes de coordination supplémentaires. Pour la plupart des scénarios B2B en Europe soumis à des exigences de conformité, la variante hiérarchique est la plus prévisible, car le chemin de délégation reste auditable.

Frameworks et mise en œuvre (situation en 2026)

• CrewAI : correspondance directe. Process.hierarchical active un manager (manager_agent ou manager_llm) qui délègue les tâches à la crew et ajoute un niveau de replanification managériale. Avec Crew(planning=True), un AgentPlanner génère en plus un plan étape par étape avant chaque itération. CrewAI est très répandu dans l'univers de l'automatisation marketing de la région DACH (Allemagne, Autriche, Suisse).
• LangGraph : sous forme de graphe d'état avec un nœud superviseur et plusieurs sous-agents ReAct (create_react_agent, dans l'API de 2026 de plus en plus langchain.agents.create_agent avec middleware). Les tutoriels Plan-and-Execute et ReWOO fournissent les briques pour la planification et l'exécution déléguée.
• Microsoft Agent Framework : l'orchestration Magentic fait appel à un agent manager qui établit un plan, attribue les sous-tâches à des agents exécutants, suit la progression et replanifie en cas de blocage. Pour une coordination plus simple, un orchestrateur détermine dans le Group Chat quel agent intervient ensuite. AutoGen est en mode maintenance ; les nouveaux projets sont orientés vers Microsoft Agent Framework.
• n8n : réaliste pour des workflows batch orchestrés (agent planificateur plus exécutants exposés comme outils via des sous-workflows), mais les boucles avec état d'une exécution à l'autre nécessitent un stockage externe.

Exemple pratique : l'analyse concurrentielle comme workflow d'agence

Une agence doit réaliser une analyse concurrentielle pour un client B2B. Un agent unique perdrait l'objectif de vue au fil de nombreux appels d'outils. En version hiérarchique, le déroulement se présente ainsi (pseudo-code) :

```
Supervisor.plan("Analyse concurrentielle pour le client X"):
-> Sous-tâche 1: research_agent("Top 5 des concurrents + positionnement")
-> Sous-tâche 2: pricing_agent("recenser les modèles de prix publics")
-> Sous-tâche 3: seo_agent("visibilité organique des concurrents")
# 1-3 s'exécutent en parallèle (read-only)

results = gather(1, 2, 3) # sous-agents de lecture parallèles
Supervisor.aggregate(results) # seule étape d'écriture
-> writer_agent("Synthèse managériale à partir des éléments recueillis") # single-threaded
```

Trois sous-agents en lecture travaillent en parallèle et fournissent des éléments probants ; le superviseur les fusionne, et une seule étape d'écriture (la rédaction de la synthèse) reste sur un seul fil d'exécution. Le workflow suit ainsi le principe recommandé par Cognition : lire en parallèle, n'écrire que sur un seul fil. Grâce au tiering de modèles (un grand modèle pour le superviseur et le rédacteur, un modèle moins cher pour les exécutants en lecture), une économie d'environ 40 à 70 % par rapport à une variante coûteuse de bout en bout est réaliste sur des workflows à plusieurs étapes (ordre de grandeur, situation en 2026 ; mesure-le sur ta propre charge).

Pour les agences et le B2B

Les agents hiérarchiques ne sont pas un choix par défaut, mais une escalade délibérée. Pour les agences, cela signifie que les livrables décomposables et récurrents, comme les briefings de recherche, les reportings ou les pipelines de contenu, se prêtent à un superviseur doté de sous-agents de lecture spécialisés, tandis que l'étape finale, celle qui modifie l'état, reste centralisée. Pour les décideurs B2B en Europe, l'auditabilité du chemin de délégation (persistance complète des traces avec nettoyage des données personnelles) est un avantage concret au regard du RGPD et du règlement européen sur l'IA. Si tu veux évaluer un workflow d'agents hiérarchique pour le marketing ou les opérations, commence par un cas concret mesurable, garde comme référence le pattern le plus simple qui fonctionne et ne passe à la hiérarchie qu'une fois son utilité démontrée. Blck Alpaca accompagne cette décision d'architecture dans le cadre de l'intégration d'agents IA, de la décomposition des tâches jusqu'à une mise en production conforme à la réglementation.