Protocoles de commerce agentique : ACP, AP2 et UCP, et ce dont votre catalogue a besoin

TL;DR

• Les trois protocoles de commerce agentique ouverts qui comptent en octobre 2026 sont ACP (OpenAI et Stripe), UCP (Google et des partenaires de la distribution) et AP2 (créé par Google, désormais avec la FIDO Alliance). Ils couvrent des couches différentes d'un même achat.
• ACP et UCP normalisent le catalogue produit et le paiement de la commande entre l'agent et le marchand. AP2 normalise la preuve signée qu'un utilisateur a autorisé un achat et un paiement précis. Visa et Mastercard gèrent leurs propres programmes de vérification des agents et des identifiants de paiement.
• Les trois acceptent un GTIN dans les données produit, mais aucun ne l'exige, et aucun ne mentionne GS1 Digital Link. Le checkout repose sur les identifiants d'article propres au marchand, et c'est précisément là que l'identité du produit peut se perdre.

Les protocoles de commerce agentique sont les spécifications ouvertes qui permettent à un agent IA de trouver un produit, de le mettre dans un panier et de le payer pour le compte de quelqu'un sans aspirer le contenu d'un site web. En octobre 2026, trois d'entre eux portent l'essentiel du poids du secteur : l'Agentic Commerce Protocol (ACP), l'Universal Commerce Protocol (UCP) et l'Agent Payments Protocol (AP2). Ils fonctionnent comme des couches : ACP et UCP décrivent la façon dont un agent échange avec un marchand sur les produits, les paniers et les commandes, et AP2 décrit comment chacun peut prouver après coup ce que l'utilisateur a réellement autorisé.

Pour une marque ou un importateur, la question pratique est plus étroite. Quel que soit le protocole utilisé par un agent, il pose les mêmes questions à votre catalogue : quel est cet article, combien coûte-t-il, puis-je l'acheter, et quel identifiant dois-je transmettre au checkout ? Ce guide présente qui détient chaque protocole, ce qu'il normalise, ce qu'un marchand doit fournir et où se situe l'identité du produit, à la date d'octobre 2026.

Quels protocoles de commerce agentique existent, et quand ont-ils été lancés ?

Qu'est-ce que l'Agentic Commerce Protocol (ACP) ?

ACP est une spécification ouverte pour le commerce entre les acheteurs, leurs agents IA et les entreprises. OpenAI et Stripe l'ont publiée le 29 septembre 2025, en même temps qu'Instant Checkout dans ChatGPT, sous licence Apache 2.0. Le dépôt officiel la présente comme en version bêta et maintenue par OpenAI et Stripe en tant que mainteneurs fondateurs ; depuis avril 2026, son fichier des mainteneurs mentionne aussi Meta comme mainteneur principal. La dernière version stable est la 2026-04-17.

ACP normalise quatre choses :

• Le checkout. Le marchand expose une API de session de checkout : l'agent crée une session à partir d'articles, la met à jour avec l'adresse et le choix de livraison, puis la finalise ou l'annule. La spécification indique explicitement que le marchand reste le système de référence pour les commandes, les paiements, les taxes et la conformité, et que le paiement passe par le propre prestataire de services de paiement du marchand.
• Le paiement délégué. Un prestataire de paiement émet un jeton à usage unique dont l'utilisation est limitée par une « allowance » : un montant maximal, une devise, une session de checkout précise, un marchand précis et une date d'expiration. Le Shared Payment Token de Stripe a été la première implémentation compatible. Une API distincte d'authentification déléguée couvre les contrôles 3-D Secure 2.
• Le flux produit. La version 2026-04-17 a ajouté une Feed API. Il s'agit d'un modèle push : le marchand envoie son catalogue vers un flux hébergé par la plateforme de l'agent, soit sous forme de fichier complet, soit par mises à jour partielles.
• Le panier et les commandes, ainsi qu'une liaison avec le Model Context Protocol (MCP).

Qu'est devenu Instant Checkout ?

