MCP vs A2A vs UCP vs AP2 vs A2UI : La pile de protocoles d'agent expliquée

Les protocoles d'agents IA se multiplient rapidement : MCP, A2A, UCP, AP2, A2UI et les standards connexes apparaissent de plus en plus souvent dans les mêmes schémas d'architecture. Ils sont fréquemment présentés comme des protocoles concurrents. En pratique, la plupart d'entre eux résolvent des problèmes d'interopérabilité différents à des niveaux d'interface distincts. La question pertinente n'est pas « Quel protocole l'emporte ? », mais plutôt « Quelle relation au sein du système nécessite d'être standardisée ? »

L'erreur fondamentale : comparer des protocoles opérant à des niveaux d'interface différents

Un protocole est utile dès lors que deux systèmes développés indépendamment ont besoin d'un contrat stable. Ce contrat n'a de sens que si la frontière entre les deux est bien définie. La communication entre un agent et une base de données relève d'un problème d'interopérabilité bien distinct de la délégation de tâches entre agents, de l'autorisation d'un achat par un internaute ou de la requête d'un agent distant demandant à une application native de générer un formulaire.

Le guide pour développeurs 2026 de Google présente explicitement MCP, A2A, UCP, AP2, A2UI et les protocoles d'interface utilisateur associés comme une pile de standards complémentaires. Un même exemple de flux de travail peut en mobiliser plusieurs simultanément : des outils pour l'inventaire, des agents distants pour les fournisseurs, le commerce pour les commandes, l'autorisation de paiement pour les dépenses et des protocoles d'interface pour l'interaction.

La pile de responsabilités des protocoles

1. MCP : connecter l'agent aux capacités

Le Model Context Protocol est un standard ouvert permettant de connecter les applications d'IA à des systèmes externes hébergeant des outils, des données et des ressources réutilisables. Un serveur expose des capacités ; un hôte MCP se connecte à ce serveur et met ces capacités à la disposition du modèle ou de l'application.

La documentation actuelle de MCP TypeScript v2 décrit précisément le protocole en ces termes : les serveurs exposent des outils, des ressources et des prompts, tandis que des hôtes tels que des environnements de développement ou des applications personnalisées s'y connectent. Cela fait de MCP avant tout un protocole d'intégration de capacités.

Quand utiliser MCP

• Une application d'IA nécessite un accès standardisé à des outils ou des API.
• Vous souhaitez qu'un même serveur de capacités fonctionne avec plusieurs hôtes d'IA compatibles.
• Vous avez besoin d'un accès structuré aux données ou aux ressources sans coder en dur chaque intégration dans chaque agent.
• Le système externe est un fournisseur de capacités, et non un agent pair autonome.

2. A2A : connecter des agents indépendants

Agent2Agent (A2A) est conçu pour la communication entre des systèmes d'agents indépendants et potentiellement opaques. Sa spécification actuelle v1.0 se concentre sur la découverte des capacités, la messagerie, les tâches, les artefacts, le contenu multimodal et la collaboration à long terme sans exiger qu'un agent expose ses outils internes, sa mémoire ou son implémentation à un autre.

Cette opacité constitue la frontière essentielle. L'agent appelant n'a pas besoin de savoir si l'agent distant utilise en interne MCP, des outils personnalisés, un planificateur propriétaire, un autre fournisseur de modèles ou une escalade humaine. Il a besoin d'un contrat pour découvrir les capacités et déléguer le travail.

A2A v1.0 standardise également la négociation de version et prend en charge plusieurs liaisons autour d'un modèle de données commun. Son mécanisme publié d'Agent Card offre aux clients un point de découverte standard pour les capacités d'un agent, les protocoles pris en charge, les exigences d'authentification et les compétences.

Utiliser A2A lorsque

• Un agent autonome doit déléguer du travail à un autre agent autonome.
• Le système distant doit rester opaque derrière un contrat de capacités.
• Les tâches peuvent être de longue durée, asynchrones ou nécessiter une intervention humaine (human-in-the-loop).
• Les agents sont conçus avec des frameworks, des langages, des fournisseurs ou des appartenances organisationnelles différents.

