Système multi-agents IA : quand séparer les rôles et comment les coordonner

Un système multi-agents n’est pas un groupe de modèles qui discutent jusqu’à trouver une bonne réponse. C’est une architecture dans laquelle plusieurs agents reçoivent des responsabilités distinctes, échangent un état limité et sont coordonnés par un manager, du code ou des règles de transfert. Cette séparation peut accélérer une recherche large ou isoler des permissions. Elle peut aussi multiplier les coûts, les erreurs de contexte et les chemins impossibles à rejouer.

La bonne question n’est donc pas « combien d’agents faut-il ? », mais « quelle dépendance justifie un second décideur probabiliste ? ». Si une fonction, une requête structurée ou un workflow déterministe suffit, ajoutez cette brique. Ne créez un agent supplémentaire que lorsque sa spécialisation, son contexte ou son autonomie bornée apporte un gain vérifiable.

Réponse en bref

Pour concevoir un système multi-agents IA :

1. partez d’une tâche et d’un résultat acceptables, pas d’un organigramme d’agents ;
2. gardez un seul agent lorsque les étapes partagent le même contexte et dépendent fortement les unes des autres ;
3. utilisez du code pour les routes stables, les validations, les budgets et les arrêts ;
4. séparez un spécialiste uniquement si son objectif, ses outils, ses permissions ou son contexte sont réellement différents ;
5. choisissez qui possède la réponse finale et qui peut déclencher un effet ;
6. définissez un contrat de délégation avec entrée, sortie, budget, données autorisées et critère de fin ;
7. transmettez un résumé ciblé plutôt que tout l’historique ;
8. testez les doublons, les trous de couverture, les boucles, les conflits, les fuites de contexte et la reprise ;
9. comparez le système à une référence mono-agent sur qualité, délai, coût et taux d’escalade ;
10. retirez les agents qui ne changent aucune décision utile.

La prochaine action consiste à dessiner le flux actuel avec une boîte par décision. Pour chaque boîte, marquez code, outil, agent ou humain. Si plusieurs boîtes restent marquées agent, appliquez la matrice SÉPARER avant d’écrire les prompts.

Un agent avec plusieurs outils n’est pas forcément multi-agents

Un agent est généralement un modèle configuré avec des instructions, des outils, un état d’exécution et des règles de sortie. Il peut appeler une recherche, interroger une base ou exécuter une fonction sans déléguer la décision à un autre agent. Ajouter trois outils ne crée donc pas automatiquement un système multi-agents.

À l’inverse, une chaîne de trois appels de modèle n’est pas toujours un collectif autonome. Si le code impose l’ordre « extraire, contrôler, reformuler », il s’agit d’un workflow qui utilise plusieurs composants probabilistes. Cette architecture peut être excellente. La nommer correctement aide à tester la bonne chose.

Microsoft recommande d’utiliser une fonction lorsqu’une fonction suffit, un agent pour une tâche ouverte ou conversationnelle, et un workflow lorsque l’ordre doit rester explicite. La documentation d’OpenAI distingue elle aussi l’orchestration décidée par le modèle et l’orchestration décidée par le code. Ces deux modes peuvent être combinés : le code borne le flux, puis un agent choisit parmi quelques options autorisées à un endroit précis.

Le guide prompt ou workflow couvre le premier changement d’échelle. Ici, le sujet commence un cran plus loin : décider si un workflow agentique doit contenir plusieurs centres de décision.

La matrice SÉPARER avant d’ajouter un agent

La matrice SÉPARER évalue sept raisons possibles de créer une frontière. Elle ne produit pas un score universel ; elle oblige à nommer le bénéfice attendu et son test.

Lettre	Question	Signal favorable	Signal défavorable
S, simultanéité	des branches peuvent-elles avancer indépendamment ?	recherches parallèles sans dépendance	chaque étape attend la précédente
É, expertise	faut-il des instructions ou critères vraiment différents ?	spécialiste fiscal et spécialiste technique	même tâche avec deux personas décoratifs
P, permissions	les outils ou données doivent-ils être isolés ?	lecture seule séparée d’une action	tous les agents reçoivent les mêmes droits
A, arbitrage	qui tranche les résultats contradictoires ?	propriétaire final explicite	consensus implicite entre modèles
R, reprise	une branche peut-elle échouer sans perdre le reste ?	checkpoint et sortie partielle	redémarrage complet obligatoire
E, évaluation	chaque rôle a-t-il un test spécifique ?	critères propres et cas limites	une note globale sur le texte final
R, rendement	le gain couvre-t-il coût et délai supplémentaires ?	meilleure couverture mesurée	davantage de jetons sans décision améliorée

