Comparaison de quatre modèles de systèmes multi-agents : sous-agents, compétences, transferts de tâches, routeurs.

Une histoire bien connue : une équipe développe un système d’agents sophistiqué composé de plusieurs modèles, de chemins de routage complexes et d’agents qui génèrent d’autres agents, pour découvrir ensuite qu’une version à un seul agent, conçue en une fin de semaine, est supérieure en termes de latence, de facilité de débogage et de tous les autres critères importants. Pour sortir de ce piège, il faut d’abord comprendre que presque tous les systèmes multi-agents sérieux sont construits à partir de quatre modèles, et savoir quel est le coût de chacun ainsi que ce qu’ils apportent.

Avez-vous vraiment besoin de plusieurs agents ?

Généralement non. Il est courant de recourir à un cadre multi-agents dès la première semaine, poussé par l’enthousiasme et l’attrait d’un diagramme rempli de flèches ; le résultat est souvent fragile et coûteux, alors qu’un seul agent bien configuré aurait pu faire mieux.

Deux situations justifient l’utilisation d’outils supplémentaires. La première concerne la limite de la fenêtre de contexte : on ne peut pas intégrer une analyse juridique, du codage médical, de la modélisation financière et du traitement des émotions dans une seule demande tout en espérant un résultat cohérent, car un contexte surchargé diminue la qualité et ralentit les réponses. La seconde situation concerne la répartition des responsabilités au sein d’une équipe : lorsque l’une gère les stocks et l’autre l’exécution des commandes, leur imposition à utiliser une seule demande unique entraîne des conflits, des déploiements défaillants et de la confusion quant à savoir qui est responsable de quoi. Face à l’un ou l’autre de ces problèmes, les modèles présentés ci-dessous deviennent une solution pratique plutôt qu’une architecture mise en place pour elle-même.

Subagents : le chef de cabinet

Imaginez un chef de cabinet qui ne fait jamais le travail personnellement mais sait exactement à qui s’adresser. Un agent superviseur principal a une vue d’ensemble de la situation. Lorsqu’il est nécessaire de récupérer des données CRM, de rédiger un e-mail ou d’exécuter un calcul, il fait appel à un sous-agent spécialisé comme s’il s’agissait d’un outil, reçoit le résultat et assemble tout ensemble.

L’avantage réside dans la propreté du système. Chaque sous-agent travaille de manière isolée dans son propre contexte restreint, de sorte qu’aucune information ne s’écoule entre les domaines : le sous-agent juridique ne sait rien de l’inventaire. Cet isolement est avantageux lorsque les domaines sont importants et distincts, car chaque spécialiste peut suivre des instructions détaillées sans avoir à partager l’espace avec des informations non pertinentes. Il facilite également les tests, car un sous-agent peut être évalué indépendamment. Le prix à payer est une appel supplémentaire au modèle par requête, car les résultats doivent remonter via le superviseur ; ainsi, trois sous-agents entraînent trois allers-retours supplémentaires. Les applications sensibles à la latence le ressentent rapidement.

Cela convient aux plateformes de recherche qui délèguent le travail à des spécialistes du domaine, aux assistants personnels qui coordonnent en même temps le calendrier, les e-mails et les tâches, ainsi qu’au tri médical où un agent principal envoie des instructions en parallèle à des sous-agents cliniques. Une configuration de recherche publiée, où un modèle de grande taille agissait en leader et des modèles plus petits en tant que sous-agents, aurait surpassé un modèle de grande taille indépendant de plus de 90 % sur des benchmarks internes. Le raisonnement parallèle dans des fenêtres de contexte distinctes est très efficace lorsque la tâche l’exige.

Compétences : un agent, plusieurs rôles

Techniquement, il s’agit toujours d’un seul agent, même s’il ne se comporte pas comme tel. Il commence chaque conversation en ne connaissant que les noms et les descriptions succinctes des compétences disponibles, puis charge le contexte complet d’une compétence lorsque des éléments pertinents apparaissent. Un médecin généraliste fonctionne de la même manière, en consultant le protocole spécialisé correspondant lorsqu’une maladie particulière se présente, sans avoir à mémoriser tous ces protocoles pour chaque consultation.

L’avantage pratique est l’indépendance. Une équipe Python gère la compétence Python et une équipe de base de données gère les compétences SQL, chacune en tant que package distinct, sans qu’aucune coordination ne soit nécessaire autour d’un prompt commun. Cela représente un véritable soulagement pour les organisations d’ingénierie distribuées. L’inconvénient réside dans l’accumulation de tokens : plus la conversation dure et plus de compétences sont chargées, plus le contexte devient lourd, ce qui finit par nuire à la fois aux coûts et à la qualité vers la fin de la session. C’est gérable, mais c’est un problème réel.

Les compétences correspondent aux assistants de codage qui passent d’un mode frontend à un mode backend ou d’infrastructure, aux outils créatifs qui changent de style d’écriture, ainsi qu’aux agents de support qui mobilisent des connaissances spécialisées en fonction du problème réel du client.

Transferts : la course de relais

Si les sous-agents représentent une délégation parallèle et les compétences une spécialisation dynamique, les transferts constituent une progression séquentielle, similaire à la manière dont les gens avancent à travers un processus complexe. Un utilisateur commence avec l’Agent A. Dès qu’un élément est énoncé ou qu’une condition est remplie, le contrôle est transféré à l’Agent B, qui dispose de ses propres prompts système, outils et peut-être même de sa propre personnalité, puis à l’Agent C. Tout au long de ce processus, l’état, c’est-à-dire tout ce qui a été discuté et décidé, est transmis avec chaque transfert.

