ACP, UCP et AP2 comparés : les protocoles du commerce agentique en octobre 2026, et celui dont votre boutique a besoin

Trois protocoles ouverts décrivent désormais la manière dont un agent IA achète dans une boutique. L'Agentic Commerce Protocol (ACP) vient d'OpenAI et de Stripe. L'Universal Commerce Protocol (UCP) vient de Google et de Shopify. L'Agent Payments Protocol (AP2), lancé par Google puis cédé à la FIDO Alliance en avril, n'est pas du tout un protocole d'achat : il définit une preuve signée qu'un utilisateur a autorisé un paiement, et il est conçu pour s'insérer dans UCP. Tous trois sont sous licence Apache 2.0.

Au 22 octobre 2026, ils en sont à des stades très différents. ACP porte la mention bêta, sa dernière version est 2026-04-17 et aucun commit n'y a été ajouté depuis le 17 juillet. ChatGPT, son principal utilisateur, s'est éloigné en mars du paiement intégré autonome et se sert désormais d'ACP surtout pour recevoir des données produits. UCP a publié en août une version non rétrocompatible, 2026-08-25, alors que les propres services de Google tournent encore sur 2026-04-08 et que son paiement intégré est en accès anticipé, aux États-Unis uniquement. AP2 en est à la v0.2, et aucun produit Google ne documente son utilisation.

Cet article s'adresse aux CTO et aux lead développeurs de boutiques et de plateformes de commerce qui doivent décider quoi implémenter. Pour ce que chaque plateforme d'IA attend d'une boutique en tant qu'entreprise, commencez par notre vue d'ensemble du commerce agentique.

Côte à côte

ACP : l'Agentic Commerce Protocol

Gouvernance et versions

Le dépôt de la spécification indique qu'ACP est maintenu par OpenAI et Stripe et le présente comme une bêta. Son document de gouvernance fait des deux sociétés les mainteneurs fondateurs (Founding Maintainers) : elles pourvoient les sièges du comité de pilotage (sept au maximum) et conservent un veto à utiliser « en dernier recours ». Meta a rejoint le projet le 24 avril 2026 comme troisième mainteneur principal et membre du comité. La documentation de Stripe décrit ACP comme « créé par Stripe, OpenAI et Meta », mais le fichier NOTICE du dépôt ne crédite qu'OpenAI et Stripe. Une fondation neutre n'est qu'une piste évoquée pour l'avenir.

Il existe cinq versions datées : 2025-09-29 (session de paiement et paiement délégué), 2025-12-12 (des changements non rétrocompatibles tirés des adaptateurs d'URBN et d'Etsy), 2026-01-16 (un prestataire 3DS choisi par le marchand), 2026-01-30 (négociation des capacités, extensions et un cadre de gestionnaires de paiement non rétrocompatible) et 2026-04-17 (panier, flux, commandes, authentification déléguée, découverte et MCP), qui a rendu 2026-01-30 obsolète. Rien n'a été publié au cours des six mois qui ont suivi. Le dossier unreleased/ contient des changements plus modestes, datés jusqu'au 17 juillet, comme un identifiant de mise à jour du flux et une URL de produit facultative sur les articles de la session de paiement.

Ce qu'un marchand implémente avec la version 2026-04-17

L'API de paiement est hébergée par le marchand et appelée par l'agent :

• POST /checkout_sessions crée une session, POST /checkout_sessions/{checkout_session_id} la met à jour (un POST, pas un PUT), un GET sur ce chemin la récupère, et .../complete et .../cancel la clôturent.
• Les requêtes portent une clé d'API de type bearer et un header API-Version obligatoire. Depuis 2026-04-17, une Idempotency-Key est obligatoire sur chaque POST, avec des erreurs définies : 400 idempotency_key_required, 409 idempotency_in_flight et 422 idempotency_conflict.
• La requête de création porte un objet capabilities. L'agent déclare ce qu'il prend en charge et le vendeur renvoie l'intersection, si bien qu'une incompatibilité apparaît avant le paiement.
• Le marchand envoie par POST les événements de commande à un récepteur hébergé par OpenAI à /agentic_checkout/webhooks/order_events, signés en HMAC-SHA256 dans un header Merchant-Signature. Les statuts vont de created à delivered ou canceled, et adjustments[] transporte les remboursements, les retours, les litiges et les rétrofacturations.

