Commerce agentique : carte des protocoles de 2024 à 2026
Publié le . Périmètres vérifiés dans les spécifications et annonces primaires.
Réponse courte : il n'existe pas un protocole gagnant qui remplacerait tous les autres. MCP relie l'agent aux outils ; A2A relie des agents entre eux ; ACP et UCP décrivent des opérations de commerce ; AP2 produit des preuves d'intention et d'autorisation ; TAP et Agent Pay permettent d'identifier ou d'encadrer l'agent payeur ; x402 et MPP organisent le paiement programmatique d'une ressource. Les opposer sans préciser la couche revient à comparer une API de commande, une pièce d'identité et un rail de règlement.
Une carte, pas une course
Le mot « protocole » masque des responsabilités très différentes. Pour acheter sans intervention humaine, un agent doit trouver un produit, appeler un outil, comprendre une offre, recevoir une autorisation limitée, prouver son identité, commander, payer puis gérer l'après-vente. Aucun des standards étudiés ne couvre seul cette chaîne de bout en bout.
La bonne question n'est donc pas « quel protocole choisir ? », mais « quelle responsabilité manque dans notre architecture ? ». La carte suivante classe chaque initiative selon son objet principal et son hors-périmètre le plus important.
| Initiative | Responsabilité principale | Ce qu'elle normalise | Ce qu'elle ne remplace pas |
|---|---|---|---|
| MCP | Agent vers outils et données | Découverte et appel de tools, resources et prompts via JSON-RPC | Catalogue, checkout, autorisation et règlement |
| A2A | Agent vers agent | Découverte, délégation et coordination entre agents | Accès aux outils, paiement et cycle de commande |
| ACP | Commerce | Découverte produit, flux marchands et primitives transactionnelles versionnées | Identité universelle de l'agent et rail de règlement |
| UCP | Commerce | Découverte d'un profil, négociation de capacités, services, extensions et gestionnaires de paiement | Preuve autonome de l'autorisation du porteur |
| AP2 | Intention et autorisation | Mandats et preuves vérifiables pour les paiements avec humain présent ou absent | Catalogue et API de checkout |
| TAP | Identité et confiance | Signatures HTTP permettant au marchand de reconnaître un agent approuvé | Parcours de commande et règlement universel |
| Agent Pay | Confiance et paiement par carte | Agents enregistrés, Agentic Tokens et contrôles sur le réseau Mastercard | Standard ouvert multi-réseaux |
| x402 | Paiement programmatique | Conditions de paiement dans un échange HTTP 402, avec règlement documenté en stablecoins | Panier, livraison, commande et après-vente |
| MPP | Paiement programmatique | Demande et autorisation de paiement HTTP pour stablecoins et moyens fiat | Découverte produit et orchestration du checkout |
Les six couches d'une transaction agentique
1. Accès au contexte et aux outils : MCP
Anthropic a publié MCP le 25 novembre 2024 pour standardiser la connexion d'une application d'IA à des systèmes externes. Un serveur MCP expose des outils, des ressources et des modèles de prompts ; un client MCP les consomme. Le protocole utilise JSON-RPC 2.0 sur une entrée-sortie locale ou HTTP. Il ne contient pas de sémantique native de prix, de panier, d'autorisation ou de paiement. ACP et UCP peuvent transporter certaines capacités via MCP précisément parce que leurs responsabilités sont différentes.
2. Coordination entre agents : A2A
Google a annoncé A2A le 9 avril 2025, puis l'a donné à la Linux Foundation le 23 juin 2025. A2A permet à des agents construits avec des technologies différentes de se découvrir, de déléguer des tâches et de suivre leur exécution. La distinction la plus simple est stable : MCP relie un agent à un outil ; A2A relie un agent à un autre agent. AP2 peut s'appuyer sur les deux sans transformer l'un ou l'autre en protocole de paiement.
3. Parcours de commerce : ACP et UCP
ACP, annoncé par OpenAI et Stripe le 29 septembre 2025, et UCP, lancé par Google avec Shopify et d'autres partenaires le 11 janvier 2026, sont les deux initiatives de cette liste dont l'objet principal est le commerce. Elles portent des notions comme la découverte, le checkout, la commande ou l'après-vente, avec des périmètres et des modèles d'intégration différents.
UCP rend la négociation explicite. Un marchand publie un profil à /.well-known/ucp ; chaque capacité porte un identifiant de domaine inversé et une version datée ; le serveur retient la version la plus récente prise en charge par les deux parties et retire les extensions dont la capacité mère n'a pas été négociée. ACP utilise lui aussi des versions datées et a publié cinq versions entre septembre 2025 et avril 2026. L'existence d'une spécification commune ne prouve toutefois pas qu'un marchand expose toutes les capacités ni que deux produits ont réussi un test d'interopérabilité.
4. Preuve de l'intention et de l'autorisation : AP2
La frontière d'AP2 est particulièrement claire dans la version 0.2. La spécification le décrit comme une fonction de sécurité opérant dans un protocole de commerce et place les API de catalogue et de checkout hors périmètre. Elle définit cinq rôles et deux preuves principales : un mandat de checkout qui capture ce que l'utilisateur autorise, puis un mandat de paiement lié à l'instrument et aux conditions d'exécution. Les scénarios distinguent la présence et l'absence de l'utilisateur au moment de la transaction.
AP2 cite UCP comme protocole compatible. Cette articulation corrige une erreur fréquente : AP2 n'est pas un autre panier. Il apporte une preuve vérifiable à un parcours que UCP, ACP ou une plateforme propriétaire peut exécuter.
5. Identité et confiance de l'agent : TAP et Agent Pay
Le Trusted Agent Protocol publié par Visa avec Cloudflare le 14 octobre 2025 utilise les signatures de messages HTTP de la RFC 9421 pour aider un marchand à distinguer un agent approuvé d'un bot non identifié. Le programme Mastercard Agent Pay, annoncé le 29 avril 2025, s'appuie de son côté sur l'enregistrement des agents et sur des Agentic Tokens dans le réseau Mastercard. Les deux traitent la confiance, mais leur gouvernance diffère : TAP possède un dépôt public sous licence spécifique ; Agent Pay est un programme propriétaire du réseau Mastercard.
6. Paiement d'une ressource : x402 et MPP
x402, lancé par Coinbase le 6 mai 2025, donne une sémantique de paiement au code HTTP 402 : le serveur renvoie des conditions, le client paie puis rejoue la requête. Le règlement documenté passe par des facilitateurs et des stablecoins. MPP, coécrit par Tempo et Stripe et lancé le 18 mars 2026, organise lui aussi un échange HTTP de paiement, mais annonce couvrir les stablecoins et les moyens fiat grâce aux Shared Payment Tokens de Stripe. Ces protocoles conviennent particulièrement aux API, contenus et services facturés à l'appel. Ils ne définissent pas à eux seuls la disponibilité d'un produit, les retours ou une promesse de livraison.
Chronologie vérifiable : du connecteur d'outils au paiement machine
| Date | Événement | Responsabilité ajoutée à la pile |
|---|---|---|
| 25 nov. 2024 | Anthropic publie MCP | Accès standardisé aux outils et aux données |
| 9 avr. 2025 | Google annonce A2A | Coordination entre agents |
| 29 avr. 2025 | Mastercard annonce Agent Pay | Agents enregistrés et paiement tokenisé sur son réseau |
| 6 mai 2025 | Coinbase lance x402 | Paiement natif dans un échange HTTP |
| 16 sept. 2025 | Google annonce AP2 | Mandats vérifiables d'intention et de paiement |
| 29 sept. 2025 | OpenAI et Stripe publient ACP | Protocole de commerce pour agents et marchands |
| 14 oct. 2025 | Visa publie TAP | Identification cryptographique de l'agent auprès du marchand |
| 11 janv. 2026 | Google lance UCP avec ses partenaires | Découverte et négociation de capacités de commerce |
| 18 mars 2026 | Tempo et Stripe lancent MPP | Paiements machine HTTP en stablecoins et fiat |
La gouvernance change la nature du risque
Une spécification publique, une gouvernance de fondation et une licence ouverte sont trois propriétés distinctes. MCP et A2A ont quitté leur entreprise d'origine pour des structures de la Linux Foundation. AP2 a été donné à la FIDO Alliance le 28 avril 2026. x402 indique être porté par une fondation dédiée. ACP reste maintenu par OpenAI et Stripe avec un chemin annoncé vers une gouvernance plus large. UCP est un projet open source co-développé par plusieurs entreprises. TAP reste une spécification Visa publiée sous une licence propre, et Agent Pay un programme propriétaire Mastercard.
Aucune de ces formes ne garantit l'adoption. Elles déterminent plutôt qui peut modifier la norme, sous quelles règles, avec quel risque de dépendance et quelle possibilité d'implémentation indépendante.
Le test le plus difficile reste hors de la spécification
Dans sa note 2026/004, le Fonds monétaire international décompose le paiement agentique en trois couches : intention, autorisation et règlement. Il souligne la tension entre le caractère probabiliste des systèmes d'IA et l'exigence déterministe des infrastructures de paiement. Cette distinction explique pourquoi les spécifications multiplient les mandats, signatures, limites de dépense et journaux vérifiables : une phrase plausible de l'agent ne suffit pas à autoriser irrévocablement un transfert.
La conformité syntaxique à un protocole ne répond pas non plus aux questions de responsabilité, de recours, de fraude, de protection des données ou de consentement. Un déploiement sérieux doit donc tester les échecs : instrument refusé, prix modifié, mandat expiré, agent révoqué, remboursement partiel, livraison impossible et litige.
Comment choisir sans se tromper de couche
- Décrivez l'opération. Acheter un produit, payer un appel d'API et déléguer une tâche à un agent ne sont pas le même flux.
- Attribuez chaque responsabilité. Découverte, outils, coordination, commande, intention, identité, règlement et recours doivent avoir un propriétaire.
- Vérifiez la version. Une compatibilité annoncée sans version ni capacités communes n'est pas un test d'interopérabilité.
- Vérifiez la gouvernance et la licence. Un dépôt public n'implique pas automatiquement une licence open source ni une gouvernance neutre.
- Exigez une preuve de déploiement. Classez séparément spécification, démonstration, intégration accessible et transaction observée.
- Testez les scénarios d'échec. Le chemin nominal ne dit rien sur la révocation, le remboursement ou le litige.
Conclusion : le standard utile dépend de la responsabilité
Entre novembre 2024 et mars 2026, l'écosystème n'a pas convergé vers un protocole unique. Il a commencé à séparer les responsabilités. MCP et A2A transportent du contexte et du travail ; ACP et UCP structurent le commerce ; AP2, TAP et Agent Pay ajoutent de la confiance ; x402 et MPP déplacent le paiement dans l'échange machine.
Cette séparation rend la pile plus complexe à lire, mais potentiellement plus interopérable. La décision robuste consiste à combiner le moins de composants possible tout en couvrant chaque responsabilité, puis à vérifier les versions et les déploiements réels. Pour comparer les caractéristiques détaillées, consultez le comparatif des standards. Pour comprendre le seul volet paiement, lisez comment les agents IA paient.