A2A, MCP et la course aux standards agents : pourquoi l'interoperabilite doit etre gouvernee

L'interopérabilité est devenue le nouveau terrain de bataille des agents

En août 2026, Axios a rapporté que le protocole Agent2Agent de Google, A2A, passait sous l'égide de l'Agentic AI Foundation. L'objectif d'A2A est simple : des agents indépendants ont besoin d'une manière standard de communiquer entre plateformes.

Ce mouvement s'inscrit à côté de l'adoption rapide du Model Context Protocol, MCP. MCP traite une autre couche : il donne aux applications IA et aux agents une manière commune de se connecter aux outils, services, bases de données, systèmes de fichiers et APIs.

Ensemble, le schéma est clair :

• MCP : comment un agent accède aux outils et aux données
• A2A : comment les agents parlent à d'autres agents
• gouvernance : comment l'entreprise décide ce que chacun d'eux est autorisé à faire

Les deux premiers deviennent des sujets de standardisation. Le troisième est le problème de contrôle de l'entreprise.

Les standards facilitent l'adoption, et facilitent aussi la diffusion du risque

L'interopérabilité est précieuse parce qu'elle réduit le travail d'intégration. Une équipe peut brancher un agent sur un écosystème d'outils sans construire chaque connecteur depuis zéro. Une autre équipe peut laisser des agents collaborer entre périmètres au lieu de coder en dur un workflow unique.

Mais cette même propriété crée du risque. Si un standard facilite la connexion, il facilite aussi la sur-connexion. Un agent mal gouverné peut hériter de trop d'outils, faire confiance à trop de descriptions, appeler trop d'endpoints et faire transiter des données par trop de sauts.

Les recherches sécurité de Microsoft publiées en juin 2026 expliquent pourquoi cela compte. À mesure que les agents passent de la lecture à l'action, une injection de prompt contre un agent peut déclencher une action. Microsoft a aussi détaillé un schéma de tool poisoning MCP dans lequel une modification de description d'outil pouvait rediriger le comportement d'un agent et provoquer l'envoi de données sensibles via un appel outil.

C'est la vraie leçon de la course aux standards. La question n'est pas de savoir si MCP ou A2A est bon ou mauvais. La question est de savoir si l'organisation dispose d'un control plane autour des capacités que ces standards exposent.

L'autorisation des agents devient une discipline à part entière

Le playbook du World Economic Forum publié en mai 2026 sur les agents a cadré le sujet en termes d'autorisation. Les organisations doivent définir les conditions dans lesquelles les agents sont autorisés à agir, et elles ont besoin d'une application qui continue de fonctionner lorsque les systèmes évoluent.

Ce cadrage est utile parce que les agents ne correspondent pas proprement aux anciennes catégories de gouvernance.

Ils ne sont pas seulement des utilisateurs. Ils peuvent agir au nom d'utilisateurs, d'équipes, de services ou de workflows.

Ils ne sont pas seulement des applications. Ils peuvent choisir des outils dynamiquement et composer des actions au runtime.

Ils ne sont pas seulement des modèles. Plusieurs agents peuvent partager un même modèle tout en ayant des périmètres, des accès aux données et des actions autorisées très différents.

C'est pourquoi la gouvernance doit passer de "quel modèle avons-nous approuvé ?" à "quelle identité agent peut utiliser quelle capacité, sous quelle politique ?"

MCP est le point de contrôle immédiat

A2A compte parce que les workflows agent-à-agent arrivent. Mais pour la plupart des entreprises, MCP est la surface de risque immédiate, parce qu'il connecte les agents à des systèmes qui peuvent lire, écrire, dépenser, supprimer, créer, rechercher et modifier.

La data room d'Odock présente la gouvernance MCP comme un différenciateur précisément pour cette raison. Un serveur MCP n'est pas une simple intégration. C'est un ensemble de capacités. Certains outils peuvent être inoffensifs, d'autres peuvent exposer des données sensibles, et d'autres encore peuvent être destructifs. Traiter tout le serveur comme autorisé ou refusé est trop grossier pour la production.