Une architecture multi-agents devient plausible lorsque plusieurs lignes ont une réponse nette et testable. Une seule raison peut suffire si elle porte sur une isolation forte des permissions. À l’inverse, cinq rôles aux noms différents ne justifient rien si tous lisent le même contexte, utilisent les mêmes outils et produisent le même type de texte.

Quand garder un seul agent

Gardez un agent unique lorsque la tâche tient dans un contexte maîtrisé, exige des décisions très dépendantes et possède un propriétaire clair. Un agent qui analyse un dossier puis rédige une réponse à partir de cette même analyse profite souvent de la continuité. Le diviser peut forcer à compresser des nuances importantes dans un handoff.

Vous pouvez toujours structurer ce mono-agent avec des outils spécialisés, une sortie intermédiaire typée, un budget d’itérations et une validation finale. La simplicité facilite la journalisation et la comparaison.

Quand préférer un workflow sans second agent

Si la route est connue, encodez-la. Une classification à cinq catégories, un calcul, une validation de schéma, une vérification de droit ou un envoi après approbation ne gagne pas à être redécidé librement à chaque exécution. Le modèle peut proposer une catégorie ; le code contrôle la valeur et sélectionne la branche.

Cette distinction évite de confier à une conversation entre agents des propriétés que Python, une base ou une machine à états garantissent mieux.

Quatre architectures utiles

1. Manager et spécialistes comme outils

Un manager reste propriétaire de l’échange et appelle des spécialistes pour des sous-tâches bornées. OpenAI décrit ce patron comme des agents exposés au manager sous forme d’outils. Il convient lorsqu’une seule entité doit synthétiser la réponse, appliquer des garde-fous communs et conserver la relation avec l’utilisateur.

Le manager doit recevoir des sorties compactes et structurées. S’il transmet la conversation complète, laisse chaque spécialiste rédiger une conclusion générale puis réécrit tout, le système paie plusieurs fois le même travail et augmente le risque de contradiction.

Utilisez ce patron pour une recherche comportant trois axes indépendants, une analyse qui combine des disciplines ou un dossier dans lequel les spécialistes n’ont pas besoin de parler directement à l’utilisateur.

2. Handoff vers un spécialiste

Un agent de tri choisit un spécialiste, puis lui transfère le contrôle. Ce patron convient lorsque le spécialiste doit mener la suite de l’échange avec ses propres instructions : support facturation, question technique ou demande commerciale, par exemple.

Le transfert doit préciser la raison, la priorité, le résumé utile et ce qui ne doit pas être transmis. La documentation OpenAI rappelle qu’un handoff peut, par défaut, exposer l’historique de conversation au nouvel agent et propose des filtres d’entrée. Elle précise également que certains garde-fous ne s’appliquent qu’au premier ou au dernier agent selon leur type. Il faut donc tester chaque frontière, pas supposer qu’un contrôle global protège toute la chaîne.

Un handoff ne doit pas devenir un ping-pong. Ajoutez une limite de transferts, une règle de retour et un propriétaire final.

3. Pipeline séquentiel contrôlé par le code

Le code appelle plusieurs spécialistes dans un ordre déterminé. Chaque sortie doit franchir un schéma ou une règle avant l’étape suivante. Ce patron sert lorsque les rôles diffèrent mais que le processus ne doit pas improviser son ordre : extraction, analyse, critique, rédaction finale.

L’avantage est la reproductibilité du flux. Le risque est l’accumulation silencieuse d’erreurs : une extraction incomplète peut paraître plausible à toutes les étapes suivantes. Conservez donc la source, le statut et les omissions à chaque passage. N’envoyez pas uniquement une reformulation qui efface l’incertitude.

4. Parallèle puis fusion

