Hook

J’ai activé Agentic Storefronts sur le shop d’un client la semaine dernière. C’est une grande marque française du reconditionné : 50 000 SKUs actifs, statut ESS, Shopify Plus, équipe data interne, plusieurs millions d’euros de chiffre annuel. Pas un débutant.

Le toggle s’allume en deux clics. À ce moment-là, leur catalogue devient théoriquement accessible aux agents IA qui consomment l’écosystème Shopify (ChatGPT via le Catalog, Google AI Mode et Copilot via UCP). Théoriquement.

J’ai fait ce que tout marchand devrait faire avant de présumer que ça marche : j’ai voulu vérifier ce que les agents voient vraiment. J’ai posé un audit en sept points sur leur infrastructure agentique. L’audit n’est pas terminé au moment où j’écris : on est en plein milieu, les premiers chiffres remontent. J’ai décidé de publier la méthode et le scope avant de publier les résultats, pour deux raisons. La première, c’est que la méthode est plus utile que les chiffres : tu peux la dérouler chez toi cette semaine. La seconde, c’est que dans deux mois on aura les chiffres comparés avant/après fix, et l’article #2bis sera plus précis.

Cet article est donc en deux temps. La méthode et les hypothèses de gravité maintenant. Les résultats chiffrés et les correctifs appliqués dans une mise à jour datée fin juin. Si tu veux la version courte : la checklist 30 points en PDF est en bas de l’article.

Pourquoi ce shop, pourquoi maintenant

Trois raisons d’avoir choisi cette boutique pour le case study public.

D’abord, le profil colle au mid-market que je sers. 50 000 SKUs n’est pas un catalogue trivial : c’est suffisamment grand pour que les problèmes de qualité de donnée soient massifs en cumulé, et suffisamment petit pour qu’une équipe de trois personnes puisse les corriger en deux mois. Si la méthode marche ici, elle marche pour 80 % des boutiques Shopify Plus FR.

Ensuite, le reconditionné est un secteur qui a des spécificités françaises rares dans la documentation UCP : indice de réparabilité (devenu indice de durabilité depuis 2025 sur certaines catégories), TVA à 5,5 % sur certains flux ESS, certifications Bonus Réparation. Aucun de ces attributs n’est natif dans le schema.org Product standard. Ils sont absents du manifest UCP auto-généré par Shopify. Pour un agent qui répond à “trouve-moi un iPhone reconditionné réparable et certifié français”, c’est une catastrophe : le shop est techniquement éligible, mais invisible au tag.

Enfin, le marchand a accepté que je publie. C’est rare : la plupart des clients en mid-market FR refusent d’apparaître dans un case study technique de peur que ça nuise à leur SEO ou trahisse des trade secrets. J’ai signé un NDA limité (j’anonymise la marque, je n’expose pas les volumes par catégorie, je ne montre pas les screenshots de leur admin sans floutage) en échange du droit de publier la méthode et les ordres de grandeur. C’est un deal qui devrait devenir un standard dans notre métier : si tu acceptes l’audit, tu acceptes que ses leçons servent au marché.

Ce que Shopify auto-génère, ce qui manque

Avant de pointer les sept trous, il faut comprendre la baseline. Shopify pousse un manifest UCP par défaut sur chaque boutique éligible. Voici à quoi ça ressemble pour ce shop, dans sa version la plus récente capturée le 2 mai 2026 (champs sensibles remplacés par des placeholders).

{
  "ucp_version": "2026-04-08",
  "merchant": {
    "id": "shop_xxxxxxx",
    "name": "[Marque anonymisée]",
    "domain": "[domaine].fr",
    "merchant_of_record": true
  },
  "services": [
    {
      "name": "dev.ucp.shopping",
      "version": "2026-04-08",
      "transport": "rest",
      "base_url": "https://[domaine].fr/ucp/v1"
    }
  ],
  "capabilities": [
    "dev.ucp.checkout",
    "dev.ucp.order"
  ],
  "extensions": [],
  "payment_handlers": [],
  "auth": {
    "oauth2": null
  }
}

Tu peux faire pareil sur ta boutique : curl https://ton-shop.com/.well-known/ucp te sort le tien. Regarde-le.

Trois choses sautent aux yeux quand tu lis ça avec la doc UCP 2026-04-08 à côté.

extensions est un tableau vide. Aucune capability métier exposée. Pas de loyalty, pas d’abonnement, pas de fulfillment custom, pas de discount. Pour un agent qui cherche “un shop qui accepte les cartes cadeau Cdiscount” ou “un shop qui fait BOPIS sur Paris”, la réponse est : skip.

