Interopérabilité des agents : où en sont les standards

La question du standard pour les agents IA est posée à l'envers dans la plupart des discussions commerciales. On vous demande si votre plateforme « supporte MCP », comme s'il s'agissait d'une case à cocher. La vraie question est différente : si vous décidez dans dix-huit mois de changer de fournisseur de modèle ou de plateforme d'agents, qu'est-ce que vous conservez, et qu'est-ce que vous devez reconstruire ?

Deux protocoles ont émergé et se sont installés depuis 2025. Le premier, MCP, décrit comment un modèle accède à des outils et à des données. Le second, A2A, décrit comment deux agents se parlent. Ils ne s'opposent pas, ils traitent des problèmes différents, et tous deux sont passés sous la gouvernance d'une fondation, ce qui change nettement les termes du débat sur la dépendance.

Cet article fait le point sur l'état réel de ces efforts de normalisation à la mi-2026, sur les briques annexes qui gravitent autour, et surtout sur ce qu'un protocole ouvert protège et ce qu'il ne protège pas. Le résultat est plus nuancé que le discours ambiant.

Standard agent IA : deux problèmes distincts, deux familles de protocoles

Confondre les deux couches est l'erreur la plus fréquente, et elle conduit à des architectures bancales.

Le lien entre un modèle et des outils. Un assistant doit lire un fichier, interroger une base, appeler un service. Il lui faut une description standardisée des outils disponibles, un moyen de les appeler et de recevoir un résultat structuré. C'est le rôle du Model Context Protocol, dont nous avons expliqué le fonctionnement dans notre article dédié au protocole MCP.

Le lien entre deux agents. Un agent de qualification de demandes doit passer la main à un agent de devis, exploité par une autre équipe, éventuellement construit sur une autre pile technique. Il faut alors décrire ce que sait faire l'agent d'en face, savoir à qui l'on parle, et gérer une tâche qui peut durer. C'est le rôle d'A2A, dans la lignée des architectures que nous avons décrites à propos des systèmes multi-agents.

Une manière simple de mémoriser : MCP relie un agent à ses outils, verticalement. A2A relie des agents entre eux, horizontalement. Une organisation qui n'a qu'un seul agent n'a besoin que du premier.

MCP : passé sous gouvernance de fondation

Le point le plus important de l'année sur ce protocole n'est pas technique. Le 9 décembre 2025, Anthropic a transféré MCP à l'Agentic AI Foundation, un fonds dirigé hébergé par la Linux Foundation, co-fondé avec Block et OpenAI. La liste des membres de premier rang annoncée à cette occasion inclut Amazon Web Services, Bloomberg, Cloudflare, Google et Microsoft.

Ce transfert répond à l'objection principale que l'on faisait au protocole : un format créé et contrôlé par un éditeur de modèles, aussi ouvert soit-il sur le papier, reste un format qu'un éditeur peut faire évoluer dans son intérêt. La donation ne supprime pas tout risque, l'équipe de mainteneurs restant largement la même, mais elle place la propriété du protocole et son processus de décision hors du bilan d'une entreprise.

Côté spécification, la révision en vigueur à ce jour est datée du 25 novembre 2025. Elle a apporté la découverte du serveur d'autorisation via OpenID Connect, le consentement incrémental sur les périmètres d'accès, une refonte du mécanisme qui permet à un serveur de demander une information à l'utilisateur en cours d'interaction, et une primitive expérimentale de tâches durables, pour les traitements qui ne tiennent pas dans le temps d'une requête. Les deux révisions précédentes avaient posé les fondations réellement structurantes : une autorisation fondée sur OAuth 2.1 et un transport HTTP moderne en mars 2025, puis la sortie structurée des résultats d'outils et l'obligation, pour les clients, de restreindre la portée des jetons d'accès en juin 2025.

Une révision suivante est en fenêtre de validation depuis le printemps, avec une orientation claire vers un cœur de protocole sans état et un cadre d'extensions. Concrètement, pour vous : ce protocole bouge encore vite. Ancrer une intégration sur une révision précise, et vérifier que votre fournisseur annonce laquelle il implémente, n'est pas une précaution excessive.

A2A : une version stable depuis mars 2026

A2A a suivi une trajectoire comparable, avec un an d'avance sur la mise sous fondation. Annoncé par Google en avril 2025, le protocole a été confié à la Linux Foundation en juin 2025, avec Amazon Web Services, Cisco, Microsoft, Salesforce, SAP et ServiceNow parmi les membres fondateurs du projet.

La version 1.0, publiée en mars 2026, est la première annoncée comme utilisable en production. Elle apporte trois choses qui comptent en entreprise : la prise en charge d'environnements hétérogènes, la gestion multi-locataires, et surtout des fiches d'agent signées cryptographiquement, qui permettent de vérifier l'identité de l'agent avec lequel on dialogue. Le protocole supporte plusieurs transports et propose de récupérer les résultats en interrogation, en flux continu ou par rappel web, ce qui est adapté à des tâches longues.

Le bilan publié par la fondation en avril 2026 annonce plus de 150 organisations impliquées, cinq kits de développement et une intégration dans les plateformes d'agents des grands fournisseurs de cloud. Ces chiffres sont ceux du promoteur, mais l'ordre de grandeur situe le protocole du bon côté de la frontière.

Un signal de consolidation mérite d'être noté : un protocole concurrent porté par IBM a cessé son développement à l'été 2025 pour verser sa technologie dans A2A. Le paysage se simplifie, ce qui est plutôt une bonne nouvelle quand on doit choisir sur quoi bâtir.

Les briques annexes, et celles qui n'existent pas encore

