Préparer son flux au commerce agentique : ce qu'exigent réellement UCP, ACP et AI Mode

Au cours des dix-huit derniers mois, quelque chose de structurel s'est produit discrètement dans l'e-commerce, et la plupart de ce qui s'est écrit à ce sujet était soit dithyrambique, soit vague.

Voici la version concrète. Lorsqu'un acheteur demande à un assistant IA de lui trouver un produit, l'assistant ne visite pas votre page d'accueil. Il ne voit ni vos photos, ni l'histoire de votre marque, ni la description produit sur laquelle votre rédacteur a peiné. Il lit des données produits structurées — un flux, un bloc de schéma, une réponse d'API — et décide à partir de là s'il vous recommande, vous ou quelqu'un d'autre.

Votre flux a toujours été la matière première de vos publicités. Il est désormais la matière première de la recommandation elle-même.

Trois systèmes définissent aujourd'hui ce fonctionnement : l'Universal Commerce Protocol (UCP) de Google, l'Agentic Commerce Protocol (ACP) d'OpenAI et Stripe, et le programme marchands de Perplexity. On en parle souvent comme s'il s'agissait de la même chose sous des logos différents. Ce n'est pas le cas. Ils consomment des données différentes, dans des formats différents, avec des exigences différentes, et ils sont actifs dans des pays différents.

Ce guide présente ce que chacun exige réellement au niveau des champs, ce qui se recoupe vraiment, ce qui ne se recoupe pas et — parce que la plupart des lecteurs de ce blog ne vendent pas principalement aux États-Unis — ce qu'il vaut la peine de faire si le paiement agentique n'est pas encore arrivé sur votre marché.

Le paysage, en toute honnêteté

Deux observations avant d'aller plus loin.

Premièrement : la découverte et le paiement sont deux problèmes distincts. Être trouvable par un agent IA est un problème de qualité des données qui s'applique partout dans le monde, dès aujourd'hui. Être transactionnel au sein d'une surface IA est un problème d'intégration de protocole, actuellement limité à une poignée de marchés. Confondre les deux est l'erreur la plus fréquente dans le traitement de ce sujet, et elle conduit les marchands hors des États-Unis à conclure que rien de tout cela ne les concerne. C'est l'inverse qui est vrai — la couche découverte s'applique à tout le monde et concentre actuellement la quasi-totalité de la valeur disponible.

Deuxièmement : les protocoles convergent sur l'infrastructure, pas sur les données. UCP fonctionne explicitement avec A2A, AP2 et MCP. ACP repose sur la même idée générale. Mais leurs schémas produits restent réellement différents, et un flux conçu pour l'un ne s'intègre pas tel quel dans l'autre. C'est un problème de gestion de flux, et non de stratégie, et il a une solution simple : maintenir une source de vérité interne unique et enrichie, et en générer des exports propres à chaque destination.