payment_handlers est aussi vide. Shopify n’expose pas par défaut les méthodes de paiement actives (Shop Pay, Google Pay, Klarna, CB) dans le manifest. Sans cette info, un agent ne sait pas s’il peut finaliser le checkout, et il préfère un concurrent qui l’expose.

auth.oauth2 est null. La capability identity link n’est pas active. L’agent ne peut pas relier l’identité utilisateur au shop pour appliquer un compte fidélité ou retrouver des commandes passées. Pour un shop qui mise sur la rétention (le reconditionné a des cycles de rachat de 18-24 mois), c’est une perte d’attribution énorme.

C’est le contexte. À partir de là, je vais auditer sept points qui couvrent : le manifest lui-même, les attributs produit, le tracking, et les spécificités françaises ESS.

Les 7 trous qu’on va mesurer

Trou n°1 : Signing keys absentes

Ce qu’on cherche. UCP 2026-04-08 introduit un champ optionnel mais déterminant pour la confiance agent : signing_keys. C’est l’URL d’une JWKS (JSON Web Key Set) qui permet à l’agent de vérifier cryptographiquement que les manifestes signés par ce shop sont légitimes, et de valider les signatures AP2 retournées en checkout. Sans cette URL, un agent en mode “high trust” (Gemini, Le Chat) classera ton shop en “non-vérifié” et te rétrogradera dans son ranking. Les agents en mode “low trust” (la majorité aujourd’hui) ignoreront ce signal, mais le différentiel se creusera dès Q3 2026 quand les retailers premium passeront tous en signed.

Ce qu’on regarde concrètement. Présence du champ signing_keys dans le manifest. Si présent, vérification que la JWKS est servie en HTTPS, qu’elle expose au moins une clé RSA-2048 ou Ed25519, qu’elle a un kid stable, et que la rotation est documentée. Pour ce shop : champ absent. Coût du fix : faible techniquement, mais nécessite de générer une paire de clés, de les stocker proprement (idéalement dans un KMS type AWS KMS ou Cloudflare KMS), et de les exposer via un endpoint dédié sur le custom domain.

Hypothèse de gravité. Faible aujourd’hui, modérée à 12 mois. Si la spec UCP impose signing_keys en required dans 2026-10-08 (probable selon les discussions GitHub), ça devient bloquant. Action recommandée : implémenter avant fin Q3 2026.

Trou n°2 : Payment handlers vides

Ce qu’on cherche. Le champ payment_handlers doit lister les méthodes de paiement actives sur le shop, avec leur type d’instrument. Shopify connaît cette info (elle est dans Shopify Payments → Payment methods), mais ne la pousse pas dans le manifest auto-généré. L’agent qui veut finaliser un checkout en ready_for_complete doit savoir s’il peut le faire avec les credentials qu’il porte (carte Visa tokenisée, Google Pay, Apple Pay, Klarna). Sans ça, il route le user en requires_escalation, ce qui ajoute une friction et fait chuter la conversion agentique.

Ce qu’on regarde concrètement. Diff entre les méthodes actives dans l’admin Shopify et le contenu du manifest. Pour ce shop : 6 méthodes actives en admin (CB via Shopify Payments, Shop Pay, Google Pay, Apple Pay, PayPal, Klarna 4x), 0 dans le manifest. Le fix passe par une app qui patch le /.well-known/ucp via App Proxy Shopify (pattern documenté dans la spec UCP §3 et la doc Shopify Engineering UCP) et synchronise les payment_handlers automatiquement.

Hypothèse de gravité. Élevée immédiate. C’est probablement le facteur n°1 d’invisibilité agentique pour les shops Shopify FR aujourd’hui. Action : prioriser, ça se règle en deux jours-dev.

Trou n°3 : Schema.org Organization absent ou incomplet

Ce qu’on cherche. Le manifest UCP est consommé par les agents commerciaux, mais l’identité de la marque est consommée par les modèles de fond (ChatGPT, Gemini, Le Chat) qui décident quels marchands recommander. Cette identité passe par le schema.org Organization injecté dans le <head> de la home page, et idéalement complété par un LocalBusiness ou Store selon ton statut. Pour un acteur ESS, le nonprofitStatus de schema.org (étendu par les Google Knowledge Graph guidelines) est un signal fort.

Ce qu’on regarde concrètement. Présence d’un bloc <script type="application/ld+json"> avec @type: "Organization". Champs critiques : name, url, logo, sameAs (liens vers profils sociaux et Wikipedia si applicable), taxID ou SIREN exposé via identifier, nonprofitStatus. Pour un reconditionné : ajouter additionalType pointant vers une URL définissant l’activité (schema.org/PreOwnedRetailer n’existe pas officiellement mais les Google Merchant guidelines acceptent les types extensifs).

