UCP Google (Universal Commerce Protocol) : les données dont tu as besoin

Le Universal Commerce Protocol (UCP) de Google est un standard open source qui permet aux agents d'AI, aux plateformes de shopping, aux distributeurs et aux prestataires de paiement de gérer un achat dans un format commun : trouver des produits, constituer un panier, passer commande, associer le compte d'un acheteur et suivre la commande. Google l'a annoncé le 11 janvier 2026, co-développé avec Shopify, Etsy, Wayfair, Target et Walmart et soutenu par plus de 20 entreprises, dont Visa, Mastercard, Stripe, Adyen, Best Buy et Zalando. Au lieu de construire une intégration distincte pour chaque surface d'AI, une entreprise publie une seule fois ce qu'elle prend en charge, et n'importe quel agent compatible UCP peut l'utiliser.

La première mise en œuvre de Google est le checkout dans AI Mode de la recherche et dans l'app Gemini, où le distributeur reste le vendeur officiel (merchant of record). Pour y participer, un marchand a besoin d'un compte Merchant Center avec des produits approuvés, des paramètres de retour et d'assistance, un indicateur d'éligibilité au checkout sur chaque produit et des données produit propres : ID stables, variantes avec leurs options, codes-barres, prix, disponibilité et catégories. Cet article explique ce qu'est UCP, son lien avec ACP, AP2 et MCP, et précisément sur quels champs produit il s'appuie. Notre article précédent sur l'Universal Cart de Google couvre le côté acheteur et l'enjeu stratégique ; celui-ci est la checklist technique et données.

Chronologie UCP Google : de l'annonce de janvier à la spec d'août 2026

UCP a évolué rapidement au cours de ses neuf premiers mois. Les étapes qui comptent pour les marchands :

Le protocole est versionné par date : un agent et une entreprise s'accordent donc sur une version au moment de la connexion. Attends-toi à ce que ta plateforme ou ton prestataire de paiement gère l'essentiel de cette négociation pour toi.

Comment fonctionne UCP : le profil /.well-known/ucp, les capacités et les transports

Une entreprise publie un profil JSON à l'adresse /.well-known/ucp sur son propre domaine. Le profil liste les versions du protocole qu'elle prend en charge, ses endpoints de service, les capacités qu'elle propose et sa configuration de paiement. Un agent lit d'abord ce fichier et sait alors ce qu'il peut faire avec cette boutique, sans intégration codée en dur. La présentation technique pour développeurs de Google montre l'échange complet, de la lecture du profil à l'application d'un code de réduction au checkout.

• Les capacités sont les briques de base : checkout, panier, catalogue, association d'identité et gestion des commandes. Une entreprise choisit celles qu'elle prend en charge.
• Les extensions ajoutent des fonctions à une capacité. Les réductions, par exemple, étendent le checkout et le panier.
• Les transports : une même capacité peut être exposée sous forme d'API REST, via un binding MCP ou via Agent2Agent (A2A). Une capacité de checkout, par exemple, peut avoir un binding REST ou un binding MCP selon la stack de l'entreprise.
• Les paiements séparent l'instrument (ce avec quoi l'acheteur paie, comme Google Pay) du handler (le processeur qui encaisse le paiement), pour qu'UCP puisse fonctionner avec les prestataires de paiement que les marchands utilisent déjà. UCP est compatible avec AP2 pour prouver que l'acheteur a autorisé l'achat.
• Vendeur officiel : le distributeur reste le vendeur officiel (merchant of record) et conserve sa propre logique métier.

Pour les surfaces de Google, un marchand peut utiliser le checkout natif, construit sur sa propre API de checkout, ou une option intégrée qui conserve une expérience de checkout entièrement personnalisée à l'intérieur de l'agent.

UCP, ACP, AP2 et MCP : quel protocole fait quoi

Quatre acronymes apparaissent dans chaque article sur le commerce agentique. Ils agissent à des couches différentes, et seuls deux d'entre eux sont en concurrence :

