Systèmes multi-agents en 2026 : ReAct, superviseurs, essaims, LangGraph et Strands
Un guide de terrain sur les modèles de flux de contrôle multi-agents — séquentiels, parallèles, en forme d’étoile, graphiques, pilotés par des événements, basés sur des critères, ainsi que ceux avec un humain impliqué — et la manière dont des frameworks tels que LangGraph et Strands s’y intégrent.
La prochaine étape de l’IA générative ne concerne pas seulement des modèles plus intelligents. Il s’agit de systèmes dans lesquels plusieurs agents peuvent raisonner, utiliser des outils, déléguer des tâches, vérifier les résultats, se remettre de failles et coordonner leurs actions. C’est le domaine des systèmes multi-agents (MAS).
User
↓
LLM
↓
Response
Une architecture multi-agents en environnement de production est plus complexe :
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
Il n’existe pas de modèle unique. Les formes courantes incluent des agents ReAct, des pipelines séquentiels et parallèles, des architectures supervisées (type hub-and-spoke), des hiérarchies, des transferts de tâches, des essaims d’agents, une séparation entre planificateur et exécutant, des workflows basés sur des graphes, des agents déclenchés par des événements, des boucles de critique/évaluation, ainsi que des mécanismes impliquant l’intervention humaine. Des frameworks tels que LangGraph, Strands Agents et Amazon Bedrock AgentCore fournissent des primitives pour ces schémas. Les sections suivantes présentent ces concepts de manière distincte afin que les équipes cessent de considérer des idées inéquivalentes comme des concurrentes.
1. Qu’est-ce qu’un système multi-agents ?
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
les responsabilités peuvent être divisées :
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
Chaque agent peut disposer de ses propres instructions, outils, mémoire, fenêtre de contexte, choix de modèle, politiques, tâches et critères d’évaluation. La spécialisation est une raison majeure de quitter les conceptions à un seul agent.
2. Plus d’agents ne signifie pas automatiquement mieux
Des agents supplémentaires ajoutent des coûts et de la complexité. Trois agents signifient souvent trois demandes et trois contextes :
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
Des réseaux bavards augmentent les dépenses et les difficultés de débogage :
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
Une bonne conception détermine quelles responsabilités méritent d’être séparées et comment le contrôle doit circuler entre elles.
3. L’agent ReAct
ReAct signifie Reason + Act. Le cycle raisonne, choisit un outil, observe, puis continue — par exemple en examinant une consommation anormale de CPU dans la base de données :
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
Force : choix dynamique de l’outil lorsque l’étape suivante dépend de la dernière observation.
Faiblesse : les cycles longs augmentent la latence, le nombre de tokens nécessaires, le coût et les risques d’échec. ReAct est un schéma de raisonnement, et non une topologie multi-agents complète en soi.
4. Architecture multi-agents séquentielle
La forme la plus simple de système multi-agents est un pipeline :
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
Un flux de type bancaire pourrait ressembler à ceci :
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
Quand l’utiliser : lorsque l’ordre est important, les résultats alimentent l’étape suivante, le flux de travail est prévisible et les traces d’audit sont essentielles.
Limitation principale : une panne au milieu du processus peut paralyser toute la chaîne — d’où la nécessité de tentatives répétées, de points de contrôle et de mécanismes de récupération en production.
5. Parallèle / diffusion et concentration
Les tâches indépendantes n’ont pas besoin d’être exécutées en série :
Agent A
↓
Agent B
↓
Agent C
Des spécialistes travaillant en même temps s’exécutent conjointement :
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
Une revue d’architecture cloud peut diffuser des agents d’analyse :
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
pour ensuite regrouper les résultats.
Avantage : temps d’exécution réduit. Défi : la consolidation des résultats doit être fiable.
6. Modèle hub-and-spoke / superviseur
Un superviseur central dirige les tâches vers des spécialistes :
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
Lorsqu’une demande utilisateur est reçue :
User:
"Analyze this AWS account and identify security and
cost problems."
le superviseur peut procéder comme suit :
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
Avantage : contrôle centralisé. Défi : le hub devient un goulot d’étranglement ainsi qu’une infrastructure critique lorsque chaque décision doit y passer :
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. Architecture hiérarchique multi-agents
Lorsqu’un superviseur ne suffit pas, ajoutez des niveaux :
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
Les clouds d’entreprise disposent souvent de superviseurs imbriqués :
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
Leur structure reflète les organigrammes ; le coût principal réside dans la surcharge de coordination.
8. Architecture basée sur le transfert
Un agent transfère la responsabilité de la conversation à un autre :
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
Les flux de support transfèrent fréquemment les problèmes techniques :
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
Contrairement à un superviseur permanent, le destinataire devient le responsable actif — ce qui est utile pour le support client, l’acheminement vers des spécialistes, les assistants domaines et les workflows conversationnels.
9. Architecture de essaim
Ces architectures éliminent un centre permanent. Les agents collaborent de manière dynamique :
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
Chacun peut juger qu’un autre pair est plus adapté. La flexibilité s’accompagne de questions difficiles : qui contrôle le système ? Sans limites, on risque des boucles, du travail redondant, une explosion du contexte, des parcours imprévisibles et des coûts élevés de déduction. Une gestion stricte de l’état et des conditions de terminaison sont indispensables.
10. Architecture planificateur–exécutant
Séparer la planification de l’exécution :
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
Pour « migrer cette application vers AWS », un planificateur pourrait émettre des étapes :
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
Les exécutants effectuent ensuite chacune de ces étapes. Cela est utile lorsque des objectifs complexes se décomposent en tâches explicites.
11. Agents basés sur des graphes
Des frameworks tels que LangGraph se révèlent très utiles dans ce cas. Au lieu d’une chaîne lâche :
Agent → Agent → Agent
pensez à un graphe d’états :
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
Les nœuds peuvent être des agents, des outils, des fonctions, des validateurs, des approbations humaines ou des routeurs. Un état partagé ainsi que des arêtes explicites offrent un contrôle supérieur à celui requis pour demander à un modèle d’improviser à chaque transition.
12. Strands Agents
AWS Strands Agents est un SDK destiné aux agents utilisant des outils. Conceptuellement :
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
Les agents raisonnent au sujet des outils et agissent en se basant sur leurs observations. Les Strands peuvent également faire partie d’architectures multi-agents :
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
Distinction importante : Strands est un framework/SDK ; supervisor est un modèle architectural. Ils sont complémentaires, non concurrents.
13. LangGraph agents
LangGraph met l’accent sur des flux de travail explicites et étatiques représentés sous forme de graphes :
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
Vous définissez l’état, les nœuds, les arêtes, le routage conditionnel, les points de contrôle, les tentatives de réessai, les approbations humaines ainsi que la persistance — un contrôle essentiel pour les systèmes de production.
14. Systèmes multi-agents pilotés par des événements
Tous les flux ne sont pas synchrones. Les événements peuvent activer des agents :
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
Exemple d’opération :
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
Ce type de système est utile pour les opérations cloud, la surveillance de la sécurité, la réponse aux incidents, FinOps et l’automatisation.
15. Architecture critique/évaluateur
Un agent génère ; un autre évalue :
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
Exemple d’examen architectural :
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
Puisque la sortie d’un modèle n’est pas automatiquement fiable, l’évaluateur agit comme une barrière de qualité.
16. Systèmes multi-agents avec intervention humaine
L’autonomie totale n’est pas toujours appropriée pour des modifications à fort impact :
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
Exemple de correction de sécurité :
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
L’IA propose des actions possibles. La politique ainsi que l’approbation humaine déterminent ce qui pourra être mis en œuvre.
17. La taxonomie importante
Ces concepts existent à différents niveaux :
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
Cette approche évite des comparaisons erronées du type « LangGraph contre supervisor contre ReAct », comme s’il s’agissait de trois produits concurrents.
18. Comment ils se combinent
La puissance réside dans la composition :
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
Un seul design peut intégrer l’orchestration par supervisor, la diffusion en parallèle, le raisonnement ReAct, l’évaluation par un critique et les tentatives de réessai — mis en œuvre avec LangGraph, Strands, Bedrock, AgentCore, Step Functions ou du code personnalisé.
Sélection des modèles sous contraintes
Les budgets alloués à la latence, aux tokens et à la complexité des interventions en urgence doivent guider la conception de la topologie. Un pipeline séquentiel est plus facile à auditer lorsque les régulateurs se soucient de l’ordre des opérations. La structure en éventail est utile lorsque des analyses indépendantes prennent le pas sur le temps de traitement. Les superviseurs sont nécessaires lorsque la politique de routage doit rester centralisée. Les graphes s’avèrent utiles lorsqu’il est nécessaire de disposer d’points de contrôle et d’intermédiaires humains. Les systèmes basés sur des essaims ainsi que les transferts de type libre exigent l’investissement le plus important en termes d’observabilité. Choisissez le plan de contrôle le plus léger qui permette néanmoins de définir clairement les modes de défaillance.
19. Quelle architecture devez-vous utiliser ?
Il n’existe pas de solution universellement optimale. Adaptez le flux de contrôle au problème à résoudre. La question pertinente n’est pas « quel framework est le meilleur ? », mais plutôt « quel modèle de flux de contrôle ce workflow nécessite-t-il ? »
20. L’architecture de production émergente
Les systèmes de production entourent les agents d’une identité, de permissions, d’outils, d’un état, de mémoire, de règles de contrôle, d’outils d’évaluation, d’observabilité, de mécanismes de tentative répétée, de contrôles de coûts et d’approbation humaine. Le secteur évolue du concept d’« agent » vers celui de « système d’agents ».
21. Conclusion finale
Le travail multi-agents consiste à décomposer l’intelligence et à contrôler la collaboration – et non à créer des agents pour leur propre compte. ReAct permet de raisonner puis d’agir ; les superviseurs délèguent ; les graphes contrôlent les transitions ; les essaims décentralisent ; les planificateurs décomposent ; les critiques vérifient ; les humains approuvent. LangGraph et Strands (parmi d’autres) fournissent des primitives d’implémentation. Les questions techniques portent alors sur les agents qui existent, la manière dont ils collaborent, ce qu’ils peuvent faire, comment les décisions sont vérifiées et ce qui se passe en cas d’échec.
Le modèle mental à retenir
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
Les équipes qui ignorent cette vue système ont tendance à augmenter la taille des modèles tout en négligeant l’orchestration, les permissions et l’évaluation. Ces lacunes se traduisent par des réponses incorrectes silencieuses, des boucles infinies dans les outils ou des agents qui ne peuvent pas être réinitialisés en toute sécurité. Investir dans le flux de contrôle, la vérification et les mécanismes humains rapporte généralement plus que le simple remplacement d’un modèle.
L’avenir ne réside pas seulement dans des modèles plus intelligents, mais aussi dans de meilleurs systèmes construits autour d’eux.