Pour ce shop : Organization présent mais minimal (name, url, logo seulement). Pas de sameAs, pas de taxID, pas de nonprofitStatus. Le shop a une page Wikipedia (français), elle n’est pas linkée. Le shop est ESS, ce n’est pas exposé.

Hypothèse de gravité. Modérée. L’impact direct sur le checkout agentique est faible, mais l’impact sur le ranking dans les modèles de fond est significatif et compound dans le temps. Une marque ESS qui ne signale pas son statut ESS rate le filtre “achat responsable” qui devient un critère explicite chez Le Chat et Gemini depuis Q1 2026.

Trou n°4 : Indice de réparabilité non exposé

Ce qu’on cherche. C’est le trou spécifiquement français, et c’est aussi le plus intéressant éditorialement. Depuis janvier 2021, les fabricants et distributeurs français doivent afficher l’indice de réparabilité sur 5 catégories de produits électroniques (smartphones, ordinateurs, TV, lave-linge, tondeuses). Depuis 2024, l’indice de durabilité remplace progressivement l’indice de réparabilité sur les TV et lave-linge. Pour un acteur du reconditionné, c’est un argument de vente clé : “ce smartphone reconditionné a un indice de réparabilité de 8,2/10, garanti 24 mois”.

Le problème : aucun de ces indices n’est exposé dans schema.org Product, dans Google Merchant Center, ni dans le manifest UCP par défaut. Quand un agent répond à un user qui demande “trouve-moi un téléphone reconditionné facile à réparer”, le shop FR qui a fait le boulot d’évaluation est invisible face à un Back Market international qui ne l’a pas fait. C’est un cas d’école d’asymétrie réglementaire qui se retourne contre les acteurs vertueux.

Ce qu’on regarde concrètement. Présence d’un metafield produit repair_index ou équivalent sur les SKUs concernés. Mapping vers un attribut custom UCP via une extension namespacée : fr.[domaine].repairability (par exemple). Documentation publique de l’extension dans le manifest pour qu’un agent capable la consomme.

Pour ce shop : indices saisis dans le PIM interne, présents en frontend (affichés sur les fiches produit conformément à la loi), mais pas exposés en metafield Shopify, pas dans schema.org, pas dans UCP. La donnée existe et est invisible aux machines.

Hypothèse de gravité. Faible court terme (peu d’agents savent encore filtrer là-dessus), élevée à 18 mois. Et c’est précisément le type de différenciation où une boutique FR mid-market peut prendre une avance défendable contre un concurrent international, à condition de l’exposer proprement. Action recommandée : créer une extension UCP fr.[domaine].repairability et la pusher dans le manifest. Travail de spec : 1 semaine. Implémentation : 2-3 semaines selon volume.

Trou n°5 : Bundles incompatibles avec le checkout agentique

Ce qu’on cherche. Le shop vend pas mal de bundles (smartphone + coque + chargeur, ordinateur + souris + sacoche). Sur Shopify, ces bundles sont gérés via deux mécanismes possibles : Shopify Bundles natif (depuis 2023) ou des apps tierces type Bundler ou Fast Bundle. UCP 2026-04-08 supporte les line items composites via une extension dev.ucp.bundle mais Shopify ne pousse pas cette extension dans le manifest auto-généré, et beaucoup d’apps bundle tierces ne sérialisent pas leurs bundles en line items composites, elles passent en hack via des produits virtuels.

Conséquence : quand un agent veut acheter “le pack iPhone reconditionné + accessoires” via UCP, soit il ne voit qu’un produit virtuel sans les composants détaillés (impossible de répondre aux questions du user sur les éléments individuels), soit il route en requires_escalation parce qu’il ne sait pas calculer les taxes correctement sur un produit composite. Dans les deux cas, conversion qui chute.

Ce qu’on regarde concrètement. Inventaire des bundles existants. Pour chacun, mécanisme de gestion sous-jacent (Shopify Bundles natif, app tierce, hack manuel). Test d’une session UCP simulée sur un bundle : l’agent peut-il récupérer la liste des composants ? Le total se calcule-t-il correctement ? Pour ce shop : ~340 bundles actifs, mix de Shopify Bundles natif (60 %) et d’une app tierce qui passe en hack (40 %). Les 40 % “hack” sont actuellement invisibles aux agents.

Hypothèse de gravité. Modérée. Le revenu impacté direct est mesurable (les bundles font ~12 % du chiffre du shop), et le fix demande soit une migration vers Shopify Bundles natif, soit une intervention sur l’app tierce pour qu’elle expose proprement les composites. Action recommandée : migrer les 40 % vers Shopify Bundles natif d’ici la rentrée.