Le 24 mars 2026, OpenAI a annoncé que la version initiale d'Instant Checkout n'avait pas offert la flexibilité souhaitée, et que les marchands pourraient utiliser leur propre checkout pendant qu'OpenAI se concentrait sur la découverte de produits. Dans la même annonce, l'entreprise indiquait étendre ACP pour transporter des flux de produits et de promotions dans ChatGPT. Le protocole continue donc, la spécification du checkout existe toujours, et dans ChatGPT aujourd'hui le flux compte davantage que le checkout. L'intégration de flux produits dans ChatGPT est réservée à des partenaires approuvés, qui posent leur candidature auprès d'OpenAI.

De quelles données produit un flux ACP a-t-il besoin ?

Dans la Feed API ouverte d'ACP, un produit a besoin d'un id stable et d'au moins une variante, et chaque variante a besoin d'un id stable et d'un title. Tout le reste est facultatif dans le schéma : prix et prix catalogue en unités monétaires mineures, statut de disponibilité, médias, catégories, options de variante telles que la couleur et la taille, vendeur, prix unitaire, et une liste de barcodes, où chaque entrée comporte un type, par exemple GTIN, UPC ou EAN, et une valeur.

La propre spécification de flux d'OpenAI pour ChatGPT est plus stricte. Elle exige un identifiant d'article, un titre, une description, une URL de produit, une marque, un nom de vendeur, une URL d'image principale, la disponibilité et le prix. Le champ gtin est facultatif, doit comporter 8, 12, 13 ou 14 chiffres avec une clé de contrôle valide, et doit être omis si le produit n'en a pas. Le champ mpn doit être envoyé avec la marque, et la spécification demande aux marchands de ne pas inventer de référence fabricant pour remplacer un GTIN manquant.

La proposition de flux ACP tranche aussi un point important : les données du flux sont informatives, et la réponse du checkout fait foi pour le prix, le stock, les taxes et la livraison. Si l'identifiant de variante du flux n'est pas celui qu'accepte le checkout du marchand, le marchand doit fournir une table de correspondance.

Qu'est-ce que l'Universal Commerce Protocol (UCP) ?

UCP est une norme ouverte qui couvre l'ensemble du parcours d'achat : découverte, panier, checkout, liaison de compte et commandes. Google l'a lancé le 11 janvier 2026, développé en collaboration avec Shopify, Etsy, Wayfair, Target et Walmart et publié sur ucp.dev sous licence Apache 2.0. La gouvernance s'est élargie depuis : en avril 2026, Stripe a rejoint Google et Shopify comme membre permanent du Governing Council, et des comités techniques consacrés aux paiements, à l'hébergement et à la restauration ont été créés au cours de l'été. La version actuelle est la v2026-08-25.

Une entreprise qui prend en charge UCP publie un profil à l'adresse /.well-known/ucp qui liste les capacités qu'elle propose, afin qu'un agent puisse les découvrir sans intégration sur mesure. Ces capacités comprennent :

• La recherche et la consultation dans le catalogue, ajoutées dans la v2026-04-08.
• Le panier et le checkout, avec des taxes et des prix calculés par l'entreprise.
• La liaison d'identité via OAuth 2.0, afin qu'un agent puisse agir dans le compte d'un client sans détenir son mot de passe.
• Les commandes, avec des mises à jour de statut, d'expédition et de retour par webhook.
• Les gestionnaires de paiement (payment handlers), qui séparent l'instrument de paiement du prestataire qui le traite, et qui utilisent AP2 pour les mandats de paiement.

UCP peut être proposé via REST, MCP ou Agent2Agent (A2A). La première implémentation de Google permet d'acheter auprès de marchands éligibles dans AI Mode de la recherche Google et dans l'application Gemini. Elle fonctionne à partir d'un compte Google Merchant Center et des flux shopping existants, l'accès se fait via une liste d'attente, et le marchand reste le vendeur officiel (merchant of record).

De quelles données produit UCP a-t-il besoin ?