Couche 1 : le socle de découverte (valable partout, dès aujourd'hui)

Avant tout travail propre à un protocole, il existe un ensemble d'exigences communes à tous ces systèmes. Si vous ne deviez retenir qu'une chose de cet article, ce serait cette couche. Elle ne demande aucun travail d'intégration et c'est elle qui détermine réellement si vous êtes recommandé.

Identifiants produits

Le GTIN est la clé de jointure de tout l'écosystème du shopping IA. Chacun de ces systèmes utilise des identifiants standardisés pour associer votre produit au même produit ailleurs — pour comparer les prix, agréger les avis, savoir que votre annonce et celle d'un site d'avis décrivent le même objet.

Des GTIN manquants ne produisent aucun message d'erreur. Ils produisent du silence : votre produit ne fait tout simplement pas partie de la comparaison que l'agent effectue. Perplexity en particulier accorderait plus d'importance à l'exhaustivité des identifiants que Google.

Mesurez la couverture GTIN en pourcentage des SKU actifs. Si elle est inférieure à 90 %, ce chiffre est votre premier chantier.

Exhaustivité des attributs

Les annonces Shopping traditionnelles fonctionnaient avec un ensemble assez restreint d'attributs obligatoires. Un agent raisonne sur tout ce que vous lui donnez. Chaque champ renseigné est une raison potentielle pour l'agent de vous recommander — matière, dimensions, compatibilité, conseils d'entretien, alimentation électrique, conditions de garantie.

Le changement de perspective est le suivant : un attribut n'est plus une valeur de filtre. C'est un argument. material: full-grain leather n'est pas une facette — c'est la phrase que l'agent utilise lorsqu'un acheteur demande lequel de deux sacs vieillira le mieux.

Cohérence sur toutes les surfaces

C'est l'exigence la plus souvent négligée, et celle qui risque le plus de vous pénaliser.

Un acheteur humain qui voit 2 499 ₺ sur votre page produit et 2 399 ₺ dans un résultat de comparaison hausse les épaules et passe à autre chose. Un agent traite cet écart comme un signal sur la fiabilité de vos données — et un paiement qui échoue parce que le prix a changé est un résultat bien pire pour l'opérateur de l'agent que le simple fait de ne pas vous recommander.

Vérifiez la cohérence entre vos pages produits, votre flux Merchant Center, vos données structurées sur la page et toutes les annonces de marketplaces que vous gérez. Prix, disponibilité, conditions de livraison et politique de retour doivent tous concorder. Les politiques de retour et de livraison, en particulier, sont de plus en plus lues par les agents et citées aux acheteurs.

Fraîcheur

<!-- İç link: /feed-update-frequency -->

L'actualisation nocturne du flux ne suffit plus. Le Shopping Graph de Google s'actualise à une échelle de plusieurs milliards d'annonces par heure et privilégie les données en temps réel ; l'ingestion de flux d'OpenAI accepte des actualisations jusqu'à toutes les 15 minutes.

La raison n'est pas cosmétique. Lorsqu'un agent est capable de finaliser une transaction, des données de stock obsolètes ne produisent pas un acheteur légèrement déçu — elles produisent une transaction échouée. Et les systèmes qui font échouer des transactions sont déclassés.

Objectif concret : une propagation du prix et de la disponibilité en moins de 15 minutes pour les stocks à forte rotation, et au minimum toutes les heures pour tout le reste. Pour la plupart des marchands, cela implique de passer de récupérations de fichiers planifiées à des mises à jour via API ou en mode push.

Accès des robots d'exploration

Vérifiez votre robots.txt pour les robots d'exploration IA. De nombreux marchands les ont bloqués par réflexe en 2024 et 2025, pendant le débat sur la question « faut-il laisser l'IA s'entraîner sur nos contenus », et ne sont jamais revenus sur cette décision. Bloquer le robot qui alimente un index shopping n'est pas la même décision que bloquer un robot d'entraînement — et elle est souvent prise par accident, par une équipe qui n'y a jamais vu une décision commerciale.

Couche 2 : Google — les attributs conversationnels

C'est la partie la plus concrète, la moins commentée et la plus immédiatement actionnable de tout le sujet, et c'est la section que je relirais deux fois.

En parallèle d'UCP, Google a ajouté un ensemble d'attributs conversationnels à la spécification des données produits de Merchant Center. Ils sont facultatifs, complètent vos données produits existantes, et ont pour objectif explicite d'aider les systèmes d'IA et les agents conversationnels à comprendre les spécificités de vos produits. Google précise que leur ajout n'affecte pas le statut d'approbation de vos produits existants.

Ce dernier point compte : le risque est nul. Vous ajoutez des données descriptives, sans rien modifier de ce que Google valide pour l'approbation.

Voici cet ensemble :

L'exemple détaillé de Google, pour une variante d'un téléphone, combine item_group_title, variant_option, question_and_answer, product_highlight, product_detail, related_product, popularity_rank et document_link sur un même article, en plus des attributs standard.

Pourquoi ces six attributs, et à quoi ils servent vraiment

Regardez ce que chacun apporte à un agent :

• question_and_answer est le script de l'agent. Un acheteur demande « est-ce que ça passe au lave-vaisselle ? » et l'agent a votre réponse ou ne l'a pas. S'il ne l'a pas, soit il dit qu'il ne sait pas — ce qui fait perdre la vente —, soit il recommande un concurrent qui a renseigné le champ.
• document_link donne à l'agent un document sur lequel il peut raisonner. La notice de montage répond à « est-ce difficile à assembler ? ». Les fiches techniques répondent à des questions de compatibilité que vous n'auriez pas pu anticiper.
• related_product est la façon dont la vente croisée survit à la disparition de votre site web du parcours d'achat. required_part en particulier évite le pire scénario du commerce agentique : un acheteur qui achète un produit qui ne fonctionne pas seul.
• item_group_title et variant_option résolvent le problème qui empoisonne les flux de variantes depuis toujours — un agent qui voit huit lignes sans comprendre qu'il s'agit d'un seul produit en huit tailles. C'est le problème de structuration des variantes dans un nouveau contexte.
• popularity_rank vous permet d'indiquer à l'agent lesquels de vos produits se vendent réellement. Personne d'autre ne peut lui donner ce signal.

Les renseigner à grande échelle

L'obstacle, en toute honnêteté : personne n'a de colonne question_and_answer dans son PIM.

Mais la plupart des marchands disposent de la matière première — thèmes récurrents des tickets du service client, FAQ produits sur les pages, contenu des avis, motifs de retour. Les paires de questions-réponses les plus utiles se trouvent généralement dans les questions auxquelles votre équipe support répond le plus souvent, et dans les raisons pour lesquelles les produits sont retournés. Un retour motivé par « ne convient pas à ma machine » est une question de compatibilité à laquelle vous devriez répondre dans le flux.

Google recommande d'ajouter ces attributs via une source de données supplémentaire plutôt que de remanier votre flux principal — ce qui est le bon choix opérationnel, car l'équipe propriétaire des données produits et celle qui gère les contenus support sont rarement la même.

À l'échelle d'un catalogue, cela devient un problème de règles : dérivez item_group_title du nom de votre produit parent, construisez variant_option à partir des attributs que vous stockez déjà en tant que couleur et taille, calculez popularity_rank à partir de vos propres données de ventes sous forme de centile, et mappez document_link à partir de votre bibliothèque de manuels existante selon des motifs de SKU. Dans Feedance, il s'agit de règles de flux appliquées à chaque actualisation, et popularity_rank en particulier peut être recalculé automatiquement à partir des données de ventes au lieu d'être maintenu à la main.

Commencez par vos 200 SKU les plus rentables, avec trois paires de questions-réponses chacun. C'est une semaine de travail, et cela couvre la majorité de vos impressions visibles par les agents.

Couche 3 : l'ACP d'OpenAI — une structure réellement différente

Si vous partez du principe que le flux ChatGPT est votre flux Google avec d'autres noms de colonnes, vous construirez la mauvaise chose. Le schéma de flux produits ACP est structurellement différent, et ces différences en disent long sur ce que veulent les systèmes agentiques.

Les produits contiennent des variantes. Le flux Google est plat : chaque variante est une ligne à part, reliée aux autres par item_group_id. ACP inverse cette logique — un objet produit est l'enregistrement de référence, et il contient un tableau d'objets variantes. Chaque variante a son propre id, titre, prix, disponibilité, médias et options.

C'est un meilleur modèle pour un agent, et il vaut la peine de comprendre pourquoi. Un flux plat oblige l'agent à reconstituer « il s'agit d'une seule chaussure en neuf tailles » à partir d'une clé de regroupement commune. Un flux imbriqué lui donne directement cette information. Les marchands dont le catalogue comporte beaucoup de variantes — la mode avant tout — y gagnent réellement en précision.

Les prix sont des entiers exprimés en unités mineures. { "amount": 7999, "currency": "USD" } correspond à 79,99 USD. Pas une chaîne décimale. Toute chaîne de traitement qui effectue des calculs en virgule flottante sur les prix doit être vérifiée avant de produire silencieusement un résultat erroné.

Les descriptions sont des objets, pas des chaînes. L'objet description accepte plain, html et markdown — vous pouvez fournir n'importe quelle combinaison.

Les liens vers les politiques du vendeur sont des éléments à part entière. L'objet seller contient des links, typés privacy_policy, terms_of_service, refund_policy, shipping_policy ou faq. Relisez cette liste : l'agent veut votre politique de retour sous forme de champ structuré. Dans un monde où l'acheteur ne voit jamais votre site, vos politiques doivent accompagner le produit.

L'état est un tableau. ["new"], et plusieurs valeurs peuvent s'appliquer — ce qui anticipe la revente et les stocks reconditionnés.

Une structure minimale :

{
  "id": "SKU12345",
  "title": "Trail Running Shoe",
  "description": { "plain": "Waterproof trail shoe with cushioned sole." },
  "url": "https://example.com/products/SKU12345",
  "media": [
    { "type": "image", "url": "https://example.com/images/SKU12345.jpg",
      "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 }
  ],
  "variants": [
    {
      "id": "SKU12345-BLK-10",
      "title": "Black / 10",
      "barcodes": [{ "type": "gtin", "value": "1234567890123" }],
      "price": { "amount": 7999, "currency": "USD" },
      "list_price": { "amount": 9999, "currency": "USD" },
      "availability": { "available": true, "status": "in_stock" },
      "variant_options": [
        { "name": "color", "value": "Black" },
        { "name": "size", "value": "10" }
      ],
      "categories": [
        { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" }
      ],
      "condition": ["new"],
      "seller": {
        "name": "Example Store",
        "links": [
          { "type": "refund_policy", "title": "Returns policy",
            "url": "https://example.com/returns" }
        ]
      }
    }
  ]
}

Le fichier de flux est accompagné d'un en-tête contenant feed_id, account_id, target_merchant et target_country — notez que le pays est défini au niveau du flux, ce qui signifie que les marchands multimarchés envoient un flux par marché.

Le mode de livraison recommandé par OpenAI est un flux complet une fois par jour par import de fichier, avec des mises à jour intrajournalières envoyées via l'API. Les petits catalogues peuvent faire les deux via l'API.

Un point mérite d'être regardé lucidement : le paiement intégré au chat d'OpenAI a connu une première année plus compliquée que ne le laissaient entendre les annonces, et l'entreprise a reconnu publiquement que la première implémentation d'Instant Checkout était moins flexible que prévu, en déplaçant l'accent vers la découverte de produits avec un renvoi vers le site du marchand pour le paiement. Si vous devez établir des priorités, considérez la découverte ACP comme l'opportunité à court terme et le paiement ACP comme un pari à plus long terme.

Couche 4 : Perplexity

Le programme marchands de Perplexity est le moins documenté des trois et, pour cette raison, celui qui fait l'objet du plus d'informations erronées. Les guides qui publient une spécification de champs détaillée pour Perplexity extrapolent à partir de Google — aucune spécification officielle des champs n'est publiée.

Ce que l'on sait :

• Le programme est gratuit et fonctionne sur candidature ; l'intégration des marchands s'est élargie au fil de 2025 et 2026.
• Le flux est livré en CSV ou en XML, via API, SFTP ou un bucket S3 dédié, au format Google Shopping.
• L'exhaustivité des données produits sert de critère de classement — des données plus complètes donnent au système davantage de matière pour générer des comparaisons et des synthèses avantages/inconvénients.
• L'exhaustivité des identifiants, les données d'avis et le balisage Schema.org sur la page semblent peser plus lourd que chez Google.
• Un flux n'est pas strictement nécessaire pour être cité — un catalogue explorable avec un schéma Product propre peut être mis en avant —, mais un flux améliore les chances de faire partie des produits recommandés.
• Les fonctionnalités transactionnelles sont limitées aux États-Unis. En dehors des États-Unis, vous pouvez être cité et faire l'objet d'un lien, mais pas vendre via la plateforme.

En pratique : pour Perplexity, le travail porte sur l'hygiène Schema.org de vos pages produits et sur les données d'avis, et non sur une nouvelle intégration de flux. Si vos fiches produits émettent déjà un balisage Product et Offer valide avec GTIN, prix, disponibilité et aggregateRating, vous avez fait l'essentiel.

Couche 5 : le paiement — et la géographie, en toute honnêteté

C'est là que les commentaires ont tendance à s'emballer ; soyons donc précis sur ce qui est réellement en service.

Paiement UCP. Disponible pour des marchands sélectionnés, avec une éligibilité des produits aux États-Unis, au Canada et en Australie au moment de la rédaction. Il apparaît sous la forme d'un bouton Acheter sur les annonces éligibles dans AI Mode et Gemini. Vous restez le vendeur officiel. Les clients paient via Google Pay avec les identifiants déjà enregistrés dans leur Google Wallet. La participation exige de remplir les conditions techniques, de soumettre un formulaire de manifestation d'intérêt et de mener à bien l'implémentation — et surtout, seules les annonces portant l'attribut produit native_commerce(checkout_eligibility) afficheront le bouton Acheter.

Ce dernier détail est l'enseignement clé au niveau du flux. Tout le reste du paiement UCP relève de l'intégration back-end ; le signal d'éligibilité lui-même se trouve dans vos données produits.

Google a annoncé en mars 2026 une intégration UCP simplifiée via Merchant Center, ainsi que des fonctionnalités de panier, de catalogue et d'association d'identité, et a indiqué une expansion mondiale au cours de 2026.

Paiement ACP. Nécessite l'implémentation de trois flux — un flux produits, une API de paiement et un paiement délégué via un PSP comme Stripe — et est ouvert aux partenaires approuvés.

Perplexity Buy with Pro. Limité aux États-Unis.

Si vous vendez en dehors des États-Unis

La plupart de nos clients vendent en Turquie, dans le Golfe et en Europe. Voici la situation, en toute honnêteté, dans ce cas :

Le paiement agentique ne vous est pas encore accessible. La découverte agentique l'est, entièrement, dès aujourd'hui.

Un acheteur à Istanbul qui demande à Gemini ou à ChatGPT de comparer des produits obtient dès maintenant une réponse construite à partir de données produits structurées. Que cette réponse inclue ou non vos produits dépend entièrement des couches 1 et 2 ci-dessus — couverture des identifiants, exhaustivité des attributs, attributs conversationnels, fraîcheur et cohérence. Rien de tout cela ne nécessite une intégration de protocole, une entité américaine ou une candidature à un accès anticipé.

L'ordre des priorités pour un marchand hors des États-Unis est donc clair :

1. Traitez entièrement la couche 1. Elle ne présente que des avantages et améliore aussi vos performances actuelles sur Shopping et Performance Max.
2. Traitez la couche 2 dès maintenant. Les attributs conversationnels sont disponibles dans la spécification standard de Merchant Center, ne présentent aucun risque pour l'approbation, et presque personne sur votre marché ne les a renseignés.
3. Surveillez la couche 5. Lorsque le paiement arrivera sur votre marché, les marchands qui auront traité les couches 1 et 2 s'intégreront en quelques semaines. Ceux qui ne l'auront pas fait partiront d'un catalogue incomplet.

L'avantage d'agir tôt n'est pas de réaliser des transactions dans ChatGPT ce trimestre. C'est que la qualité des données d'un catalogue demande des mois de travail et ne s'achète pas dans l'urgence le jour où la fenêtre s'ouvre.

⚠️ Une échéance qui n'est pas facultative

Indépendamment de tout ce qui précède, et bien plus urgent : la Content API for Shopping de Google prend fin le 18 août 2026. Après cette date, les appels aux anciens points de terminaison v2.1 cessent de fonctionner.

Cela concerne uniquement les intégrations programmatiques — les imports manuels, les récupérations planifiées et les flux Google Sheets ne sont pas concernés. Pour les marchands qui utilisent les intégrations officielles des plateformes (le canal Google & YouTube de Shopify, Google Listings & Ads de WooCommerce), la plateforme s'en charge. Les intégrations personnalisées et certains outils tiers doivent migrer manuellement vers Merchant API v1.

Deux points à vérifier dès aujourd'hui : dans Merchant Center, allez dans Paramètres → Sources de données et regardez la colonne Source. Si elle indique « Content API », vous avez une action à mener. Et sachez que les libellés de flux ne sont pas transférés automatiquement — si la structure de vos campagnes Google Ads dépend des libellés de flux, une migration menée sans précaution peut interrompre la diffusion des campagnes.

Si votre flux parvient à Merchant Center via Feedance, cette migration est gérée de notre côté et votre configuration d'export ne change pas.

Ce que signifie « prêt pour les agents », champ par champ

En réunissant les couches dans une seule vue opérationnelle :

L'exercice utile consiste à lire ce tableau en transversal : remarquez à quel point le comportement de la colonne de droite dépend de champs facultatifs, que la plupart des catalogues laissent vides.

La check-list de préparation

Les fondamentaux — à faire en premier, ils s'appliquent à toutes les surfaces

• [ ] Couverture GTIN supérieure à 90 % des SKU actifs
• [ ] Prix et disponibilité propagés en 15 minutes à une heure, et non du jour au lendemain
• [ ] Prix, disponibilité, livraison et retours cohérents entre le site, le flux et les marketplaces
• [ ] Toutes les images en 500×500 minimum (également exigé par Google à partir du 31 janvier 2027)
• [ ] Balisage Schema.org Product et Offer valide sur chaque fiche produit, avec aggregateRating lorsque vous avez des avis
• [ ] Robots d'exploration IA non bloqués par accident dans robots.txt
• [ ] google_product_category correctement mappé, et non laissé à l'inférence
• [ ] Migration de la Content API confirmée comme terminée

Avantage concurrentiel — la plupart des acteurs de votre marché ne l'ont pas fait

• [ ] question_and_answer renseigné sur vos 200 premiers SKU, avec au moins 3 paires chacun
• [ ] item_group_title et variant_option sur chaque famille de variantes
• [ ] popularity_rank calculé à partir de vos propres données de ventes
• [ ] document_link mappé à partir de votre bibliothèque existante de manuels et de fiches techniques
• [ ] related_product pour les accessoires et les pièces nécessaires
• [ ] video_link sur les produits phares
• [ ] Exhaustivité des attributs supérieure à 95 % sur votre premier décile de chiffre d'affaires

À la pointe — pour les marchands des marchés éligibles

• [ ] Flux ACP généré et livré, complet chaque jour, avec mises à jour intrajournalières via l'API
• [ ] Candidature au programme marchands de Perplexity envoyée
• [ ] Formulaire d'intérêt UCP envoyé, éligibilité native_commerce signalée sur les annonces admissibles
• [ ] Trafic et commandes issus des agents étiquetés séparément dans les outils d'analyse

Ce dernier point mérite d'être souligné. Les commandes générées par des agents ne s'attribueront pas comme la recherche ou le social payant, et si vous ne les étiquetez pas au moment de l'intégration, vous ne pourrez pas prouver que quoi que ce soit a fonctionné. Mettez en place la mesure avant d'en avoir besoin.

Est-ce que ça vaut la peine ?

Une réponse nuancée, car le sujet suscite plus de certitudes que les données ne le justifient.

Les raisons d'être sceptique. L'adoption du paiement a été plus lente que ne le laissaient entendre les annonces de lancement. OpenAI a publiquement revu son approche après la première tentative d'Instant Checkout. La plupart des fonctionnalités transactionnelles sont géographiquement restreintes. Les données publiées sur le chiffre d'affaires incrémental sont maigres, et les multiples de croissance impressionnants partent généralement d'une base très faible.

Les raisons d'agir malgré tout. Presque tout ce qui figure dans les couches 1 et 2 améliore vos performances payantes actuelles, que le commerce agentique soit ou non à la hauteur des projections. Des attributs complets, des identifiants exacts et des données de stock fraîches améliorent dès aujourd'hui les performances de Performance Max. Les attributs conversationnels ne présentent aucun risque pour l'approbation. Et la qualité des données d'un catalogue est un projet de plusieurs mois, sans raccourci — les marchands qui commenceront lorsque l'opportunité sera évidente partiront avec du retard.

Le cadre que nous suggérons : ne construisez pas pour le commerce agentique, construisez un catalogue complet et exact. Être prêt pour les agents, c'est à cela que ressemble un catalogue complet et exact en 2026. Le travail sur les protocoles n'est qu'une fine couche par-dessus, et c'est la partie qui peut être réalisée rapidement une fois que les données sous-jacentes sont correctes.

Si vous souhaitez établir un point de départ avant de vous engager, notre outil gratuit d'audit de flux produits note n'importe quel flux sur l'exhaustivité des données, leur qualité et sa santé technique — ce qui donne une bonne idée de ce que vous avez déjà en place.

Sources

• Aide Google Merchant Center — À propos de l'Universal Commerce Protocol (UCP) : https://support.google.com/merchants/answer/16837055
• Aide Google Merchant Center — Utiliser les attributs conversationnels : https://support.google.com/merchants/answer/17085370
• Aide Google Merchant Center — Spécifications des données produits : https://support.google.com/merchants/answer/7052112
• Google Developers Blog — Under the Hood : Universal Commerce Protocol : https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Google for Developers — Migrer de la Content API for Shopping vers Merchant API : https://developers.google.com/merchant/api/guides/compatibility/overview
• OpenAI Developers — Product Feed Spec (Agentic Commerce) : https://developers.openai.com/commerce/specs/spec
• OpenAI Developers — Concepts clés de l'Agentic Commerce : https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol : https://www.agenticcommerce.dev/
• Universal Commerce Protocol : https://ucp.dev