En bref
Un système multi-agents distribue un problème complexe entre plusieurs agents spécialisés qui coopèrent. L’efficacité repose sur des protocoles de communication standardisés et une ontologie partagée — sans ces deux éléments, la collaboration produit du bruit plutôt que de la valeur. Six modèles d’interrelation décrivent les architectures disponibles, chacun avec ses compromis entre contrôle centralisé, résilience et complexité opérationnelle.
Pourquoi un seul agent ne suffit pas toujours
Imaginez une rédaction de presse : un journaliste solitaire qui devrait à la fois enquêter, rédiger, fact-checker et mettre en page produirait nécessairement moins bien qu’une équipe où chacun a son rôle. Mais une équipe sans protocole — chacun parle dans le vide, personne ne sait qui s’occupe de quoi — produit pire qu’un solitaire désorganisé. Les systèmes multi-agents reproduisent fidèlement ce paradoxe.
Un agent LLM monolithique rencontre des limites concrètes : sa fenêtre de contexte est finie, ses outils sont génériques, et son traitement est séquentiel. Pour les tâches qui dépassent ces contraintes — recherche multi-sources, génération et critique en parallèle, pipelines longs — la solution n’est pas un modèle plus grand, mais une décomposition en agents spécialisés.
La logique est celle de la division du travail : un agent chercheur extrait les faits, un agent rédacteur produit le texte, un agent critique évalue la conformité. Chaque agent opère dans son domaine de compétence avec un contexte limité et pertinent.
Mais la décomposition crée une dépendance nouvelle : la coordination. Des agents qui ne se comprennent pas produisent des outputs incohérents. D’où l’importance des protocoles et de l’ontologie partagée.
En clair : ajouter des agents n’est pas comme ajouter des serveurs — la coordination ne scale pas linéairement. À partir de 3-4 agents sans protocole strict, le bruit produit dépasse souvent le gain de spécialisation.
Les six modèles d’interrelation
Gulli (2025) identifie six architectures fondamentales pour organiser les interactions entre agents :
1. Agent simple (autonome)
Un seul agent sans interaction avec d’autres agents. Simple à implémenter et à déboguer, mais limité en portée. Adapté aux tâches unitaires qui n’exigent pas de spécialisation.
2. Réseau pair-à-pair (P2P)
Les agents communiquent directement entre eux sans nœud central. Architecture résiliente : la défaillance d’un agent n’interrompt pas l’ensemble du système. Limite : l’overhead de coordination peut devenir prohibitif à grande échelle, et la cohérence des outputs est plus difficile à garantir.
3. Superviseur
Un agent central coordonne des agents subordonnés, délègue les tâches et synthétise les résultats. Architecture claire et prévisible. Limite : le superviseur constitue un point de rupture unique — s’il échoue, le système s’arrête. Il peut aussi devenir un goulot d’étranglement lorsque le volume de sous-tâches augmente.
4. Superviseur comme outil
Variante du modèle précédent : le superviseur fournit des ressources et des orientations sans commander directement l’exécution. Moins de rigidité hiérarchique, mais aussi moins de contrôle sur l’ordonnancement des tâches.
5. Hiérarchique
Plusieurs couches de superviseurs, chacun gérant un sous-groupe d’agents. Adapté aux problèmes très complexes décomposables en niveaux d’abstraction. Limite : la logistique est lourde — les erreurs peuvent se propager à travers les couches avant d’être détectées.
6. Custom
Combinaisons hybrides ou architectures émergentes optimisées pour des contraintes de domaine spécifiques. Ce modèle reconnaît qu’aucune taxonomie ne couvre tous les cas réels — les systèmes en production combinent souvent plusieurs patterns.
En clair : les six modèles couvrent un spectre du plus simple (autonome) au plus complexe (hiérarchique). Le choix dépend de la nature des sous-tâches et de la tolérance à la latence — pas du désir d’avoir “plus d’agents”.
Quand la collaboration ajoute de la valeur
La collaboration multi-agents est bénéfique dans trois situations précises :
Spécialisation réelle. Si les sous-tâches requièrent des compétences distinctes (extraction de données, analyse légale, rédaction), des agents distincts avec des prompts spécialisés surpassent un agent généraliste. La valeur vient de la spécialisation du contexte, pas du nombre d’agents.
Parallélisation indépendante. Lorsque des sous-tâches sont indépendantes, les exécuter en parallèle réduit la latence totale. Le pattern fire-and-consolidate — lancer N agents en parallèle, attendre la convergence, consolider — est le mécanisme dominant (Gulli, 2025, Ch.3).
Critique et révision. Séparer génération et évaluation élimine les biais d’auto-complaisance. Un agent produit, un agent distinct critique sur des critères explicites. Cette séparation est structurellement différente de l’auto-révision.
Quand la collaboration ajoute du bruit
Plusieurs situations produisent l’effet inverse :
Absence d’ontologie partagée. Si les agents utilisent des termes différents pour le même concept, les outputs divergent silencieusement. L’ontologie partagée n’est pas optionnelle : c’est le contrat sémantique qui rend l’interopérabilité possible.
Overhead de coordination supérieur au gain. Pour une tâche simple, orchestrer trois agents coûte plus cher (latence, tokens, complexité de débogage) que d’en confier l’exécution à un seul. L’ajout d’agents sans analyse préalable de l’indépendance des sous-tâches est la cause principale de sur-ingénierie.
Protocoles de communication absents ou incompatibles. Sans format d’échange standardisé — structure JSON définie, conventions de nommage, gestion des erreurs — chaque agent interprète les outputs des autres à sa manière. Les erreurs s’accumulent à chaque handoff.
Dépendances cachées. Si les sous-tâches sont en réalité séquentielles (la tâche B dépend du résultat de A), les exécuter en parallèle force des synchronisations qui annulent le bénéfice de la parallélisation.
En clair : 4 agents avec protocole flou produisent du bruit ; 4 agents avec protocole strict produisent de la valeur. Le facteur déterminant n’est jamais le nombre — c’est l’ontologie commune et le format d’échange entre eux.
Choisir l’architecture multi-agents
| Contexte | Recommandation | Pourquoi |
|---|---|---|
| Tâche simple, résultat unique attendu | Agent autonome | Coordination = surcoût pur, gain spécialisation nul |
| Pipeline avec dépendances strictes (extract → analyse → rédige) | Handoff séquentiel + structured output | Traçabilité maximale, débogage par étape |
| N sous-tâches indépendantes, livrable agrégé | Fire-and-consolidate (parallèle + synthèse) | Latence réduite proportionnellement, cohérence par consolidateur |
| Décision critique, diversité d’angles requise | Producer-Critic ou Débat | Élimine biais auto-complaisance, score qualité |
| Système production grande échelle, frameworks différents | Architecture A2A + MCP | Découplage, composabilité, agents inter-vendor |
Protocoles de communication et ontologie
Deux éléments techniques conditionnent la fiabilité d’un système multi-agents :
Le protocole de communication standardise comment les agents échangent des données et coordonnent leurs actions. Il définit les formats d’entrée et sortie, les conventions d’erreur, et les mécanismes de délégation de sous-tâches. Sans standardisation, l’ajout d’un nouvel agent dans le système nécessite de modifier tous les agents existants.
L’ontologie partagée fournit le vocabulaire commun et la sémantique d’interopérabilité. Elle garantit que quand l’agent A parle d’un “client”, l’agent B comprend la même entité. En pratique, elle se matérialise dans les prompts systèmes, les schémas de données partagés, et les définitions de rôles.
Deux protocoles standardisés émergent dans l’écosystème : MCP (Model Context Protocol) pour la découverte et consommation dynamiques d’outils entre agent et environnement, et A2A (Agent-to-Agent) pour l’interopérabilité entre agents de frameworks différents, via des Agent Cards JSON déclarant les capacités et endpoints de chaque agent (Gulli, 2025, Ch.10 et Ch.15).
Patterns de collaboration courants
| Pattern | Description | Quand l’utiliser |
|---|---|---|
| Handoff séquentiel | Chaque agent complète sa tâche et transmet au suivant | Pipeline avec dépendances strictes |
| Traitement parallèle | N agents traitent simultanément des portions indépendantes | Sous-tâches vraiment indépendantes |
| Débat et consensus | Agents aux perspectives variées délibèrent avant décision | Décisions à forte incertitude |
| Critique-révision | Un agent génère, un groupe évalue, révision basée sur le retour | Qualité de sortie critique |
| Équipes d’experts | Spécialistes distincts (chercheur, rédacteur, éditeur) sur un livrable | Livrables complexes multi-dimensionnels |
Ce qu’il faut retenir
- Six modèles d’interrelation couvrent le spectre des architectures multi-agents : de l’agent simple au système hiérarchique. Chaque modèle implique un compromis entre contrôle, résilience et complexité.
- La valeur d’un système multi-agents émerge de la coordination, non du nombre d’agents. Des agents mal coordonnés produisent des résultats moins fiables qu’un agent unique bien configuré.
- Le protocole de communication et l’ontologie partagée sont des conditions nécessaires — pas suffisantes — pour que la collaboration soit productive. Leur absence est la première cause d’échec.
- Le pattern fire-and-consolidate (parallélisation + convergence + synthèse) est l’architecture dominante pour les tâches décomposables en sous-tâches indépendantes.
- Les protocoles ouverts MCP et A2A réduisent le couplage entre agents, permettant la composabilité entre frameworks différents.