Une variante UCP doit avoir un id, un title, une description et un price. L'id de la variante est celui utilisé comme identifiant d'article au checkout. Les champs facultatifs comprennent le sku du marchand, une URL canonique, la disponibilité, les médias, le prix unitaire et les barcodes, dont les types connus sont UPC, EAN, ISBN, GTIN et JAN.

Les règles de consultation sont révélatrices. Un catalogue UCP doit permettre la consultation par identifiant de produit et par identifiant de variante. Il peut prendre en charge des identifiants secondaires tels que le SKU. Une consultation par GTIN n'est pas quelque chose sur quoi un agent peut compter.

Pour l'implémentation propre de Google, les règles de flux de Merchant Center continuent de s'appliquer. Google recommande un GTIN pour tous les produits auxquels le fabricant en a attribué un, et avertit que l'omission d'un GTIN attribué peut entraîner le refus du produit.

Qu'est-ce que l'Agent Payments Protocol (AP2) ?

AP2 résout un autre problème. Lorsqu'un agent paie, le marchand, l'émetteur de la carte et le réseau de paiement n'ont pas vu l'utilisateur cliquer sur « acheter ». AP2 leur fournit une preuve signée de ce que l'utilisateur a autorisé, afin qu'ils puissent accepter la transaction et régler les litiges. Google l'a annoncé le 16 septembre 2025. Le 28 avril 2026, Google a publié la version 0.2 et annoncé faire don d'AP2 à la FIDO Alliance, où la normalisation se poursuit au sein des groupes de travail de FIDO. Le site de la spécification AP2 et le dépôt sont publiés sous licence Apache 2.0.

Les deux versions décrivent la même idée différemment :

• La version 0.1 (septembre 2025) utilisait trois mandats : un Intent Mandate qui capture ce que l'utilisateur a demandé, un Cart Mandate qui enregistre les articles et le prix exacts approuvés par l'utilisateur, et un Payment Mandate.
• La version 0.2 (avril 2026) utilise un Checkout Mandate, qui sécurise ce qui est acheté, et un Payment Mandate lié, qui sécurise le paiement. Chacun existe sous une forme ouverte, qui contient les contraintes de l'utilisateur avant que le panier soit définitif, et sous une forme fermée, liée à un checkout finalisé. Les mandats sont des justificatifs signés à divulgation sélective, de sorte que chaque partie ne voit que ce dont elle a besoin.

