ACP et UCP quand le commerce agentique transforme la découverte produit en achat réel
Tu demandes à ChatGPT une valise cabine pour un vol low-cost en mai. Il t'en propose trois, explique pourquoi chacune correspond à tes critères, te dit laquelle est la plus légère. Puis il finalise l'achat — sans te rediriger vers un site, sans que tu saisisses ta carte, sans friction visible.
Ce n'est plus une projection. Le commerce agentique — cette bascule où l'IA devient acteur transactionnel et non plus simple conseiller — prend forme avec deux protocoles distincts : ACP côté ChatGPT (OpenAI), UCP côté Google. Deux approches parallèles, deux écosystèmes différents, un même objectif : aller jusqu'au bout de l'achat sans renvoyer l'utilisateur vers un site.
Pour les marchands, le commerce agentique va plus loin que l'apparence technique. Ce n'est pas une nouvelle API de paiement. C'est une nouvelle façon de distribuer ses produits, dans des espaces que l'on ne contrôle plus directement.
Votre checkout perd 70% de vos acheteurs potentiels. C'est la norme — et c'est optimisable.
Analyse du funnel d'achat + plan d'action pour réduire l'abandon panier.
ACP : rendre son catalogue compréhensible par ChatGPT
Commencer par le catalogue
L'Agent Commerce Protocol est une spécification initiée par OpenAI (annoncée en avril 2025), formalisée comme standard ouvert avec Stripe. À la base, c'est simple : un marchand expose ses données produit dans un format que ChatGPT peut lire, interroger et utiliser dans une conversation.
Ce format, c'est un feed produit — un fichier structuré qui contient les attributs de chaque article : titre, description, prix, disponibilité, catégorie, variants. Pas très différent de ce que vous envoyez déjà à Google Shopping ou Facebook Catalog. Sauf que l'exigence de complétude est plus haute. Un titre approximatif ou une description générique suffit pour passer un filtre d'indexation. Pour un agent IA, ça suffit rarement : le shopping agentique ne peut raisonner correctement que sur des données précises.
OpenAI a précisé un détail peu repris dans la presse : le feed est transmis quotidiennement pour les données de base, mais une API séparée est nécessaire pour les promotions et les variations de stock en temps réel. Ce n'est pas anodin. Un marchand qui veut que ChatGPT mentionne ses offres flash doit câbler une API — pas juste déposer un fichier.
Aller jusqu'au checkout
Une fois le catalogue ingéré, l'agent peut aller plus loin que la recommandation. ACP définit une séquence de checkout natif : l'agent crée un panier, collecte les informations de livraison, et finalise la commande sans jamais renvoyer l'utilisateur vers le site du marchand. La transaction se passe dans l'interface de ChatGPT.
Pour que ça fonctionne, le marchand doit exposer des endpoints REST conformes à la spec ACP — création de panier, mise à jour, confirmation de commande. Stripe fournit une implémentation de référence. D'autres PSP (payment service providers) peuvent s'y conformer s'ils adoptent le standard.
Ce que ça change pour un marchand
La différence fondamentale avec Google Shopping ou Amazon ? Vous ne participez plus à un catalogue passif qu'un moteur classe. Vous connectez vos données à un agent qui raisonne, filtre, compare et transacte de manière autonome. C'est le propre du commerce agentique : une distribution active, pas passive.
En pratique aujourd'hui : l'accès à ACP est restreint aux partenaires approuvés par OpenAI. Ce n'est pas un programme ouvert. Pour la majorité des marchands, l'étape réaliste est de préparer les données et l'infrastructure — en attendant une ouverture plus large.
UCP : le checkout natif sur les surfaces Google
Ce que Google promet
Le Universal Checkout Protocol s'inscrit dans l'écosystème Google Shopping et Google AI Mode — la version conversationnelle du moteur de recherche, alimentée par Gemini. Dans la vision Google du commerce agentique, l'utilisateur pose une question dans AI Mode, reçoit des recommandations produit enrichies, et peut acheter directement via Google Pay, sans visiter le site marchand.
Côté marchand, l'intégration passe par le Merchant Center — l'outil que la plupart des e-commerçants européens connaissent déjà pour Google Shopping. UCP s'appuie sur cette infrastructure existante plutôt que d'en imposer une nouvelle. C'est une décision intelligente : l'adoption sera plus rapide si les marchands n'ont pas à tout recommencer.
Le parcours d'implémentation concret
Shopify a documenté son implémentation d'UCP en détail dans sa documentation technique publiée en Q1 2026. Le flux repose sur une logique de négociation : le marchand déclare ses capacités (méthodes de paiement acceptées, options de livraison, personnalisation possible), l'agent Google déclare les siennes, et les deux systèmes s'accordent sur ce qu'il est possible d'exécuter dans ce contexte précis.
L'architecture change de fond en comble par rapport à une intégration classique. Avant, le marchand configurait une fois pour toutes. Avec UCP, chaque session est une mini-négociation. L'avantage concret : des cas complexes deviennent gérables — un panier multi-articles avec des règles de livraison différentes selon les références, par exemple.
En pratique, l'implémentation côté marchand passe par des extensions Shopify déjà disponibles, ou par un développement custom pour les plateformes hors Shopify.
Ce que ça dit sur le marché
Google a été explicite sur un point que beaucoup d'articles sur UCP ignorent : toutes les fonctionnalités annoncées ne sont pas encore disponibles. Certaines capacités sont en déploiement progressif, d'autres en roadmap. C'est une information que j'aurais préféré voir en gros titre dans la communication officielle, parce qu'elle distingue ce qui est actionnable maintenant de ce qui est prospectif.
Ma lecture : Google fait le bon choix en le disant clairement. Annoncer des fonctionnalités qui ne sont pas en production — comme l'a fait Amazon à plusieurs reprises avec Alexa Shopping — coûte de la confiance marchand. La transparence sur la roadmap UCP est un signal positif sur la maturité de l'approche.
Le checkout est l'étape la plus critique de votre funnel. Un point de friction = des ventes perdues.
Audit CRO de votre tunnel d'achat pour identifier et supprimer les blocages.
Le vrai tournant : le checkout devient une négociation entre systèmes
| Critère | ACP (OpenAI) | UCP (Google) |
|---|---|---|
| Surface principale | ChatGPT | AI Mode / Google Shopping |
| Infrastructure d'entrée | Feed produit + endpoints REST | Merchant Center |
| Standard | Open source (avec Stripe) | Propriétaire Google |
| Accès marchand | Partenaires approuvés seulement | Via Merchant Center (progressif) |
| Paiement natif | Dans ChatGPT | Google Pay |
| État en avril 2026 | Accès restreint | Déploiement partiel |
Pourquoi cette logique est nouvelle
La plupart des comparaisons entre ACP et UCP s'arrêtent à la surface : OpenAI versus Google, ChatGPT versus AI Mode. Mais le changement structurel est ailleurs — et il passe souvent sous le radar.
Dans le commerce en ligne classique, le marchand configure un tunnel de conversion et l'acheteur le parcourt. C'est un système fermé, défini unilatéralement par le marchand. Les intégrations de paiement (Stripe, Adyen, PayPal) s'insèrent dans ce tunnel, mais elles ne le redéfinissent pas.
ACP et UCP introduisent une logique radicalement différente : celle de la négociation de capacités entre deux systèmes autonomes. Dans le commerce agentique, le marchand ne configure plus un tunnel — il déclare ce qu'il sait faire. L'agent IA déclare ce dont il a besoin pour cette transaction précise. Et les deux systèmes s'accordent en temps réel sur le périmètre du possible.
Cette logique vient du monde des APIs enterprise et des protocoles de service discovery. Elle suppose que les deux parties peuvent évoluer indépendamment : un marchand peut ajouter une capacité (livraison express, retrait en magasin) sans que l'agent ne soit reprogrammé. L'agent, de son côté, peut gérer un nouveau type de panier sans que le marchand ne change quoi que ce soit. C'est la vraie rupture — pas la disparition de la page produit. La rupture, c'est que le checkout passe d'un flux défini unilatéralement à un protocole négocié dynamiquement.
Pourquoi cette logique est utile
Le commerce réel est complexe. Un panier qui mélange des articles soumis à des règles de transport différentes, des promotions avec des conditions, des options de personnalisation qui changent le prix — gérer ça dans un agent IA sans logique de négociation serait une catastrophe de cas particuliers.
La négociation de capacités permet à l'agent de savoir ce qu'il peut promettre dans chaque contexte. Si un marchand n'a pas activé la livraison express, l'agent ne la propose pas — il ne découvre pas l'erreur au moment de la confirmation. C'est de la gestion d'état distribuée appliquée au commerce agentique.
Le checkout devient programmable
L'expression "checkout programmable" résume ce qui se joue. Pendant vingt ans, le checkout était un formulaire que le marchand construisait. Il va devenir un protocole que les agents IA instancient à la volée, selon les règles exposées par le marchand.
Pour les équipes techniques des e-commerçants, c'est une invitation à repenser l'architecture backend — non plus en fonction des frontends (mobile, web, marketplace), mais en fonction des capacités exposables à n'importe quel agent IA.
Ce que les marchands doivent préparer dès maintenant
Trois chantiers ne dépendent d'aucun protocole spécifique — ils seront utiles quel que soit le standard qui s'impose :
- Qualité des données produit — attributs factuels complets, descriptions précises
- Architecture agent-ready — endpoints API propres, gestion des erreurs sémantiques
- Continuité entre autonomie et reprise en main — états d'escalade définis et testés
Revoir la qualité des données produit
Le premier chantier n'est pas technique. Il est éditorial. Les données produit de la plupart des catalogues e-commerce ont été optimisées pour des moteurs de matching — des algorithmes qui cherchent des correspondances entre mots-clés et requêtes.
Un agent IA raisonne différemment. Il interprète, compare, déduit. Un titre comme "Valise Samsonite S55 Black" donne peu à un moteur de recherche mais beaucoup à un agent — si ce titre est complété par des attributs précis :
- Poids exact (ex : 2,8 kg)
- Compatibilité compagnies aériennes (easyJet, Ryanair, Air France en cabine)
- Format de roues (4 roues spinner multidirectionnelles)
- Dimensions exactes en cm (55 × 40 × 20 cm)
La qualité des données produit va devenir un facteur de distribution dans le commerce agentique, pas seulement de conversion. Ce travail ne sera pas perdu quel que soit le protocole qui finit par s'imposer.
Préparer une architecture agent-ready
L'intégration ACP ou UCP suppose des endpoints API exposés — création de panier, vérification de stock, confirmation de commande, gestion des retours. Ce sont des capacités que Shopify, Magento et WooCommerce (via plugins) ont déjà en partie. Mais l'implémentation doit être propre, documentée et stable.
Un point souvent négligé : la gestion des états d'erreur. Un agent qui tente une commande et reçoit une erreur 500 non documentée ne sait pas quoi faire. Les endpoints exposés à des agents doivent gérer explicitement les cas d'échec — stock épuisé entre réservation et confirmation, adresse non livrée, moyen de paiement refusé — avec des codes d'erreur sémantiques, pas génériques.
Gérer la continuité entre autonomie et reprise en main
Shopify a documenté un aspect peu commenté mais structurant dans sa documentation UCP (Q1 2026) : les états d'escalade. L'idée est simple en surface — si l'agent ne peut pas compléter la transaction seul, il rend la main à l'utilisateur. Mais la mise en œuvre demande une vraie réflexion.
Quand est-ce que l'agent doit escalader ? Les cas évidents : une vérification d'âge obligatoire, un paiement refusé, un doute sur l'adresse. Les cas moins évidents : un utilisateur qui hésite entre deux produits et ne répond plus, un prix qui a changé entre la consultation et la confirmation, une promotion qui vient d'expirer.
Si l'escalade est mal gérée — un message générique, une redirection brutale, une perte du contexte de la conversation — l'expérience est pire que si l'agent n'avait jamais commencé. La continuité entre le moment où l'agent lâche et le moment où l'humain reprend doit être sans rupture : même panier, même contexte, même point d'avancement dans la commande. C'est un défi d'ingénierie et de design que très peu d'articles sur le commerce agentique mentionnent.
Les limites à ne pas masquer
Tout n'est pas encore disponible
Soyons directs : en avril 2026, le commerce agentique n'est pas encore en production générale. ACP est en accès restreint aux partenaires OpenAI approuvés. UCP est en déploiement progressif sur les surfaces Google, avec des fonctionnalités encore en roadmap que Google lui-même documente comme "à venir".
Le risque pour les marchands qui lisent les annonces sans filtre : investir dans une intégration pour une capacité qui n'existe pas encore. Le risque inverse : attendre que tout soit parfait avant de se préparer, et prendre du retard sur des compétiteurs qui auront fait le travail en amont.
Travaillez dès maintenant sur ce qui ne changera pas quel que soit le protocole : la qualité des données produit, la propreté des APIs backend, la gestion des erreurs. Ces trois chantiers seront utiles même si un troisième protocole émerge d'ici là.
L'ouverture est réelle, mais l'accès reste piloté par plateforme
ACP a été présenté comme un standard ouvert — et il l'est formellement. La spécification est publique, Stripe a contribué à sa rédaction, n'importe qui peut implémenter le protocole côté marchand. Mais l'accès à ChatGPT comme canal de distribution, lui, reste conditionnel à une approbation par OpenAI.
C'est la différence entre un protocole ouvert et un écosystème ouvert. Sur le web, si vous respectez les standards HTTP, n'importe quel navigateur peut vous atteindre. Sur ACP, même si vous respectez la spec, vous dépendez d'OpenAI pour être visible dans ChatGPT.
Google adopte une logique similaire avec UCP : le Merchant Center reste la porte d'entrée, et Google contrôle les règles de sélection des produits présentés dans AI Mode. Ce contrôle de plateforme existait déjà avec Google Shopping — il ne disparaît pas avec UCP, il change juste de niveau.
La confiance restera décisive
Un agent qui finalise un achat au nom d'un utilisateur porte une responsabilité nouvelle. L'utilisateur lui fait confiance pour choisir le bon produit, au bon prix, chez le bon marchand, avec la bonne politique de retour.
Cette confiance ne se transfère pas automatiquement. Elle se construit sur des données fiables (le catalogue est à jour), des pratiques claires (le marchand est identifié, la politique de retour est lisible), et une réputation de plateforme. OpenAI ou Google garantissent-ils quelque chose sur la qualité des marchands référencés dans leur agent IA ? La réponse à cette question reste ouverte — et elle déterminera en partie l'adoption côté consommateurs.
First party data, Consent Mode, tROAS — la gestion Google Ads 2026 demande une mise à niveau permanente.
Une méthode maintenue à jour avec les dernières évolutions de la plateforme.
Être agent-ready sera-t-il le prochain critère de sélection ?
Le prochain critère de sélection d'une plateforme e-commerce ne sera peut-être pas "qui a les meilleures fonctionnalités marketing" mais "qui expose ses capacités de façon exploitable par les agents IA". Dans le commerce agentique, être agent-ready va devenir un avantage concurrentiel — probablement d'ici deux ou trois ans, pas vingt.
Ce qui se joue avec ACP et UCP dépasse la transaction. C'est la question de savoir dans quels espaces un marchand est distributable. Pendant dix ans, la réponse était : web, mobile, marketplace. Elle s'élargit à : interfaces conversationnelles IA.
Préparer cette transition ne demande pas d'attendre que les protocoles soient en production générale. Ça demande de traiter les données produit comme une infrastructure, les APIs backend comme un service exposable, et le checkout comme un protocole — pas comme une page.