Le système multi-agents est devenu l'architecture par défaut dans les présentations de projets d'IA. Le schéma est toujours élégant : un agent chef de projet, un agent chercheur, un agent rédacteur, un agent relecteur, reliés par des flèches. Il évoque une équipe, il rassure, et il se dessine très bien sur une diapositive.
En production, les choses se passent moins bien. La latence se multiplie, la facture explose, et le diagnostic d'une réponse ratée devient un exercice pénible : lequel des cinq agents s'est trompé, et à quelle étape ? Beaucoup d'équipes finissent par revenir à un agent unique, mieux outillé, qui fait le même travail plus vite et pour moins cher.
Cet article décrit les schémas d'organisation courants, chiffre ce qu'ils coûtent réellement, et propose des critères de décision. La thèse défendue ici est simple : un agent unique correctement outillé bat souvent une équipe d'agents mal cadrée, et le vrai motif de passer à plusieurs agents n'est presque jamais celui que l'on avance.
Ce qu'on appelle une architecture multi-agents
Rappelons le point de départ. Un agent est un modèle de langage placé dans une boucle : il reçoit un objectif, choisit d'appeler un outil, observe le résultat, décide de l'étape suivante, et recommence jusqu'à ce qu'il estime avoir terminé. Ce schéma de raisonnement et d'action alterné a été formalisé dans les travaux académiques sur les agents outillés, et il constitue la brique de base. Si la notion n'est pas familière, notre article qu'est-ce qu'un agent IA pose les définitions.
Une architecture multi-agents consiste à faire coexister plusieurs de ces boucles, avec des rôles, des instructions et parfois des outils différents, et à organiser leurs échanges. La littérature technique, à commencer par les travaux sur les cadres de conversation entre agents, décrit plusieurs schémas récurrents.
Le superviseur
Un agent central reçoit la demande, la découpe, délègue chaque morceau à un agent spécialisé, puis assemble. C'est le schéma le plus répandu et le plus lisible. Sa faiblesse est que le superviseur devient un goulot : il doit comprendre assez de chaque spécialité pour bien découper, et il porte tout le contexte.
La chaîne
Les agents se succèdent, chacun consommant la sortie du précédent : extraction, puis analyse, puis rédaction. Simple, prévisible, facile à tester étape par étape. Sa faiblesse est la propagation d'erreur : une extraction ratée en position 1 contamine tout ce qui suit, sans aucun mécanisme de rattrapage.
Le débat ou la critique
Un agent produit, un autre critique, le premier corrige. Ce schéma améliore réellement la qualité sur les tâches où l'erreur est identifiable à la lecture : cohérence d'un raisonnement, respect d'un cahier des charges, conformité à un format. Il n'apporte rien quand la vérification demande une information que ni l'un ni l'autre ne possède.
Le parallèle avec agrégation
Plusieurs agents traitent la même tâche indépendamment, et un dernier arbitre. Cela réduit la variance des réponses, au prix d'une multiplication directe du coût. Utile sur des décisions à fort enjeu et à faible volume, absurde sur un flux quotidien.
Ce que coûte réellement l'orchestration d'agents
Le coût d'un système multi-agents n'est pas la somme des coûts de ses agents : il est nettement supérieur, pour trois raisons cumulatives.
Le contexte est rechargé par chacun. Chaque agent possède ses propres instructions, et reçoit tout ou partie de l'historique nécessaire pour comprendre sa mission. Une même information peut être payée quatre fois. Sur une architecture à cinq agents, il n'est pas rare que la consommation soit trois à six fois supérieure à celle d'un agent unique traitant la même demande. Notre article sur le coût du token et la lecture d'une facture d'API détaille cette mécanique.
La latence s'additionne. Les étapes séquentielles ne se recouvrent pas. Un agent unique qui répond en 8 secondes devient une chaîne de quatre agents qui répond en 35 secondes. Pour un usage en arrière-plan, c'est indifférent. Pour un utilisateur qui attend devant son écran, c'est rédhibitoire.
Le diagnostic devient coûteux. C'est le coût caché le plus lourd. Avec un agent, la trace d'exécution est linéaire et se lit en deux minutes. Avec cinq agents, il faut reconstituer qui a dit quoi à qui, et comprendre pourquoi une consigne s'est déformée en passant de main en main.
| Schéma | Quand il apporte quelque chose | Surcoût en jetons | Risque principal |
| Agent unique outillé | Tâche cohérente, moins de 15 à 20 outils | Référence | Confusion si trop d'outils |
| Superviseur | Sous-tâches hétérogènes, droits distincts | x2 à x4 | Découpage inadapté |
| Chaîne | Étapes strictement ordonnées | x1,5 à x3 | Propagation d'erreur |
| Débat ou critique | Erreurs détectables à la relecture | x2 à x3 | Accord sur une erreur commune |
| Parallèle avec arbitrage | Décisions rares à fort enjeu | x3 à x6 | Coût sans gain sur les cas simples |
Les quatre bonnes raisons de passer à plusieurs agents IA
Il existe des situations où faire travailler plusieurs agents IA est le bon choix, et elles se reconnaissent à des critères objectifs.
- Le cloisonnement des droits. C'est de loin la meilleure raison, et la plus rarement citée. Si une partie du traitement doit accéder à des données sensibles et une autre écrire dans un système externe, les séparer en deux agents aux permissions distinctes est une décision de sécurité, pas d'architecture. Le principe rejoint ce que nous décrivions dans notre article sur la façon de sécuriser un agent IA.
- Le nombre d'outils devenu ingérable. Au-delà d'une quinzaine ou d'une vingtaine d'outils exposés dans un même contexte, la qualité de sélection se dégrade nettement : l'agent choisit le mauvais outil, ou en oublie l'existence. Regrouper par domaine devient alors une nécessité pratique.
- Les régimes de latence incompatibles. Une partie doit répondre en deux secondes, une autre peut prendre dix minutes. Ce sont deux services différents, et il vaut mieux l'assumer.
- Le besoin d'une vérification indépendante. Quand le contrôle doit être structurellement séparé de la production, par exemple pour une validation de conformité, un agent distinct avec ses propres critères a du sens.
À l'inverse, trois motifs très fréquents ne justifient pas une architecture multi-agents : le fait que le processus métier comporte plusieurs étapes (une fonction suffit), le fait que la tâche soit « complexe » (un meilleur découpage des outils règle souvent le problème), et le fait que le schéma soit plus lisible sur une présentation.
Comment décider, concrètement
La méthode la plus fiable consiste à commencer par le cas simple et à ne complexifier que sur constat d'échec. Quatre étapes :
- Construisez d'abord un agent unique, avec les outils strictement nécessaires, et un jeu de tests de trente à cent cas réels. Sans ce jeu de tests, aucune comparaison n'est possible. Notre article sur la façon d'évaluer les réponses d'une IA avec un jeu de tests décrit le protocole.
- Mesurez trois choses : taux de réussite, latence médiane, consommation moyenne par demande.
- Analysez les échecs par catégorie. S'ils viennent d'un mauvais choix d'outil, réorganisez les outils. S'ils viennent d'un manque de vérification, ajoutez une étape de critique. S'ils viennent d'un contexte saturé, découpez.
- N'ajoutez qu'un agent à la fois, et comparez sur le même jeu de tests. Un ajout qui n'améliore pas le taux de réussite d'au moins quelques points ne mérite pas son surcoût.
Sur le plan de l'outillage, la standardisation des accès aux outils facilite grandement ces réorganisations : un même serveur d'outils peut être exposé à un agent ou à cinq sans réécriture, ce qui est précisément l'objet des protocoles d'interconnexion décrits dans notre article sur le protocole MCP.
Enfin, quelle que soit l'architecture, les garde-fous restent les mêmes : limitation du nombre d'itérations, plafond de dépense par demande, journalisation complète des appels d'outils, et validation humaine sur les actions irréversibles. Notre article sur les agents IA en production détaille ce dispositif, qui devient d'autant plus nécessaire que les agents sont nombreux.
Système multi-agents : ce qu'il faut retenir
Un système multi-agents n'est ni une mode creuse ni une solution générale. C'est un choix d'architecture qui se paie en latence, en jetons et en difficulté de diagnostic, et qui doit donc s'acheter avec une contrepartie mesurée sur un jeu de tests.
La règle pratique tient en une phrase : commencez par un agent unique avec de bons outils, mesurez, et ne divisez que lorsque vous pouvez nommer précisément le problème que la division résout. Dans les projets d'entreprise, les deux motifs qui tiennent réellement sont le cloisonnement des permissions et le trop grand nombre d'outils. Tout le reste se règle le plus souvent en améliorant les outils d'un seul agent.
Laisser un commentaire