Si vous êtes directeur e-commerce, la pression n’a plus rien d’abstrait. Tout le monde présente l’achat dans les conversations IA comme « le futur », et la direction veut savoir si les clients pourront y trouver, comparer et acheter vos produits. Pourtant, le présent est moins net : demandez à un assistant IA de respecter plusieurs contraintes, de distinguer deux variantes ou de confirmer un prix actuel, et sa réponse peut encore être incomplète ou fausse.
Est-ce que cela signifie que les sites e-commerce sont mal conçus ? Parfois, les données du marchand contribuent au problème. Mais une mauvaise réponse peut aussi venir de l’accès à la plateforme, de la normalisation de catalogues différents, de la récupération des produits ou du raisonnement de l’agent. La conversation seule ne permet pas de savoir où se trouve la panne.
Autre confusion : « l’IA peut acheter » peut désigner un passage utile vers le checkout que vous exploitez déjà. Cela peut aussi désigner un agent qui termine lui-même la transaction - une capacité documentée par certaines plateformes, mais soumise à accès ou éligibilité. Aucun travail sur le catalogue ou le site ne peut débloquer cet accès à lui seul.
Ce guide s’adresse aux enseignes et fabricants établis en France dont la vérité produit traverse plusieurs systèmes, variantes, canaux ou marchés. Avant de financer un flux, une intégration ou un projet de « commerce agentique », testez une catégorie réelle depuis la source jusqu’au parcours d’achat. Vous devez en sortir avec trois réponses : qu’est-ce qui casse, qui le contrôle et faut-il réellement construire quelque chose ? Si votre catalogue est simple et maintenu dans une seule plateforme e-commerce, commencez par la documentation actuelle de cette plateforme ; une mission transverse peut être inutile.
La réponse en 60 secondes
Pour la plupart des marchands, le parcours d’achat réaliste reste aujourd’hui un passage vers le checkout qu’ils exploitent déjà. Certaines plateformes documentent un paiement terminé par un agent pour les intégrations éligibles, mais un marchand ne peut pas activer cette capacité en modifiant ses fiches produits. Considérez-la comme indisponible tant que la plateforme visée n’a pas confirmé l’accès.
Commencez par une catégorie importante pour le chiffre d’affaires et un échantillon fondé sur le risque : un produit courant, une variante complexe, un prix ou une promotion qui vient de changer, un changement de stock, une restriction de livraison ou de marché et un produit dont les caractéristiques comptent réellement dans la comparaison.
Pour chaque cas, comparez la source de référence, la fiche produit, les données structurées, le flux produit actuel et le résultat du canal IA visé. Vérifiez le produit et la variante exacts, le titre, les attributs, le prix, la devise, le stock, les images, la livraison, les retours et l’éligibilité. Exécutez ensuite cinq tâches d’acheteur : recherche exacte, découverte sous contraintes, comparaison, vérification du prix ou du stock, puis prochaine étape d’achat réellement disponible.
Classez chaque résultat dans un seul état : conforme sur ce test, anomalie contrôlée par le marchand, limite côté canal observée ou inconnu. Si la plateforme est réservée à des partenaires ou si le produit n’a jamais été ingéré, ne transformez pas l’absence de résultat en faute du site.
Conservez votre checkout marchand lorsqu’un passage fiable suffit. Le travail d’intégration commence lorsque le transfert doit garder la bonne variante, la quantité ou un panier prérempli. Ne cadrez un checkout terminé par l’agent qu’après confirmation de l’éligibilité du marchand et de l’intégration.
La décision finale doit être précise : réparer la vérité produit, réparer l’accès public, exploiter un flux fiable, améliorer le passage au checkout, cadrer une intégration éligible - ou surveiller le canal sans construire pour le moment.
Dans cet article
- Deux parcours réalistes et une capacité sous conditions
- Pourquoi la découverte et la comparaison échouent encore
- Comment tester une catégorie réelle
- Comment transformer les résultats en décision
- Ce qu’il faut corriger maintenant et ne pas encore construire
- Quand une revue externe devient utile
1. Deux parcours réalistes et une capacité sous conditions
Définissez le projet par l’expérience du client. Ne regroupez pas découverte, passage au checkout marchand et achat terminé par l’agent sous une seule étiquette de « commerce agentique ».
| Capacité | Ce que vit le client | Ce dont le marchand a besoin |
|---|---|---|
| Trouver et comparer | L’IA identifie des produits adaptés et explique les différences utiles | Des données produit accessibles ou ingérées, actuelles et comparables |
| Passer au checkout marchand | L’IA ouvre la bonne fiche, le bon panier ou le checkout du marchand | Une destination stable qui conserve le produit, la variante et, lorsque c’est possible, la quantité |
| Checkout terminé par un agent éligible | Un agent autorisé confirme les totaux et termine la commande | Un accès plateforme confirmé, puis identité, état du panier, prix en temps réel, paiement, confirmation, commande et gestion des exceptions |
Pour la majorité des marchands, les deux premières lignes sont les parcours réalistes. Le passage au checkout peut réutiliser l’infrastructure existante, même si la conservation de la variante, de la quantité ou du panier demande parfois une intégration. La troisième ligne existe dans des parcours documentés, mais son accès est contrôlé. Ce n’est ni un réglage catalogue, ni une fonction que le marchand peut présumer disponible.
Cet article traite des canaux d’achat IA externes. Si l’assistant se trouve dans votre propre boutique, la décision est différente ; consultez notre guide sur l’assistant d’achat IA intégré au site e-commerce.
Qu’est-ce qui est documenté aujourd’hui ?
Les accès évoluent rapidement. Le tableau suivant reflète la documentation consultée le 20 août 2026.
| Parcours plateforme | Position actuellement documentée | Ce que cela ne prouve pas |
|---|---|---|
| Flux produits ChatGPT | L’intégration des flux produits OpenAI est actuellement proposée aux partenaires approuvés. Le schéma produit sépare l’éligibilité à la recherche de l’éligibilité au checkout. | L’approbation, l’affichage, le classement ou le checkout d’un marchand ou produit précis |
| Checkout marchand depuis ChatGPT | OpenAI présente actuellement le checkout externe hébergé par le marchand comme la voie recommandée et généralement disponible pour la plupart des développeurs de plugins. | Qu’un agent puisse créer un panier ou terminer le paiement de chaque marchand |
| Paiement intégré à ChatGPT | OpenAI décrit sa feuille de paiement intégrée comme une bêta privée limitée à certains partenaires de places de marché. | Un accès prochain pour un marchand non approuvé |
| Commerce agentique Shopify | Shopify documente le passage au checkout marchand pour l’accès général et la finalisation directe pour les agents éligibles. | Une disponibilité universelle pour tous les agents, marchands, marchés ou produits |
L’infrastructure publiée est réelle. L’accès universel ne l’est pas. Une fiche accessible ou un flux accepté peut soutenir la découverte sans permettre à l’agent de terminer la commande.
2. Pourquoi la découverte et la comparaison échouent encore
Le problème n’est pas imaginaire. Plusieurs benchmarks récents montrent que les agents rencontrent encore des difficultés sur des tâches produit ancrées dans des faits :
- ShoppingBench, publié dans les actes AAAI 2026, a testé un environnement contrôlé de plus de 2,5 millions de produits. GPT-4.1 y obtient un taux de réussite absolu inférieur à 50 % sur les tâches évaluées.
- EComAgentBench, une prépublication portant sur 662 tâches, distribue les exigences entre la demande, le profil de l’acheteur et une étape de clarification. Le meilleur des sept modèles évalués atteint 57,1 % de précision globale.
- ShoppingComp, également en prépublication, évalue 145 instances et 558 scénarios construits à partir de produits réels. Le meilleur modèle rapporté, GPT-5.2, obtient 17,76 %. Les auteurs attribuent les échecs à l’ancrage dans des données produit ouvertes, à la vérification d’exigences multiples, au raisonnement sur des informations bruitées ou contradictoires et à la prise de décision face au risque.
Ces pourcentages ne sont pas comparables entre eux : les tâches et métriques diffèrent. Ils n’estiment pas non plus la fréquence à laquelle un acheteur français reçoit une mauvaise réponse. Ils établissent un point plus étroit : trouver, filtrer et vérifier des produits reste difficile, même lorsque l’agent paraît sûr de lui.
Une mauvaise réponse peut entrer dans la chaîne à plusieurs endroits.
| Où se situe le problème | Ce qui peut mal fonctionner | Contrôle principal |
|---|---|---|
| Vérité produit du marchand | Les identifiants de variantes changent ; des attributs manquent ; la fiche, le flux et le checkout ne donnent pas le même prix ou stock | Marchand |
| Accès public | Les fiches ou images sont bloquées, instables, dupliquées ou dépendantes d’un rendu fragile | Marchand, hébergement et sécurité |
| Données du canal | Le flux manque, est obsolète, rejeté, hors marché ou inaccessible à ce marchand | Marchand et plateforme |
| Normalisation entre catalogues | Deux catalogues représentent différemment un même produit, lot ou variante | Principalement plateforme |
| Intention de l’acheteur | Des contraintes importantes restent implicites ou changent pendant l’échange | Acheteur et agent |
| Récupération et raisonnement | L’agent choisit le mauvais candidat, oublie une contrainte ou produit une comparaison non étayée | Principalement agent et plateforme |
Deux marchands peuvent aussi structurer correctement le même produit de façons différentes sans que l’un des deux sites soit « mal fait ». Shopify décrit cette hétérogénéité comme un problème d’identité et de regroupement dans son travail d’ingénierie sur l’API Catalog.
La bonne question n’est donc pas « notre e-commerce est-il bon ? », mais : à quel endroit un parcours produit testé cesse-t-il de correspondre aux preuves ?
3. Comment tester une catégorie réelle
Ce test est un diagnostic, pas une enquête statistique sur tout le catalogue. Son objectif est de couvrir les règles produit les plus susceptibles de révéler une identité cassée, une mauvaise correspondance entre systèmes, une mise à jour en retard ou un passage au checkout défaillant.
Étape 1 : fixer le périmètre
Choisissez :
- une catégorie importante pour le chiffre d’affaires ;
- le marché français, l’euro et une destination de livraison précise en France ;
- un canal IA cible, avec le modèle ou le mode visible lorsque cette information existe ;
- une date et une heure de test ;
- les systèmes qui doivent détenir les valeurs de référence : plateforme e-commerce, PIM, ERP, OMS ou autre source nommée.
Ne commencez ni par tout le catalogue, ni par plusieurs plateformes IA. Un périmètre fixe permet de distinguer un défaut de données d’une simple variation entre canaux.
Étape 2 : construire un échantillon fondé sur le risque
Ne sélectionnez pas uniquement les produits simples et propres. Incluez au moins un cas de chaque groupe applicable.
| Cas de test | Règle de sélection | Défaut que le cas peut révéler |
|---|---|---|
| Produit courant | Produit populaire ou important avec un parcours d’achat normal | Problème de base d’identité, de fiche, de flux ou de découverte |
| Produit à variantes | Taille, couleur, matière, capacité ou autre option modifiant l’offre | Confusion parent/variante, mauvaise image, mauvais prix ou stock |
| Événement de prix | Promotion active ou prix récemment modifié | Flux obsolète, promotion expirée ou mauvaise devise |
| Événement de stock | Stock faible, rupture, précommande, réapprovisionnement récent | Retard de mise à jour et affirmation de disponibilité non fondée |
| Restriction de marché ou politique | Livraison, retours ou éligibilité limités en France ou sur une zone donnée | Recommandation d’un produit que le client ne peut pas acheter |
| Cas de comparaison | Caractéristiques techniques ou propres à la catégorie déterminant le choix | Champs manquants et comparaison non étayée |
| Modèle non standard | Lot, abonnement, produit configurable ou fabriqué à la demande, si la catégorie en contient | Mauvaise frontière produit, totaux ou hypothèses de livraison erronés |
Le premier passage est suffisamment couvert lorsque chaque règle pertinente apparaît au moins une fois, avec un prix ou un stock ayant changé récemment. Cela ne rend pas l’échantillon statistiquement représentatif.
Si un cas échoue, ajoutez d’autres produits soumis à la même règle. Le but est de déterminer si le défaut appartient à une fiche isolée ou à une correspondance, une responsabilité ou un processus de mise à jour répété. Notez cette distinction ; ne transformez pas ce petit diagnostic en pourcentage valable pour tout le catalogue.
Étape 3 : suivre chaque produit dans la chaîne de vérité
Créez une ligne par produit ou variante et relevez les mêmes champs à chaque couche disponible.
| Couche | Preuves à relever |
|---|---|
| Source de référence | Identifiants produit et variante, titre, attributs, prix, devise, promotion, disponibilité, éligibilité et responsable nommé |
| Fiche produit publique | Valeurs visibles, variante sélectionnée, URL canonique, image, livraison et retours |
| Données structurées de la page | Champs Product, Offer et variantes réellement rendus dans la source |
| Flux produit actuel | Valeurs envoyées, horodatage, lignes acceptées, rejetées et avertissements |
| Résultat du canal IA | Produit choisi, variante, affirmations, source ou destination visible, conditions et horodatage du test |
| Parcours d’achat | Destination produit ou panier, variante et quantité conservées, prix recalculé, stock et confirmation client |
Définissez avant le test le retard acceptable pour chaque champ. Un article fabriqué à la demande et un stock à rotation rapide n’ont pas besoin de la même fréquence. Sans tolérance déclarée, « à jour » n’a pas de sens opérationnel.
Lorsqu’une couche n’existe pas, notez non applicable. Lorsque l’accès, l’ingestion ou l’éligibilité ne peuvent pas être confirmés, notez inconnu. Ne remplissez jamais un résultat plateforme manquant par une supposition.
La documentation actuelle de Google sur les données structurées produit recommande le balisage des fiches, un flux Merchant Center, ou les deux pour les expériences Google. Google indique que leur combinaison peut élargir l’éligibilité et l’aider à comprendre et vérifier les données. Ce bénéfice est propre à Google ; ce n’est pas une garantie pour les autres systèmes IA.
Étape 4 : exécuter cinq tâches d’acheteur
Utilisez les produits sélectionnés dans une nouvelle conversation. Conservez la demande exacte, la réponse, les sources, la date, la langue, le pays et les conditions visibles de la plateforme.
- Recherche exacte : retrouver chez le marchand un produit nommé et sa variante précise.
- Découverte sous contraintes : trouver un produit de la catégorie respectant le budget et au moins deux contraintes utiles.
- Comparaison : comparer deux produits sélectionnés avec les attributs qui déterminent réellement la décision.
- Vérification de fraîcheur : confirmer prix, promotion, disponibilité et livraison du cas volatil.
- Parcours d’achat : sélectionner la bonne variante et utiliser la prochaine étape réellement proposée - fiche produit, panier ou checkout.
Répétez les résultats surprenants dans les mêmes conditions avant d’y voir un comportement stable. Les sorties IA varient, et une seule réponse ne prouve pas un fonctionnement durable du canal.
Étape 5 : attribuer un seul statut honnête
| Statut | Quand l’utiliser | Ce qu’il ne faut pas conclure |
|---|---|---|
| Conforme sur ce test | L’étape produit le bon produit, la bonne variante et les bonnes valeurs dans la tolérance fixée | Que tout le catalogue ou toutes les demandes réussiront |
| Anomalie contrôlée par le marchand | Une source, une fiche, une image, une donnée structurée, une correspondance de flux ou une destination checkout est contradictoire, inaccessible ou rejetée pour une raison contrôlée par le marchand | Que la correction garantira une recommandation IA |
| Limite côté canal observée | Les preuves contrôlées par le marchand sont correctes et disponibles, mais le résultat IA manque, se trompe ou perd une contrainte | Que le modèle ou la plateforme est la cause racine prouvée après un seul test |
| Inconnu | L’accès, l’ingestion, l’éligibilité ou une preuve nécessaire ne peuvent pas être inspectés | Que le marchand a réussi ou échoué |
Le livrable utile est un registre d’anomalies : produit, champ, couche affectée, preuve, responsable et prochaine action. Un score unique « prêt pour l’IA » masque les informations nécessaires pour réparer.
4. Comment transformer les résultats en décision
Lisez la première couche qui casse, pas la solution la plus à la mode.
| Constat observé | Prochaine action adaptée | Ce qu’il ne faut pas présumer |
|---|---|---|
| Les identifiants ou valeurs diffèrent avant même le canal IA | Réparer la propriété des données, les correspondances entre systèmes et les règles de mise à jour | Qu’un nouveau flux ou chatbot réconciliera les contradictions |
| Les fiches ou images ne sont pas accessibles comme prévu | Réparer URL, rendu, canonicalisation, règles de robots ou configuration de sécurité | Que les données structurées seules rendront le produit découvrable |
| Les fiches sont correctes, mais le flux manque, est obsolète ou rejeté | Réparer la correspondance des champs, la validation, la cadence de mise à jour et le traitement des rejets | Qu’un export valide une fois suffit pour rester à jour |
| Source, fiche et flux accepté sont corrects, mais le résultat IA est absent ou faux | Répéter le test contrôlé, conserver les preuves et traiter le résultat comme une limite observée ou un inconnu | Que le site e-commerce doit être reconstruit |
| Le bon produit est trouvé et le passage marchand fonctionne | Conserver et améliorer le checkout existant | Qu’un paiement intégré est nécessaire |
| Le passage perd la variante, la quantité ou le contexte | Cadrer la plus petite intégration panier ou checkout possible | Qu’une transaction terminée par l’agent est nécessaire |
| L’entreprise veut un checkout terminé par l’agent, mais l’accès n’est pas confirmé | Considérer la capacité comme indisponible dans le plan et surveiller la plateforme | Que le catalogue, le balisage ou le site peuvent débloquer l’accès |
| La plateforme confirme l’éligibilité du marchand et de l’intégration | Cadrer identité, état, confirmation, paiement, commande et gestion des exceptions | Que l’éligibilité supprime les risques transactionnels, opérationnels ou d’expérience client |
C’est ici que la distinction entre découverte et checkout devient concrète. Un produit peut être éligible à la recherche sans l’être au checkout. Le parcours peut tout de même être utile si le client termine l’achat sur le site du marchand.
Si la panne se poursuit au paiement, à la livraison, aux retours ou à la mesure, dépassez ce test de canal et examinez l’ensemble de la chaîne de conversion e-commerce.
5. Ce qu’il faut corriger maintenant et ne pas encore construire
Corriger lorsque les preuves le justifient
- Stabiliser les identifiants produit et variante.
- Nommer le système de référence et le responsable du prix, du stock, des attributs, de la livraison et de l’éligibilité.
- Supprimer les contradictions entre fiche publique, données structurées, flux et checkout.
- Rendre les fiches et images prévues fiables et accessibles.
- Valider les flux avant envoi, puis enregistrer les lignes acceptées, rejetées et en avertissement.
- Définir des tolérances de mise à jour et un responsable d’incident pour les écarts commercialement dangereux.
- Conserver le produit et la variante lorsque l’acheteur passe sur le site marchand.
Ce travail sert aussi le e-commerce ordinaire, les marketplaces et les équipes internes. Il ne dépend pas d’une promesse sur l’avenir des agents.
Ne pas construire sans parcours vérifié
- un flux propre à une plateforme lorsque le marchand n’a aucun accès confirmé ;
- une couche de traduction multi-plateformes avant d’avoir compris un parcours de bout en bout ;
- un paiement terminé par l’agent sans éligibilité confirmée ni parcours client contrôlé ;
- un serveur MCP dont le seul objectif est une vague « visibilité IA » ;
- un fichier
llms.txtprésenté comme un substitut aux données produit, aux flux ou aux outils transactionnels ; - une campagne promettant l’inclusion dans ChatGPT, un classement IA ou des achats automatiques.
Un robot d’exploration, un flux produit, un catalogue de plateforme et un outil MCP répondent à des problèmes différents. Notre guide sur llms.txt et WebMCP explique la différence entre décrire un site et exposer une action contrôlée.
Les moteurs IA peuvent également récupérer et citer des sources différentes selon les conditions. Si les preuves produit sont correctes, mais qu’une seule plateforme se comporte autrement, utilisez une méthode multi-moteurs contrôlée plutôt qu’un diagnostic générique de visibilité ; consultez pourquoi les moteurs IA citent des sources différentes.
6. Quand une revue externe devient utile
En tant que directeur e-commerce, vous n’avez pas besoin d’un prestataire pour vous rappeler que les données produit doivent être exactes. Une aide extérieure gagne sa place lorsque catalogue, e-commerce, merchandising, ingénierie et plateformes ne s’accordent pas sur la première couche cassée - ou lorsque la correction traverse plusieurs systèmes, marchés et responsables.
Le modèle de Conseil d’IZZY peut être cadré sur une catégorie et un canal avant d’engager un chantier plus large. Les éléments utiles à apporter sont :
- la catégorie et le marché testés ;
- les systèmes contenant produits, prix et stocks ;
- le canal IA et l’état actuel de l’accès ;
- l’échantillon fondé sur le risque ;
- une contradiction, un rejet ou un résultat inconnu déjà observé.
Si le produit est correctement trouvé et que la panne commence après l’arrivée sur votre site - rendu JavaScript, consentement, anti-bot, panier ou checkout - l’Audit Agent Readiness d’IZZY est la voie la plus pertinente. Il teste les parcours critiques du site avec de vrais agents. Il ne remplace pas le diagnostic de la vérité catalogue, de l’ingestion du flux ou de l’éligibilité plateforme.
La mission de Conseil doit se terminer par une décision d’investissement délimitée : corriger en interne, intégrer un Expert embarqué sur un manque défini, cadrer une implémentation via un Partenariat complet, ou ne rien construire pour le moment. Elle ne doit promettre ni inclusion dans ChatGPT, ni meilleur classement IA, ni achat automatique, ni support d’une plateforme précise.
Conclusion
La documentation actuelle d’OpenAI et de Shopify couvre la découverte produit, le passage au checkout marchand et certains checkouts terminés par des agents éligibles. Cette infrastructure ne rend ni les réponses produit toujours fiables, ni tous les marchands automatiquement éligibles.
La bonne réaction n’est ni d’ignorer le canal, ni de reconstruire votre e-commerce autour du discours ambiant. Testez une catégorie qui compte. Couvrez les règles produit les plus susceptibles de casser. Suivez chaque produit depuis la source jusqu’au résultat IA et au parcours d’achat. Séparez anomalies marchandes, limites observées côté canal et inconnues.
Financez ensuite la première correction révélée par les preuves. Ce sera parfois un chantier catalogue, parfois un flux ou un passage au checkout. Parfois, les fondations seront propres, mais l’accès plateforme absent - et la bonne décision sera d’attendre.
Transformer une catégorie en décision d’investissement défendable
En tant que directeur e-commerce, apportez une catégorie, ses systèmes sources, le canal d’achat IA envisagé et une contradiction ou incertitude déjà visible. Nous cadrerons la prochaine étape : correction interne, mission de Conseil, Expert embarqué, implémentation contrôlée - ou rien à construire pour le moment.
Questions fréquentes
Pas à elle seule. Des données contradictoires, des pages inaccessibles ou un flux obsolète peuvent contribuer. Mais la couverture plateforme, la normalisation des catalogues, l’intention de l’acheteur et la récupération ou le raisonnement de l’agent peuvent aussi dégrader le résultat. Testez la chaîne avant d’attribuer la faute.
Elles peuvent rendre les faits produit publics et plus simples à interpréter par les systèmes qui les prennent en charge. Elles ne garantissent pas que ChatGPT ou un autre assistant ingère, retrouve, recommande ou classe le produit.
Cela dépend du canal visé. Un flux peut fournir une fiche normalisée, un contrôle des mises à jour et des retours de validation. Suivez la spécification actuelle du canal et confirmez l’accès marchand avant de construire un nouvel export.
OpenAI documente un chemin compatible avec le format Google après confirmation que le flux enregistré peut utiliser cette représentation. La compatibilité ne signifie pas qu’un export existant sera complet ou accepté sans modification. Validez-le contre la spécification produit OpenAI actuelle.
Pas nécessairement. MCP peut exposer des outils ou actions contrôlés lorsque le parcours cible l’exige. Il ne remplace pas des fiches accessibles, des données exactes ou un flux marchand documenté.
Non. Un assistant peut souvent envoyer l’acheteur vers une fiche ou un checkout. Terminer l’achat comme agent exige une intégration prise en charge, une éligibilité confirmée, des contrôles transactionnels et une confirmation du client. Tant que la plateforme ne confirme pas cet accès, planifiez un passage au checkout marchand.
Sources et méthode
Cet article utilise la documentation plateforme actuelle pour les affirmations sur les accès, flux et checkout, ainsi que des travaux méthodologiques sur la performance des agents d’achat. Sources principales :
- OpenAI - démarrer avec Agentic Commerce
- OpenAI - spécification stable des produits
- OpenAI - documentation checkout
- OpenAI - documentation des robots
- Shopify - documentation du commerce agentique
- Shopify - Checkout MCP
- Google - données structurées produit
- ShoppingBench, AAAI 2026
- EComAgentBench, prépublication
- ShoppingComp, prépublication
- Shopify Engineering - regroupement des catalogues
- IZZY - Audit Agent Readiness
ShoppingBench est évalué par les pairs. EComAgentBench et ShoppingComp sont des prépublications. Leurs métriques ne sont pas directement comparables et n’estiment pas la fréquence des mauvaises réponses reçues par les consommateurs français. L’échantillon fondé sur le risque et les quatre statuts sont une méthode de diagnostic IZZY, pas une norme sectorielle, un audit statistique ou une certification de préparation.
Les accès, spécifications et statuts de bêta peuvent évoluer. Revérifiez les affirmations sur l’éligibilité et le checkout immédiatement avant publication. Cet article ne promet ni inclusion plateforme, ni classement, ni recommandation, ni trafic, ni vente, ni achat automatisé. Il ne constitue pas un avis juridique, fiscal, paiement ou conformité adapté à une implémentation précise.