Systèmes multi-agents: orchestrateur + sous-agents en pratique
Un seul agent IA gère bien une tâche étroite. Quand le scénario grossit - tickets, documents, code, CRM, support - un agent « universel » commence à mélanger les rôles, à gonfler le contexte et à coûter plus cher à chaque étape. Un système multi-agents résout cela autrement: un orchestrateur prend l'objectif et coordonne le travail, tandis que les sous-agents exécutent des rôles étroits avec des outils et des instructions séparés. Ci-dessous - comment cela fonctionne en pratique, quand le schéma rentabilise, et quelles erreurs tuent un pilote.
- Orchestrateur - plan, routage, contrôle des limites et assemblage du résultat
- Sous-agents - rôles étroits: recherche, code, revue, rédaction, CRM
- Contexte - chaque agent ne reçoit que ce dont il a besoin pour son étape
- Contrôle - human-in-the-loop sur les actions critiques
- Démarrage - 2-4 rôles et un scénario mesurable, pas un « zoo d'agents »
- Risque - boucles infinies, courses d'outils et propriété floue
Qu'est-ce qu'un système multi-agents
Un système multi-agents est une architecture où plusieurs agents IA résolvent conjointement une tâche sous un coordinateur. Contrairement à un seul agent avec un prompt « gras » pour tous les cas, les rôles sont séparés:
| Rôle | Ce qu'il fait | Ce qu'il ne fait pas |
|---|---|---|
| Orchestrateur | Comprend l'objectif, décompose, appelle les sous-agents, assemble la réponse | Ne touche pas aux outils étrangers sans besoin |
| Sous-agent | Exécute une sous-tâche étroite avec ses propres outils | Ne replanifie pas tout le projet |
| Humain | Approuve les risques: argent, suppression, publication, e-mails clients | Ne doit pas micromanager chaque appel d'outil |
La même idée est déjà familière dans l'automatisation de workflows: il y a un dispatcher et des workers. La différence est que les étapes et les branches sont en partie choisies par un LLM, pas seulement par des règles if-then figées.
Pourquoi séparer orchestrateur et sous-agents
Un agent avec accès à toutes les API semble pratique - et devient vite un problème:
- Le contexte gonfle. Un seul dialogue mélange logs, brouillons d'e-mails, morceaux de code et exports CRM - le modèle perd le focus.
- Le coût monte. Chaque token supplémentaire dans le chat « partagé » est payé à chaque tour.
- Les permissions sont trop larges. Un agent qui écrit du code et e-mail le client est plus risqué qu'un worker étroit.
- Plus dur à déboguer. Quand tout vit dans une seule boucle, on ne sait pas ce qui a cassé: le plan, l'outil ou la formulation.
La séparation des rôles apporte:
- Un system prompt étroit par sous-agent - moins d'hallucinations « hors rôle ».
- Un jeu d'outils séparé - un researcher ne peut pas supprimer accidentellement une affaire CRM.
- Le parallélisme - plusieurs sous-agents peuvent travailler en même temps (recherche + brouillon + fact-check).
- L'observabilité - les logs montrent qui a été appelé, avec quelle entrée et quelle sortie.
Conception de base: orchestrateur + pool de sous-agents
Un squelette minimal pratique:
User / trigger
│
▼
Orchestrator
(plan, routes, limits)
│
┌────┼────┬────────┐
▼ ▼ ▼ ▼
Research Coder Reviewer Writer
│ │ │ │
└────┴────┴────────┘
│
▼
Summary + artifacts
(+ human approval on risk)
Ce que fait l'orchestrateur
- accepte l'objectif et les contraintes (temps, budget tokens, interdictions);
- choisit quels sous-agents appeler et dans quel ordre;
- passe à chacun un brief compressé, pas tout le chat brut;
- applique les limites d'étapes et arrête les boucles;
- assemble le résultat au format dont le métier a besoin (rapport, diff, fiche affaire).
L'orchestrateur peut être « mince » (routage seulement) ou « épais » (planifie et replanifie lui-même). Pour le business, un orchestrateur mince + des sous-agents étroits solides gagne en général: plus facile à tester et moins cher à garder sous contrôle.
Sous-agents typiques en scénarios business et dev
| Sous-agent | Mission | Outils (exemple) |
|---|---|---|
| Research | Collecter faits, docs, concurrents | search, RAG, browser, MCP |
| Analyst | Tableaux, métriques, conclusions | SQL, Excel/Sheets, entrepôt de rapports |
| Coder | Patches, scripts, tests | repo, terminal, CI |
| Reviewer | Contrôles qualité et risques | linters, checklists, diff |
| Writer | E-mails, specs, notes de version, FAQ | templates, base de ton de marque |
| CRM-agent | Fiches, tâches, statuts | API CRM, webhooks |
| Ops | Deploy, alertes, runbooks de routine | SSH/API, monitoring (avec garde-fous stricts) |
Vous n'avez pas besoin de tous les rôles dès le premier jour. Un pilote n'a en général besoin que d'un orchestrateur + 2-3 sous-agents.
Quand le schéma vaut vraiment le coup
La conception multi-agents a du sens quand au moins deux de ces points sont vrais:
- la tâche est composite (plusieurs compétences: recherche + synthèse + action);
- vous avez besoin de droits d'accès différents aux systèmes;
- le volume de contexte est grand - un seul agent « ne rentre pas » sans perte de qualité;
- vous avez besoin d'un reviewer séparé, pas de l'auto-contrôle de l'auteur;
- le scénario se répète et peut être décrit comme un pipeline basé sur des rôles.
Exemples pratiques
- Support: orchestrateur → Research (base de connaissances/RAG) → Writer (réponse) → un humain approuve l'envoi.
- Leads et CRM: qualification → enrichment → écriture dans le CRM → tâche manager; les champs critiques sont vérifiés par un humain ou une règle.
- Développement: orchestrateur dans Cursor / runtime agent → sous-agent explore → coder → reviewer; deploy uniquement après approve.
- Contenu et GEO: recherche de sujet → writer → sous-agent fact-check → publication par checklist.
- Opérations: parser l'e-mail entrant → classifier → actions via n8n/API → escalader les exceptions à un humain.
Si la tâche est un simple if-then (« formulaire soumis → créer une affaire »), le multi-agents est excessif: mieux vaut une automatisation native ou n8n.
Comment concevoir les rôles en une journée
Une checklist pragmatique courte:
- Décrire le happy path sur papier: entrée → 3-6 étapes → artefact de sortie.
- Nommer les rôles par des verbes: « trouver », « vérifier », « écrire », « écrire dans le CRM » - pas « agent intelligent #3 ».
- Pour chaque rôle, fixer: entrée, sortie (schéma/JSON), outils, interdictions.
- Décider qui orchestre: planificateur LLM ou graphe déterministe (souvent un hybride: graphe + LLM dans les nœuds).
- Insérer le human-in-the-loop là où le coût de l'erreur est élevé.
- Fixer les conditions d'arrêt: max étapes, max coût, timeout, « si doute - escalader ».
Un contrat de sous-agent bat un « beau prompt »
Un bon contrat:
- entrée:
{ task, constraints, sources[] } - sortie:
{ status, summary, artifacts[], confidence, needs_human } - interdiction: « ne pas inventer d'URL », « ne pas modifier la prod », « ne pas e-mailer le client directement »
Ensuite l'orchestrateur peut fusionner fiablement les réponses et décider qui appeler ensuite.
Patterns d'orchestration qui marchent
| Pattern | Comment ça marche | Quand l'utiliser |
|---|---|---|
| Pipeline séquentiel | A → B → C | Processus stable, peu de branches |
| Dispatcher | L'orchestrateur choisit 1 sous-agent par type de requête | Beaucoup de types de demandes entrantes |
| Parallèle + merge | Plusieurs recherches, puis un résumé | Faits provenant de plusieurs sources |
| Debate / reviewer | Auteur et critique | Qualité du texte, du code, des décisions |
| Hiérarchie | Orchestrateur → chefs d'équipe → workers | Grands programmes avec sous-projets |
Pour les PME, pipeline + dispatcher suffit en général. Les « débats d'agents » ont l'air géniaux en démo et coûtent cher en production sans budget tokens dur.
Contrôle, sécurité et coût
Un système multi-agents sans garde-fous devient vite un bot chaotique et cher.
Minimum indispensable:
- Clés API et permissions séparées par rôle (least privilege).
- Limites: étapes, tokens, parallélisme, timeouts.
- Actions idempotentes (un retry ne doit pas créer 5 affaires).
- Journal d'audit: qui → avec quelle entrée → quel outil → quelle sortie.
- Secrets hors du prompt: vault, env - pas « coller le token dans le system message ».
- Approbation humaine pour les actions irréversibles: paiements, suppression, mailings, deploy prod.
Sur le coût, comptez non pas le « prix du modèle » mais le prix de la chaîne: orchestrateur × N appels de sous-agents × retries. Parfois un seul appel fort avec un bon contexte coûte moins cher que cinq appels faibles qui se passent du JSON.
Erreurs d'implémentation courantes
- Créer 10 sous-agents « pour plus tard » sans un scénario qui fonctionne.
- Donner à tous le même accès à tous les outils.
- Passer le log complet de l'orchestrateur à un sous-agent au lieu d'un brief court.
- Ne pas limiter les boucles - orchestrateur et reviewer se disputent à l'infini.
- Traiter le multi-agents comme un substitut de processus: sans Definition of Done claire, le système imite l'activité.
- Le confondre avec le vibe coding: « laissez les agents se débrouiller » sans rôles ni contrats - chemin vers la dette technique.
Comment lancer un pilote de 2-3 semaines
- Choisir un scénario avec un KPI mesurable (temps de réponse, taux d'erreur, minutes manager).
- Construire orchestrateur + deux sous-agents (ex. research + writer, ou coder + reviewer).
- Figer les contrats entrée/sortie et une checklist d'escalade pour les humains.
- Passer 20-50 cas réels et étiqueter les échecs par type.
- Seulement ensuite ajouter un troisième rôle ou du parallélisme.
Les outils peuvent être un framework d'agents (LangGraph, setups type Crew, runtime IDE), un pont vers n8n pour les arêtes déterministes, ou du Python custom. L'architecture des rôles compte plus que le logo du framework.
En résumé
Orchestrateur + sous-agents est un schéma qui marche quand la tâche dépasse une seule compétence et qu'il faut des droits, des contextes et des contrôles qualité différents. La force n'est pas le nombre d'agents - c'est des rôles clairs, des outils étroits et des arrêts durs. Commencez par une petite boucle et un scénario mesurable: c'est ainsi qu'un système multi-agents devient un levier de vitesse, pas un théâtre d'autonomie coûteux.
Questions fréquentes
En quoi un système multi-agents diffère-t-il d'un seul agent avec un long prompt?
Un agent à long prompt tente d'être « tout à la fois » dans un seul contexte et un seul jeu de permissions. Une conception multi-agents sépare les rôles: l'orchestrateur coordonne, les sous-agents exécutent de façon étroite. C'est plus facile à contrôler, moins cher en tokens sur les longues chaînes, et plus sûr parce que chaque worker a une surface d'accès plus petite.
Faut-il toujours un orchestrateur LLM?
Non. Souvent un graphe déterministe (machine à états / workflow) est meilleur, avec le LLM vivant dans les nœuds. Un orchestrateur LLM rentabilise quand l'entrée est non structurée et que la route ne peut pas être codée en dur à l'avance. L'hybride est le choix de production le plus courant.
Combien de sous-agents sont optimaux au démarrage?
En général 2-4. Un orchestrateur plus research et writer est déjà une boucle qui marche pour le contenu et le support; coder et reviewer - pour le développement. Plus de rôles n'ont de sens qu'après que le pilote touche le KPI régulièrement et que les logs sont lisibles.
Comment éviter de brûler de l'argent en tokens?
Compresser les briefs, interdire de « rételer tout le dialogue », cacher le system prompt stable, plafonner le max d'étapes, paralléliser seulement là où cela réduit le wall-time - pas pour la démonstration. Mesurer le coût du scénario de bout en bout, pas d'une jolie réponse démo.
Faut-il encore un humain dans la boucle si les agents sont « intelligents »?
Oui, sur les risques. Un modèle ne retire pas la responsabilité pour l'argent, les données personnelles, le libellé juridique et la production. Le human-in-the-loop n'est pas une faiblesse d'architecture - c'est la condition pour que le business laisse des agents près des systèmes réels.