MCP et A2A : les standards d'interopérabilité des agents, vus par un architecte

Deux sigles reviennent dans toutes les présentations sur l'IA agentique : MCP et A2A. Pour un architecte, la question utile n'est pas « lequel gagne » mais « à quelle couche chacun intervient, et que dois-je encore concevoir moi-même ».

Deux protocoles, deux couches

MCP (Model Context Protocol) a été introduit par Anthropic en novembre 2024. Il standardise la façon dont un agent se connecte à des outils, des bases de données et des services : un serveur MCP expose des capacités, un client (l'application ou l'agent) les découvre et les appelle. C'est l'axe agent ↔ outil.

A2A (Agent2Agent) a été annoncé par Google Cloud en avril 2025 puis confié à la Linux Foundation en juin 2025. Il standardise la communication entre agents, y compris d'organisations ou d'éditeurs différents : découverte des capacités d'un agent distant, délégation de tâches, suivi de leur avancement. C'est l'axe agent ↔ agent. Les deux sont présentés comme complémentaires : l'un connecte vers l'intérieur (outils et données), l'autre vers l'extérieur (autres agents).

Une gouvernance désormais neutre

Le fait marquant des douze derniers mois est la gouvernance : A2A relève de la Linux Foundation depuis 2025, et MCP a été confié à l'Agentic AI Foundation de la Linux Foundation fin 2025. Le projet A2A a annoncé plus de 150 organisations soutenant le standard à son premier anniversaire, avec une intégration dans les plateformes des grands fournisseurs cloud. Pour un décideur, c'est la réponse à une crainte légitime : investir dans un protocole propriétaire qui disparaîtrait. Le risque de verrouillage baisse ; il ne disparaît pas, car l'implémentation, les extensions et les passerelles restent propres à chaque fournisseur.

Ce que cela change dans vos choix d'architecture

• Exposer ses systèmes via des serveurs MCP plutôt que de coder une intégration par agent et par fournisseur de modèle. Le coût d'intégration passe de N × M à N + M.
• Prévoir une passerelle d'agents (agent gateway) : un point unique où appliquer authentification, quotas, journalisation et politiques. La Linux Foundation accueille elle-même un projet de ce type, agentgateway, qui gère MCP et A2A.
• Traiter chaque serveur MCP comme une surface d'attaque : il donne à un agent des capacités d'action. Inventaire, droits minimaux, revue des serveurs tiers, et attention à l'injection de consignes via les contenus que l'agent lit.

Ce que les standards ne résolvent pas

Un protocole standardise la communication, pas la confiance. Il ne dit pas si un agent distant est digne de recevoir une tâche, ni qui est responsable en cas d'erreur dans une chaîne de plusieurs agents. Il ne fournit ni la qualité des données, ni la gouvernance, ni la traçabilité de bout en bout : ce sont des décisions d'architecture, à prendre en amont. Enfin, le nombre de serveurs et de bibliothèques disponibles ne mesure pas leur qualité — la plupart des serveurs publics n'ont pas été conçus pour un environnement d'entreprise.

Recommandation pratique

Adoptez MCP comme couche d'accès à vos outils internes pour les cas d'usage où vous avez déjà identifié un agent et un propriétaire. Retardez les scénarios multi-agents inter-organisations (A2A) tant que vos agents individuels ne sont pas observables et gouvernés : la complexité d'orchestration croît plus vite que la valeur.

• MCP relie un agent à ses outils ; A2A relie les agents entre eux. Les deux sont complémentaires.
• Les deux standards relèvent désormais de la Linux Foundation, ce qui réduit le risque de verrouillage sans l'éliminer.
• Passerelle d'agents, droits minimaux et inventaire des serveurs MCP sont à concevoir dès le départ.
• Un protocole standardise la communication, pas la confiance, la qualité des données ni la responsabilité.

Sources

• Linux Foundation — lancement du projet Agent2Agent
• A2A — plus de 150 organisations à un an
• Linux Foundation — projet agentgateway