Trou n°6 : Tracking GA aveugle au trafic agent

Ce qu’on cherche. C’est le sujet de l’article #1, on le décline ici en mesure concrète. Sur un mois de référence, on segmente le trafic GA4 du shop par source/medium et on isole les sessions qui correspondent à des patterns agentiques connus : referrer vide + user-agent contenant “GPTBot”, “ChatGPT-User”, “PerplexityBot”, “Google-Extended”, “MistralAI-User”, “ClaudeBot”, “OAI-SearchBot”, “Anthropic-User”. On compare à la part attribuée correctement dans GA (typiquement nulle parce que ces sources tombent en “direct” ou “(other)”).

Ce qu’on regarde concrètement. Logs serveur Cloudflare ou nginx croisés avec les events GA4. Webhooks Shopify orders/create enrichis avec un parsing du client_details.user_agent et du landing_site_ref. Pour ce shop : audit en cours sur avril 2026, premier signal : environ 4 % du trafic du shop arrive avec un user-agent agent IA détectable, et zéro de ces sessions n’est attribuée à une source IA dans GA4. Donc 100 % du trafic IA détectable est aujourd’hui mal attribué. À mettre en perspective : 4 % du trafic d’un shop qui fait plusieurs millions, c’est un volume non-négligeable.

Hypothèse de gravité. Élevée immédiate pour la qualité du pilotage marketing, modérée pour le revenu direct. Sans visibilité, impossible d’investir intelligemment dans les contenus qui nourrissent les agents. Action : implémentation d’un tracking server-side via Shopify Pixel API + parsing systématique du user-agent dans les webhooks order. Coût : 5-8 jours-dev pour un setup propre.

Trou n°7 : Reviews non structurées en schema.org

Ce qu’on cherche. Les agents pondèrent fortement les reviews dans leurs recommandations produit, surtout sur le reconditionné où la qualité d’état est l’angoisse n°1 du consommateur. Pour qu’un agent extraie correctement les reviews de ton shop, il faut qu’elles soient sérialisées en schema.org/Review ou agrégées en AggregateRating, idéalement avec les champs author, datePublished, reviewBody, reviewRating complets. La majorité des apps reviews Shopify (Judge.me, Yotpo, Loox, Stamped) injectent du schema.org, mais avec des trous fréquents : pas de datePublished, ou des reviews tronquées à 200 caractères, ou des champs author génériques (“client vérifié”).

Ce qu’on regarde concrètement. Sur une page produit échantillon, extraction du schema.org Review ou AggregateRating, validation via le Rich Results Test de Google, et inspection des champs présents/absents. Pour ce shop : utilise une app reviews populaire FR, schema injecté mais datePublished manquant sur 100 % des reviews et reviewBody tronqué à 250 caractères. Au total, sur les 50 000 SKUs, on estime à environ 180 000 reviews mal structurées.

Hypothèse de gravité. Modérée à élevée selon la catégorie. Sur le reconditionné, où la review est l’argument central, c’est probablement un facteur de ranking critique chez les agents. Le fix passe par une discussion avec l’éditeur de l’app reviews ou par une réécriture du schema injecté via theme.liquid. Coût : 2-4 jours-dev.

Ce qu’on attend de l’avant/après

Voici les hypothèses chiffrées qu’on va vérifier dans les 60 jours qui suivent les correctifs. Je publie les hypothèses avant de mesurer les résultats parce que c’est la seule manière honnête de faire un case study : si je ne les pose pas maintenant, je vais ajuster mes hypothèses aux résultats post-hoc et le case study deviendra du marketing déguisé.

MétriqueBaseline (état actuel)Hypothèse post-fix (60j)Méthode de mesure
Score complétude manifest UCP~40/100 (estimation v0)>90/100UCP Validator open-source ou interne
% de SKUs avec schema.org Product complet~55%>95%Crawl interne + Rich Results Test
% du trafic IA correctement attribué dans GA4~0%>80%Cross-check logs serveur vs GA4
Conversion sur les sessions agent IA détectéesnon mesurée actuellementbaseline à mesurerWebhooks order + parsing UA
Volume de checkouts UCP en ready_for_complete vs requires_escalationnon mesuré<20% requires_escalationLogs UCP côté shop

Je publierai les chiffres réels mi-juillet 2026, avec un article de suivi dédié. Si certaines hypothèses ne se confirment pas, je le dirai aussi. C’est le deal du case study public.

Pourquoi tu peux faire ça toi-même cette semaine

