Google veut rendre vos promos achetables par des agents IA

La recherche « liens + site marchand » bascule vers l’achat piloté par des agents IA, capables de comparer et d’acheter à la place de l’internaute. Avec google, l’enjeu devient simple : être visible et achetable dans AI Mode et dans l’application Gemini.

La promesse est très concrète pour l’e-commerce et le marketing : rendre vos offres « lisibles et activables » par ces agents, via un protocole standard et des formats de remises intégrables.

Ce que google vient d’annoncer, et pourquoi le commerce change d’interface

Google a présenté le protocole universel de commerce (UCP), un standard open source destiné à permettre à des agents IA de découvrir des produits, construire un panier, gérer les contraintes, puis finaliser un achat. L’annonce s’inscrit dans un ensemble d’outils qui visent une chose : réduire la distance entre intention et paiement.

Dans les faits, trois briques se complètent :

• Le paiement dans AI Mode, pour acheter sans quitter l’interface de conversation, avec des champs préremplis via le portefeuille Google.
• L’agent de marque (Business Agent), qui fait apparaître un chat « au nom » du marchand directement dans Google, utile pour conseiller et rassurer.
• Les offres directes (Direct Offers), qui injectent une remise au moment où l’agent compare et arbitre.

Point clé pour les directions e-commerce : Google insiste sur le principe de vendeur responsable (seller of record). Cela signifie que le marchand reste juridiquement le vendeur, conserve la relation client et porte la responsabilité de la transaction.

Cette initiative vise large : e-commerçants, enseignes, places de marché, prestataires de paiement (PSP) et plateformes. Google cite notamment Shopify et Walmart parmi les partenaires de l’écosystème autour d’UCP, signe qu’on parle d’infrastructure, pas d’un simple format publicitaire ( TechCrunch, Shopify Engineering, message du PDG de Google ).

Comment un agent IA “lit” votre catalogue : la donnée produit devient une arme de conversion

Un agent n’est pas sensible à votre identité visuelle. Il valide des attributs : compatibilité, stock, prix, délais, retours, variantes. Si ces éléments sont incomplets ou incohérents, il hésite, propose un concurrent, ou renvoie l’utilisateur vers une étape manuelle.

En pratique, la base se joue dans Google Merchant Center (Merchant Center), qui alimente déjà la visibilité Shopping et sert de socle à ces expériences. Google annonce aussi l’arrivée de nombreux attributs orientés conversation dans Merchant Center, pour répondre à des questions « humaines » avec des données structurées ( Google Ads & Commerce, documentation UCP Merchant ).

Checklist côté flux produit, à traiter comme un chantier “qualité de service” : identifiant mondial d’article (GTIN), variantes propres, prix cohérents entre flux et page, stock quasi temps réel, images de qualité, URL stables. Google rappelle l’importance des identifiants produit, notamment le GTIN, pour la qualité de diffusion Shopping ( aide Merchant Center sur les identifiants ).

À court terme, la différence se fera sur les attributs conversationnels : compatibilités (ex. « fonctionne avec tel modèle »), questions fréquentes, accessoires recommandés, produits de remplacement si rupture, instructions d’entretien, conditions de livraison et de retour. Ce sont ces détails qui permettent à l’agent de conclure une recommandation sans repasser par un humain.

À faire tout de suite : lancer un audit de feed par familles (best-sellers d’abord), repérer les « trous » et corriger les incohérences prix/stock. Ensuite, industrialiser avec une règle simple : aucune variation (taille/couleur) sans attributs complets et sans stock fiable.

Choisir entre deux intégrations : aller vite, ou garder la main sur le passage en caisse

UCP ouvre deux chemins techniques principaux, qui ne se valent pas selon votre passage en caisse et votre maturité données.

Option A — Paiement natif (native checkout). Le principe : l’agent pilote le passage en caisse via des interfaces de programmation (API) standardisées, côté marchand. L’effort est souvent plus faible, et la mise sur le marché plus rapide, mais vous contrôlez moins l’interface affichée.

Option B — Paiement intégré (embedded checkout). Ici, l’agent bascule vers votre passage en caisse dans une fenêtre intégrée, via une URL de poursuite (continue_url) et un protocole de paiement intégré (ECP). Protocole de paiement intégré (ECP) désigne un canal d’échange structuré entre l’interface de l’agent et votre passage en caisse, pour éviter les abandons lorsque l’agent ne peut pas tout faire seul. C’est préférable si vous avez des parcours complexes, des contraintes réglementaires, ou une expérience de paiement très personnalisée ( guide Embedded checkout, Under the hood UCP ).

Règle de décision simple : plus votre passage en caisse est complexe (options de livraison, paiement fractionné, expéditions multiples, comptes, personnalisation), plus l’option intégrée est pertinente. Si l’objectif est de capter vite un nouveau canal, le paiement natif est souvent un bon point de départ.