ACP et UCP se recoupent surtout au checkout : l'un alimente l'achat dans ChatGPT, l'autre dans les surfaces de Google, et Stripe, qui a co-développé ACP, a annoncé en mars 2026 qu'il mettrait aussi en œuvre UCP. Un marchand ne choisit pas l'un pour toujours. Ce que les deux exigent, c'est la même matière première : un catalogue produit qu'une machine peut lire sans deviner. Si ton feed fonctionne pour l'un, l'essentiel du travail pour l'autre est déjà fait. Notre entrée du dictionnaire e-commerce sur le commerce agentique explique l'évolution plus large.

Les champs produit que transporte une réponse catalogue UCP

La capacité catalogue d'UCP définit à quoi ressemble un produit quand un agent le demande. Les schémas de la version 2026-08-25 forment une checklist pratique, car chaque champ obligatoire doit provenir de tes données produit et chaque champ optionnel est une occasion de répondre à la question de l'acheteur.

Niveau produit. Obligatoires : id, title, description, price_range et variants. Optionnels : handle, url canonique, categories avec un identifiant de taxonomie, list_price_range pour les prix barrés, media (images, vidéo, 3D ; le premier élément est celui mis en avant), options comme Size et Color, rating, tags et métadonnées définies par l'entreprise.

Niveau variante. Obligatoires : id, title (par exemple « Blue / Large »), description et price. Optionnels : sku, barcodes (de type UPC, EAN, ISBN, GTIN ou JAN), list_price, unit_price pour la comparaison au kilo ou au litre, availability avec un statut in_stock, backorder, preorder, out_of_stock ou discontinued, les options qui définissent la variante, ses propres médias, catégories et vendeur.

Deux détails passent facilement inaperçus. Les descriptions peuvent être envoyées en texte brut, en HTML ou en Markdown, et la spec demande aux plateformes d'assainir le HTML : une description propre en texte brut est donc la version la plus sûre à maintenir. Et les catégories portent un nom de taxonomie : google_product_category, shopify ou merchant. Si tes produits sont déjà associés à la taxonomie produit Google pour Shopping, tu peux transmettre cet ID tel quel.

Exemple concret : une chaussure de randonnée en termes UCP

Prends une chaussure de randonnée imperméable à tige mi-haute fictive, vendue en quatre pointures et deux couleurs. Voici ce que chaque champ UCP attend du catalogue :

• ID et titre du produit : un ID stable qui ne change jamais quand le produit est renommé ; titre « Trailmark Ridge Mid GTX Hiking Boot, Men's ».
• Description : une version en texte brut sans HTML, qui indique à quoi sert la chaussure, la membrane, la semelle et l'ajustement.
• Catégories : catégorie de produits Google 187 (Apparel & Accessories > Shoes) avec la taxonomie google_product_category, plus ton propre chemin de catégorie avec la taxonomie merchant.
• Options : Color (Slate, Olive) et Size (EU 42, 43, 44, 45).
• Variantes : huit au total, chacune avec son propre ID, son SKU (TRM-RDG-SLT-43), un code-barres EAN de type EAN, un price et un list_price en EUR, un statut de disponibilité et les valeurs Color et Size. Le titre de la variante suit les valeurs d'options : « Slate / EU 43 ».
• Médias : une image mise en avant par couleur, puis des photos de la semelle et des détails.
• Métadonnées : les informations que les champs standard ne contiennent pas, comme la membrane, le poids par chaussure en grammes et la largeur de forme, issues de ton jeu d'attributs.

Chaque lacune de cette liste se traduit par une réponse plus faible. Une variante sans code-barres est plus difficile à rapprocher entre vendeurs ; une variante sans statut de disponibilité ne peut pas être achetée en confiance ; un produit sans options ne peut pas être filtré par pointure. Vérifie tes identifiants avec notre guide GTIN, UPC et EAN si les types de codes-barres de ton catalogue sont mélangés.

Paramètres Merchant Center et attributs de feed pour le checkout sur Google

Pour la mise en œuvre de Google, le guide de préparation Merchant Center liste ce qui doit être en place avant de construire la partie API :