Odock gouverne MCP au niveau du tool call :

Server registry. Les serveurs MCP approuvés sont enregistrés de manière centralisée au lieu d'être découverts informellement par chaque équipe agent.

Grants. L'accès est scoped aux virtual API keys, aux équipes ou aux workloads.

Tool allowlists. Une clé peut n'exposer que les outils dont l'agent a réellement besoin.

Tool blocklists. Les actions destructives ou risquées peuvent être bloquées explicitement.

Semantic payload filters. Les payloads de tool call peuvent être inspectés avant exécution pour détecter des motifs dangereux.

Upstream auth injection. Les credentials restent dans Odock, afin que les agents ne manipulent pas directement les secrets.

Usage records. Les tool calls sont attribués à une clé, une équipe, un serveur, un outil, un coût, un statut et un résultat.

Cet ensemble de contrôles transforme MCP d'une surface ouverte de capacités en infrastructure gouvernée.

La prochaine couche de gouvernance couvrira les chaînes d'agents

À mesure que l'adoption d'A2A progressera, les mêmes principes devront s'appliquer aux chaînes d'agents. Le control plane devra comprendre non seulement "l'agent A a appelé l'outil X", mais aussi "l'agent A a délégué à l'agent B, qui a utilisé l'outil X sous la politique Y".

La forme de la réponse est déjà visible :

• chaque agent a besoin d'une identité non humaine
• chaque délégation a besoin d'un périmètre
• chaque tool call a besoin d'une autorisation
• chaque action à fort impact a besoin d'un chemin d'arrêt ou d'approbation
• chaque workflow cross-agent a besoin de traçabilité
• chaque décision de politique doit pouvoir être reconstruite plus tard

C'est pourquoi l'interopérabilité des agents et la gouvernance IA deviennent la même conversation. Les standards définissent comment les agents se connectent. La couche de gouvernance définit s'ils devraient le faire.

Ce que les entreprises devraient faire maintenant

N'attendez pas que l'écosystème des standards agents soit stabilisé avant de construire les contrôles. La direction est déjà suffisamment claire.

Créez un inventaire des serveurs MCP et des connecteurs agents. Identifiez les outils capables de lire des données sensibles, d'écrire dans des systèmes métier, de dépenser de l'argent ou de modifier l'état de production.

Remplacez les clés provider partagées par des virtual API keys scoped. La clé doit porter le propriétaire, l'équipe, l'accès aux modèles, l'accès MCP, le budget, le quota et le contexte de politique.

Passez de l'approbation au niveau serveur à l'approbation au niveau outil. "Cet agent peut utiliser GitHub" est trop large. "Cet agent peut lire les issues et ouvrir des pull requests, mais ne peut pas supprimer de repositories ni modifier des secrets" est plus proche d'une gouvernance de production.

Inspectez les métadonnées et les payloads des outils. Les descriptions d'outils font partie du contexte de l'agent, et les payloads sont souvent l'endroit où les données sensibles quittent le périmètre.

Enregistrez chaque action. Si un incident implique une chaîne d'agents, un outil MCP et une réponse provider, les équipes ont besoin d'une piste de preuve unique.

A2A et MCP rendent l'IA agentique plus interopérable. C'est positif pour l'adoption. C'est aussi précisément pour cela que la couche de gouvernance compte désormais. Plus les agents peuvent se connecter, plus les entreprises ont besoin d'un endroit unique pour décider, appliquer et prouver ce que ces agents sont autorisés à faire.

Sources

• Axios, Google-backed agentic A2A protocol gets a new home, August 17, 2026
• Microsoft Security, Securing AI agents: When AI tools move from reading to acting, June 30, 2026
• World Economic Forum, AI Agents in Action: A Playbook for Trusted Adoption, Authorization and Scaling, May 26, 2026
• Microsoft for Developers, Securing MCP: A Control Plane for Agent Tool Execution, April 22, 2026
• Odock MCP Servers documentation
• Odock MCP Security documentation