Un acheteur demande un produit dans AI Mode de Google, l’agent le trouve dans votre catalogue, et l’achat a lieu sans que l’acheteur charge jamais votre site. C’est l’Universal Commerce Protocol (UCP) qui permet à l’agent de le faire, et cela ne fonctionne que si votre boutique répond correctement au moment où l’agent l’interroge. Que doit publier votre boutique ? Quels produits un agent peut-il acheter ? Que vérifie Google avant de vous laisser passer en ligne ? Dans le travail sur UCP que nous avons mené, la page produit en savait chaque fois plus que le flux, et un endpoint construit à partir du seul flux donnerait aux agents moins d’éléments que ce qu’un acheteur voit sur la page.
UCP est un standard ouvert, et votre boutique publie ce qu’elle prend en charge
UCP a été développé par Google avec Shopify, Etsy, Wayfair, Target et Walmart, et sa spécification se trouve sur ucp.dev. Votre boutique est le marchand officiel (merchant of record) : vous gardez le client, la commande et la responsabilité du paiement, et l’agent agit pour le compte de l’acheteur.
Tout commence par un profil que votre boutique publie à /.well-known/ucp. Il indique la version du protocole, les services que vous proposez et comment les joindre, vos gestionnaires de paiement et les clés publiques qu’un agent utilise pour vérifier vos messages signés. Un agent le lit avant de faire quoi que ce soit d’autre.
| Ce que vous publiez | Ce que cela fait | Requis pour le checkout Google |
|---|---|---|
Profil UCP à /.well-known/ucp |
Déclare votre version, vos services, vos gestionnaires de paiement et vos clés de signature | Oui |
| Checkout | Crée, met à jour et finalise une session de checkout | Oui, sur le parcours de checkout natif |
| Gestionnaire de paiement Google Pay | Permet à l’agent de payer avec un token Google Pay que votre processeur accepte | Oui, sur le parcours de checkout natif |
| Cycle de vie de la commande | Envoie des mises à jour de commande signées après l’achat, comme expédiée et livrée | Oui, sur le parcours de checkout natif |
| Panier | Transmet un panier constitué sur Google à votre propre site pour finaliser l’achat | L’alternative au checkout natif |
| Liaison d’identité | Lie le compte d’un acheteur avec OAuth 2.0 au lieu d’un checkout invité | Facultatif |
| Remises | Applique des codes promo pendant le checkout | Facultatif |
| Recherche et consultation du catalogue | Permet à un agent d’interroger directement les produits | Facultatif dans la spécification |
Les versions d’UCP sont des dates. La spécification la plus récente en octobre 2026 est 2026-08-25, et les guides d’implémentation de Google utilisent 2026-04-08. Une boutique peut servir REST, MCP, A2A ou un checkout intégré, et REST est le mode principal.
Étape 1 : Corrigez les données produit erronées
Google lit un flux selon un calendrier, mais un agent appelle un endpoint UCP en temps réel, donc toute erreur dans vos données atteint l’acheteur au moment de l’achat, sans personne pour la repérer. Nous corrigeons les données erronées avant d’ajouter quoi que ce soit, et ces corrections portent leurs fruits dans Merchant Center, que UCP soit un jour déployé ou non.
| Problème | Pourquoi c’est important pour un agent |
|---|---|
| Deux produits différents qui partagent un même GTIN, comme un appareil neuf et sa version reconditionnée | L’agent ne peut pas savoir lequel il achète |
| Un SKU copié dans le champ GTIN, ou un GTIN avec une longueur ou une clé de contrôle erronée | Le produit ne peut pas être rattaché à la fiche de son fabricant |
| Un prix soldé égal au prix normal | Il masque le vrai prix catalogue, donc la remise que voit l’acheteur est fausse |
| Des liens produits qui redirigent | Le lien de l’agent et votre checkout ne s’accordent pas sur l’adresse du produit |
| Des champs de stock qui se contredisent | L’agent propose quelque chose qui ne peut pas être expédié |
Conservez les GTIN au format texte de bout en bout. Un système qui les traite comme des nombres supprime les zéros initiaux, et le GTIN ne correspond plus. Vérifiez chacun d’eux par rapport à la fiche GS1 du fabricant plutôt que de le compléter jusqu’à ce qu’il passe.
Étape 2 : Ajoutez les données dont un agent a besoin pour finaliser un achat
Les pages produits contiennent généralement plus que le flux : la galerie d’images complète, la marque, les avis, le vrai prix catalogue et les conditions de livraison. Un agent ne voit que ce que vous lui envoyez.
- Descriptions détaillées. Placez la principale différence du produit en premier, car un agent peut n’en citer que le début. Énoncez clairement les contraintes, comme les limites de poids, les besoins en alimentation électrique et les destinations de livraison, et donnez les mesures dans les deux systèmes d’unités.
- Variantes séparées. Un produit parent dont les tailles ou les couleurs sont regroupées sur une seule ligne doit devenir une ligne par variante, regroupées avec
item_group_id. - Livraison, retours et garantie sous forme de données, pas seulement sous forme de paragraphes sur une page de politique.
- Toutes les images que montre la page. Un flux qui ne contient que la première laisse à l’agent moins que ce que voit l’acheteur.
- Niveaux de stock en temps réel au lieu d’un indicateur en stock ou en rupture. Google exige une vérification du stock en temps réel au checkout, et une erreur
out_of_stockquand l’article est épuisé.
Merchant Center limite une description à 5,000 caractères et n’y veut pas de détails promotionnels comme les prix ou les offres de livraison, alors qu’une description UCP peut inclure la livraison, la garantie et les contraintes. Rédigez la version complète pour UCP et réduisez-la pour le flux.
Dans UCP, les prix sont des nombres entiers dans la plus petite unité de la devise, donc $129.99 est envoyé sous la forme 12999. Une erreur d’unité fausse le prix du produit d’un facteur cent, dans un sens ou dans l’autre, donc vérifiez-la avant toute mise en ligne.
Étape 3 : Décidez quels produits un agent peut acheter
Les consignes Merchant Center de Google excluent des catégories entières du checkout par agent, parmi lesquelles :
- les abonnements et les plans de paiement échelonné ou de financement ;
- les produits personnalisés, les articles reconditionnés, d’occasion et en vente finale, et les précommandes ;
- les services groupés comme l’installation ou les extensions de garantie, le fret et la livraison premium, et l’activation en magasin ;
- les produits soumis à une restriction d’âge et les produits interdits, les services, les locations et les articles virtuels.
Laissez-les de côté, et activez le reste produit par produit.
Un produit à prix élevé que beaucoup d’acheteurs achètent avec un plan de financement peut moins bien se vendre via un checkout par portefeuille numérique qui ne propose pas ce plan. Mesurez combien de commandes de ce produit utilisent un financement avant d’activer le checkout par agent pour lui. Une boutique peut aussi publier son catalogue pour les agents et garder le checkout sur son propre site, ce qui est une configuration UCP légitime et souvent la bonne première phase.
Étape 4 : Préparez Merchant Center
Le guide d’implémentation de Google commence par Merchant Center : le compte doit être en règle, avec des produits approuvés pour les fiches gratuites.
- Politique de retour. Définissez le coût du retour, le délai de retour et un lien vers la politique complète, au niveau du compte ou par produit avec l’attribut
returns. Google l’affiche sur l’écran du checkout. - Service client. Ajoutez au moins un moyen de contact : une page d’assistance, une adresse e-mail ou un numéro de téléphone. Il alimente le lien “Contact Merchant” de la confirmation de commande.
- Activez les produits. Réglez
native_commerce(checkout_eligibility)surTRUEpour chaque produit éligible. Google recommande une source de données supplémentaire, afin que l’activation ne perturbe pas votre flux principal. - Mentions réglementaires. Les produits qui portent un avertissement juridique, une consigne de sécurité ou un avertissement Proposition 65 ont besoin d’un
consumer_notice, avec son type et un message de 1,000 caractères au maximum. - ID correspondants. L’
iddu flux doit correspondre à l’ID produit qu’attend votre checkout. Lorsqu’ils diffèrent, envoyezmerchant_item_id.
Étape 5 : Inscrivez-vous sur la liste d’attente de Google
Google indique qu’une intégration “doit être approuvée par Google avant que vous puissiez passer en ligne” dans AI Mode et Gemini. La porte d’entrée est le formulaire d’intérêt pour l’intégration UCP dans l’aide Merchant Center, qui inscrit votre boutique sur la liste d’attente. Le checkout intégré, dans lequel votre propre checkout s’exécute au sein de l’interface de Google, est réservé aux marchands approuvés. Envoyez le formulaire pendant que vous construisez, car l’approbation est l’étape que vous ne pouvez pas accélérer vous-même.
Étape 6 : Construisez le profil et les endpoints
Une boutique utilise soit la prise en charge d’UCP intégrée à sa plateforme de commerce, soit la construit elle-même. Quand nous construisons, nous plaçons devant la boutique un service léger qui parle UCP aux agents et l’API propre de la plateforme à la boutique, monté sous le domaine de la boutique pour que le profil et les endpoints partagent une même origine. UCP est révisé souvent, et le garder hors de la plateforme permet à une nouvelle version de ne pas attendre une mise à jour de la plateforme.
- Ne publiez que ce qui fonctionne. Un agent qui trouve le checkout dans votre profil essaiera de l’utiliser. Une première version peut n’annoncer que la recherche et la consultation du catalogue, et ajouter le checkout quand il est prêt.
- Utilisez de vraies clés de signature. Les clés publiques du profil vérifient vos mises à jour de commande signées, donc générez une paire de clés et gardez la moitié privée sur le serveur.
- Sécurisez les nouvelles tentatives. Acceptez une clé d’idempotence sur les appels de checkout, pour qu’une requête répétée ne débite pas deux fois.
- Servez-le en HTTPS. La spécification REST exige au minimum TLS 1.3.
- Validez les adresses. Renvoyez une adresse non livrable sous forme d’erreur récupérable, pour que l’acheteur puisse la corriger au lieu de se retrouver dans une impasse.
- Liez vos politiques. Vos conditions s’appliquent à chaque achat UCP, donc incluez dans la réponse du checkout des liens vers vos politiques de confidentialité, vos conditions générales, vos politiques de remboursement et de livraison.
Étape 7 : Connectez les paiements
Sur le parcours de checkout natif de Google, votre profil déclare le gestionnaire de paiement Google Pay. Vous n’avez pas besoin de l’API Google Pay sur votre propre site, mais votre processeur de paiement doit accepter les tokens de paiement de Google, et la plupart des grands processeurs le font. La FAQ de Google précise que ses interfaces IA n’utilisent que la méthode d’autorisation PAN_ONLY et que les paramètres Google Pay du profil utilisent des noms en snake_case. Séparez les identifiants de test et de production du processeur, et ne les journalisez jamais.
Étape 8 : Testez comme le fera Google
Google envoie des contrôles de santé avec le user agent Google-UCP-Prober/1.0, et marque les requêtes d’agents avec un en-tête UCP-Agent et un user agent qui commence par Google/UCP. Avant de postuler, interrogez vos propres endpoints comme le ferait Google.
/.well-known/ucpatteint-il votre boutique ? Une règle du serveur web peut répondre à ce chemin par sa propre erreur 404 avant même que la requête n’atteigne l’application, alors que vos endpoints UCP fonctionnent.- Votre pare-feu laisse-t-il passer Google ? Une protection anti-bots qui bloque le trafic automatisé bloquera aussi le prober, donc laissez passer les requêtes UCP de Google d’après leurs en-têtes plutôt que d’après leur adresse.
- Les endpoints protégés se comportent-ils correctement ? Les endpoints de checkout, de paiement et de commande doivent refuser les requêtes sans identifiants et accepter celles de Google.
Étape 9 : Préparez la prochaine version d’UCP
La spécification 2026-08-25 ajoute des politiques standard de retour et de garantie que 2026-04-08 n’a pas, et Google documente 2026-04-08. Tant que les guides de Google n’adoptent pas une version plus récente, c’est votre politique de retour Merchant Center qui porte ces informations. Quand vous adoptez une nouvelle version, Google recommande de la servir depuis un endpoint distinct, afin de pouvoir renvoyer le trafic vers l’ancien si quelque chose ne fonctionne plus.
WISLR configure UCP pour les marques et pour les clients des agences
Chacune des étapes ci-dessus fait partie du service Agentic Commerce Optimization de WISLR. Nous auditons le catalogue au regard des exigences de Google, corrigeons et complétons les données produit, préparons Merchant Center et le flux d’activation, puis construisons et testons le profil UCP et les endpoints jusqu’à ce que l’intégration soit prête pour l’approbation de Google. Les marques font appel à nous directement, et les agences font appel à nous sous leur propre nom pour le mettre en place pour leurs clients. Découvrez comment nous configurons UCP et demandez une évaluation de votre catalogue.