Jalons projet réalistes : cadrage des cas d’usage et des risques, tests en environnement de simulation, mise en place des points d’entrée de paiement, vérification stock/prix en conditions réelles, puis pilote sur une catégorie limitée avant montée en charge.

Mettre vos remises au bon endroit : mode d’emploi des Direct Offers côté marketing

Les offres directes (Direct Offers) visent un moment précis : quand l’utilisateur hésite entre deux produits, et que l’agent est prêt à acheter. Au lieu d’une bannière, la remise apparaît comme un argument de décision dans AI Mode.

En pratique, la mise en place passe par Google Ads et Merchant Center : vous configurez l’offre, vous fournissez des codes promotionnels vérifiés, et Google choisit quand l’afficher selon le contexte de recherche et de comparaison ( présentation du test Direct Offers, détails côté Ads & commerce ).

Pour les équipes marketing, une séquence simple limite les mauvaises surprises : définir l’objectif (conversion, conquête, déstockage), fixer la mécanique (souvent un pourcentage au départ), écrire des conditions d’éligibilité sans ambiguïté, puis poser des garde-fous de marge, d’exclusions et de stock.

Trois cas d’usage concrets reviennent déjà chez les annonceurs :

• Conquête : offre « nouveaux clients » quand l’agent détecte un achat comparable chez un concurrent.
• Produits très substituables : remise courte pour gagner l’arbitrage quand les fiches se ressemblent.
• Accélération saisonnière : remise ciblée sur une catégorie où l’hésitation est forte, avec stock surveillé.

Le point non négociable : cohérence totale entre le prix affiché, le code, et le prix final au paiement. Dans un parcours piloté par agent, la moindre divergence se transforme en échec de transaction.

Mesurer, attribuer, sécuriser : trois angles morts avant de passer à l’échelle

La première zone grise, c’est l’attribution. Vous devrez isoler le chiffre d’affaires « piloté par agent » du search et du paid classique, sinon vous piloterez à l’aveugle. Cela implique du marquage de source (Gemini vs AI Mode), et des indicateurs dédiés : taux de conversion, panier moyen, retours, annulations, délais de livraison promis vs tenus.

Deuxième angle mort : l’exploitation. Un agent peut déclencher plus vite des commandes “haute intention”, mais il expose aussi davantage vos faiblesses opérationnelles. Ruptures, délais mal paramétrés, options de livraison imprécises : tout se paie en avis négatifs, en retours, et en support.

Troisième sujet, souvent sous-estimé : fraude et litiges. Les schémas changent car la transaction peut être initiée par un agent, pas par un humain en navigation classique. Google met en avant des mécanismes de preuve et d’autorisation liés aux paiements, et l’industrie carte alerte sur une montée des menaces dans ce nouveau modèle ( analyse Visa sur les risques du commerce agentique ).

Dans ce contexte, il faut poser des règles simples : revue humaine au-delà d’un seuil (montant, adresse risquée, répétition), surveillance en temps réel des commandes issues des agents, et procédures de résolution pensées pour des parcours « conversation + paiement ».

Dans 6 à 12 mois, l’enjeu sera l’interopérabilité et la dépendance aux plateformes

La coexistence de standards est probable. UCP se déploie côté Google, tandis qu’OpenAI pousse son propre protocole dans ChatGPT, avec des logiques d’intégration proches mais non identiques. Pour un marchand, cela plaide pour une stratégie “interopérabilité” plutôt qu’un pari unique, surtout si vous visez plusieurs sources de demande.

Toutefois, plus l’achat se fait dans des interfaces d’agents, plus vous dépendez de règles externes : classement, éligibilité, formats de données, et modalités d’offres. L’arbitrage devient stratégique : être présent là où l’intention naît, tout en préservant vos canaux directs et votre capacité d’animation commerciale.

Recommandation opérationnelle : démarrer par un pilote mesuré (catégories limitées, marge maîtrisée), puis monter en charge selon le retour sur investissement publicitaire (ROAS) et le niveau de risque observé.

Verdict : une nouvelle couche de distribution, comme le mobile hier

UCP et les Direct Offers peuvent réduire fortement la friction d’achat, mais la « simplicité » dépend surtout de votre qualité de données, de votre passage en caisse et de votre gouvernance promotionnelle. Le protocole standardise l’accès, il ne corrige pas un catalogue mal tenu.

Feuille de route minimale : nettoyer flux, stock et prix ; choisir paiement natif ou paiement intégré ; lancer une offre pilote avec garde-fous ; mettre en place un suivi et une lutte anti-fraude dédiés. L’enjeu n’est pas seulement technique : c’est une nouvelle couche de distribution où la fiabilité des données fera la visibilité, comme le mobile l’a fait pour l’e-commerce il y a dix ans.