La version 2026-04-17 a aussi ajouté un fichier /.well-known/acp.json statique et public, dont le champ transports indique si la boutique parle rest, mcp ou les deux. Elle a ajouté une liaison MCP sur Streamable HTTP avec cinq outils (create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session), authentifiée dans la configuration du serveur plutôt qu'à chaque requête. Elle a enfin ajouté une API de flux que l'agent héberge et vers laquelle le marchand pousse ses données (POST /feeds, PATCH /feeds/{id}/products), un panier à vendeur unique sans données de paiement (POST /carts, PUT /carts/{id}) et l'authentification 3DS2 déléguée (POST /delegate_authentication). Il n'y a pas d'abonnements : la RFC sur les extensions mentionne subscription comme « prise en charge de la facturation récurrente (future) ».

Le paiement dans ACP

La réponse d'origine d'ACP est le paiement délégué. Le PSP ou le coffre-fort de cartes implémente POST /agentic_commerce/delegate_payment, qui transforme une carte (le seul type d'identifiant de paiement) en un token que le PSP du marchand ne peut utiliser que dans les limites d'une autorisation : reason (uniquement one_time), max_amount, currency, checkout_session_id, merchant_id et expires_at. Selon les termes de la RFC, « les paiements, le règlement et la conformité restent sur l'infrastructure du marchand. » Worldpay documente sa propre version de cet appel, et PayPal prend en charge ACP via des tokens délégués dans Braintree.

Depuis 2026-01-30, les moyens de paiement acceptés sont déclarés comme gestionnaires sous capabilities.payment.handlers. Exemple de données de paiement tiré du journal des modifications :

{ "handler_id": "card_tokenized", "instrument": { "type": "card", "credential": { "type": "spt", "token": "spt_123" } } }

Le spt est le Shared Payment Token de Stripe, disponible « aux États-Unis, au Canada et dans certains pays européens ». Un vendeur sur Stripe l'encaisse avec payment_method_data[shared_payment_granted_token] sur une version d'API en préversion ; un vendeur qui passe par un autre processeur de paiement peut le convertir une seule fois en identifiants réseau. Notre article sur les paiements agentiques explique qui porte le risque.

Ce que le revirement d'OpenAI en mars a changé

Le 24 mars 2026, OpenAI a écrit que « la version initiale d'Instant Checkout n'offrait pas le niveau de flexibilité que nous souhaitons proposer », a laissé les marchands utiliser leur propre page de paiement et a annoncé « étendre ACP pour en faire la couche de liaison entre les marchands et les utilisateurs tout au long de la découverte. » Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot et Wayfair avaient intégré ACP pour la découverte, et les catalogues Shopify arrivent via Shopify Catalog. Ce que cela signifie pour un développeur :

• Le flux est la partie en service. La page marchands d'OpenAI indique que les achats « sont finalisés sur des sites web ou des applications appartenant aux marchands » et que le shopping est disponible pour les utilisateurs américains. L'onboarding des flux est réservé à des partenaires approuvés, admis depuis une liste d'attente : un fichier complet quotidien par SFTP avec neuf champs obligatoires, des mises à jour par API en cours de journée, les promotions uniquement par API. L'envoi standard « cible actuellement les États-Unis ».
• Le paiement passe par une autre porte. La spécification du flux indique que le paiement « nécessite une intégration activée séparément ». Pour les applications ChatGPT, la voie en disponibilité générale est un paiement externe sur le propre domaine du développeur. La fenêtre de paiement dans la conversation est une bêta privée « limitée à certaines marketplaces », qui transmet un token de paiement au serveur MCP de l'application dans un appel d'outil complete_checkout.
• Les pages d'OpenAI sont en retard sur la spécification. Sa référence du paiement affiche toujours API-Version 2025-09-12 et une énumération provider composée de stripe, adyen et braintree. Développez d'après le dépôt et vérifiez auprès d'OpenAI quelle version est acceptée.

Les pages de PSP qui présentent encore Instant Checkout comme actif ne sont plus à jour.

UCP : l'Universal Commerce Protocol

Gouvernance et versions

Google a lancé UCP le 11 janvier 2026, protocole codéveloppé avec Shopify, Etsy, Wayfair, Target et Walmart. Les règles de gouvernance accordent à Google et à Shopify une voix permanente chacun au conseil de gouvernance (Governing Council), que Stripe a rejoint le 28 avril 2026, et précisent que « Google détient le vote par procuration pour tous les sièges vacants jusqu'en décembre 2028 ». Le 24 avril, le Shopping Tech Council est passé à 16 sièges avec l'arrivée d'Amazon, Meta, Microsoft, Salesforce et Stripe : Meta et Stripe siègent donc désormais à la fois au comité d'ACP et au conseil d'UCP.

Le dépôt compte quatre versions. 2026-04-08 a ajouté les capacités de panier et de catalogue, la signature des requêtes et des réponses, et Get Order. 2026-08-25 n'est pas rétrocompatible : signing_keys[] a cédé la place à un JWK Set dans keys[], les extensions de paiement sont passées de dev.ucp.shopping.* à dev.ucp.common.payment.*, les schémas partagés ont été déplacés et ont changé d'URL $id, et les PAN et les tokens réseau sont devenus des types d'identifiants distincts. Elle a aussi ajouté un 3DS2 indépendant des fournisseurs, les paiements scindés (split payments), les conditions de paiement et l'interopérabilité avec Web Bot Auth.

C'est là que se trouve le piège. Le guide du profil de Google ne couvre que 2026-04-08 et 2026-01-23, le profil d'agent de Google lui-même, sur ucp.goog, déclare "version": "2026-04-08", et Salesforce B2C Commerce 26.9 sert les deux mêmes versions. Le Checkout MCP de Shopify, de son côté, renvoie à 2026-08-25. Développez d'après la dernière version, et vous développez une version que Google ne documente pas. La réponse de la spécification est un objet supported_versions qui associe à chaque version plus ancienne l'URI de son propre profil.

Découverte, transports et authentification

Chaque marchand publie un profil à /.well-known/ucp avec ucp.version, ucp.services et ucp.payment_handlers, et Google exige qu'il soit public et accessible sans authentification. La plateforme de l'agent publie elle aussi le sien, et chaque requête porte son URI dans un header UCP-Agent, en HTTPS avec TLS 1.3 au minimum. L'authentification est au choix du marchand : aucune, X-API-Key, OAuth 2.0, TLS mutuel ou les HTTP Message Signatures de la RFC 9421. Google envoie un token bearer, et sa FAQ propose aussi le mTLS. Une Idempotency-Key n'est qu'un « SHOULD » ; un serveur qui en accepte une la conserve au moins 24 heures et répond 409 lorsqu'elle est réutilisée avec un corps différent.

REST est le transport de base, aux côtés de MCP, d'une extension A2A et d'un mode embarqué accessible via une continue_url. Les commandes se résument à un GET /orders/{id} et à un webhook du marchand vers la plateforme, signé selon la RFC 9421. Les chemins du panier sont les mêmes que dans ACP. Les opérations de paiement se ressemblent, mais ne sont pas interchangeables :

Un même cœur de paiement peut servir les deux. Une même table de routes, non.

Le paiement dans UCP

UCP ne transfère pas d'argent. Un gestionnaire de paiement est une spécification rédigée par un fournisseur d'identifiants de paiement, comme com.google.pay pour Google Pay ou dev.shopify.shop_pay pour Shop Pay. Le marchand liste les gestionnaires qu'il accepte, la plateforme en exécute un, et lors du complete le marchand reçoit un token opaque qu'il encaisse via son propre PSP.

Sur les services de Google, le seul gestionnaire est Google Pay, PAN_ONLY est la seule méthode d'authentification utilisée, et votre PSP « doit être en mesure de traiter nos tokens ». Stripe publie com.stripe.payments pour la carte et Apple Pay : « L'agent envoie un shared payment token (SPT) dans la requête Complete Checkout, et le vendeur l'encaisse. » Google Pay reste sur son propre gestionnaire. PayPal accepte le gestionnaire Google Pay via Braintree ou via son API Orders v2.

Ce que Google exige avant de vous appeler

Le guide du paiement intégré de Google demande l'API de paiement REST et se réserve l'étape du paiement : l'acheteur saisit ses informations sensibles « uniquement via l'interface de Google ». Les niveaux de service exigés sont d'au moins 95 % de disponibilité sur chaque endpoint, avec des latences p50 et p95 de 1 et 4 secondes pour la création, 1 et 5 pour la mise à jour, et 6 et 10 pour la finalisation. Après une commande, vous envoyez les mises à jour de statut à un webhook de Google, avec un identifiant de partenaire et une clé fournis lors de l'onboarding. Dans Merchant Center, chaque produit doit avoir native_commerce(checkout_eligibility) défini sur true (l'attribut « vaut FALSE par défaut »), une politique de retour et un contact pour le support sont obligatoires, et les abonnements, les paiements en plusieurs fois, les produits personnalisés, les articles d'occasion et reconditionnés, les précommandes et les articles soumis à une restriction d'âge sont exclus.

L'option plus légère, depuis 2026-04-08, est le transfert de panier : vous n'implémentez que la création du panier, Google transmet le panier à votre site, et aucun gestionnaire de paiement ni webhook de commande n'est nécessaire.

La vraie limite, c'est l'accès. Le paiement est « disponible pour certains marchands » via le formulaire de manifestation d'intérêt du programme en accès anticipé, sur lequel vous vous engagez à démarrer sous 30 jours et acceptez que l'accès « puisse être retiré » si vous ne progressez pas. Les conditions UCP Checkout s'appliquent « aux États-Unis uniquement ». Le hub Merchant Center doit suivre en Australie et au Canada « au début de l'année prochaine » ; Google ne donne aucune date de paiement intégré pour un autre pays.

UCP en dehors de Google

Microsoft Merchant Center accepte les flux compatibles UCP aux États-Unis depuis le 21 avril 2026. Copilot Checkout exige un flux conforme à UCP, accepte les marchands de langue anglaise qui vendent à des acheteurs américains en dollars, avec un seul PSP chacun, et son réglage de boutique porte la mention « en pilote uniquement, pour certains clients ». Shopify expose UCP via MCP à https://{shop}/api/ucp/mcp et a supprimé ses anciens outils de catalogue et de panier. Une capacité de réservation d'hébergement a été fusionnée à l'état de brouillon le 24 septembre 2026 et ne figure dans aucune version.

AP2 : l'Agent Payments Protocol

AP2 n'est pas une troisième façon de finaliser un achat. Sa spécification indique qu'il « fonctionne comme une fonctionnalité de sécurité au sein d'un protocole de commerce » et qu'il est « conçu explicitement pour être compatible avec l'Universal Commerce Protocol (UCP) ». La version 0.1.0 est sortie le 16 septembre 2025 et la v0.2 le 28 avril 2026, le jour où Google a cédé AP2 à la FIDO Alliance. L'annonce de la FIDO cite un groupe de travail Agentic Authentication et un groupe de travail Payments présidé par des membres de Mastercard et de Visa, et indique que les contributions « seront examinées et développées plus avant ». La FIDO n'a publié aucune spécification AP2. Le dépôt GitHub n'accepte plus que des exemples et des modifications du SDK, et son dernier commit date du 29 avril.

La version 0.2 définit un Checkout Mandate (ce qui est acheté) et un Payment Mandate (le paiement, avec des contraintes comme payment.amount_range, payment.budget et payment.allowed_payees). Chacun est un SD-JWT sous une forme fermée et une forme ouverte (mandate.payment.1 et mandate.payment.open.1, par exemple). En mode Human Present, l'utilisateur approuve les mandats fermés. En mode Human Not Present, l'utilisateur approuve des mandats ouverts qui fixent des contraintes et portent la clé publique de l'agent dans un claim cnf, et l'agent assemble les mandats fermés dans ces limites. Les tutoriels qui parlent d'Intent Mandates et de Cart Mandates décrivent la v0.1 ; ces termes ont disparu de la v0.2.

Dans UCP, AP2 est l'extension dev.ucp.common.payment.ap2_mandate (dev.ucp.shopping.ap2_mandate avant 2026-08-25). Une fois qu'elle est négociée, le marchand signe les réponses de sa session de paiement, la plateforme présente un checkout_mandate et un payment_mandate lors du complete, et la session est « Security Locked » : aucune des deux parties ne peut se rabattre sur un paiement ordinaire.

Personne ne le demande encore. La FAQ de Google décrit AP2 comme « particulièrement utile pour de futurs scénarios impliquant des transactions autonomes d'agents IA ». Le profil d'agent de Google lui-même indique Google Pay comme seul gestionnaire de paiement et ne déclare aucune capacité AP2, et son profil 2026-08-25 n'a pas non plus d'entrée AP2. Aucun produit Google ne documente l'utilisation d'AP2 : un marchand n'a donc rien à construire tant qu'une plateforme ne le négocie pas.

Les protocoles voisins

MCP

ACP et UCP peuvent tous deux fonctionner sur MCP, dont la spécification actuelle, 2026-07-28, supprime les sessions et le header Mcp-Session-Id, abandonne le handshake initialize, impose server/discover et oblige un client à renvoyer sa requête sous un nouvel identifiant lorsque son stream est interrompu. La liaison MCP d'ACP renvoie encore au transport 2025-11-25. Un identifiant de session de paiement est précisément le type d'identifiant émis par le serveur qu'attend la nouvelle spécification, et un complete perdu en plein stream revient sous la forme d'une nouvelle requête : traitez les clés d'idempotence comme obligatoires sur les deux protocoles.

WebMCP

WebMCP est une proposition de standard web qui permet d'exposer les fonctions propres d'une page aux agents des navigateurs. Shopify propose le paiement UCP à la fois sous forme de Checkout MCP et de Checkout WebMCP, avec le même objet de paiement, et recommande Checkout MCP. Notre guide WebMCP fait le point sur son statut.

x402 et MPP

x402 et le Machine Payments Protocol, conçu par Tempo et Stripe, font payer un agent à chaque requête HTTP pour une API, des données ou du contenu. Ce ne sont pas des protocoles d'achat pour les boutiques. Voir notre article sur x402.

Visa Trusted Agent Protocol et Mastercard Agent Pay

Ces deux programmes s'ajoutent à ACP et à UCP plutôt que de les remplacer. Le Trusted Agent Protocol de Visa donne à un agent « une méthode cryptographique standardisée » pour prouver son identité et son autorisation auprès des marchands, et Mastercard Agent Pay est un programme de tokenisation pour le commerce agentique. Le guide marchands de Mastercard place UCP et ACP à son niveau de préparation le plus élevé, note que « les premiers adoptants procèdent actuellement à l'intégration » et conseille aux marchands de commencer par ses deux niveaux plus simples. Notre article sur les paiements agentiques couvre les deux programmes.

Personal Agent Protocol

Sierra indique avoir annoncé le Personal Agent Protocol (« Poppy ») avec Meta le 6 octobre 2026, et en a publié un brouillon le 9 octobre. Une entreprise publie un seul fichier, à /.well-known/poppy.json ; le protocole s'appuie sur OAuth, les JWT, HTTPS, OpenAPI et MCP pour permettre à un agent personnel de s'identifier et d'obtenir l'autorisation du client pour tout type de tâche, et Sierra le présente comme complémentaire d'UCP. Le site du protocole affiche la version 0.2 et indique « Il s'agit d'un brouillon ». Nous n'avons trouvé aucune publication à ce sujet dans la salle de presse de Meta.

Lequel vous faut-il ?

Sur Shopify

Rien à construire. Les boutiques en ligne agentiques de Shopify sont « actives par défaut pour les boutiques admissibles ». ChatGPT reçoit votre catalogue via Shopify Catalog et envoie les acheteurs vers votre boutique. Le paiement direct de Google est activé par défaut pour les boutiques établies aux États-Unis et qui y vendent, et Copilot a inscrit automatiquement les marchands Shopify. Vos décisions portent sur les données produits et sur le maintien ou non du paiement direct, sachant que les pixels personnalisés ne se déclenchent pas dans celui de Google.

Sur Salesforce, commercetools ou une autre plateforme

Salesforce B2C Commerce 26.9 sert UCP en versions 2026-01-23 et 2026-04-08 : /.well-known/ucp avec une table supported_versions, et les endpoints de session de paiement derrière un token SLAS. Salesforce présente le paiement UCP sur Google comme en disponibilité générale en octobre 2026. Une session est une vue headless d'un panier, et le guide d'audit de Salesforce prévient que les contrôleurs SFRA et SiteGenesis ainsi que « les autres ressources SCAPI que vous utilisez aujourd'hui ne s'exécutent pas dans ce parcours » : la logique qui leur est rattachée doit donc être copiée ou raccordée aux hooks de session de paiement d'UCP. Le flux doit cibler en-US, et Salesforce « ne dispense pas de la liste d'attente de Google ». Pour ChatGPT, Salesforce fait partie des canaux de livraison qu'OpenAI cite pour les flux ACP.

Sur commercetools ou une autre plateforme, demandez à l'éditeur quelles versions et capacités d'UCP il sert, lesquels de vos hooks s'exécutent dans un paiement mené par un agent, et s'il envoie des flux à OpenAI.

Sur votre propre logiciel

1. D'abord les flux. Google Merchant Center et, une fois qu'OpenAI vous a admis, son flux produits. L'usage commercial d'ACP dans ChatGPT aujourd'hui, c'est exactement cela.
2. UCP pour Google, si vous vendez aux États-Unis et que Google vous admet. Développez d'après 2026-04-08 : le profil avec com.google.pay, les opérations de paiement dans les objectifs de latence de Google, un PSP qui traite les tokens Google Pay, le webhook de commande et l'attribut de flux. Ou commencez par le seul transfert de panier.
3. Le paiement ACP seulement si vous avez une raison précise, par exemple une application ChatGPT admise à la bêta de la fenêtre de paiement. Développez d'après la version 2026-04-17 du dépôt.
4. AP2 : rien pour l'instant.
5. Un seul cœur de paiement. Les deux protocoles veulent une session que l'on peut créer, mettre à jour, finaliser et annuler par API, et relancer sans risque. Construisez-la une seule fois, au-dessus de votre logique de commande, de taxes et de paiement, avec de fins adaptateurs ACP et UCP par-dessus, et MCP là où les agents en ont besoin.

Aucun des deux protocoles n'offre aujourd'hui à une entreprise d'abonnements un paiement intégré pour les agents.

Si vous ne vendez qu'en dehors des États-Unis

Aucun des trois ne vous donne aujourd'hui un paiement par agent. Le shopping dans ChatGPT et l'envoi standard de flux d'OpenAI sont limités aux États-Unis ; les conditions UCP Checkout de Google ne valent qu'aux États-Unis ; Copilot Checkout sert les acheteurs américains en dollars. La prochaine étape annoncée par Google est le hub Merchant Center en Australie et au Canada « au début de l'année prochaine », sans date pour le Royaume-Uni ni pour l'UE.

Gardez votre flux Merchant Center complet et, si vous refaites de toute façon votre paiement, construisez le cœur piloté par API décrit plus haut : un adaptateur sera un petit chantier lorsque votre marché s'ouvrira. Vous vendez aux États-Unis depuis l'étranger ? Vérifiez où chaque programme exige que le marchand soit établi ; le paiement direct de Google via Shopify, par exemple, exige une boutique américaine.

Où trouver de l'aide

Nous construisons la couche protocolaire pour les boutiques qui ne tournent pas sur Shopify : un profil /.well-known/ucp et des endpoints de session de paiement au-dessus de votre logique existante de commande, de taxes et de paiement, des webhooks de commande vers Google, des flux produits pour Google Merchant Center et OpenAI, et des serveurs MCP qui exposent le même paiement aux agents. Notre service de développement d'agents IA et d'intégration de serveurs MCP est le point de départ de ce travail.

Écrivez à office@c9group.dev en précisant votre plateforme, votre prestataire de paiement et les pays dans lesquels vous vendez, et nous vous dirons quel protocole s'applique et ce que son implémentation demanderait. Les conditions des programmes de Google et d'OpenAI sont des contrats : nous sommes des ingénieurs, pas des juristes, alors faites-les lire par un conseiller avant de signer.