Un agent qui rédige les comptes rendus de vos rendez-vous et un agent qui met à jour votre CRM peuvent tourner six mois côte à côte sans jamais échanger une ligne. Chacun a son prompt, ses accès, son historique. Le jour où vous voulez que le premier déclenche le second, il n'y a rien entre les deux, et le tuyau devient un projet à lui tout seul.
L'interopérabilité des agents IA n'est pas un problème de modèle. C'est un problème de contrats, de droits et de formats — des choses ennuyeuses, qui se règlent avec un schéma, un identifiant et un journal. Les protocoles disponibles aujourd'hui en couvrent une partie. Voici laquelle, ce qu'ils laissent à votre charge, et le montage qu'on garde quand plusieurs agents doivent travailler ensemble.
Interopérabilité des agents IA : trois problèmes qu'on confond
Le mot recouvre trois questions distinctes. Elles n'ont ni la même maturité ni les mêmes réponses, et les mélanger est la première cause de réunions qui tournent en rond.
Un agent et vos outils
Comment un agent lit votre base documentaire, crée un ticket, interroge votre facturation. C'est la question la mieux résolue aujourd'hui, et celle qui produit le plus de valeur immédiate. Historiquement, chaque intégration s'écrivait à la main pour un agent donné : changer de framework ou de modèle revenait à tout réécrire.
Un agent et un autre agent
Comment un agent confie une tâche à un agent qu'il n'a pas écrit, suit son avancement, récupère le résultat, et sait quoi faire quand l'autre échoue. C'est la question la moins mûre. C'est aussi celle à laquelle les gens pensent quand ils disent « interopérabilité ».
Un agent et la plateforme qui l'exécute
Ce qui se passe le jour où vous voulez déplacer un agent d'un fournisseur à un autre. Les prompts se déplacent facilement. Le reste — mémoire, historique des exécutions, format des traces, gestion des reprises — beaucoup moins. C'est là que se joue la dépendance réelle à un fournisseur, et personne ne la mesure avant d'avoir essayé.
La suite traite les trois dans cet ordre, parce que c'est celui dans lequel ils se posent.
MCP : brancher un agent sur un outil sans réécrire l'agent
Le Model Context Protocol, publié en open source par Anthropic, résout un problème de multiplication. Avant lui, brancher N agents sur M outils demandait N × M intégrations. Avec un protocole commun, chaque outil expose un serveur une fois, chaque agent parle ce protocole une fois, et on passe à N + M.
Le fonctionnement tient en trois idées.
Un serveur expose des capacités. Des outils, c'est-à-dire des actions que l'agent peut déclencher. Des ressources, c'est-à-dire de la donnée qu'il peut lire. Et des prompts prêts à l'emploi. Chaque outil est décrit par un schéma : son nom, ce qu'il fait, ses paramètres et leurs types.
Un client interroge ce serveur. L'agent demande la liste des capacités au démarrage et la reçoit sous une forme qu'il sait présenter au modèle. Il n'a pas besoin de connaître l'outil à l'avance : la description arrive dans la réponse.
Le transport est interchangeable. Un serveur peut tourner en local, à côté de l'agent, ou être appelé à distance en HTTP. Le même serveur sert un agent Claude Code sur le poste d'un développeur et un agent en production dans une intégration continue.
Ce que ça change concrètement : un connecteur écrit une fois sert tous vos agents. Le même serveur publicitaire alimente aussi bien un agent de reporting qu'un agent de pilotage de campagne — c'est le montage que nous décrivons dans notre article sur MCP appliqué à Google Ads.
Ce que ça ne change pas, et qu'il faut savoir avant de s'engager : le protocole décrit comment appeler un outil. Pas qui a le droit de l'appeler. Pas ce qui se passe quand l'outil répond une erreur. Pas comment vos quotas se partagent entre trois agents qui tapent sur la même API. Ces questions restent entières, et ce sont exactement celles d'une intégration ordinaire — nous les avons traitées côté outils métier dans notre guide sur comment intégrer des agents IA à vos outils existants.
A2A : déléguer une tâche à un agent qu'on n'a pas écrit
Le second problème est d'une autre nature. Un outil est passif : on l'appelle, il répond. Un agent est actif : il peut mettre trois minutes, demander une précision, échouer à mi-parcours, ou rendre un résultat partiel.
Le protocole Agent2Agent, initié par Google puis placé sous gouvernance ouverte, s'attaque précisément à ça. Deux idées le structurent.
La carte d'agent. Un document que chaque agent publie et qui dit ce qu'il sait faire, comment on l'appelle, et quelle authentification il attend. C'est l'équivalent d'un menu : un agent appelant peut le lire sans que personne ait câblé la relation à l'avance.
La tâche comme objet à part entière. On n'envoie pas une requête en attendant une réponse. On crée une tâche, qui porte un identifiant et un cycle de vie : soumise, en cours, en attente d'une information, terminée, échouée. L'appelant peut la suivre, et le résultat peut arriver en plusieurs morceaux.
Cette distinction n'est pas cosmétique, elle décide de votre architecture. Un appel synchrone se code en une ligne et casse dès que la tâche dépasse la minute. Une tâche avec un état se code en une journée et tient.
Faut-il l'adopter tout de suite ? Notre réponse honnête : pas par défaut. La délégation entre agents autonomes est un besoin réel dans les organisations qui exploitent des agents de plusieurs éditeurs. Dans la plupart des cas que nous voyons, deux ou trois agents maison se coordonnent très bien avec un workflow n8n qui les enchaîne et une table Postgres qui porte l'état, et le protocole ajoute une couche pour un bénéfice qui n'arrive qu'au dixième agent. Le bon moment pour l'adopter, c'est quand vous devez appeler un agent que vous n'avez pas écrit.
Ce que les protocoles ne règlent pas
Quatre points de friction reviennent à chaque fois. Aucun protocole ne les traite à votre place.
L'identité et les droits
Quand l'agent A demande à l'agent B de modifier une fiche client, qui agit ? Si B utilise ses propres accès, il devient un compte de service tout-puissant, et le journal ne dit plus qui a voulu quoi. Si B reprend l'identité de l'utilisateur d'origine, il faut propager ce contexte à chaque saut de la chaîne, et chaque saut est une occasion de le perdre.
La règle que nous appliquons : l'identité de l'utilisateur voyage avec la tâche, et chaque agent vérifie les droits pour lui-même. Un agent ne fait jamais confiance à son appelant sur le fait que l'appel était autorisé.
La sémantique des données
Deux agents peuvent échanger un JSON parfaitement valide sans parler de la même chose. Un « client » est un contact dans le CRM, une entité facturable en comptabilité, un compte dans l'application. Un « montant » est hors taxes ici, toutes taxes comprises là. Un protocole valide la forme, pas le sens.
Le remède n'est pas technique. C'est un dictionnaire écrit : la liste des objets qui circulent entre vos agents, avec pour chacun sa définition, l'identifiant qui fait foi, et le système qui en est la source de vérité. C'est le travail de gouvernance des données que demande toute automatisation, appliqué cette fois aux échanges entre agents.
L'échec
Un agent qui échoue proprement est rare. Le cas courant est plus embêtant : il rend un résultat plausible et faux. L'appelant n'a aucun moyen de le savoir, et il empile son propre raisonnement dessus.
Deux garde-fous tiennent. Le premier : une tâche déléguée revient toujours avec un statut explicite, et « je n'ai pas pu » doit être une réponse possible et prévue. Un agent qui n'a le choix qu'entre réussir et échouer inventera. Le second : la sortie d'un agent qui alimente un autre agent doit être vérifiable par du code — un schéma, une valeur dans une liste fermée, un identifiant qui existe vraiment en base. Ce que le code peut vérifier, le modèle n'a pas à le garantir.
La trace de bout en bout
Trois agents et deux serveurs d'outils, cela fait cinq journaux dans cinq formats. Le jour où une décision est contestée, personne ne sait reconstituer la chaîne.
Un identifiant de corrélation unique, créé à l'entrée et propagé à chaque appel, coûte une heure de travail et vaut tout le reste. Adossé à un format de traces commun à vos services, il permet de rejouer une exécution complète depuis un seul écran. C'est le premier réflexe à avoir, avant même de choisir un protocole.
Le montage qu'on garde
Cinq règles, dans l'ordre où elles nous ont servi.
- Un registre d'outils, pas des intégrations par agent. Chaque connexion à un système est exposée une fois, en serveur, et tous les agents s'y branchent. C'est ce qui rend le remplacement d'un agent indolore.
- Un contrat écrit par agent. Ce qu'il accepte en entrée, ce qu'il rend en sortie, ce qu'il fait quand il ne sait pas. Un schéma, pas un paragraphe.
- L'identité voyage, les droits se revérifient. À chaque saut, sans exception.
- Un identifiant de corrélation, un seul journal consultable. Sinon l'incident est irracontable.
- Des plafonds partout. Nombre d'appels, profondeur de délégation, dépense par tâche. Deux agents qui s'appellent l'un l'autre forment une boucle infinie qui coûte de l'argent, et ça n'arrive pas qu'aux autres.
Aucune de ces règles n'exige un protocole particulier. Toutes se mettent en place avant d'en choisir un, et elles restent valables si vous en changez.
Faut-il standardiser maintenant ?
L'arbitrage tient en trois questions.
Combien d'agents avez-vous réellement en production ? En dessous de trois, un protocole d'échange entre agents répond à un problème que vous n'avez pas. La priorité est ailleurs : le registre d'outils et la trace.
Vos agents viennent-ils tous de chez vous ? Si oui, votre format maison est parfaitement légitime, à condition qu'il soit écrit quelque part. Si vous devez appeler l'agent d'un éditeur tiers, la question est tranchée : c'est lui qui impose le protocole, et vous avez tout intérêt à ce que ce soit un standard ouvert.
Que coûterait un changement de fournisseur ? Faites l'exercice sur papier, une fois. D'un côté ce qui partirait sans effort : les prompts, les schémas d'outils, la logique métier si elle est dans votre code. De l'autre ce qui resterait bloqué : la mémoire, l'historique des exécutions, les traces, l'ordonnancement. C'est cette seconde liste qui mesure votre dépendance, et elle se réduit chaque fois que vous sortez un élément de la plateforme pour le poser dans votre propre base.
Cette assurance a un coût, et il se chiffre comme le reste d'un projet d'agent : des jours de construction au départ, une ligne de maintenance tous les mois. Elle se justifie quand le processus qu'elle protège existera encore dans deux ans.
Les questions à poser avant de brancher deux agents
- Qui agit, techniquement ? L'identité utilisée par l'agent appelé, et l'endroit où elle est journalisée.
- Quel est le contrat de sortie ? Le schéma exact, et le comportement attendu quand l'agent ne sait pas répondre.
- Combien de temps peut durer la tâche ? Au-delà de quelques secondes, il faut un état, pas un appel bloquant.
- Que se passe-t-il en cas d'échec partiel ? Reprise, compensation ou escalade vers un humain — l'un des trois, écrit noir sur blanc.
- Où lit-on la chaîne complète ? Un écran, un identifiant, les cinq appels dans l'ordre.
- Quel est le plafond ? Profondeur de délégation et dépense maximale par tâche.
Si vous montez un dispositif à plusieurs agents et que ces six réponses n'existent pas encore, c'est exactement ce qu'on cadre en premier sur nos agents IA sur mesure : le registre, les contrats, la trace et les plafonds, avant la première ligne de prompt.