Autour de ces deux protocoles gravitent des efforts complémentaires, à des degrés de maturité très inégaux. Il vaut la peine de savoir lesquels sont réels.

• Découverte et identité des agents. Un projet porté par Cisco, accueilli par la Linux Foundation en juillet 2025, travaille sur les annuaires d'agents, l'identité vérifiable et l'observabilité. Il se positionne en complément : les agents A2A et les serveurs MCP y sont référençables.
• Paiements initiés par un agent. Un protocole annoncé par Google en septembre 2025, conçu comme une extension d'A2A, encadre les autorisations de paiement par des mandats signés. Sujet à surveiller, pas encore un sujet de déploiement.
• Travaux de normalisation formelle. Un groupe communautaire du W3C travaille depuis mai 2025 sur les protocoles d'agents, et l'institut américain de normalisation a lancé en février 2026 une initiative dédiée aux standards des agents, centrée notamment sur leur identité et leur autorisation. Ce sont des travaux en cours, pas des normes publiées.

Ce qui n'existe pas, en revanche, mérite d'être dit aussi clairement : il n'y a pas, à ce jour, de norme internationale publiée sur l'interopérabilité des agents, ni de standard sur la portabilité de la mémoire d'un agent d'une plateforme à l'autre. Un fournisseur qui vous vend l'un ou l'autre vend une intention.

Ce qu'un protocole ouvert protège, et ce qu'il ne protège pas

Voici le cœur du sujet pour qui cherche à éviter l'enfermement propriétaire. Un protocole d'interopérabilité déplace la dépendance, il ne la supprime pas.

Ce qu'il protège réellement : le travail d'intégration à vos outils internes. Un serveur MCP que vous avez écrit pour exposer votre progiciel de gestion fonctionne avec n'importe quel client compatible. C'est un actif réutilisable, et c'est loin d'être négligeable : sur un projet d'agent, l'intégration représente souvent la majeure partie de l'effort.

Ce qu'il ne protège pas :

• Les instructions et le comportement. Vos consignes système, vos exemples, vos garde-fous sont calibrés pour un modèle. Changer de modèle impose de les reprendre et de refaire passer votre jeu de tests. Aucun protocole ne transporte cela.
• La mémoire et l'état. Ce que l'agent a accumulé sur vos dossiers vit dans la plateforme, dans un format propre à l'éditeur. C'est aujourd'hui le principal point d'accrochage, et c'est précisément là qu'aucun standard n'existe.
• Les traces d'exécution. Historiques, journaux et évaluations sont rarement exportables dans un format exploitable ailleurs. Or ce sont eux qui vous permettraient de comparer honnêtement un fournisseur à un autre.
• Le niveau d'implémentation. Deux plateformes « compatibles MCP » peuvent implémenter des révisions différentes et des sous-ensembles différents. La compatibilité annoncée n'est pas une garantie de portabilité.

Un mot sur la sécurité, qui est le revers de cette ouverture. Microsoft, pourtant promoteur du protocole, a listé publiquement dès mai 2025 les failles structurelles de MCP telles qu'il les voyait : injection de consignes par des contenus tiers, autorisation restée optionnelle et inégalement adoptée, agents opérant avec l'ensemble des privilèges de l'utilisateur, empoisonnement de la description d'un outil, risques de chaîne d'approvisionnement sur les serveurs tiers. La fondation OWASP travaille de son côté à une liste des dix risques principaux, encore à l'état de version préliminaire. Les révisions successives de la spécification ont durci l'autorisation, mais le sujet reste ouvert : brancher un serveur MCP trouvé sur un annuaire public dans un agent qui a accès à vos systèmes est une décision de sécurité, pas une commodité.

Les quatre questions à poser à un fournisseur

Plutôt qu'une case « compatible MCP » dans un tableau comparatif, voici ce qui départage réellement deux offres. Ces questions se posent avant la signature, et les réponses ont leur place dans le contrat, comme nous l'avons détaillé à propos des clauses à négocier avec un fournisseur d'IA.

1. Quelle révision du protocole implémentez-vous, et laquelle prévoyez-vous d'implémenter ensuite ? Une réponse vague sur ce point est une réponse.
2. Sous quel format puis-je exporter la mémoire, l'état et l'historique de mes agents ? C'est la question qui fait le plus mal, parce qu'aucun standard ne la couvre. Une réponse honnête, même limitée, vaut mieux qu'une promesse d'interopérabilité générale.
3. Puis-je faire pointer votre plateforme vers un modèle que je choisis, y compris chez un concurrent ou hébergé chez moi ? C'est le test le plus discriminant sur la dépendance réelle.
4. Comment sont autorisés, journalisés et révoqués les accès des agents à mes systèmes ? Les protocoles fournissent les mécanismes, les plateformes ne les activent pas toujours.

Ce qu'il faut retenir

À la mi-2026, le paysage du standard pour les agents IA s'est stabilisé plus vite que prévu : deux protocoles complémentaires, tous deux sous gouvernance de fondation, l'un pour l'accès aux outils, l'autre pour le dialogue entre agents, avec une version stable côté A2A depuis mars et une spécification MCP qui continue d'évoluer par révisions datées.

Cette stabilisation est une bonne nouvelle pour vos intégrations, qui deviennent réutilisables. Elle ne règle en rien la question de la dépendance sur ce qui compte le plus à l'usage : les instructions, la mémoire accumulée et les traces. Le raisonnement à tenir n'est donc pas « ce fournisseur est compatible, je suis protégé », mais « qu'est-ce que je récupère le jour où je pars ». Posez la question maintenant : la réponse est bien plus facile à obtenir avant la signature qu'après.