Les transitions sont déterminées par l’état. Les agents ne s’appellent pas simplement les uns les autres ; ils mettent à jour un état partagé, et c’est cet état qui décide qui sera actif ensuite. En réalité, il s’agit d’une machine à états où les agents représentent les états eux-mêmes.

C’est une structure naturelle pour les flux de support en plusieurs étapes (triage, puis diagnostic, puis résolution), pour les processus juridiques où les vérifications de conflits doivent précéder l’examen de l’affaire, ainsi que pour les flux de paiement où le règlement ne peut commencer qu’après confirmation du panier. L’équilibre que les gens oublient, c’est que la séquentialité signifie l’absence de parallélisme : si vous devez interroger trois bases de connaissances en même temps, cherchez ailleurs. Cela convient uniquement aux workflows où l’Étape B ne peut vraiment pas commencer avant que l’Étape A ne soit terminée. La gestion de l’état est également complexe, et lorsque la chaîne de transfert est perturbée, le débogage n’est pas trivial ; prévoyez donc du temps supplémentaire pour les outils de suivi et d’observabilité avant de choisir cette approche.

Routeur : le contrôleur aérien

Conceptuellement, c’est simple. Un élément en amont classe chaque requête reçue et la dirige vers le ou les spécialistes appropriés. Ceux-ci fonctionnent en parallèle, et leurs résultats sont fusionnés en une seule réponse. Le routeur ne conserve aucun état, ce qui permet de traiter chaque demande de manière indépendante.

Sa force réside dans sa capacité de traitement. Une question relevant de trois domaines de connaissance est envoyée simultanément aux trois agents concernés, et le temps total nécessaire correspond approximativement à celui de l’appel le plus lent, et non à la somme des temps. Dans une base de connaissances d’entreprise, une question d’un employé peut concerner les politiques RH, les directives de sécurité informatique et les exigences financières ; le routeur déclenche alors les trois agents en même temps et synthétise une seule réponse, alors qu’autrement il faudrait effectuer trois requêtes ou confier à un seul agent surchargé la gestion des trois domaines.

La limite fondamentale est que l’absence d’état signifie l’absence de mémoire. Une question suivante arrive sans aucun souvenir de ce qui a précédé, ce qui représente un véritable problème pour les produits conversationnels. La solution habituelle consiste à entourer le routeur d’un agent externe doté d’un état qui conserve l’historique, bien que cela combine différents schémas et augmente la complexité. Les routeurs conviennent aux systèmes à fort volume avec des composants clairement séparés, à tout ce qui nécessite plusieurs sources de connaissances simultanément, ainsi qu’aux cas où la cohérence par requête est plus importante que la continuité conversationnelle.

Choix

Cela n’a pas besoin d’être source d’angoisse.

• Plusieurs domaines distincts, une exécution parallèle propre et un point de contrôle centralisé vers des sous-agents.
• Un seul agent avec de nombreuses spécialisations, géré par différentes équipes, orienté vers des compétences spécifiques.
• Un flux de travail intrinsèquement séquentiel, avec des préconditions et un état transmis d’une étape à l’autre, orienté vers des transferts de responsabilités.
• Des volumes importants de requêtes dans différents domaines, nécessitant un traitement parallèle sans historique de conversation, indiquent l’utilité d’un routeur.

Un autre facteur à considérer est la performance. Les modèles à état, avec leurs compétences et mécanismes de transfert, permettent d’économiser environ 40 à 50 pour cent des appels au modèle pour les requêtes répétées, car ils se souviennent du contexte précédent. Les sous-agents et les routeurs, quant à eux, n’ont pas d’état et entraînent toujours les mêmes coûts, mais obtiennent en retour une forte isolation du contexte, ce qui est essentiel pour les charges de travail parallèles sur de grands domaines.

La retenue passe en premier

Ne créez pas de systèmes multi-agents simplement pour paraître sophistiqués ; créez-les pour résoudre un problème que vous avez réellement rencontré. Une progression logique consiste d’abord à disposer d’un agent avec des instructions vraiment efficaces, puis d’ajouter des outils, et seulement ensuite des schémas multi-agents, une fois que vous avez heurté un obstacle concret tel qu’un débordement de contexte, des tensions liées à la responsabilité au sein de l’équipe ou un besoin de parallélisme que seul un agent ne peut pas assurer. Les équipes disposant des meilleurs systèmes sont généralement celles qui ont résisté le plus longtemps à la complexité et qui savent expliquer pourquoi chaque élément existe.

Que vient ensuite ?

Considérez ces quatre modèles comme la grammaire de base du design multi-agents actuellement, avec un vocabulaire nouveau qui apparaît rapidement. Les agents locaux persistants, capables de conserver leur mémoire entre les sessions et de se connecter à des fichiers et des applications personnelles, passent du domaine de la recherche à celui des produits. Le Model Context Protocol, dont le nombre d’installations atteignait 97 millions au début de 2026, devient le mécanisme qui permet aux agents de différents fournisseurs de communiquer sans intégration personnalisée. Des réseaux d’agents qui génèrent dynamiquement de nouveaux agents, en adaptant leur force de travail en fonction de la complexité des tâches, commencent à apparaître. Les sous-agents, les compétences, les transferts de responsabilités et les routeurs constituent la base de tout cela ; donc les maîtriser dès maintenant donne un avantage. Une règle pratique pour décider : écrivez d’abord le problème concret, identifiez le modèle qui y répond, et ce n’est qu’ensuite que vous dessinerez le diagramme. Commencez par quelque chose de simple, soyez honnête sur vos besoins, et lorsque vous passerez à des systèmes multi-agents, vous saurez quelle voie choisir.