Sommaire
Une fois assimilé le concept de « coordonner plusieurs IA » dans Qu'est-ce qu'un système multi-agents ?, la question suivante est comment en construire un concrètement. Cet article détaille un processus pratique en 5 étapes pour les débutants, en s'appuyant sur le standard de fait de 2026 : le pattern supervisor.
Avant tout discours sur les frameworks, voici le principe le plus important : « construisez d'abord avec un seul agent, et n'en ajoutez d'autres — de façon minimale — qu'une fois que vous atteignez une limite. » Partir en multi dès le départ relève le plus souvent de la sur-ingénierie. Le code est présenté en pseudo-code indépendant de tout framework, il s'applique donc que vous utilisiez MCP ou n'importe quel SDK.
Construire petit, mesurer, puis ajouter
— Le pattern supervisor, à partir d'une configuration minimale
* Les étapes et chiffres de cet article sont cités de documents publics, de guides de praticiens et de rapports de recherche (à jour de juin 2026). Le code est un pseudo-code conceptuel ; consultez la documentation officielle de chaque framework pour l'API réelle.
1. Avant de construire : avez-vous vraiment besoin du multi ?
Le premier filtre n'est pas technique — c'est une question de jugement. Le multi-agents est puissant, mais ~80% des cas d'usage se contentent très bien d'un seul agent. Si aucun des points suivants ne s'applique, construisez d'abord avec un agent unique.
3 signes qu'il faut passer au multi
- Séparation des spécialités : les connaissances ne tiennent pas dans un seul prompt (les domaines s'étendent à la recherche, au juridique, au code, etc.)
- Parallélisme : exécuter plusieurs tâches en même temps est nettement plus rapide
- Séparation des décisions : la qualité s'améliore lorsqu'on sépare « l'exécutant » et « le vérificateur »
À l'inverse, utiliser le multi pour un processus simple et linéaire — comme abordé la dernière fois — gonfle le coût de 3-10x et fait en réalité baisser la précision sur les tâches séquentielles (la recherche de Google rapporte -39-70% par rapport au mono-agent). Partez du principe que « plus d'agents ne signifie pas plus intelligent ».
2. La forme de base : le supervisor (le standard 2026)
Si vous hésitez sur le pattern à construire, optez pour le pattern supervisor, point final. Les sous-agents de Claude Code, LangGraph Supervisor, les handoffs de l'OpenAI Agents SDK — les implémentations majeures ont toutes convergé vers cette forme. Les raisons sont claires.
Le support framework le plus large
Support natif dans les principaux frameworks. Implémentations de référence abondantes.
Mode de défaillance connu
La défaillance principale est la « sur-délégation », bornée par un plafond d'itérations.
Facile à auditer
« Qui a fait quoi » est clair, ce qui facilite le débogage.
Le mécanisme est simple. Le supervisor reçoit la tâche globale, la découpe en sous-tâches, les délègue à des workers spécialisés et agrège les résultats. Le supervisor n'a pas besoin de savoir comment un worker fait son travail — seulement quel worker appeler et dans quel format de sortie. L'expertise réside dans les workers.
3. Le construire en 5 étapes
Assemblez une configuration supervisor minimale en cinq étapes. La règle d'or : commencez avec 2-3 workers, puis n'en ajoutez d'autres que lorsque la mesure le justifie.
ÉTAPE 1. Décomposer la tâche
Notez « l'objectif final » et les « rôles spécialisés » nécessaires. Exemple : pour un rapport d'étude de marché, « 1) collecter l'information → 2) analyser → 3) rédiger → 4) vérifier les faits ». Décomposez clairement en amont — un flou à ce stade fait tout s'effondrer.
ÉTAPE 2. Définir les workers (jusqu'à 3-5)
Donnez à chaque worker un rôle, les outils dont il a besoin et un format de sortie. Ne soyez pas gourmand au début — 3-5 au maximum. Chaque worker est indépendant et ne détient que ses propres outils (recherche, exécution de code, etc.).
ÉTAPE 3. Concevoir le supervisor
Dans le prompt du supervisor, énumérez explicitement les noms des workers qu'il peut appeler (un plafond strict). L'astuce : consacrez plus de temps au supervisor qu'à n'importe quel worker individuel. C'est lui qui détermine la qualité globale.
ÉTAPE 4. Décider du handoff et du partage de contexte
Définissez ce qui est transmis entre les workers, et dans quel format. Transmettre tout le contexte à chacun gonfle les tokens, donc ne transmettez que l'information nécessaire. Le protocole standard pour la coordination entre agents est A2A.
ÉTAPE 5. Mesurer et exploiter avec des plafonds
Instrumentez chaque handoff avant d'ajouter des agents (l'observabilité n'est pas optionnelle). Fixez des plafonds sur les itérations, les tokens et le coût. Mettez en place des evals et des garde-fous en même temps.
4. Exemple de code minimal (pseudo-code)
L'essence du pattern supervisor est étonnamment courte. Voici un pseudo-code indépendant de tout framework qui montre la boucle où le supervisor choisit un worker et l'exécute (consultez la documentation officielle de chaque SDK pour l'API réelle).
# Définir les workers : un rôle + des outils dédiés
workers = {
"researcher": Agent(tools=[web_search]),
"writer": Agent(tools=[]),
"factcheck": Agent(tools=[web_search]),
}
# Supervisor : plafonner strictement les noms de workers qu'il peut appeler
supervisor = Agent(
instructions="Decompose the goal and pick one worker to call next. "
"Return 'DONE' when finished.",
allowed_workers=["researcher", "writer", "factcheck"],
)
# Boucle d'exécution (un plafond d'itérations empêche la sur-délégation)
state = {"goal": "Write an AI market report", "history": []}
for step in range(MAX_STEPS): # <- un plafond est essentiel
next_worker = supervisor.decide(state)
if next_worker == "DONE":
break
result = workers[next_worker].run(state)
state["history"].append({next_worker: result}) # partager uniquement le contexte nécessaire
log_handoff(next_worker, result) # <- instrumenter chaque handoffTrois enseignements : 1) chaque worker est un rôle + des outils dédiés, 2) l'ensemble des appels possibles du supervisor est limité, 3) la boucle a toujours un plafond d'itérations. Ajoutez la mesure, les garde-fous et les evals sur ce squelette et vous vous rapprochez de la qualité de production. Les sous-agents de Claude Agent SDK et de Claude Code suivent la même idée.
5. Pièges courants et solutions
Les endroits où l'on trébuche dans le développement multi-agents sont assez prévisibles. Anticipez-les.
| Piège | Solution |
|---|---|
| Sur-délégation (le supervisor boucle indéfiniment) | Plafond d'itérations + limitation des workers appelables |
| Explosion des tokens (coût 3-10x) | Arrêter de partager tout le contexte ; ne transmettre que le nécessaire + cache |
| Comportement instable et non déterministe | Garder peu de workers (3-5) + fixer les formats de sortie |
| Baisse de précision sur les tâches séquentielles (-39-70%) | Revenir à un agent unique pour le travail linéaire |
| Impossible de savoir où ça a échoué | Instrumenter chaque handoff avant de passer à l'échelle (observabilité) |
La leçon partagée : « les prompts, la conception des outils et le harnais d'evals décident du succès bien plus que le framework. » Plutôt qu'une architecture tape-à-l'œil, c'est la discipline de construire petit, mesurer et n'ajouter que lorsque ça rapporte qui est la plus rapide au final.
Résumé
Construire un système multi-agents n'a rien d'effrayant si l'on commence par le pattern supervisor à partir d'une configuration minimale. Récapitulons.
Points clés
- 🚦 D'abord le mono-agent. N'ajoutez des agents qu'après l'apparition de signes de spécialisation / parallélisme / séparation des décisions.
- 🧠 La forme de base est le supervisor (standard 2026). Consacrez le plus de temps à la conception du supervisor.
- 🔢 5 étapes : décomposer → définir les workers (3-5) → concevoir le supervisor → handoff → mesurer.
- ⚠️ Pièges : sur-délégation, explosion des tokens, instabilité. À corriger par des plafonds, le partage du strict nécessaire et la mesure.
- 📏 Discipline : les prompts, les outils et les evals décident du succès plus que le framework.
« Construire petit, mesurer, puis ajouter. » Gardez cette discipline et un système multi-agents devient un partenaire puissant pour le travail complexe. Pour le concept, voir Qu'est-ce qu'un système multi-agents ? ; pour en construire un seul, Comment construire un agent IA.
FAQ
Q. Quel pattern construire en premier ?
A. Le pattern supervisor, sans hésiter. Les principaux frameworks le prennent en charge, son mode de défaillance est connu et les implémentations de référence sont les plus nombreuses. Explorez d'autres patterns une fois à l'aise.
Q. Avec combien de workers commencer ?
A. Commencez avec 2-3, et tenez-vous-en à 3-5 au maximum. Plus vous en ajoutez, plus le système devient instable et plus les tokens explosent. La norme est de n'en ajouter que lorsque la mesure en prouve le besoin.
Q. Un framework est-il indispensable ?
A. Pas indispensable. Comme le montre le pseudo-code, une boucle et des prompts suffisent à construire une configuration minimale. Mais si vous avez besoin de persistance d'état, d'observabilité et de récupération en production, un framework de support est un raccourci.
Q. Comment éviter l'explosion des coûts ?
A. Trois choses aident : 1) plafonner le nombre d'itérations, 2) ne partager que le contexte nécessaire au lieu de tout transmettre, et 3) utiliser le cache de prompts. Passer au multi peut coûter 3-10x un agent unique, donc les plafonds sont essentiels dès le premier jour.
