Guide · Avancé · 10 min
Systèmes multi-agents : quand plusieurs agents valent mieux qu'un, architectures, coûts et pièges
Les systèmes multi-agents répartissent le travail entre agents spécialisés. Découvrez quand les utiliser, comment les organiser et maîtriser leurs coûts.
Un système multi-agents devient utile lorsque le travail se divise en missions indépendantes, exige des contextes spécialisés ou nécessite des permissions séparées. Il peut améliorer la couverture d’un sujet et réduire certains délais, mais ajoute des échanges, des coûts et des défaillances possibles. Le bon choix consiste à comparer son résultat à celui d’un agent unique correctement équipé, puis à conserver uniquement les délégations dont le bénéfice est mesuré.
Ce qui distingue plusieurs agents d’un simple workflow
Un système multi-agents coordonne plusieurs agents capables de prendre des décisions dans leur périmètre. Chacun reçoit une mission, utilise éventuellement des outils et transmet un résultat. Ils peuvent partager le même modèle : leur séparation repose aussi sur leurs instructions, leur contexte, leur état et leurs droits.
Enchaîner extraction, traduction et mise en forme ne constitue donc pas automatiquement une équipe d’agents. Si chaque étape applique une opération prédéfinie, vous avez un workflow. Cette solution reste souvent préférable pour un processus stable, car son chemin est plus facile à vérifier.
L’orchestration définit qui reçoit quelle tâche, dans quel ordre, avec quelles informations et selon quelle règle d’arrêt. Elle peut être programmée, décidée par un modèle ou combiner les deux approches. Une décision flexible n’oblige pas à rendre flexible tout le système.
Le guide historique d’Anthropic Building effective agents distingue ainsi chemins prédéfinis et décisions dynamiques. Cette distinction aide à éviter une confusion fréquente : multiplier les rôles nommés ne prouve ni une meilleure autonomie ni une meilleure qualité.
Pour identifier les logiciels concernés, l’annuaire des agents et frameworks rassemble leurs fiches. L’architecture doit néanmoins partir du besoin métier, avant le choix d’un framework ou d’une métaphore d’équipe.
Quand la délégation apporte un bénéfice
Le premier cas favorable est une recherche divisible. Pour comparer des fournisseurs, des agents peuvent examiner séparément la documentation technique, les conditions contractuelles et les possibilités d’intégration. Le coordinateur rapproche ensuite les résultats selon une grille commune. Cet exemple décrit une architecture possible, pas un cas client mesuré.
Le deuxième cas concerne l’isolation du contexte. Une investigation produit parfois beaucoup de documents et de résultats intermédiaires dont seule une petite partie sert à la décision finale. Un sous-agent peut explorer ce matériau puis restituer une synthèse accompagnée de preuves, sans encombrer toute la conversation principale.
Le troisième cas repose sur des frontières opérationnelles. Un agent consulte des informations publiques ; un autre interroge un système interne avec des droits limités. Cette séparation n’est protectrice que si l’infrastructure impose réellement les restrictions.
Dans son retour technique sur son système de recherche multi-agents, publié en juin 2025, Anthropic décrit une organisation avec coordinateur et sous-agents parallèles. Ce retour concerne son propre dispositif ; il ne démontre pas qu’une architecture semblable améliore toutes les tâches.
À l’inverse, gardez un agent unique lorsque les étapes dépendent étroitement les unes des autres, que le contexte tient facilement dans une session ou que la mission est courte. Avant de déléguer, vérifiez aussi si de meilleurs outils, des instructions plus précises ou un accès documentaire mieux ciblé suffisent.
Les architectures et leurs compromis
Les schémas suivants répondent à des contraintes différentes. Ils peuvent se combiner, mais chaque combinaison augmente le nombre de transitions à expliquer, surveiller et tester.
| Architecture | Organisation | Usage adapté | Coût de coordination | Piège principal |
|---|---|---|---|---|
| Chaîne séquentielle | Chaque agent transmet au suivant | Étapes spécialisées avec livrables distincts | Transmissions successives | Une erreur initiale se propage |
| Coordinateur et exécutants | Un agent délègue puis assemble | Recherche divisible, investigations ciblées | Planification et synthèse | Le coordinateur devient un goulot |
| Routage | Une demande part vers le spécialiste choisi | Catégories de demandes bien séparées | Classification initiale | Mauvaise orientation |
| Passage de relais | Un spécialiste reprend la conversation | Parcours nécessitant des compétences successives | Transfert de contexte et de responsabilité | Relais répétés ou contexte perdu |
| Production et vérification | Un agent produit, un autre contrôle | Résultats avec critères vérifiables | Relecture et corrections | Accord trompeur entre agents |
Une chaîne séquentielle conserve un ordre clair, mais ne raccourcit pas forcément le délai. Le parallélisme n’apporte un gain que pour les branches indépendantes. Si chaque agent attend le précédent, vous ajoutez surtout des frontières de contexte.
Le coordinateur central facilite l’attribution des missions et l’assemblage final. En contrepartie, il doit comprendre les résultats reçus, identifier les contradictions et décider s’il manque une preuve. Un résumé mal compris peut annuler la qualité des investigations.
La documentation des architectures multi-agents de LangChain présente notamment sous-agents, routage et passages de relais. Elle rappelle qu’un agent unique, avec des outils et un contexte adaptés, peut suffire à une tâche complexe.
Choisissez donc le schéma selon les dépendances du travail. Une organisation qui ressemble à un organigramme humain n’est pas nécessairement adaptée à un programme.
Définir des missions et des transmissions vérifiables
Un rôle tel que « expert qualité » ne suffit pas à encadrer une délégation. Le sous-agent doit recevoir une question précise, un périmètre, des sources autorisées et un résultat attendu. Il doit également savoir quand s’arrêter et comment signaler une impossibilité.
Pour une recherche documentaire, un contrat de mission peut préciser :
- les éléments à établir et ceux qui restent hors périmètre ;
- les documents accessibles et leur niveau de confiance ;
- le format des constats et des références ;
- les limites de durée, de dépenses et d’appels d’outils ;
- les conditions d’escalade vers le coordinateur.
Le livrable doit distinguer les faits établis, les hypothèses et les points non résolus. Une réponse fluide sans références ne donne pas au coordinateur les moyens de vérifier. Demandez les éléments utiles au contrôle : passage source, date pertinente, résultat d’outil ou identifiant du document consulté.
Évitez aussi les transmissions qui recopient systématiquement toute la conversation. Elles diffusent des données inutiles et augmentent le volume traité. À l’inverse, une mission trop dépouillée force le spécialiste à refaire l’exploration déjà accomplie.
Le bon contexte contient l’objectif global nécessaire, les contraintes applicables et les pièces pertinentes. Le coordinateur conserve un registre des missions : responsable, état, dépendances, livrable attendu et motif d’arrêt. Ce registre permet de repérer les tâches abandonnées, les doublons et les résultats arrivés après la décision finale.
Organiser l’état partagé et les accès aux outils
Séparez l’état de chaque agent des informations faisant autorité pour l’ensemble du système. Les notes exploratoires peuvent rester locales. Les décisions validées, les livrables et les références doivent rejoindre un espace contrôlé, avec une provenance et une version.
Pour un travail sur fichiers, attribuez explicitement la responsabilité des écritures. Des agents qui modifient simultanément le même document peuvent écraser leurs changements ou travailler sur des hypothèses incompatibles. Des espaces séparés, puis une intégration contrôlée, rendent les conflits visibles.
La reprise après incident mérite le même soin. Avant de relancer une action, vérifiez si elle a déjà réussi. Une création de ticket ou un envoi ne doit pas se répéter simplement parce que la réponse de l’outil s’est perdue. Utilisez des identifiants d’opération et des mécanismes de déduplication lorsque le service le permet.
Les protocoles ne règlent pas automatiquement ces problèmes. L’architecture officielle de MCP décrit les échanges entre applications et serveurs exposant notamment outils et ressources. Elle ne remplace pas votre politique d’attribution des tâches.
La documentation du protocole A2A concerne la communication et la collaboration entre agents. Un système interne peut fonctionner sans ce protocole ; son intérêt dépend des besoins d’interopérabilité.
Dans tous les cas, définissez qui peut lire, écrire et transmettre chaque donnée. Un message entre agents reste un transfert d’information, même si les deux agents appartiennent au même projet.
Calculer le coût par tâche acceptée
Le nombre d’agents ne permet pas de prévoir directement la facture. Le coût dépend des appels au modèle, des volumes traités, des outils payants, de l’infrastructure et des reprises. Une équipe avec des contextes courts peut consommer moins qu’un agent qui relit continuellement un historique volumineux.
Pour chaque appel, distinguez les tokens d’entrée, les tokens de sortie et les éventuelles catégories facturées séparément. Appliquez les tarifs réellement utilisés, puis additionnez les dépenses des agents et du coordinateur. Le calculateur de prix LLM aide à préparer ces estimations.
Exemple arithmétique fictif, sans mesure de performance. La fiche de Claude Sonnet 5.5 indique 2 dollars par million de tokens en entrée et 10 dollars en sortie, selon le relevé du site, octobre 2026. À ces tarifs, un appel hypothétique de 10 000 tokens d’entrée et 2 000 de sortie coûte 0,04 dollar, hors autres postes et mécanismes tarifaires.
Quatre appels identiques coûteraient donc 0,16 dollar. Cela ne représente pas nécessairement quatre agents : un seul agent peut effectuer ces appels, tandis qu’une équipe peut en effectuer beaucoup davantage. L’exemple illustre une méthode de calcul, pas un budget courant.
Mesurez surtout le coût par tâche acceptée : dépenses de toutes les tentatives divisées par le nombre de résultats satisfaisant vos critères. Ajoutez séparément le temps de correction humaine. Une architecture moins chère par tentative peut devenir plus coûteuse si elle exige davantage de reprises.
Maîtriser les délais, les budgets et l’arrêt
En parallèle, le délai dépend de la branche la plus lente, puis de l’intégration finale. Il faut aussi compter les files d’attente, les limites des services et les éventuels contrôles humains. Lancer davantage de tâches ne garantit donc pas une réponse plus rapide.
Une branche peut également devenir inutile après une découverte faite ailleurs. Prévoyez un mécanisme d’annulation et une façon de récupérer son travail partiel. Sans cela, le système continue à dépenser alors que la décision est déjà prise.
Fixez des limites à plusieurs niveaux : mission globale, sous-tâche et outil. Elles peuvent porter sur le temps, les dépenses, les tentatives ou la profondeur des délégations. Le coordinateur ne doit pas pouvoir contourner un plafond en créant de nouveaux exécutants.
Définissez aussi les états de sortie : résultat complet, résultat partiel, blocage technique, preuve insuffisante ou validation requise. Un dépassement de budget ne doit pas être transformé en réponse apparemment complète.
Le guide Réduire le coût d’un agent IA approfondit le travail sur le contexte, le routage et les budgets. Pour le multi-agents, ajoutez une règle : toute nouvelle délégation doit avoir une raison explicite.
Choisir un framework sur ses contraintes d’exploitation
Deux approches méritent d’être distinguées. LangGraph permet de représenter explicitement les étapes et les transitions d’un système. Sa documentation sur les workflows et agents présente notamment des schémas de routage, de parallélisation et de coordination.
CrewAI organise notamment le travail autour d’agents et de tâches. Sa documentation des processus décrit des organisations séquentielles et hiérarchiques. Ces concepts peuvent faciliter la représentation d’une répartition des responsabilités.
| Critère de conception | Approche par graphe explicite | Approche par équipe et tâches |
|---|---|---|
| Description du travail | États, transitions, conditions | Missions, rôles, délégations |
| Contrôle recherché | Chemins et reprises visibles | Attribution des tâches lisible |
| Vigilance principale | Complexité du graphe | Délégations trop ouvertes |
| Vérification nécessaire | Transitions et état persistant | Missions et livrables transmis |
Ce tableau compare des approches, pas une frontière absolue entre produits. Un framework peut proposer plusieurs abstractions ; leur présence ne prouve pas que votre application gère correctement les incidents.
Avant de retenir une bibliothèque, vérifiez la conservation de l’état, l’annulation, l’inspection des exécutions, la gestion des secrets et la possibilité de remplacer un modèle. Testez ces fonctions sur un scénario dégradé.
L’article sur le choix d’un framework d’agents IA complète ce guide par un angle centré sur l’apprentissage et les outils. Pour une tâche limitée, une orchestration programmée dans votre application peut également suffire.
Les pièges de fiabilité et de sécurité
Le premier piège est l’erreur partagée. Des agents utilisant les mêmes sources ou recevant la même hypothèse initiale peuvent converger vers une réponse fausse. Leur accord ne constitue pas une validation indépendante.
Pour la relecture, donnez au contrôleur des critères observables et l’accès aux preuves originales. Demandez-lui de rechercher des défauts précis : référence absente, calcul incorrect, contrainte oubliée, action non autorisée. Les contrôles logiciels doivent prendre en charge ce qui peut être vérifié mécaniquement.
Le deuxième piège est la dilution des instructions. Une contrainte globale peut disparaître lors d’une transmission. Les règles essentielles doivent être appliquées par l’orchestrateur et les outils, plutôt que dépendre seulement d’un rappel textuel.
Le troisième concerne les contenus malveillants. Un document externe peut pousser un agent à transmettre une instruction piégée à son coordinateur. Le fait qu’un message provienne d’un sous-agent ne transforme pas le contenu cité en instruction fiable.
Limitez donc les droits de chaque exécutant, protégez les secrets hors de son contexte et contrôlez les sorties vers l’extérieur. La validation d’une action sensible doit porter sur ses paramètres exacts. Une approbation générale du plan ne suffit pas à autoriser toutes ses conséquences.
Le guide Sécuriser un agent IA développe ces mesures. Dans une équipe d’agents, leur application doit suivre toute la chaîne de délégation.
Évaluer le bénéfice avant le déploiement
Préparez un ensemble de tâches représentatives avant de multiplier les rôles. Incluez des demandes simples, ambiguës, incomplètes et difficiles, ainsi que des indisponibilités d’outils. Définissez pour chacune ce qui constitue une réponse acceptable et ce qui impose un arrêt.
Comparez le workflow déterministe lorsque le chemin est connu, l’agent unique et l’architecture multi-agents envisagée. Gardez des conditions comparables : accès aux données, outils, budget maximal et critères de qualité. Si vous changez simultanément le modèle et l’architecture, vous ne pourrez pas attribuer clairement le gain.
Suivez la réussite finale, les erreurs critiques, le coût par résultat accepté, les délais et les interventions humaines. Répétez les essais lorsque les résultats varient. Une moyenne favorable peut masquer des blocages longs ou des échecs coûteux.
Examinez ensuite les traces : mauvaise décomposition, doublon, preuve perdue, synthèse incorrecte ou permission excessive. Supprimez temporairement une délégation pour vérifier son apport. Si sa disparition ne dégrade pas le résultat, elle mérite d’être simplifiée.
Avant l’ouverture en production :
- chaque mission possède un livrable et une règle d’arrêt ;
- les budgets et les permissions sont imposés techniquement ;
- les écritures concurrentes et les reprises sont contrôlées ;
- les preuves restent accessibles au vérificateur ;
- les résultats sont comparés à une solution plus simple ;
- les actions sensibles disposent d’une validation adaptée.
Conservez enfin une possibilité de revenir au dispositif précédent. Une architecture multi-agents se justifie par un résultat mieux couvert, plus fiable ou obtenu dans un délai utile, avec un coût explicable. Le nombre de participants reste un moyen de conception, jamais une mesure de qualité.
Pages liées
Questions fréquentes
Faut-il plusieurs modèles pour créer un système multi-agents ?
Non. Plusieurs agents peuvent utiliser le même modèle avec des instructions, des outils et des contextes distincts. Employer des modèles différents est un choix de conception, à valider selon la qualité obtenue et le coût total.
Un système multi-agents peut-il fonctionner en local ?
Oui, si les modèles et les outils retenus peuvent fonctionner sur votre infrastructure. La concurrence entre agents sollicite toutefois les ressources disponibles : plusieurs tâches lancées ensemble peuvent finir par attendre le même moteur d'inférence.
Quelle différence entre sous-agent et appel d'outil ?
Un outil exécute une fonction définie, tandis qu'un sous-agent peut choisir ses propres étapes pour accomplir une mission. Le coordinateur peut néanmoins appeler un sous-agent au moyen d'une interface d'outil : les deux notions décrivent des niveaux différents.
Combien d'agents faut-il prévoir ?
Il n'existe pas de nombre optimal universel. Partezz d'une architecture simple, puis ajoutez une délégation seulement si elle résout une limite observée. Le nombre utile dépend des tâches indépendantes, des contraintes de délai et du budget disponible.
Peut-on laisser les agents se contrôler mutuellement ?
Une relecture entre agents peut détecter certaines erreurs, sans constituer une garantie. Pour une action sensible, associez des contrôles logiciels, des permissions limitées et une validation humaine adaptée aux conséquences.