MCP vs A2A : intégration verticale vs collaboration horizontale

Le projet A2A lui-même décrit désormais cette distinction comme horizontale contre verticale : MCP connecte les agents aux outils et bases de données internes, tandis qu'A2A permet la collaboration de pair à pair entre systèmes d'agents.

3. UCP : standardiser le commerce agentique

L'Universal Commerce Protocol n'est pas un protocole d'agent générique. Il standardise les parcours commerciaux entre les surfaces grand public, les marchands et les prestataires de paiement. L'implémentation de Google prend déjà en charge des fonctionnalités telles que la création de panier, le paiement, l'exécution des commandes et le cycle de vie des commandes via des profils et des API versionnés.

Un marchand peut publier un profil UCP sous /.well-known/ucp décrivant les services, les versions de protocole et les capacités. Ce modèle de découverte est essentiel car une surface agentique ne devrait pas avoir besoin d'un contrat de paiement sur mesure pour chaque marchand.

UCP est également conçu pour être modulaire et composable. La présentation technique de Google indique qu'il peut s'intégrer via des API, A2A et MCP, et qu'il est compatible avec AP2 pour l'autorisation des paiements agentiques.

Utiliser UCP lorsque

• Le flux de travail implique des produits marchands, des paniers, le paiement, l'exécution ou le cycle de vie des commandes.
• Vous concevez une interface marchande qui doit fonctionner avec des expériences d'achat agentiques.
• L'intégration nécessite une sémantique spécifique au commerce plutôt que des appels d'outils génériques.
• Vous souhaitez un contrat commercial interopérable pouvant coexister avec MCP, A2A et les protocoles de paiement.

4. AP2 : prouver que l'agent était autorisé à dépenser

Le commerce agentique introduit un problème que les flux d'achat classiques n'avaient pas à résoudre de la même manière : un agent peut effectuer une transaction sans que l'humain ne clique sur le bouton final en temps réel. Le protocole Agent Payments Protocol (AP2) répond aux exigences d'autorisation, d'authenticité et de responsabilité pour les paiements pilotés par des agents.

Le guide des protocoles 2026 de Google décrit AP2 à travers des mandats typés qui capturent l'intention de l'utilisateur, les contraintes de dépense et la transaction spécifique autorisée. AP2 peut fonctionner comme une extension aux côtés d'UCP : UCP décrit la transaction commerciale, tandis qu'AP2 fournit la preuve que l'agent avait l'autorité nécessaire pour effectuer le paiement.

Cette distinction est importante. Un protocole de paiement peut indiquer à un marchand ce qui doit être acheté. En lui-même, il ne prouve pas qui a autorisé l'agent à dépenser, sous quelle limite, pour quel marchand, pendant combien de temps, ni si le panier final est resté dans les limites de cette autorisation.

UCP vs AP2 : sémantique des transactions vs autorité

5. A2UI : laisser les agents décrire des interfaces sans s'approprier votre frontend

Agent-to-User Interface (A2UI) s'attaque à une autre frontière : la façon dont un agent distant ou local communique une interface interactive riche à une application hôte. Au lieu d'envoyer du HTML, du CSS et du JavaScript arbitraires, A2UI utilise des données déclaratives que l'hôte restitue via son propre catalogue de composants de confiance.

Cela préserve le design system et le modèle de sécurité de l'application hôte tout en permettant à un agent de solliciter des interfaces dynamiques. A2UI v0.9 met particulièrement l'accent sur l'intention d'interface utilisateur indépendante du framework et les mises à jour en continu sur le Web, le mobile et d'autres clients.

Les travaux ultérieurs de Google sur A2UI + MCP Apps démontrent également que ces modèles d'interface utilisateur ne s'excluent pas nécessairement mutuellement. Une interface utilisateur native déclarative et des expériences d'applications intégrées plus riches peuvent coexister selon la tâche.

Utiliser A2UI lorsque

• Un agent distant doit demander des formulaires, des cartes, des contrôles ou d'autres interfaces interactives.
• L'hôte doit préserver ses composants natifs, son style et son périmètre de sécurité.
• Vous ne voulez pas que des agents distants transmettent du code frontend exécutable arbitraire.
• La même intention d'interface utilisateur définie par l'agent doit fonctionner sur différents frameworks clients.