Plusieurs agents explorent des branches indépendantes, puis un manager ou du code fusionne les résultats. C’est le patron le plus naturel pour une recherche large, une comparaison multi-source ou un audit de surfaces séparées. Anthropic l’utilise dans son système de recherche et explique que la séparation des fenêtres de contexte aide les sous-agents à explorer des trajectoires différentes.

Cette architecture consomme davantage. Anthropic rapporte, sur son propre système, qu’un dispositif multi-agents utilisait environ quinze fois plus de jetons qu’un échange de chat. Ce chiffre n’est pas une norme, mais il rappelle qu’un gain de couverture doit être comparé au coût, au délai et à la valeur de la tâche.

La fusion ne doit pas consister à concaténer. Elle doit dédupliquer, signaler les désaccords, vérifier les sources et décider ce qui reste absent.

Le contrat de délégation à neuf champs

Chaque appel de spécialiste doit pouvoir être relu comme une mission indépendante. Utilisez au minimum :

objective: résultat précis attendu
scope: ce que le spécialiste couvre et exclut
input_refs: références autorisées, pas tout le contexte
tools: outils permis et mode lecture ou action
output_schema: champs et statut de sortie
budget: appels, durée, jetons ou coût maximal
stop_conditions: succès, absence, erreur ou escalade
evidence: preuves à joindre au résultat
owner_next: composant ou personne qui reçoit la sortie

Objective doit décrire un livrable, pas un thème. « Recherche la sécurité » invite à couvrir n’importe quoi. « Identifie les exigences de permission applicables à trois outils et renvoie une ligne par outil avec source et incertitude » crée une tâche vérifiable.

Scope empêche les doublons. Si deux spécialistes couvrent des axes proches, écrivez explicitement le partage. Anthropic explique que des consignes de délégation vagues ont conduit ses agents à répéter les mêmes recherches ou à explorer des périodes différentes.

Output_schema ne garantit pas la vérité, mais il rend les résultats comparables. Associez-le à un statut tel que complete, partial, not_found, blocked ou conflict. Un agent qui ne trouve rien doit pouvoir le dire sans inventer une conclusion.

Partager le contexte sans le dupliquer

Une architecture multi-agents traite le contexte comme une donnée avec un propriétaire. Séparez :

• le contexte utilisateur nécessaire à la tâche ;
• l’état applicatif détenu par le code ;
• les résultats des outils ;
• les décisions déjà approuvées ;
• les informations privées qui ne doivent pas franchir certaines frontières ;
• le journal de l’exécution.

Le spécialiste n’a généralement besoin ni de tous les messages précédents, ni des sorties internes des autres agents. Envoyez une synthèse avec références et hypothèses. Si un détail complet est nécessaire, transmettez la référence vers l’espace autorisé plutôt qu’une copie dans chaque fenêtre.

Un résumé peut lui-même déformer le contexte. Testez donc des cas où une condition importante se trouve au début, une exception au milieu et une correction à la fin. Vérifiez que le transfert conserve la version la plus récente et ne réintroduit pas une instruction devenue invalide.

La journalisation d’un agent IA permet de relier les événements sans enregistrer les prompts complets. Dans un système multi-agents, ajoutez parent_run_id, agent_role, delegation_id, input_refs, output_status et next_owner.

Les douze tests avant un pilote

Construisez un jeu réduit qui couvre le comportement nominal et les frontières :

1. route évidente : le manager choisit le bon spécialiste ;
2. route ambiguë : il demande une précision ou applique une règle documentée ;
3. aucun spécialiste adapté : il s’arrête au lieu de forcer une délégation ;
4. doublon : deux branches ne répètent pas la même recherche sans justification ;
5. trou de couverture : la fusion signale une dimension non traitée ;
6. conflit : deux résultats incompatibles restent visibles jusqu’à arbitrage ;
7. échec d’outil : une branche échoue sans faire disparaître les résultats valides ;
8. budget atteint : le système rend un état partiel et arrête les nouveaux agents ;
9. boucle de handoff : la limite interrompt le ping-pong ;
10. contexte interdit : le spécialiste ne reçoit pas une donnée hors périmètre ;
11. effet externe : une seule étape autorisée peut proposer l’action et la validation reste bloquante ;
12. reprise : un redémarrage repart d’un checkpoint sans doubler l’effet ni répéter toutes les branches.

