Douze agents qui ne se parlent pas

Un seul, bien outillé, dans la très grande majorité des cas. La spécialisation par agent paraît propre sur un schéma d’architecture et elle produit en pratique ce que les entreprises constatent aujourd’hui : douze agents en moyenne, dont la moitié fonctionnent complètement isolés les uns des autres.

Le chiffre qui rend le sujet préoccupant n’est pas celui-là, c’est l’écart entre l’intention et le résultat. 71 % des entreprises déclarent avoir déployé des agents, et 11 % seulement des cas d’usage prévus l’année précédente sont effectivement passés en production. La différence n’est presque jamais un problème de modèle.

D’où viennent les douze agents

Personne ne les a choisis. Ils arrivent par les logiciels : votre outil de support en ajoute un, votre suite bureautique en propose un autre, l’équipe commerciale en essaie un troisième pendant que la comptabilité active celui de son éditeur. Au bout de dix-huit mois, l’entreprise en a douze et n’a pris aucune décision d’architecture.

C’est très exactement le mécanisme qui a produit la prolifération des abonnements SaaS il y a dix ans, avec une différence qui aggrave le problème. Un logiciel isolé est un endroit où l’on va chercher une information ; un agent isolé est un endroit où l’on doit réexpliquer son contexte, et la charge se paie à chaque usage plutôt qu’une fois à l’installation.

Le symptôme se reconnaît sans instrumentation. Dès qu’une personne copie régulièrement la sortie d’un agent vers l’entrée d’un autre, vous payez deux abonnements pour faire faire par un humain le travail d’intégration que les deux éditeurs ont laissé de côté, et cette personne est votre couche de compatibilité.

Pourquoi la spécialisation coûte plus qu’elle ne rapporte

L’argument en faveur de plusieurs agents spécialisés est intuitif : chacun fait moins de choses, donc chacun les fait mieux. L’intuition tient tant qu’on regarde une tâche isolée, et elle cesse de tenir dès que le travail réel commence, parce que le travail réel traverse les frontières que la spécialisation a posées.

Une demande ordinaire dans une ESN touche le vivier, le dossier client, l’historique des échanges et le calendrier. Découpée entre quatre agents, elle devient quatre conversations, quatre contextes à reconstituer et quatre occasions de perdre l’information qui comptait. Le gain de spécialisation est réel sur chaque segment et il est inférieur au coût des coutures.

Nous avons déjà écrit la version technique de ce constat : un agent unique bien doté en skills égale une architecture multi-agents sur les tâches où on les compare sérieusement. L’article que vous lisez en est la version organisationnelle, et elle est plus dure, parce qu’une frontière entre deux agents de deux éditeurs différents n’est pas seulement technique : c’est une frontière de contrat, de facturation et de responsabilité.

Le bon critère n’est pas le nombre d’agents

C’est le nombre d’endroits où votre contexte est recopié. Un contexte est ici tout ce qui rend une réponse pertinente chez vous : vos règles internes, vos clients, l’historique de ce qui a été fait, les préférences des personnes qui travaillent avec l’outil.

Chaque copie de ce contexte est une copie qui vieillira à sa vitesse, et vous connaissez déjà la suite du raisonnement : une donnée fausse coûte plus cher à mesure que l’agent qui la lit devient bon. Douze agents avec douze contextes, ce sont douze bases qui divergent, et la divergence ne se signale jamais.

La duplication a un second coût, qui apparaît plus tard et fait plus mal. Chaque agent détient un fragment de ce qui s’est passé, si bien qu’aucun ne sait répondre à une question portant sur le trimestre écoulé, et la seule personne capable de reconstituer la réponse est celle qui était dans toutes les conversations. Vous avez automatisé la production de traces en rendant la trace illisible.

Posez donc la question autrement quand vous évaluez un produit. Non pas « que sait faire cet agent », mais « qu’est-ce que je vais devoir lui réexpliquer que j’ai déjà expliqué ailleurs ». Si la réponse est « tout », vous n’achetez pas un collègue, vous achetez un treizième endroit où maintenir la vérité.

Ce que l’interopérabilité règle, et ce qu’elle ne règle pas

MCP a beaucoup amélioré la situation technique, et il faut lui reconnaître ce qu’il apporte : raccorder un agent à un outil est devenu une opération standard au lieu d’un développement spécifique. Ce qui reste entier est la partie qui coûte.

Un protocole commun ne décide pas qui détient la mémoire, ni quels droits chaque agent possède, ni qui répond quand deux d’entre eux ont agi sur le même dossier en dix minutes. Ces trois questions sont des questions d’architecture et d’organisation, elles ne se résolvent pas par un format d’échange, et c’est pourquoi nous écrivons que MCP est un critère de sortie plutôt qu’un critère d’achat.

Il existe une raison structurelle à ce que la fragmentation persiste malgré les protocoles. Chaque éditeur a intérêt à ce que son agent soit celui qui détient le contexte, parce que le contexte est ce qui rend le changement d’outil coûteux. Attendre que le marché résolve spontanément ce problème revient à attendre que des concurrents renoncent tous en même temps à leur meilleur verrou.

Comment revenir de douze à trois

Le conseil habituel consiste à tout rationaliser d’un coup, ce qui ne se fait jamais parce que chaque agent est attaché à un logiciel que quelqu’un défend. La méthode qui fonctionne procède par usage plutôt que par outil, et elle tient en trois étapes sur un trimestre.

Listez d’abord les dix demandes les plus fréquentes de vos équipes, formulées comme elles les formulent, sans les traduire en fonctionnalités. « Où en est-on avec ce client », « qui avons-nous de disponible sur cette technologie », « qu’est-ce qui a été dit au dernier point » : ces phrases traversent les frontières entre outils, et c’est précisément ce qui les rend utiles pour juger.

Regardez ensuite, pour chacune, combien d’agents il faut interroger pour obtenir la réponse. Une demande qui en demande trois est une demande qu’aucun des trois ne traite, et elle désigne l’endroit où le contexte devrait être commun. C’est un travail d’une demi-journée qui produit un classement bien plus solide qu’un comparatif de fonctionnalités.

Gardez enfin ce qui reste légitimement séparé, et il en reste toujours. Un agent enfermé dans un domaine étroit, sans accès à vos données et sans mémoire, ne pose pas de problème de fragmentation parce qu’il ne prétend pas connaître votre entreprise : un assistant de génération de code ou de rédaction juridique entre dans cette catégorie. Ce qui doit converger est ce qui a besoin de votre contexte pour être pertinent, et rien d’autre.

Ce que nous en tirons pour notre propre produit

Nous avons pris le parti d’un agent unique, présent là où les équipes se parlent déjà, avec une mémoire qui ne se duplique pas. Ce n’est pas un choix de simplicité : construire un agent qui traverse le vivier, les échanges et le calendrier demande plus de travail que d’en livrer quatre spécialisés, et cela se voit dans notre calendrier.

La contrepartie est réelle et nous l’assumons. Un agent unique est plus difficile à faire progresser, parce qu’une amélioration doit tenir sur tous les cas au lieu d’un seul, et il est moins impressionnant en démonstration qu’un assistant très pointu sur une tâche étroite. Nous avons jugé que la démonstration n’était pas ce qui comptait au sixième mois.

La question qui suit est celle du périmètre, et elle est légitime. Un agent qui traverse tout est aussi un agent qui pourrait faire trop, ce qui ramène à la seule limite qui tienne : celle qui est inscrite dans le produit plutôt que demandée poliment.