AP2 définit cinq rôles (agent d'achat, fournisseur d'identifiants, marchand, processeur de paiement du marchand et une interface de confiance où l'utilisateur donne son consentement) et deux modes. Dans les achats « human present », l'utilisateur approuve le panier final. Dans les achats « human not present », principal ajout de la v0.2, l'utilisateur signe des contraintes à l'avance et l'agent réalise un achat qui les respecte.

AP2 laisse délibérément les API de catalogue et de checkout hors de son champ. Il est conçu pour fonctionner avec UCP : lorsqu'il est utilisé avec UCP, le checkout signé par le marchand à l'intérieur d'un Checkout Mandate doit être l'objet checkout d'UCP. Son type d'article ne contient qu'un id (décrit comme étant souvent le SKU), un title, un price et une URL d'image facultative.

Quelle place pour Visa et Mastercard ?

Les deux réseaux de cartes ont des programmes qui se placent à côté de ces protocoles plutôt que de les remplacer. Ils traitent de l'identité des agents et des identifiants de paiement, pas des données produit.

• Visa Trusted Agent Protocol (14 octobre 2025, développé avec Cloudflare) permet à un agent approuvé de signer ses requêtes à un marchand, afin que celui-ci puisse distinguer un agent d'achat légitime d'un bot malveillant. Il peut transporter l'intention de l'agent, la reconnaissance du consommateur et, en option, des informations de paiement, et il est publié sur le Visa Developer Center et sur GitHub.
• Mastercard Agent Pay (29 avril 2025) a introduit les Agentic Tokens et exige que les agents soient enregistrés et vérifiés avant d'effectuer des transactions. Verifiable Intent, présenté par Mastercard et Google le 5 mars 2026, est une spécification ouverte pour un enregistrement infalsifiable de ce qu'un utilisateur a autorisé, aligné sur AP2 et UCP. L'annonce de Google d'avril 2026 indique que Verifiable Intent fait également l'objet d'un don à la FIDO Alliance.

Un marchand y accède généralement par l'intermédiaire de son prestataire de paiement, et ces programmes ne changent rien à ce que votre catalogue doit contenir.

Comment se comparent ACP, UCP et AP2 ?

Où se situe l'identité du produit, et sur quoi les protocoles restent-ils muets ?

Lues côte à côte, les trois spécifications identifient un produit au checkout par un identifiant choisi par le marchand. ACP utilise l'identifiant de variante du flux, UCP utilise son identifiant de variante, et les mandats d'AP2 listent les identifiants d'article acceptables fournis par le marchand. C'est raisonnable pour finaliser une commande auprès d'une seule boutique. C'est aussi le point faible décrit par Paula Rivero lors de l'atelier W3C/GS1 à Zurich : un agent peut dérouler le checkout sans faute et quand même acheter le mauvais produit, car l'identifiant interne d'un marchand ne dit rien, en dehors de cette boutique, du produit physique dont il s'agit.

Le GTIN est le champ qui franchit cette frontière. ACP et UCP prévoient tous deux un emplacement pour lui, et la spécification de flux d'OpenAI vérifie sa clé de contrôle. Aucun des trois protocoles ne le rend obligatoire, aucun n'explique comment un agent doit comparer un même GTIN d'un marchand à l'autre, et aucun ne mentionne GS1 Digital Link, le passeport numérique de produit ou tout autre moyen de relier un produit à des informations provenant de la marque elle-même.

Notre lecture de la façon dont ils s'articulent, qui n'est énoncée dans aucune des spécifications :

• Le GTIN du flux est le pont entre les marchands. Si deux boutiques vendent le même shampooing avec le même GTIN, un agent peut les reconnaître comme le même produit et comparer les offres au lieu de deviner à partir des titres. Si le GTIN manque, l'agent se rabat sur la correspondance des noms.
• Un mandat AP2 ouvert n'est pas plus précis que ses identifiants d'article. Un utilisateur qui autorise « recommander exactement ce produit » autorise, dans la v0.2, une liste d'identifiants d'article du marchand. C'est un GTIN derrière ces identifiants qui donne à l'instruction le même sens dans une deuxième boutique.
• GS1 Digital Link est l'endroit où se trouve la version de la marque. Une URI GS1 Digital Link est construite à partir du même GTIN, de sorte qu'un agent qui dispose déjà du GTIN peut la construire et la résoudre vers des informations contrôlées par la marque : caractéristiques, notices, informations de sécurité et, dans l'UE, données du passeport. Aucun des protocoles n'oblige un agent à le faire. Rien en eux ne l'en empêche non plus.

Là où un QR code n'aide pas : il ne joue aucun rôle dans le checkout, le paiement ou les mandats, et un flux conforme aux protocoles n'en a pas besoin. Sa valeur ici tient à l'identifiant qui se trouve derrière.

Que doivent faire les marques et les importateurs dès maintenant ?

Les protocoles continueront d'évoluer ; le travail sur le catalogue ne dépend pas de celui qui l'emportera.

1. Assurez-vous que chaque produit qui a un GTIN le porte dans vos propres systèmes, dans votre flux Google Merchant Center et dans tout flux ACP, et que la clé de contrôle est valide. N'inventez pas d'identifiants pour les produits qui n'en ont pas.
2. Conservez un identifiant stable par variante, et vérifiez que l'identifiant de votre flux est celui qu'accepte votre checkout. ACP comme UCP en dépendent.
3. Établissez une correspondance explicite entre GTIN et identifiant de variante. Un GTIN doit pointer vers une seule variante vendable de votre catalogue, conditionnement et formulation compris.
4. Envoyez les champs que les agents utilisent pour choisir : titre, description, marque, prix, disponibilité, images et une URL canonique du produit. Dans ACP et UCP, c'est ce qu'un agent voit avant le checkout.
5. Tenez à jour les prix et les stocks. Les deux spécifications traitent le flux comme informatif et le checkout comme faisant foi, de sorte qu'un flux périmé envoie les agents vers des checkouts qui échouent.
6. Demandez à votre prestataire de paiement quels flux agentiques il prend en charge : Shared Payment Token de Stripe pour ACP, gestionnaires de paiement UCP, mandats AP2, programmes d'agents de Visa et de Mastercard. Vous les implémentez rarement vous-même.
7. Donnez au GTIN une adresse résolvable. Un résolveur GS1 Digital Link sous votre propre domaine permet à n'importe quel agent, sur n'importe quel protocole, de vérifier le produit par rapport à vos propres données. C'est aussi la voie sur laquelle s'appuiera le passeport numérique de produit de l'UE.

Digital Link est partenaire de solutions GS1, et notre plateforme attribue à chaque produit un GS1 Digital Link construit sur son GTIN, avec des pages contrôlées par la marque et des données structurées lisibles par les personnes comme par les machines. Pour le commerce agentique, c'est la couche d'identité que les protocoles laissent ouverte : un identifiant par produit qui renvoie vers vos données, quel que soit l'agent ou le protocole qui interroge. Si vous voulez vérifier à quel point votre catalogue est prêt pour les achats menés par des agents, contactez-nous et notre équipe examinera vos données produit avec vous.

Questions fréquentes

Quelle est la différence entre ACP et AP2 ?

ACP est un protocole de commerce : il normalise le flux produit, la session de checkout et un jeton de paiement délégué entre un agent IA et un marchand. AP2 est un protocole de confiance pour les paiements : il normalise des mandats signés qui prouvent ce qu'un utilisateur a autorisé, et laisse le catalogue et le checkout à d'autres protocoles. La spécification AP2 désigne UCP comme le protocole de commerce avec lequel il est conçu pour fonctionner.

ACP est-il la même chose qu'Instant Checkout dans ChatGPT ?

Non. Instant Checkout était le produit d'OpenAI construit sur ACP. En mars 2026, OpenAI a abandonné Instant Checkout en tant que produit autonome pour que les marchands puissent utiliser leur propre checkout, et a étendu ACP pour transporter des flux de produits et de promotions destinés à la découverte dans ChatGPT. La spécification ACP elle-même reste ouverte et en version bêta.

Les protocoles de commerce agentique exigent-ils un GTIN ?

Non. ACP et UCP proposent tous deux un champ de code-barres facultatif qui accepte un GTIN, et la spécification de flux ChatGPT d'OpenAI indique gtin comme facultatif. Google Merchant Center recommande un GTIN pour chaque produit qui en possède un et peut refuser les produits dont le GTIN attribué est manquant.

L'un de ces protocoles utilise-t-il GS1 Digital Link ?

Pas en octobre 2026. Aucune des spécifications ACP, UCP ou AP2 ne mentionne GS1 Digital Link. Comme une URI GS1 Digital Link est construite à partir du GTIN, tout agent qui reçoit un GTIN via ces protocoles peut la résoudre, mais il s'agit de notre lecture de la façon dont ils se combinent, pas d'une exigence des protocoles.

À qui appartient AP2 aujourd'hui ?

Google a créé AP2 et a annoncé en faire don à la FIDO Alliance le 28 avril 2026, en même temps que la publication de la version 0.2. La spécification et le SDK restent publics sur GitHub, et la suite de la normalisation se déroule au sein des groupes de travail de FIDO.

Les marchands de l'UE peuvent-ils utiliser ces protocoles ?

Les spécifications sont ouvertes et peuvent être implémentées partout. Les premiers produits grand public construits sur elles ont été lancés aux États-Unis, et les plateformes décident pays par pays où les marchands peuvent participer ; vérifiez donc l'éligibilité actuelle de chaque plateforme avant de compter dessus.