Pour chaque test, conservez la route attendue, les agents autorisés, le budget, la sortie minimale, l’incident redouté et le verdict. Ne notez pas uniquement la qualité de la phrase finale. Une réponse élégante peut cacher trois délégations inutiles ou une permission trop large.

Comparer au mono-agent

Le système de référence doit rester simple : un agent avec les mêmes outils essentiels, le même corpus et la même définition du résultat. Exécutez les deux architectures sur un panel identique, puis comparez :

Dimension	Mesure possible
couverture	éléments exigés trouvés et correctement attribués
exactitude	erreurs critiques et corrections majeures
coordination	doublons, trous, conflits non signalés
délai	médiane et 95e percentile par tâche acceptée
coût	coût complet par résultat accepté
contrôle	actions bloquées, escalades et permissions utilisées
reprise	branches rejouées et effets doublés après incident

N’ajoutez pas plusieurs agents si le gain n’apparaît que sur une démonstration choisie. Le coût d’un agent IA par tâche acceptée fournit un dénominateur plus utile que le total de jetons. Les SLO d’un agent IA permettent ensuite de transformer les seuils retenus en règles d’exploitation.

Une amélioration de couverture peut justifier un coût supérieur sur une recherche rare et importante. Elle le justifie moins sur une classification fréquente et stable. La valeur dépend du travail, pas du nombre d’agents.

Exemple de pilote borné

Prenons une veille réglementaire qui doit relever les changements de trois autorités publiques. Chaque branche peut consulter une autorité différente en lecture seule. Un manager reçoit trois sorties structurées avec date, URL, changement et incertitude, puis les déduplique. Il ne publie rien et n’envoie aucun message.

Ce pilote justifie le parallèle parce que les sources sont indépendantes. Il garde le code responsable de la liste des autorités, du budget, de la validation des URL et du stockage. Les agents décident quelles pages officielles méritent une lecture approfondie et résument leur portée. Un humain arbitre les conséquences juridiques ou opérationnelles.

À l’inverse, si la veille porte sur une seule page dont il faut extraire cinq champs, un parseur ou un agent unique suffit probablement. Créer cinq spécialistes ne produit pas cinq preuves indépendantes ; il découpe artificiellement la même source.

Pour cadrer une automatisation qui combine Python, API et IA sans surdimensionner l’architecture, la page automatisation IA et Python décrit les contrôles, la reprise et les livrables attendus.

Checklist d’architecture

Avant de valider un second agent, demandez :

• quelle décision ne peut pas rester dans le code ?
• quelle différence d’expertise ou de permission justifie la frontière ?
• les branches peuvent-elles avancer indépendamment ?
• qui possède la réponse finale ?
• quel contexte exact franchit la délégation ?
• comment un résultat partiel est-il représenté ?
• quel budget arrête la création de nouvelles branches ?
• comment un conflit est-il rendu visible ?
• quelle étape exige une validation humaine ?
• comment le run reprend-il après une panne ?
• quel test compare le gain au mono-agent ?
• quel signal conduira à retirer un agent ?

Si plusieurs réponses restent vagues, revenez au workflow. Une architecture plus petite est plus facile à sécuriser, mesurer et transmettre.

Limites

Les patrons décrits par OpenAI, Anthropic et Microsoft évoluent avec leurs SDK et leurs produits. Les exemples de performance ou de consommation publiés par un fournisseur reflètent son système et ne se généralisent pas automatiquement. La matrice SÉPARER ne remplace ni une analyse de sécurité, ni des évaluations métier, ni un contrôle des données. Un système multi-agents peut réussir un panel de tests et dériver sur des tâches nouvelles ; limitez le périmètre, observez les coûts et conservez un chemin mono-agent ou manuel lorsque la coordination n’apporte plus de valeur.

Articles liés

• Agents API d’OpenAI : décider et recetter un premier pilote
• Prompt ou workflow : choisir le bon niveau
• Journaliser un agent IA et rejouer une exécution
• SLO d’un agent IA et budget d’erreur