L’audit complet sur ce shop va prendre 6 semaines avec une équipe de trois personnes (un dev backend, un data analyst, un PM côté marchand). Tu n’as pas besoin d’aller aussi loin pour démarrer. Voici la version réduite que tu peux dérouler en une journée si tu es solo et technique.

Une heure le matin pour curl ton manifest UCP et lister les champs vides. Tu prends une feuille, tu notes : extensions, payment_handlers, auth, signing_keys. Pour chaque champ vide, tu écris ce que ça devrait contenir au minimum vu ton activité.

Une heure ensuite pour valider ton schema.org Organization et un échantillon de 10 fiches produit dans le Rich Results Test de Google. Tu notes les warnings et les errors. Si tu vois “missing field datePublished” répété, tu sais que ton app reviews est en cause.

Une heure pour un export rapide de ton catalogue : combien de SKUs ont leurs metafields produit complets sur les attributs métier (matière, origine, dimensions, indice de réparabilité si applicable). Tu calcules le pourcentage. Si tu es sous 60 %, c’est ta priorité absolue.

Une heure pour un segment GA4 : trafic des 30 derniers jours par source/medium, en isolant “direct / (none)” et “(other)”. Tu compares à H1 2025. Si la part a augmenté de plus de 25 %, tu as du trafic IA non attribué.

Une demi-journée pour synthétiser ces quatre mesures dans une note de cadrage de 2 pages, identifier les 2-3 fixes prioritaires, et caler une mini-feuille de route 60 jours avec ton équipe ou ton agence.

Ce n’est pas un audit complet. C’est un audit de débroussaillage qui te donne une carte du territoire et un ordre de grandeur. Pour 80 % des marchands mid-market FR, c’est suffisant pour démarrer.

La checklist 30 points

J’ai compilé une checklist de 30 points qui couvre les 7 trous ci-dessus en version actionable pour une équipe non spécialiste UCP. Format PDF, 4 pages, organisée en 5 sections : Manifest UCP, Catalog & Schema, Tracking & Attribution, Spécificités FR (réparabilité, ESS, TVA), Mesure post-fix.

Télécharger la checklist 30 points (PDF) →

Tu peux l’utiliser sans m’en parler. Si tu veux passer à l’étape supérieure, deux options.

L’auditeur automatique gratuit sur agent-ecommerce.fr pose les 12 premiers points de la checklist en lecture automatique sur ton domaine, en moins de 60 secondes. Il te sort un rapport HTML que tu peux partager à ton équipe. C’est l’entrée la plus simple : tu rentres ton URL, tu obtiens un score sur 100 et une priorisation des fixes. Tester l’auditeur →

L’audit complet à la manière de ce case study, avec une équipe pour piloter les 18 points qui demandent une investigation manuelle (les 18 derniers de la checklist 30). Format : 4-6 semaines, prix sur devis selon volume catalogue, livrable type rapport + plan de remédiation + accompagnement implémentation. C’est ce qu’on a fait sur le shop reconditionné de cet article. Prendre un appel découverte de 30 minutes →

Mise à jour mi-juillet 2026

Je reviendrai mi-juillet avec les chiffres réels post-correctifs sur ce shop. Si tu veux être notifié quand l’article #2bis sort, abonne-toi à la newsletter, c’est le seul canal où je publierai la suite avant les autres.

Les chiffres pourraient être moins beaux que mes hypothèses. Ils pourraient être meilleurs. C’est le point de l’exercice : je note maintenant, je mesure dans 60 jours, je publie sans filtre. Si la méthode marche pour ce shop, elle marchera pour la plupart des mid-market FR comparables. Si elle ne marche pas, j’ai d’autres choses à apprendre, et je les publierai aussi.

Note méthodologique. Cet article décrit un audit en cours sur un client réel, anonymisé à sa demande. Les hypothèses chiffrées sont des estimations basées sur les premiers signaux remontés au 8 mai 2026 et sur les ordres de grandeur observés sur des shops comparables. Les résultats finaux seront publiés mi-juillet 2026 avec les écarts par rapport aux hypothèses initiales. Les références à UCP 2026-04-08 proviennent de la spécification publique sur ucp.dev et github.com/Universal-Commerce-Protocol/ucp. Les références aux indices de réparabilité et durabilité français sont issues du décret 2020-1757 et de la documentation ADEME / écologie.gouv.fr.

À propos. agent-ecommerce.fr accompagne les e-commerçants Shopify français dans leur passage au commerce agentique. Audits UCP, enrichissement catalogue, tracking server-side, formation équipes. Articles précédents : UCP en 2026, ce que ton mid-market doit comprendre. Suivi du sujet : newsletter hebdo →