Le test de sélection du protocole

Ne partez pas de l'acronyme. Partez de la relation qui nécessite une interopérabilité.

Un flux de travail multiprotocole réaliste

Pourquoi un protocole d'agent universel ne remplacera probablement pas tous les autres

Un protocole universel semble plus simple jusqu'à ce qu'il doive encoder la sémantique de chaque domaine. La découverte d'outils, la collaboration prolongée entre agents, le paiement, l'autorisation de paiement et l'interface utilisateur native ont tous des exigences de cycle de vie, de sécurité et d'exactitude différentes.

Le Web lui-même a évolué à travers des protocoles en couches plutôt que par le biais d'un format de message unique pour chaque problème. La pile émergente d'agents semble aller dans la même direction : des primitives horizontales communes, des contrats de domaine spécialisés et une découverte/un versionnement explicites.

Le défi architectural ne consiste donc plus à savoir « quel protocole gagne ? », mais à déterminer avec quelle fluidité les protocoles se composent sans dupliquer la sémantique d'identité, d'autorisation, d'état et d'audit.

La composition des protocoles crée de nouveaux modes de défaillance

Le choix du protocole ne remplace pas l'architecture applicative

Les standards ouverts réduisent le couplage d'intégration, mais ils ne déterminent pas votre modèle de domaine, votre politique d'autorisation, votre source de vérité, votre stratégie de nouvelle tentative ou vos critères d'acceptation. Un outil MCP peut toujours exposer la mauvaise capacité. Un agent A2A peut toujours retourner un artefact erroné. Un paiement UCP peut toujours contenir des données marchand obsolètes. Un mandat AP2 peut toujours être mal appliqué par la logique applicative.

Considérez les protocoles comme des contrats entre des composants qui évoluent de manière indépendante. Conservez la vérité du domaine et les politiques critiques dans la couche applicative qui en a la responsabilité, puis utilisez des protocoles pour rendre les frontières interopérables.

Qu'est-ce qui changerait cette réponse ?

La pile technologique évolue si les protocoles convergent, si un standard en absorbe formellement un autre, ou si les fournisseurs standardisent une couche partagée d'identité et d'autorisation à travers plusieurs frontières. UCP démontre déjà la composition en prenant en charge les API, A2A et MCP, et en s'intégrant avec AP2 plutôt qu'en les remplaçant.

La réponse varie également selon la portée de l'application. Un petit agent interne peut n'avoir besoin que de MCP. Un flux de travail multi-entreprises peut nécessiter A2A. Un commerçant peut avoir besoin d'UCP sans A2UI. Un agent d'achat délégué peut avoir besoin de tous ces protocoles. Utilisez le plus petit ensemble de protocoles qui représente les véritables frontières sans aplatir la sémantique métier.

Limites

Les protocoles abordés ici se situent à différents niveaux de maturité et possèdent des modèles de gouvernance distincts. A2A a atteint une spécification v1.0 stable, tandis que d'autres standards continuent d'évoluer rapidement. L'adoption par l'écosystème est également inégale selon les fournisseurs et les frameworks.

Cet article se concentre sur les responsabilités architecturales plutôt que sur l'exhaustivité de l'implémentation. Les méthodes d'authentification spécifiques, les liaisons de transport, les schémas et les mécanismes d'extension doivent être consultés dans la spécification actuelle de chaque protocole.

Conclusion

MCP, A2A, UCP, AP2 et A2UI prennent tout leur sens lorsqu'ils sont envisagés comme des protocoles destinés à différentes relations, et non comme cinq tentatives concurrentes de standardiser les « agents ».

MCP expose des capacités. A2A coordonne des agents indépendants. UCP dote le commerce de son propre contrat lisible par machine. AP2 apporte une autorité de paiement vérifiable. A2UI offre aux agents un chemin déclaratif sécurisé vers les interfaces utilisateur. Le web agentique émergent ne remplace donc pas les protocoles par l'IA ; il crée une nouvelle pile de protocoles autour de l'IA.

FAQ

Glossaire

Sources principales et lectures complémentaires