1. Un compte Merchant Center en règle avec des produits approuvés pour les fiches gratuites.
2. Des politiques de retour avec le coût du retour, le délai de retour et un lien vers la politique complète, définies dans les paramètres de retour du compte ou par produit avec l'attribut returns (return_policy_label limite une politique à un sous-ensemble de produits). Les comptes avancés la configurent par sous-compte. La politique s'affiche sur l'écran de checkout.
3. Des informations d'assistance client définies dans Merchant Center, utilisées pour le lien Contact Merchant sur la page de confirmation de commande.
4. native_commerce (checkout_eligibility) : une valeur true ou false par produit. Une valeur absente signifie non éligible : chaque produit que tu veux vendre via le checkout agentique doit donc la porter explicitement.
5. consumer_notice : obligatoire pour les produits soumis à des avertissements réglementaires, avec un notice_type legal_disclaimer, safety_warning ou prop_65 et un notice_message de 1 000 caractères au maximum.
6. ID produit concordants : l'id de ton feed doit correspondre à l'ID qu'attend ton API de checkout ; sinon, l'attribut merchant_item_id les associe et prévaut.

Google recommande d'envoyer ces attributs via une source de données supplémentaire plutôt que de modifier le feed principal, pour qu'une erreur de format ne casse pas l'ingestion habituelle des produits. Certains produits sont inéligibles quel que soit l'indicateur : abonnements et paiements échelonnés, produits personnalisés, articles d'occasion, reconditionnés et vendus sans retour possible, précommandes, produits nécessitant un transport de fret ou une autre livraison spéciale, articles soumis à une limite d'âge, services et locations. Mets native_commerce à false pour ceux-là.

Notre guide du feed Google Shopping couvre les attributs du feed principal qui doivent être corrects avant que tout cela s'applique.

Attributs conversationnels : question_and_answer et related_product

En parallèle d'UCP, Google a annoncé de nouveaux champs Merchant Center optionnels pour les surfaces conversationnelles comme AI Mode, Gemini et Business Agent. La présentation des attributs conversationnels en liste six :

• question_and_answer : des paires de FAQ sur le produit. Google précise que tu n'as pas besoin de répéter les détails déjà envoyés dans les attributs description, product highlight ou product detail.
• related_product : des liens vers des accessoires, des pièces nécessaires ou des articles souvent achetés ensemble, avec les sous-attributs relationship_type, identifier_type et identifier.
• document_link : des PDF comme des manuels et des fiches techniques.
• item_group_title et variant_option : un titre pour la famille de produits et les paires nom-valeur (Size: 43, Color: Slate) qui définissent chaque variante, utilisés avec item_group_id.
• popularity_rank : la popularité d'un produit, sous forme de classement en pourcentage au sein de ton inventaire total.

Ces champs ne modifient pas le statut d'approbation des produits existants, et ils s'intègrent naturellement à côté des données UCP : variant_option reflète les options de variantes UCP, related_product reflète les liens de ventes croisées et d'accessoires que beaucoup de catalogues gèrent déjà, et question_and_answer donne à un agent les réponses qu'il essaierait sinon d'extraire d'un paragraphe marketing.

Neuf corrections de catalogue à faire avant que le checkout UCP arrive sur ton marché

L'essentiel du travail d'intégration UCP revient à ta plateforme, à tes développeurs ou à ton prestataire de paiement. Le travail sur les données revient à la personne responsable du catalogue, et il peut commencer dès maintenant :

Le checkout UCP a été lancé aux États-Unis, avec le Canada et l'Australie ensuite et le Royaume-Uni plus tard : les marchands aux Pays-Bas et dans le reste de l'Europe ont donc du temps. Ce temps est mieux investi dans cette liste, car les mêmes champs améliorent aussi dès aujourd'hui les fiches Shopping, les feeds marketplace et les réponses de l'AI. Si tu réfléchis plus largement à ce que tu exposes aux agents d'AI, notre article sur llms.txt pour l'e-commerce couvre le côté fichier d'index et explique pourquoi il compte moins que les données.

WISEPIM gère la couche catalogue dont dépend cette checklist : l'AI complète les attributs, descriptions et catégories Google manquants, Quality Guard vérifie les produits par rapport aux règles des canaux, et la connexion Google Merchant Center envoie le résultat. Les équipes qui construisent leurs propres intégrations d'agents peuvent lire les données produit via l'API publique de WISEPIM avec le plan Pro. La page de la fonctionnalité commerce agentique montre comment les éléments s'articulent.