ACP, UCP, AP2 : quel protocole de commerce agentique adopter ?
Trois standards, trois périmètres, et beaucoup de confusion. Le comparatif complet pour comprendre ce que chacun couvre et lequel activer selon votre plateforme.
Depuis dix-huit mois, trois acronymes reviennent dans toutes les discussions sur le commerce agentique : ACP, UCP et AP2. On les présente souvent comme des concurrents qui s'affronteraient pour un standard unique. C'est une lecture inexacte, et elle conduit à de mauvaises décisions techniques.
La réponse courte
ACP et UCP sont des protocoles de transport commercial : ils décrivent comment un agent découvre des produits, constitue un panier et déclenche une commande. AP2 est un protocole d'autorisation de paiement : il décrit comment prouver qu'un agent avait bien le droit de payer, et pour quel montant.
Une transaction agentique typique combine donc les deux couches : un transport ACP ou UCP, avec une autorisation AP2 en dessous. La question n'est pas « lequel choisir contre les autres », mais « lesquels dois-je supporter, et dans quel ordre ».
Le comparatif
| ACP | UCP | AP2 | |
|---|---|---|---|
| Porté par | OpenAI et Stripe | Google et Shopify | Écosystème paiement, adossé à UCP |
| Nature | Transport commercial | Transport commercial | Autorisation de paiement |
| Périmètre | Centré sur le passage en caisse, avec une évolution vers la découverte | Cycle complet : découverte, panier, paiement, suivi, après-vente | Mandat signé, tokenisation, preuve d'intention |
| Surfaces concernées | ChatGPT, Copilot | Google, Shopify, Etsy, Wayfair | Transverse |
| Échange de contexte catalogue | Via le protocole | S'appuie notamment sur MCP | Non concerné |
| Maturité constatée en 2026 | Déployé sur les surfaces OpenAI | En production chez des marchands majeurs | Accepté par les acteurs bancaires |
ACP : l'entrée par le paiement
ACP est né du besoin de conclure une transaction depuis une conversation, sans redirection vers le site marchand. Sa logique est celle d'un tunnel de commande délégué : le marchand expose ce qu'il faut pour construire une commande valide, l'agent la constitue, le paiement s'exécute dans le contexte conversationnel.
Ce que cela implique côté marchand : un point d'entrée capable de créer une commande de façon idempotente, de renvoyer les taxes et frais de port exacts, et de gérer proprement les indisponibilités entre le moment de la proposition et celui de la validation.
Le piège : croire qu'il suffit d'ouvrir un point d'entrée. C'est le calcul en temps réel du prix total, taxes et livraison comprises, qui pose le vrai problème d'ingénierie — et une erreur à cet endroit se traduit par un litige, pas par un abandon de panier.
UCP : l'entrée par le cycle complet
UCP couvre l'ensemble du parcours : découverte, panier, paiement, suivi de commande et service après-vente. Il s'appuie sur AP2 pour la partie paiement et sur MCP pour l'échange de contexte entre le catalogue du marchand et le moteur de raisonnement de l'agent.
C'est le protocole avec le périmètre fonctionnel le plus large, et celui dont l'adoption a été la plus rapide côté écosystème, notamment via l'activation par défaut sur les boutiques Shopify américaines en mars 2026.
Ce que cela implique côté marchand : le catalogue doit être interrogeable de manière sémantique, pas seulement exportable en fichier. Et il faut être capable de répondre à des questions d'après-vente — « où est ma commande ? » — par une interface machine.
AP2 : la couche que personne ne peut ignorer
AP2 répond à la question qui inquiète légitimement banques et marchands : comment prouver qu'un agent avait le droit de dépenser cet argent ? Le principe est celui d'un mandat signé — l'utilisateur autorise une intention d'achat bornée (un montant, un périmètre, une durée), et l'agent présente cette preuve au moment de payer.
Pour un marchand, l'intérêt est direct : la responsabilité en cas de contestation devient traçable. C'est ce qui a permis l'adhésion des acteurs bancaires, et c'est pourquoi AP2 se retrouve sous les deux protocoles de transport.
Que faire selon votre situation
- Vous êtes sur Shopify. UCP est largement pris en charge par la plateforme. Votre travail porte sur la qualité du catalogue et l'exactitude du stock, pas sur le protocole.
- Vous êtes sur PrestaShop, Magento ou une solution sur mesure. Commencez par un flux produit propre et une API de commande idempotente. Ces deux briques servent quel que soit le protocole que vous activerez ensuite.
- Votre trafic est majoritairement français ou européen. Ne vous précipitez pas sur une implémentation complète. Faites d'abord le travail de donnée : il représente l'essentiel de l'effort et bénéficie à tous les canaux, y compris vos marketplaces.
- Vous refondez votre plateforme en ce moment. C'est le seul cas où intégrer les protocoles dès la conception coûte réellement moins cher que les ajouter après.
Questions fréquentes
Faut-il implémenter les trois ?
À terme, probablement — mais pas simultanément. AP2 arrive avec le protocole de transport que vous activez. Commencez par celui qui correspond à votre plateforme et à votre marché.
Quel est le coût d'implémentation ?
Sur une plateforme qui les prend en charge nativement, c'est une configuration. Sur une plateforme sur mesure, l'essentiel de la charge porte sur trois points : exposition sémantique du catalogue, calcul temps réel du prix total, idempotence de la création de commande. Le protocole lui-même est la partie la plus simple.
Que se passe-t-il si un standard disparaît ?
Le travail de fond — donnée produit complète, stock fiable, API de commande propre — reste valable quel que soit le protocole survivant. C'est la raison pour laquelle il faut le faire en premier.
Ces protocoles remplacent-ils les flux marketplace ?
Non. Ils coexistent, et ils consomment souvent la même donnée source. Un référentiel produit central alimente aussi bien un flux Mirakl qu'une vitrine agentique — voir notre article sur la donnée produit.
Conclusion
ACP, UCP et AP2 ne s'affrontent pas : ils s'empilent. La décision structurante pour un marchand n'est pas le choix du protocole, c'est la mise à niveau de sa donnée produit et de son API de commande — un travail qui sert tous les protocoles à la fois et se rentabilise même s'ils changent.
Suite du dossier : la checklist technique pour rendre sa boutique lisible par les agents. Pour une plateforme qui embarque ces protocoles par défaut plutôt qu'en extension, voyez Pixee Commerce.