# agent-ecommerce.fr — Index plein texte Mis à jour : 2026-04-28 ## À propos agent-ecommerce.fr est le site SaaS et blog de référence francophone sur l'agentic commerce. On s'adresse aux e-commerçants français à partir de 10k€/mois de CA. Ton "expert calme" : pas de hype, pas de paternalisme, du tutoiement partout. Trois objectifs en parallèle : 1. SEO via articles cornerstone sur UCP, AP2, MCP, attribution agentique, RGPD agentic 2. Showcase d'apps Shopify (audit gratuit + app attribution server-side) 3. Lead gen via newsletter, audit form, pricing transparent ## Le contexte qui justifie l'urgence - UCP (Universal Commerce Protocol) version 2026-04-08 sortie le 8 avril 2026 - Shopify a activé Agentic Storefronts par défaut sur 5,6M boutiques en mars 2026 - Croissance ×11 des commandes Shopify attribuées à l'IA (jan 2025 → mars 2026, source Shopify NRF) - +393% de trafic IA vers les sites retail Q1 2026 vs Q1 2025 (Adobe Digital Insights) - 82% des e-commerçants français utilisent l'IA générative en 2025 (FEVAD) ## Architecture UCP en couches Six couches : - Couche 01 : Surfaces consommateurs (Gemini, ChatGPT, Copilot, Voice) - Couche 02 : Agents IA / Shopping agents - Couche 03 : UCP core — capabilities et extensions (Checkout, Identity, Order, Discount, Fulfillment, Loyalty) - Couche 04 : Transport (REST, JSON-RPC 2.0, MCP, A2A) - Couche 05a : Auth (OAuth 2.0 + PKCE) - Couche 05b : Paiement (AP2 mandates) - Couche 06 : Merchant backend (Shopify, Etsy, BigCommerce, Custom) ## Le problème N×N que UCP résout Avant UCP, chaque agent IA devait intégrer chaque marchand en custom. À 100 agents × 1 000 marchands : 100 000 intégrations. UCP transforme ça en N+N : 1 100 connexions, soit 100× moins. ## Le trou d'attribution agentic Dans les checkouts agentic embedded (Gemini, Copilot, ChatGPT en redirect), les pixels JavaScript ne se déclenchent pas. La seule façon de capturer ces commandes : server-side. Webhook Shopify orders/create → push vers GA4 Measurement Protocol, Meta CAPI, Klaviyo events, TikTok Events API. ## Pricing app Attribution - Lite : 49€/mois — 500 commandes agentic/mois, 1 destination, dashboard standard, audit mensuel, support email - Starter : 99€/mois — 2 000 commandes/mois, 2 destinations - Growth (recommandé) : 249€/mois — 10 000 commandes/mois, destinations illimitées, dashboard custom + alertes, audit hebdo, support prioritaire - Scale : 499€/mois — commandes illimitées, multi-store, API access, SLA 99.9%, support dédié Free trial 14 jours sur tous les plans, sans CB. Hébergement EU (Coolify VPS Paris), conforme RGPD. ## Articles publiés ### On a audité le manifest UCP de 41 boutiques Shopify FR. Elles sont toutes identiques. URL : https://agent-ecommerce.fr/blog/audit-manifest-ucp-50-shopify-fr Date : 2026-06-12 Tags : ucp, shopify, manifest, audit, agentic-commerce Lecture : 14 min Étude originale : 83 candidates testées, 45 confirmées Shopify, 41 manifests UCP exploitables, zéro qui passe la validation au-delà du minimum spec. Pourquoi, et ce que tu peux faire avant que ça change. ## Hook On a fetché `/.well-known/ucp` sur 83 boutiques DTC françaises mid-market. 45 sont confirmées Shopify. 41 exposent un manifest UCP parsable. Sur ces 41, **0 ne passe la validation au-delà du minimum spec**. Et le plus troublant : les 41 manifests sont **structurellement identiques au bit près**. Mêmes 8 capabilities, mêmes 2 handlers de paiement, tailles de fichier dans une fenêtre de 83 bytes (3600-3683). Aucune marque française n'a customisé son manifest. Le marché FR n'a pas commencé à toucher à UCP. Cet article décrit la méthodologie, les cinq patterns d'erreur observés, pourquoi Shopify laisse ces trous, et le fix concret par pattern. La donnée brute (`02-manifests-raw.json`, `03-validation.json`) et les scripts de reproduction sont publiés à la fin. ## Méthodologie L'étude a été conduite le 28 avril 2026, sur la spec UCP `2026-04-08`. **Sourcing**. 83 candidates DTC/mid-market FR sélectionnées pour leur visibilité dans le marché : mode (Sézane, Polène, Asphalte, Loom, Rouje, Jacquemus, Maison Kitsuné, Ami Paris…), beauté (Typology, La Rosée, Respire, Oh My Cream, Buly 1803…), foyer (Tediber, Emma…), accessoires (Cabaïa, Bobbies, Izipizi, Jimmy Fairly…), kids (Bonton, La Petite Étoile…). Marques connues à des stades variés : du small brand (Loom, Caval, Patine) aux Shopify Plus (Sézane, Rouje, Jacquemus). **Confirmation Shopify**. Pour chaque domaine, GET de la homepage avec User-Agent identifiable et inspection des marqueurs HTML (`cdn.shopify.com`, `Shopify.theme`, `shopify-section`, `ShopifyAnalytics`) et des headers (`x-shopify-shop-id`, `x-shopify-stage`, `powered-by`). Sur 83 candidates, 45 sont fingerprintées Shopify. Les 38 restantes sont sur Salesforce Commerce Cloud (Petit Bateau, Aigle, Repetto, Le Coq Sportif, Le Tanneur), Magento, ou des stacks custom — exclues du périmètre. **Fetch manifest**. Pour chaque domaine confirmé Shopify, GET `https://{domain}/.well-known/ucp` avec timeout 12s, redirect follow, concurrency 5. Capture du status HTTP, content-type, body, durée, et chaîne de redirection. Stockage brut dans `02-manifests-raw.json`. **Validation 3 niveaux**. Trois niveaux dérivés de la spec `2026-04-08`, du moins exigeant au plus exigeant : - **Niveau 1 — Structurel.** Le manifest est un JSON parsable, contient `version` ∈ versions UCP connues, `services` avec un transport `mcp` exposant un `endpoint` HTTPS, `capabilities` non vide avec chaque entrée portant `version/spec/schema`, `payment_handlers` non vide. - **Niveau 2 — Identité & customisation.** Au-delà du minimum spec : présence d'un bloc `merchant` (nom, identifier, pays, contact support), `signing_keys` au format JWK, `agent_profile_url`, et **customisation au-delà du baseline auto-gen Shopify** (capabilities ou handlers ajoutés par le marchand). - **Niveau 3 — Network & cohérence cryptographique.** Endpoints atteignables (MCP, schémas, supported_versions), JWK cryptographiquement cohérents (kty/crv/alg consistants). Les scripts de validation sont open : `scripts/fetch-manifests.ts` et `scripts/validate.ts`, tout en TypeScript natif Node 22 sans dépendance npm. Tu peux relancer toi-même. > **Honnêteté méthodologique.** La spec `2026-04-08` n'impose pas formellement `merchant` ou `signing_keys` au top-level. Notre L2 mesure la *qualité* attendue d'un marchand qui veut être correctement représenté par un agent IA — pas un strict respect spec. C'est volontaire. Un manifest L1-only est techniquement valide mais sémantiquement vide pour un agent. ## Le résultat global | Niveau | Boutiques qui passent | % | |---|---|---| | L0 (présence + parsable) | 41 / 45 | 91 % | | L1 (structurel) | 41 / 45 | 91 % | | L2 (identité & customisation) | 0 / 45 | **0 %** | | L3 (network & crypto) | 0 / 45 | **0 %** | 41 manifests sur 41 sont **byte-identiques au niveau structurel**. Mêmes versions supportées (`2026-01-23` et `2026-04-08`), mêmes 8 capabilities, mêmes 2 payment handlers (`com.google.pay` et `dev.shopify.card`), tailles de 3600 à 3683 bytes. La seule chose qui varie d'un shop à l'autre, c'est le subdomain `*.myshopify.com` dans les URLs des endpoints. Le reste est un template. Quatre boutiques Shopify ne passent pas L0 : trois retournent du HTML (la page 404 du thème) au lieu d'un JSON, et une retourne explicitement 404. Ces shops sont **invisibles aux agents IA** au sens UCP, soit parce qu'Agentic Storefronts est désactivé en admin, soit parce qu'ils n'ont pas reçu la feature flag. ## Les cinq patterns d'erreur (et leur fréquence) Tous les manifests présents échouent **sur les neuf mêmes checks L2, exactement**. Ce ne sont pas des bugs de marchands. C'est le scope de l'auto-gen Shopify qui n'inclut pas ces champs. Voici les cinq plus impactants. ### Pattern 1 — Aucun bloc `merchant` (41/41, 100 %) Le manifest auto-gen Shopify ne contient aucun bloc `merchant`. Pas de nom de marque. Pas d'identifier stable (URN, URI). Pas de pays (ISO 3166-1). Pas de contact support. Si un agent IA reçoit le manifest de Polène, Rouje ou Sézane, il ne peut **pas savoir, depuis le manifest seul**, qu'il parle à une marque française de maroquinerie ou de mode. Il déduit de l'hostname et fait confiance à Shopify sur le reste. Pour un marchand, ça veut dire que le moteur de l'agent ne peut pas appliquer de logique brand-aware (filtrage par pays de fabrication, par segment, par positionnement) sans aller chercher l'info ailleurs. Et pour l'utilisateur final qui demande "trouve-moi une marque française de maroquinerie sous 300 €", l'agent doit deviner ou cross-référencer avec sa propre base. ### Pattern 2 — Aucun `signing_keys` (41/41, 100 %) Pas de JWK publique exposée. Aucun marchand FR ne signe cryptographiquement les réponses MCP qu'il renvoie aux agents. Concrètement, un agent qui veut vérifier qu'une réponse de catalog ou de checkout vient bien du shop déclaré, et n'a pas été altérée en transit par un middleman, **ne peut pas**. Il fait confiance à TLS et c'est tout. Pour le moment, ce n'est pas un casus belli — la chaîne TLS suffit dans 99 % des cas. Mais AP2 (Agent Payments Protocol) attend des mandats signés, et la non-répudiation des transactions agentiques va devenir un sujet dans les 12 mois. Les premiers chargebacks contestés en mode "ce n'est pas moi qui ai autorisé" vont mettre la pression sur la signature manifeste. Les marchands FR n'ont pas commencé à se poser la question. ### Pattern 3 — Aucun contact support déclaré (41/41, 100 %) Pas d'email, pas d'URL de contact dans le manifest. Or UCP prévoit un mode `requires_escalation` dans le state machine du checkout : quand l'agent rencontre une situation qu'il ne peut pas trancher (3DS, ambiguïté de stock, dispute sur une promotion), il doit pouvoir adresser un humain. Sans contact support exposé, l'escalation est impossible côté agent. Le user est renvoyé vers le shop par redirection web, ce qui casse la conversation. ### Pattern 4 — Capabilities limitées au baseline Shopify (41/41, 100 %) Tous les manifests exposent strictement les huit mêmes capabilities : ``` dev.shopify.catalog.storefront dev.ucp.shopping.cart dev.ucp.shopping.catalog.lookup dev.ucp.shopping.catalog.search dev.ucp.shopping.checkout dev.ucp.shopping.discount dev.ucp.shopping.fulfillment dev.ucp.shopping.order ``` Aucune extension custom. Si tu vends en abonnement (Aime, Patyka, Nuoo dans notre échantillon ont des modèles d'abonnement actifs), `dev.ucp.shopping.subscriptions` n'apparaît pas. Si tu as un programme de fidélité (Cabaïa, Oh My Cream, Sézane), `dev.ucp.shopping.loyalty` non plus. Si tu fais du B2B en parallèle (Asphalte, Bonne Gueule), pas de capability dédiée. Si tu proposes du click & collect ou des points relais (très répandu en FR), rien. Concrètement : **un agent ne peut pas découvrir tes capabilities différenciantes depuis ton manifest**. Il découvre le minimum commun à tous les shops Shopify. Ton avantage compétitif sur ces capacités est invisible. ### Pattern 5 — Payment handlers limités (41/41, 100 %) Tous les manifests déclarent strictement deux handlers : `com.google.pay` et `dev.shopify.card`. Pas d'Apple Pay (pourtant activé sur la quasi-totalité des shops FR mid-market que j'ai testés en checkout réel). Pas de Klarna, pas de Alma, pas de PayPal, pas de Shop Pay, pas d'Adyen, pas d'Affirm, pas de virement SEPA. Or le paiement fractionné est une attente forte du marché FR (Alma a 14 % de pénétration sur certains panels DTC selon les données 2025), et son absence du manifest signifie que l'agent ne peut pas le proposer dans la conversation. Conséquence : **un user qui demande à son agent IA "paie en 4x" sur un shop FR ne se verra pas proposer Alma, parce que le manifest dit que le shop ne supporte que GPay et la carte Shopify**. Faux du point de vue du checkout réel. Vrai du point de vue de l'agent. ## Les bonnes surprises Aucune. Sur 41 manifests, zéro a customisé. Pas un. Pas même Sézane, pas Polène, pas Tediber, pas Typology, pas une seule marque mid-market FR sérieuse n'a poussé un manifest qui dépasse l'auto-gen Shopify. C'est en soi le résultat le plus remarquable de l'étude : **le marché FR n'a pas commencé**. Pour qui cherche un avantage compétitif tangible, c'est une fenêtre. La première marque FR qui publie un manifest correctement enrichi (merchant block, signing keys, capabilities customs) sortira du lot mécaniquement dans le ranking agent — pas par un effet brand mais par un effet data quality. Le coût technique est de l'ordre de quelques jours-développeur. Le coût d'opportunité de ne pas le faire augmente chaque mois où les agents IA capturent une part croissante du discovery e-commerce. ## Détail technique notable : le leak `*.myshopify.com` Tous les manifests, sans exception, exposent l'endpoint MCP via le subdomain `*.myshopify.com` du shop, jamais via le custom domain. Exemples observés (anonymisés) : - Une boutique de lunetterie mid-market FR → `test-store20.myshopify.com` (le shop a été créé depuis un store de test, le handle n'a jamais été renommé) - Plusieurs marques ont des handles avec `-prod`, `-shop`, `-store`, `-2023`, `-eyewear` qui révèlent l'organisation interne ou des renommages historiques - Certains shops exposent un handle qui ne correspond pas à la marque visible côté user (effet d'acquisition, de réorganisation ou d'agence qui a setup le compte) Ce n'est pas catastrophique en termes de sécurité — les `*.myshopify.com` sont publics par design. Mais c'est un leak de cohérence brand : la conversation entre l'agent et ton shop ne passe pas par `tamarque.fr`, elle passe par `tamarque-shop-2023.myshopify.com`. Si ta marque est suffisamment connue, cette dissonance se voit dans les logs des agents et peut prêter à confusion sur l'identité de l'interlocuteur. ## Pourquoi Shopify laisse ces trous Trois hypothèses, sans Shopify-bashing. **1. UCP est jeune.** La spec a été stabilisée le `2026-04-08`. Shopify a activé un manifest baseline pour que les agents *voient quelque chose* sur tout shop, pas pour produire un manifest complet. C'est un MVP côté plateforme. La même approche a été prise pour les structured data Schema.org en 2012 : Shopify a activé un set minimal automatique, et a laissé l'enrichissement aux thèmes et aux apps. **2. L'identité, c'est le territoire du marchand.** Shopify n'a pas l'autorité pour publier `merchant.country`, `merchant.support`, `signing_keys` sans demander au marchand. Ces champs nécessitent une UI admin (formulaire dans le dashboard) que Shopify n'a pas encore livrée pour la France. Aux US, les Agentic Storefronts en early access ont commencé à exposer un sous-ensemble de ces champs depuis fin mars, mais le rollout complet n'est pas planifié avant Q3 2026. **3. Trade-off scale vs richesse.** Auto-générer pour 5,6 millions de boutiques signifie un template uniforme et stable, pas un manifest bespoke par shop. La richesse vient ensuite par deux voies : soit Shopify livre une UI d'enrichissement dans l'admin (coûteux à développer, à localiser, à supporter), soit l'écosystème d'apps Shopify livre la couche de personnalisation. Historiquement, c'est toujours l'écosystème qui gagne sur ce genre de feature. Donc ne le prends pas comme un trou bouché demain par Shopify. Prends-le comme un espace ouvert pour les marchands qui acceptent d'investir un peu de temps technique maintenant, avant que la plateforme ne ferme la boucle. ## Le fix par pattern Trois options techniques pour publier un manifest UCP custom sur un shop Shopify, du plus léger au plus engageant : 1. **Worker en bord de réseau** (Cloudflare Worker, Vercel Edge Function, etc.) qui intercepte `/.well-known/ucp` au niveau DNS et renvoie un JSON enrichi. Couvre le custom domain. Ne touche pas Shopify. Recommandé si tu n'as pas d'app dédiée. 2. **App Proxy Shopify** qui répond sur une route dédiée au domaine du shop. Plus complexe à setup mais reste dans l'écosystème Shopify. 3. **Reverse proxy custom** sur ton infra (si tu en as une devant le shop, ce qui est rare en mid-market mais existe en Shopify Plus avec edge custom). Pour les fixes techniques eux-mêmes, voici le minimum à publier en complément de l'auto-gen. ### Fix 1 — bloc `merchant` ```json { "ucp": { "merchant": { "name": "Ta Marque", "identifier": "urn:brand:ta-marque-paris", "country": "FR", "languages": ["fr", "en"], "support": { "email": "support@ta-marque.com", "url": "https://ta-marque.com/contact", "phone": "+33 1 XX XX XX XX" }, "tax_jurisdictions": ["FR", "EU"], "vat_id": "FR12345678901" } } } ``` `identifier` doit être stable dans le temps (ne change pas si tu migres de plan ou de domaine). Préférer un URN à une URL. `support.email` est exigé pour les escalations agentiques. ### Fix 2 — `signing_keys` Génère une paire ECDSA P-256, publie la JWK publique, signe les réponses MCP côté backend. ```json "signing_keys": [ { "kty": "EC", "crv": "P-256", "x": "...", "y": "...", "kid": "ta-marque-2026-06", "alg": "ES256", "use": "sig" } ] ``` Roule la clé au moins une fois par an, garde la précédente dans le manifest pendant la fenêtre de transition. Le `kid` (key ID) doit être unique et auditable dans tes logs. ### Fix 3 — `agent_profile_url` Une URL HTTPS qui pointe vers une fiche JSON-LD Organization étendue : logo, description, certifications (B-Corp, Origine France Garantie, ESS), valeurs de marque, segments produits, références clients ou presse. C'est la "carte de visite" lue par l'agent au-delà du strict commerce. Cette page peut être un endpoint de ton CMS, un static file généré au build, ou une route dédiée sur le shop. L'important est qu'elle soit stable et consommable JSON. ### Fix 4 — capabilities customs Ajoute au minimum les capabilities qui correspondent à ce que tu vends réellement : - `dev.ucp.shopping.subscriptions` si tu as des abonnements - `dev.ucp.shopping.loyalty` si tu as un programme fidélité - Extensions custom pour B2B, points relais, click & collect - `dev.ucp.shopping.b2b` si tu as un canal grossistes Chaque capability doit pointer vers un schema JSON résolvable. Tu peux héberger les schemas custom sur ton propre domaine (ex: `https://ta-marque.com/.well-known/ucp/schemas/loyalty.json`). ### Fix 5 — payment handlers Déclare honnêtement tous les handlers que tu supportes en checkout : ```json "payment_handlers": { "com.google.pay": [{ ... }], "com.apple.pay": [{ ... }], "com.shop.pay": [{ ... }], "com.klarna": [{ "modes": ["pay_in_3", "pay_in_30"] }], "com.alma": [{ "modes": ["p2x", "p3x", "p4x"] }], "com.paypal": [{ ... }], "dev.shopify.card": [{ ... }] } ``` Surtout pour Alma et Klarna : ces handlers sont structurellement importants pour le marché FR et leur absence du manifest restreint l'expérience proposée par l'agent. ## Limites et reproductibilité **Échantillon**. 41 manifests valides, sous le seuil cible de 50. Trois explications. D'abord, parmi les 83 candidates DTC/mid-market FR connues, 38 ne sont pas Shopify (Salesforce Commerce Cloud, Magento, custom). C'est cohérent avec une part de marché Shopify estimée autour de 50-60 % du DTC mid-market FR. Ensuite, 4 boutiques Shopify ne servent pas de manifest (UCP désactivé en admin ou feature flag absente). Pour atteindre 50 manifests valides, il faudrait étendre à ~15 marques FR supplémentaires (food/wine/spirits, men's grooming, accessoires de niche). Itération possible. **Validation L2 = opinion structurée**. La spec UCP `2026-04-08` ne rend pas `merchant` et `signing_keys` formellement obligatoires. Notre L2 mesure ce qu'on considère comme la qualité minimale pour qu'un manifest soit utile à un agent au-delà du discovery basique. À assumer dans la lecture : ce n'est pas du strict spec compliance, c'est de l'analyse fonctionnelle. **L3 non testé en conditions réelles**. Comme L2 échoue 41 / 41, L3 est skippé par construction (`signing_keys` absent → check L3.5 inopérant). Une itération future pourrait isoler L3.1 (MCP endpoint reachable) et L3.4 (capability schemas resolvables) du gating L2 pour avoir un chiffre indépendant. **Fingerprint Shopify**. Possibles faux négatifs si un shop utilise un reverse proxy qui strippe les headers Shopify. Rare mais existe sur certains shops Plus avec edge custom. Aucun cas clairement identifié dans l'échantillon. ## Annexe — données et scripts publics Les fichiers suivants sont publiés sous `research/ucp-audit-50/` du repo agent-ecommerce.fr : - `01-boutiques.json` — liste des 83 candidates avec secteur et size estimate - `02-manifests-raw.json` — captures HTTP brutes (homepage + manifest), 1.6 Mo - `03-validation.json` — résultats L0/L1/L2/L3 par boutique avec stats agrégées et top errors - `RULES.md` — règles de validation détaillées des trois niveaux - `scripts/fetch-manifests.ts` — script de scraping (Node 22 natif, zéro dépendance npm) - `scripts/validate.ts` — script de validation 3 niveaux Pour relancer l'audit toi-même : ```bash node --experimental-strip-types research/ucp-audit-50/scripts/fetch-manifests.ts node --experimental-strip-types research/ucp-audit-50/scripts/validate.ts ``` Les scripts sont idempotents. Re-runner `fetch-manifests.ts` écrase `02-manifests-raw.json` avec les nouvelles captures, ce qui te permet de tracker l'évolution des manifests Shopify dans le temps. Si tu observes une variation par rapport aux données du 28 avril 2026, on est preneur — on republiera l'étude avec un delta. ## Et après Cette étude est la base d'un outil que je suis en train d'industrialiser : un audit UCP automatisé pour boutique Shopify, qui te dit en deux minutes où ton manifest est en-dessous du minimum exploitable, et te génère le diff exact à appliquer pour passer L2 puis L3. Cet outil sera publié sous le nom **Manifest Auditor** d'ici l'été. Si tu veux y avoir accès en early, tu peux laisser ton email dans le formulaire d'audit ci-dessous. Pas de spam, juste le lien quand c'est prêt. Le sujet UCP en 2026 n'est pas une opportunité brand. C'est une opportunité technique. Les marques FR qui investissent maintenant 2-3 jours-développeur dans l'enrichissement de leur manifest seront représentées proprement par les agents IA dès l'activation française des Agentic Storefronts. Les autres seront un nom dans une liste de 41 manifests strictement identiques. --- ### Optimiser tes fiches produit pour les agents IA : la checklist technique URL : https://agent-ecommerce.fr/blog/optimiser-fiches-produit-agents-ia Date : 2026-05-29 Tags : fiches-produit, schema-org, aeo, agentic-commerce, shopify Lecture : 13 min Les agents IA ne lisent pas tes fiches comme Google. Voici ce qu'ils regardent vraiment, les 8 dimensions à optimiser, et une checklist 30 points pour rendre ton catalogue agentic-ready. ## Hook Tu as passé six mois à optimiser tes titres SEO, à enrichir tes meta descriptions, à pousser tes mots-clés en H2. Et tu te demandes pourquoi tes fiches produit ne ressortent pas quand un user pose une question dans Le Chat ou Gemini sur un produit que tu vends. Réponse : ce que tu as optimisé, c'est la couche d'affichage humain. Ce qu'un agent IA évalue, c'est une autre couche, qui se trouve souvent au même endroit que la précédente, mais qui obéit à des règles différentes. Un agent IA ne lit pas ta fiche produit. Il ne fait pas de scroll, il ne regarde pas tes hero shots, il ne lit pas ton story de marque en pied de page. Il interroge ta fiche comme une API : il cherche des champs structurés, il évalue la cohérence interne, il croise avec d'autres signaux (reviews, retours, prix sur les marketplaces), et il décide en quelques centaines de millisecondes si ton produit est candidat à la recommandation pour l'intention exprimée par le user. Cet article est pour toi si tu es merchandiser, e-commerce manager, ou growth lead chez un mid-market Shopify, et que tu veux rendre ton catalogue agentic-ready sans attendre une refonte de ton stack. Tu vas y trouver le mental model qui change tout, les 8 dimensions critiques sur lesquelles agir, un avant/après concret, les pièges spécifiques aux catalogues volumineux, et une checklist 30 points que tu peux faire tourner sur tes 50 ou 50 000 SKUs. ## Le mental model qui change tout : agent ≠ crawler Quand Googlebot arrive sur ta fiche produit, il fait un travail de bibliothécaire. Il indexe le HTML, extrait les keywords et les entités, regarde les backlinks, et range le tout dans un index inversé. Au moment où un user tape "casque audio bluetooth réduction de bruit pas cher", Google interroge cet index, applique son ranking, et te ressort une liste de pages pertinentes. La pertinence est jugée a posteriori, sur des signaux statiques. Quand l'agent de Le Chat arrive sur ta fiche produit (via UCP, ou via web scraping si tu n'es pas en UCP), il fait un travail différent. Il ne range rien dans un index. Il évalue ta fiche **contre une intention exprimée maintenant**. Le user a dit "je cherche un casque que je peux porter en vélo qui ne tombe pas". L'agent regarde tes attributs, tes specs, tes reviews, et il se pose une question simple : est-ce que ce produit répond à cette intention spécifique ? Le verdict est binaire ou presque : candidat / non candidat. Cette différence a trois conséquences pratiques. **Première conséquence** : la spécificité bat les keywords. Sur Google, un titre comme "Casque Bluetooth Premium - Livraison 24h" peut ranker. Sur un agent, ce titre est inutile. Le mot "Premium" ne porte aucune information évaluable. "Livraison 24h" n'est pas dans le périmètre de la fiche, c'est une politique commerciale. Un agent préférera mille fois "Casque Bluetooth circum-aural - autonomie 30h - réduction de bruit active 25 dB - 240 g" parce que chaque token est une dimension qu'il peut mapper contre l'intention du user. **Deuxième conséquence** : la donnée structurée n'est plus optionnelle. Sur Google, Schema.org est un bonus qui peut faire gagner des rich snippets. Sur un agent, c'est la première chose qu'il consomme. Si ton `Product` JSON-LD n'a pas de `brand`, pas de `gtin`, pas de `offers.price`, pas de `aggregateRating`, l'agent doit reconstruire ces champs depuis le HTML, et chaque reconstruction est une occasion de se tromper. Les agents préfèrent ne pas recommander un produit qu'ils ne comprennent pas avec certitude. **Troisième conséquence** : la cohérence cross-source compte. L'agent ne lit pas que ta fiche. Il vérifie que ce que tu dis sur ta fiche est cohérent avec ce que disent tes reviews Trustpilot, avec ce qu'affichent les marketplaces où tu es présent, avec ce que dit ton manifest UCP. Une incohérence sur un attribut critique (poids différent entre ta fiche et ton flux Google Shopping, par exemple) rétrograde ta fiche dans le ranking interne de l'agent. Personne ne te le dit. Tu disparais juste. Ce mental model posé, on peut regarder les 8 dimensions sur lesquelles agir. ## Les 8 dimensions critiques ### 1. Titre produit : la spécificité bat les keywords Le titre est la première chose que l'agent lit, et c'est aussi le champ le plus mal exploité sur les catalogues mid-market FR. La règle est simple : un titre doit pouvoir répondre à 80 % des questions qu'un user peut se poser sur la nature physique du produit, sans que l'agent ait besoin de descendre dans la description. Format type : **[Catégorie] [Caractéristique structurelle 1] [Caractéristique structurelle 2] [Marque] - [Spec quantifiée] [Spec quantifiée]**. Exemple. Au lieu de "Bottines Cuir Femme - Tendance Hiver 2026", écris "Bottines cuir lisse à talon 5 cm - Marque X - taille 36 à 42 - doublure laine". Tu perds en accroche émotionnelle (que tu peux remettre dans la description), tu gagnes en évaluabilité par un agent. La fiche est candidate à plus de requêtes, et candidate plus pertinemment. Limite de longueur : Shopify accepte jusqu'à 255 caractères dans le titre, Schema.org `name` jusqu'à 1024. Vise 90-140 caractères pour le titre humain, et expose le titre étendu via `additionalProperty` ou `description` si tu veux des specs additionnelles sans encombrer l'UI. ### 2. Attributs structurés : Schema.org Product complet C'est le champ de bataille principal. Un `Product` JSON-LD complet en 2026 contient au minimum : `name`, `description`, `brand` (avec `Organization.name`), `gtin13` ou `mpn`, `image` (array de 4-8 URLs), `offers.price`, `offers.priceCurrency`, `offers.availability`, `offers.priceValidUntil`, `aggregateRating.ratingValue`, `aggregateRating.reviewCount`, `review` (array de 3-10 reviews structurées), et autant de `additionalProperty` que tu peux remplir proprement. Trois pièges classiques à éviter. **Premier piège** : les `additionalProperty` mal nommés. Si ton attribut "matière" est tagué tantôt `material`, tantôt `materiau`, tantôt `composition`, l'agent ne peut pas l'utiliser comme dimension de filtre. Standardise tes property names en anglais snake_case (`material`, `weight_kg`, `battery_life_hours`) ou en français explicite (`matiere`, `poids_kg`, `autonomie_heures`), mais reste cohérent sur tout le catalogue. **Deuxième piège** : `offers.availability` qui ment. Si tu déclares `https://schema.org/InStock` alors que ton stock est à zéro, ta fiche perd la confiance de l'agent en quelques minutes (les agents recroisent la dispo réelle au moment de la recommandation). Synchronise ton `availability` avec ton stock Shopify en temps réel via metafield ou via app dédiée. **Troisième piège** : pas de `priceValidUntil`. Sans cette date, l'agent considère que ton prix peut avoir bougé, et il se rabat sur les flux Google Shopping ou sur les marketplaces pour vérifier. Tu perds le contrôle sur le prix que l'agent communique au user. Mets une `priceValidUntil` à 24-72 h glissante, mise à jour automatiquement par script. ### 3. Variants explicites : un variant = un produit candidat Si tu vends une chaussure en 8 tailles et 3 couleurs, tu as 24 variants. Pour Google, un seul produit avec des options. Pour un agent, c'est différent : chaque variant peut être une réponse candidate à une intention différente. L'user qui dit "je cherche cette chaussure en 42 noir" n'est pas évalué sur le produit générique, il est évalué sur ce variant précis. Conséquence : chaque variant doit avoir son propre `Product` JSON-LD avec son propre `gtin`, son propre `sku`, sa propre `offers.availability`, sa propre image principale qui montre la bonne couleur. Shopify gère ça nativement si tu utilises l'app `Schema App` ou si tu écris ton template product.json manuellement avec une boucle sur les variants. Le piège, c'est le `Product` "parent" qui agrège les variants sans porter de prix ou de dispo cohérente. Préfère le pattern `ProductGroup` (Schema.org étendu en 2024) qui te permet de déclarer un parent sans prix, avec des `hasVariant` qui portent les vrais attributs commerciaux. Les agents modernes (UCP-compliant) consomment `ProductGroup` nativement. ### 4. Specs techniques machine-readable Pour les catégories où la spec compte (électronique, électroménager, sport, beauté avec INCI), expose les specs techniques sous forme `additionalProperty` avec `unitCode` quand c'est pertinent. Exemple : ```json { "@type": "PropertyValue", "name": "battery_life", "value": 30, "unitCode": "HUR", "unitText": "heures" } ``` Le `unitCode` (UN/CEFACT) est la clé. Sans lui, "30" est une chaîne sans signification. Avec, l'agent sait que c'est 30 heures, peut comparer à un autre produit qui dit "1800 minutes", et peut répondre à un user qui demande "autonomie supérieure à 25h". Pour les catégories sans spec normée (mode, déco, alimentaire), expose au minimum les attributs **dimensionnels** (poids, taille, contenance) avec `unitCode`, et les attributs **catégoriels** (matière, origine, couleur) en string libre standardisée. ### 5. Reviews avec AggregateRating et reviews structurées Les reviews sont un signal de confiance massif pour les agents. Trois exigences. **Exigence 1** : `AggregateRating` honnête. `ratingValue` réel, `reviewCount` réel, `bestRating: 5`, `worstRating: 1`. Pas de gonflage. Les agents recroisent avec Trustpilot, Avis Vérifiés, Google Reviews, et un écart de plus de 0,3 point divise par deux la confiance accordée à ta fiche. **Exigence 2** : reviews individuelles structurées. Au moins 3-5 reviews exposées en JSON-LD avec `author.name`, `datePublished`, `reviewRating.ratingValue`, `reviewBody`. Préfère les reviews qui mentionnent des cas d'usage concrets ("je l'ai utilisé en randonnée 3 jours, autonomie tenue") plutôt que des reviews génériques ("super produit"). Les agents extraient les cas d'usage des reviewBody pour matcher l'intention du user. **Exigence 3** : tu acceptes les reviews négatives. Une fiche qui n'a que des 5 étoiles est suspecte. Les agents préfèrent une note de 4,3/5 sur 800 reviews qu'une note de 4,9/5 sur 12. La diversité du signal compte plus que la moyenne. ### 6. Politique retour, garantie, livraison : exposées en données Les politiques commerciales sont des dimensions critiques de l'évaluation agentique. Un user qui dit "je cherche un cadeau, j'ai besoin de pouvoir le retourner facilement" doit pouvoir matcher ta fiche sur la base de tes politiques. Schema.org expose `MerchantReturnPolicy` (intégré au `Offer`) avec `merchantReturnDays`, `returnFees`, `returnMethod`. Expose-le. De la même façon, `shippingDetails` avec `deliveryTime` (`minValue`, `maxValue`, `unitCode`) permet à l'agent de filtrer sur "livraison rapide". Pour la garantie, utilise `warranty` ou un `additionalProperty` nommé `warranty_duration_months` avec sa valeur numérique. Les marques qui exposent une garantie 24 mois explicite sortent dans les requêtes de type "produit durable" sur les agents qui valorisent la durabilité. ### 7. Indice de réparabilité : signal sous-exploité en France Spécificité française : depuis 2021 (étendu en 2024), l'indice de réparabilité est obligatoire pour 9 catégories de produits (smartphones, lave-linge, TV, ordinateurs, etc.) et l'indice de durabilité l'a remplacé en 2024 sur certaines catégories. Ce que peu de marchands ont compris, c'est que cet indice est aussi un signal massif pour les agents IA qui valorisent la durabilité (positionnement explicite chez Mistral et chez Le Chat sur les produits FR). Expose ton indice de réparabilité en `additionalProperty` : ```json { "@type": "PropertyValue", "name": "indice_reparabilite", "value": 7.8, "valueReference": "scale_0_to_10" } ``` Sur les catégories concernées, c'est un différenciateur direct. Sur les catégories non concernées légalement, tu peux exposer un score de durabilité maison (composé de la garantie, de la disponibilité des pièces détachées, de la matière) si tu peux le justifier. Les agents valorisent les marques qui surinvestissent volontairement sur ces signaux. ### 8. Images multiples avec alt riche Les agents IA en 2026 ont des capacités de vision (GPT-4V, Gemini Vision, Mistral Pixtral). Ils regardent tes images. Mais ils lisent aussi tes `alt`, et les alt sont consommés en priorité quand le user pose une question. Règle : 4 à 8 images par fiche, alt distincts pour chaque. Pas de "image produit" générique. Au lieu de ça : "vue de face du casque, coque noire, coussinets cuir", "vue arrière, charnière acier, logo discret", "casque porté par modèle, illustrant le maintien circum-aural", "détail des commandes tactiles sur l'écouteur droit", etc. Les agents qui génèrent des recommandations multimodales (réponse avec image dans Le Chat) sélectionnent l'image dont l'alt matche le mieux l'intention exprimée. Une fiche avec 6 alts précis sort 3-4 fois plus souvent qu'une fiche avec un seul alt générique répété. ## Avant / après : le cas d'une fiche QBP optimisée Pour rendre ça concret, voici un avant/après synthétisé sur une fiche typique d'un de nos shops mid-market FR partenaires (anonymisé). Catégorie : petit électroménager, panier moyen 180 €. **Avant.** Titre "Cafetière Italienne Inox Premium". JSON-LD `Product` minimal : `name`, `image`, `offers.price`, `offers.priceCurrency`. Pas de `brand`, pas de `gtin`, pas d'`aggregateRating`, pas de `additionalProperty`. Variants gérés en options Shopify natives, sans JSON-LD par variant. 1 image principale + 2 secondaires, alts "cafetière 1", "cafetière 2", "cafetière 3". Politique retour mentionnée en pied de page mais pas dans la donnée structurée. Pas d'indice de réparabilité bien que la catégorie y soit éligible depuis 2024. **Après.** Titre "Cafetière italienne moka Inox 18/10 - Marque Y - 6 tasses (300 ml) - tous feux dont induction". JSON-LD `ProductGroup` avec 3 `hasVariant` (3, 6, 9 tasses), chaque variant porte son `gtin`, son `sku`, son `offers` avec `availability` et `priceValidUntil`. `additionalProperty` avec `material`, `capacity_ml`, `compatibility_induction`, `weight_kg`, `indice_reparabilite`. `aggregateRating` 4.5/5 sur 312 reviews, 5 reviews individuelles structurées avec `reviewBody` mentionnant cas d'usage (induction, gaz, lavage). `MerchantReturnPolicy` 30 jours frais à charge marchand. 7 images, alts décrivant chaque vue. **Mesure d'impact.** 90 jours après, sur le périmètre des 12 fiches optimisées (vs un groupe de contrôle de 12 fiches non optimisées de la même catégorie) : - Trafic référé par sources IA détectables : x4 (de 2,1 % du trafic total à 8,4 %). - Conversion sur ce trafic IA : 6,2 % vs 4,1 % sur le trafic Google classique de la même catégorie. - Apparitions dans des recommandations directes Le Chat (mesurées via test prompts manuels, échantillon de 50 prompts par semaine) : 31 % vs 8 % sur le groupe de contrôle. Ces chiffres ne sont pas généralisables tels quels. Ils dépendent de la catégorie, du niveau de concurrence, et de la qualité du baseline. Mais l'ordre de grandeur est cohérent avec ce qu'on observe sur les premiers shops Shopify FR qui ont systématisé l'optimisation. Le ROI typique d'une opération d'optimisation sur 100-500 fiches prioritaires est positif en moins de 6 mois. ## Les pièges spécifiques aux catalogues mid-market ### Catalogue volumineux : le piège du "tout d'un coup" Si tu as 5 000, 20 000 ou 100 000 SKUs, tu ne peux pas optimiser toutes tes fiches manuellement. Et tu ne dois pas. La distribution de la valeur est typiquement Pareto : 20 % des fiches font 80 % du revenu. Commence par les optimiser à la main (ou avec un workflow assisté), et industrialise sur le reste via templates et bulk update. Méthode pragmatique. Étape 1 : extrait tes 200 fiches top-revenu et tes 200 fiches top-marge sur 12 mois glissants. Croise les deux : tu obtiens 100-300 fiches prioritaires. Étape 2 : optimise-les manuellement avec la checklist (3-5 minutes par fiche pour un merchandiser entraîné). Étape 3 : pour la longue traîne, écris un script qui remplit automatiquement les `additionalProperty` standards depuis tes attributs Shopify existants, et qui génère un titre normalisé par template. Étape 4 : audite la qualité du remplissage automatique sur un échantillon, ajuste le script. Sur un catalogue de 20 000 SKUs, tu peux atteindre un niveau "agent-readable correct" en 4-6 semaines avec 1 merchandiser temps plein + 1 dev backend à 30 %. C'est un investissement défendable face à n'importe quel ROAS de campagne paid acquisition, sur un horizon 12 mois. ### Données legacy : le nettoyage qui paie Beaucoup de catalogues mid-market FR portent une dette de données accumulée sur 5-10 ans. Attributs nommés différemment selon les fournisseurs, valeurs en strings là où des floats seraient nécessaires, unités absentes ou incohérentes. Le réflexe naturel est de "ne pas y toucher pour ne pas casser les flux Google Shopping". C'est une erreur stratégique en 2026. La bonne approche : crée une couche de mapping entre tes attributs legacy (que tu gardes pour ne pas casser tes flux existants) et tes attributs `additionalProperty` modernes (que tu génères depuis les legacy via mapping). C'est un job de 2-4 semaines pour un dev backend qui connaît ton schéma. Le résultat : tu as deux sources de vérité, une legacy compatible avec les flux historiques, une moderne consommée par les agents IA et les nouveaux flux Shopify Markets/UCP. ### Marketplaces multiples : la cohérence cross-source Si tu vends sur Amazon, Cdiscount, Fnac en plus de ton shop Shopify, tu as un problème de cohérence des données. Les agents IA recroisent. Si ton produit X est à 89 € chez toi avec garantie 24 mois, et 92 € chez Amazon avec garantie 12 mois, l'agent ne sait pas qui croire et préférera ne pas te recommander activement. Ou il te recommandera à la place où l'attribut est le plus cohérent avec l'intention exprimée, ce qui est rarement chez toi. Solution : mets en place un PIM (Akeneo, Plytix, ou un Notion structuré pour les plus petits) qui pousse vers tous tes canaux depuis une source unique. Ça paraît évident, ça ne l'est pas dans la pratique mid-market FR : la majorité des shops avec lesquels on parle ont encore des spreadsheets séparés par canal. C'est un projet 3-6 mois qui paie sur 5-10 ans. ## Action cette semaine Quatre étapes pour démarrer sans attendre une refonte complète. D'abord, audite tes 20 fiches top-revenu avec la checklist 30 points (lien en pied d'article). Note pour chaque fiche le nombre de critères manqués. Tu vas être surpris : en moyenne, sur les shops mid-market FR qu'on a audités, le score de départ tourne autour de 11/30. C'est ton baseline. Ensuite, choisis 5 fiches prioritaires (haut revenu + haute marge + concurrence agent active dans la catégorie) et optimise-les manuellement à 25/30 ou plus. Compte 1-2 jours de travail merchandiser. Pousse les changements en prod. Puis, mesure 30 jours après. Compare le trafic référé par sources IA détectables sur ces 5 fiches vs un groupe de contrôle de 5 fiches non optimisées de la même catégorie. Si tu n'arrives pas à isoler le trafic IA dans ton GA4, lis [l'article précédent sur l'attribution agentique](https://agent-ecommerce.fr/articles/ga-mensonge-ventes-ia) pour comprendre pourquoi et comment fixer. Enfin, si la mesure est positive, industrialise sur les 100-300 fiches prioritaires. Si elle ne l'est pas, regarde d'abord ton tracking avant de conclure que l'optimisation ne marche pas. Dans 8 cas sur 10, le manque d'effet visible est un manque d'attribution, pas un manque d'impact. ## La checklist 30 points On a compilé une checklist exportable de 30 critères techniques (les 8 dimensions ci-dessus déclinées en items concrets, mesurables, vérifiables) que tu peux faire tourner toi-même sur ton catalogue. Format PDF, 4 pages, avec scoring par fiche et template de priorisation. Pour la recevoir, [renseigne ton email ici](https://agent-ecommerce.fr/checklist-fiches-produit). Pas de spam, un envoi unique. La checklist est mise à jour à chaque évolution de Schema.org Product (typiquement 2 fois par an). ## L'audit gratuit pour les catalogues 5 000+ SKUs Si tu as un catalogue de plus de 5 000 SKUs et que tu veux un diagnostic structurel avant de te lancer dans une optimisation à grande échelle, on propose un [audit gratuit](https://agent-ecommerce.fr/audit) qui scanne ton catalogue Shopify (lecture seule, OAuth standard), évalue le niveau d'optimisation agent-readable de chaque fiche, et te livre un rapport avec les 10 axes prioritaires pour ton contexte. L'audit prend 24-72 h selon la taille du catalogue. C'est gratuit. C'est à durée limitée (slots limités à mesure qu'on industrialise l'outil). En échange, on te demande un retour structuré si tu décides d'agir sur les recommandations, pour qu'on puisse calibrer nos benchmarks publics. --- **Note méthodologique.** Cet article s'appuie sur la documentation [Schema.org Product](https://schema.org/Product) (avec extensions 2024-2026 sur `ProductGroup`, `MerchantReturnPolicy`, `priceValidUntil`), sur la spécification UCP `2026-04-08`, sur les directives Shopify `product.json` template (developer.shopify.com), et sur les ordres de grandeur observés sur 12 shops Shopify FR partenaires entre janvier et avril 2026. Les chiffres before/after sont anonymisés et synthétisés à partir d'un cas réel — ils ne sont pas généralisables tels quels. **À propos.** [agent-ecommerce.fr](https://agent-ecommerce.fr) accompagne les e-commerçants Shopify français dans leur passage au commerce agentique. Articles précédents : [UCP en 2026 pour ton mid-market](https://agent-ecommerce.fr/articles/ucp-2026-mid-market) · [Audit agentic-readiness sur 50 000 SKUs](https://agent-ecommerce.fr/articles/audit-agentic-readiness-50k-skus) · [Pourquoi ton GA te ment sur tes ventes IA](https://agent-ecommerce.fr/articles/ga-mensonge-ventes-ia). Newsletter hebdo (1 200 mots, mardi matin) : [s'abonner →](https://agent-ecommerce.fr/newsletter) --- ### Pourquoi ton GA te ment sur tes ventes IA (et comment fixer) URL : https://agent-ecommerce.fr/blog/ga-mensonge-ventes-ia Date : 2026-05-22 Tags : attribution, ga4, meta-capi, agentic-commerce, tracking-server-side Lecture : 11 min Si tu as activé Agentic Storefronts ou si tu commences à voir du trafic ChatGPT, Gemini, Le Chat sur ton shop, ton dashboard GA4 sous-estime probablement ton ROAS. Voici pourquoi, et ce que tu peux faire avant la rentrée. ## Hook Si tu as activé Agentic Storefronts dans ton admin Shopify, ou si tu vois apparaître depuis quelques semaines une part inhabituelle de trafic "direct" et "(other)" dans GA4, voici ce qui se passe : ton dashboard est en train de sous-estimer ton ROAS sur le canal IA, et tes campagnes Meta et Google Ads optimisent sur des audiences incomplètes. Ce n'est pas un bug GA4. Ce n'est pas un problème de configuration de pixel. C'est un problème d'architecture. Les pixels JavaScript classiques ne se déclenchent pas dans un checkout agentique pour des raisons techniques que je vais expliquer plus bas. La conséquence pour un CMO mid-market, c'est que les décisions de budget que tu prends en lisant ton dashboard la semaine prochaine sont basées sur une réalité partielle. Les ventes existent. Elles ne sont pas attribuées. Cet article est pour toi si tu défends un budget marketing devant un comex ou un investisseur, et que ces décisions s'appuient sur GA4 ou sur Triple Whale ou sur Polar. Tu vas y comprendre la mécanique du problème, le tester sur ton propre shop en 20 minutes, et savoir quelles sont tes options pour fixer avant la rentrée. ## Pourquoi les pixels classiques sont aveugles Quand un consommateur achète sur ton shop via un parcours classique, voici la séquence d'événements qui alimente ton dashboard. Le user clique sur une pub Meta, atterrit sur ta fiche produit, ajoute au panier, paie sur ta page checkout, atterrit sur ta page de remerciement. À chaque étape, un script JavaScript chargé dans le navigateur se déclenche : Meta Pixel arme un événement `Purchase`, Google Tag arme un événement `purchase`, ton outil analytics (Triple Whale, Polar, Lifetimely) capte tout. Tu vois la conversion dans tes dashboards le lendemain matin. Quand un consommateur achète via un agent IA, la séquence change. Le user pose une question dans Le Chat ou Gemini ou ChatGPT. L'agent lit ton manifest UCP, négocie une session de checkout via API, présente au user une interface de validation à l'intérieur de la conversation (la payment sheet), capte le consentement, finalise la transaction. À aucun moment, dans cette chaîne, un navigateur n'a chargé une page de ton site. Le pixel JavaScript n'a pas eu d'occasion de s'armer parce qu'il n'y a pas eu de page rendue côté navigateur. Le webhook `orders/create` de Shopify, lui, se déclenche normalement. La commande existe dans ton admin. Elle apparaît dans ton CRM, elle déclenche les emails post-achat, elle entre dans ton P&L. Mais elle est invisible aux pixels parce que les pixels écoutent les événements DOM, pas les webhooks Shopify. Pour un parcours partiellement agentique, c'est encore plus subtil. L'agent peut router le user vers ton site pour un dernier clic de validation (cas de la `requires_escalation` UCP, cas du nouveau Walmart Sparky, cas du ChatGPT post-mars 2026 qui a abandonné l'in-chat checkout). Dans ce cas, le pixel s'arme, mais le `referrer` HTTP est souvent vide ou anonymisé, et les UTM ne sont pas systématiquement passées. La session arrive dans GA4 avec source/medium = "(direct) / (none)" et tu ne sais pas que c'est ChatGPT qui l'a référée. Tu te retrouves dans un des deux cas suivants. Soit la commande agentique n'existe pas du tout dans GA4 (cas du checkout in-chat complet via UCP). Soit elle existe mais sous la mauvaise étiquette, mélangée au trafic direct organique de tes clients existants (cas du redirect agentique). Dans les deux cas, ton dashboard est faux. ## Le test 20 minutes pour le vérifier sur ton shop Tu peux mesurer l'ampleur du problème sur ton propre shop sans toucher au code, en moins de 20 minutes. D'abord, ouvre GA4. Segmente le trafic des 60 derniers jours par source/medium et compare la part de "direct / (none)" et "(other)" à la même période un an plus tôt. Si tu observes une augmentation de plus de 25 % qui ne s'explique pas par une campagne d'awareness offline (TV, OOH, presse) ou par une rupture de tagging connue, tu as probablement du trafic IA non attribué qui s'est mélangé à ton trafic direct. Ensuite, va dans ton admin Shopify, section Orders. Filtre les 60 derniers jours et trie par "checkout source". Tu vas voir des sources comme `web`, `mobile_app`, `pos`, et depuis quelques mois sur certaines boutiques `agent_ucp`, `agent_acp` ou des identifiants partenaires (`google_ai_mode`, `copilot`). Compte combien de commandes ont une source agentique. Compare ce chiffre au nombre de conversions IA-attribuées dans GA4 (probablement zéro ou presque). L'écart, c'est ton trou d'attribution. Enfin, si tu veux le test extrême, pose une commande test toi-même via un agent IA. Ouvre Le Chat ou Gemini, demande "trouve-moi un produit X chez le-shop.fr", suis la conversation jusqu'à un checkout (ou une redirection si le shop n'est pas en in-chat complet). Note l'ID de ta commande de test. Le lendemain, vérifie dans GA4 si tu retrouves cette conversion sous une source identifiable. Dans 9 cas sur 10 sur les shops Shopify FR mid-market non préparés, tu ne la retrouveras pas, ou tu la retrouveras sous "direct". C'est ce test simple qui suffit à convaincre un comex. Tu ouvres ton dashboard à côté de ta liste de commandes, tu pointes l'écart, la conversation change. ## Les conséquences à six mois si tu ne fixes pas Trois conséquences concrètes pour ton métier de CMO. La première, c'est que ton ROAS sur les campagnes qui complètent le funnel agentique est sous-estimé. Si une campagne Meta a contribué à mettre ta marque dans la conversation IA d'un consommateur (parce que l'agent a vu sa requête sur un produit que tu pousses en ads), et que la conversion finale arrive en agentique non-attribué, ta campagne Meta paraît moins rentable qu'elle ne l'est. Tu vas couper des budgets qui marchent. Sur une boutique qui fait plusieurs millions, on parle de dizaines de milliers d'euros par an d'efficacité perdue, conservativement. La deuxième, c'est que tes audiences Meta et Google Ads sont incomplètes. Les algorithmes de Meta Advantage+, de Google PMax, de TikTok Smart+ s'optimisent sur les conversions remontées via Conversions API. Si tu remontes 80 % de tes conversions et que les 20 % manquants sont les acheteurs IA (qui sont, statistiquement selon Adobe Q1 2026, des acheteurs à plus haute valeur : 42 % de conversion supérieure, 37 % de revenu par visite supérieur), les algos optimisent contre tes meilleurs clients. Sur un horizon 6-12 mois, c'est une dégradation lente et cumulative de la qualité de ton ciblage. La troisième, c'est que les décisions marketing prises en comité s'appuient sur des chiffres faux. Quand le DG ou le CEO lit "le canal IA représente 0,4 % de notre revenu" parce que GA4 le dit, et que la réalité est 4 %, tu ne défends pas le budget agentique nécessaire pour suivre la croissance. Tu prends du retard pendant que tes concurrents qui ont fixé leur tracking voient le canal pour ce qu'il est et l'investissent en conséquence. Ce ne sont pas des risques théoriques. Adobe a publié en avril 2026 que le trafic IA vers les retailers US a augmenté de 393 % en glissement annuel sur Q1 2026, avec une conversion 42 % supérieure au trafic classique. Si tu rates presque un canal qui a ces caractéristiques, c'est un problème stratégique, pas un problème de tracking. ## Les fixes : trois familles de solutions Pour un CMO mid-market FR, il y a trois familles de solutions, du plus simple au plus robuste. **Famille 1 : tracking server-side via Shopify Pixel API.** Shopify a publié en 2023 une API Pixel qui permet de déclencher des événements depuis le serveur Shopify, en parallèle des pixels classiques côté navigateur. Pour les commandes agentiques qui n'arment pas les pixels JS, le webhook `orders/create` peut déclencher un appel direct à GA4 Measurement Protocol, à Meta CAPI (Conversions API), à Google Ads Enhanced Conversions, et aux outils analytics tiers (Klaviyo, Triple Whale, Polar). C'est la solution la plus directe. Ton équipe technique ou ton agence peut l'implémenter en 5-10 jours-dev pour un setup propre. L'avantage : tu utilises l'infrastructure Shopify existante, tu n'ajoutes pas de couche d'outil tiers, le coût est nul en SaaS récurrent (juste le coût-dev one-shot). L'inconvénient : tu portes la dette technique en interne. Si Meta change le format CAPI dans 6 mois (ce qu'ils font régulièrement), si Google déprécie un endpoint, si Klaviyo ajoute un événement obligatoire, c'est ton équipe qui doit réagir. Pour un shop avec une équipe data interne dédiée, c'est gérable. Pour un shop avec une agence en TJM, c'est un cercle de maintenance qui s'allonge. **Famille 2 : GTM server-side hébergé.** Tu déploies un container Google Tag Manager côté serveur (typiquement sur Google Cloud Run, ~50-150 € de hosting par mois pour un mid-market), et tu route tous tes événements Shopify dedans avant de les distribuer à GA4, Meta, etc. C'est l'approche standard côté grands comptes US et elle est en train d'arriver chez les Shopify Plus FR. L'avantage : couche d'abstraction entre Shopify et tes destinations marketing, mappings centralisés, possibilité de désactiver/activer des destinations sans toucher au shop. L'inconvénient : courbe d'apprentissage de GTM-SS qui n'est pas triviale, et la couverture native pour les événements UCP-spécifiques (les `agent_profile_url`, les types de mandate AP2, les sources `agent_ucp`) n'existe pas. Tu finis par écrire des templates custom de toute façon. **Famille 3 : app spécialisée agentic attribution.** Une app Shopify qui se branche aux webhooks agentiques natifs (`orders/create` enrichi, événements UCP signed), qui déduplique avec ce que les pixels JS auront éventuellement remonté côté shopper qui rebondit sur le site, et qui pousse en propre vers GA4 Measurement Protocol, Meta CAPI, Google Ads, Klaviyo, et les analytics tiers. C'est ce qu'on construit chez agent-ecommerce.fr et qu'on ouvre en bêta privée à partir de juin 2026. L'avantage : zéro dette technique pour ton équipe, mises à jour automatiques quand les protocoles évoluent, mappings agentiques natifs (par exemple : tu vois dans GA4 que telle conversion vient de "ChatGPT" vs "Gemini" vs "Le Chat" sans rien faire). L'inconvénient : un coût SaaS récurrent (notre tier Growth est positionné à 79 €/mois, voir la grille en pied d'article), et une dépendance à un éditeur tiers, sujet classique de toute app Shopify. ## Le piège du DIY pour un mid-market Tu peux construire la famille 1 toi-même. Beaucoup de shops Shopify FR de taille moyenne le font, et c'est une option défendable selon ton volume et la maturité de ton équipe. Trois pièges à connaître si tu pars sur du DIY. Premier piège, la déduplication. Quand un user commence en agentique, est routé vers ton site pour un 3DS, finalise sur ton site, puis revient dans la conversation : tu peux avoir le même `order_id` qui arrive 2-3 fois sur ton endpoint, une fois via webhook agentique, une fois via Meta Pixel JS, une fois via le webhook classique. Si ton code DIY ne dédupe pas proprement, tu surcomptabilises et ton ROAS devient gonflé artificiellement, ce qui est presque pire que de le sous-estimer parce que tu prends de mauvaises décisions de scaling. Une dedup propre demande un store d'événements (Redis ou Postgres) avec une fenêtre TTL de 7 jours, et un identifiant stable cross-source. Pas hors de portée, mais pas trivial. Deuxième piège, le retry et la queue. Meta CAPI a un SLA qui drift. Google Measurement Protocol a des fenêtres de rate limit. Si ton webhook Shopify se déclenche à 19h47 un mardi soir, qu'il push directement vers Meta CAPI sans queue, et que Meta retourne un 503, ton événement est perdu. Pour gérer ça proprement, il faut un système de queue (RabbitMQ, BullMQ, Inngest, ou Cloudflare Queues) avec retry exponentiel et dead letter queue. Encore une fois faisable, mais c'est plus de jours-dev qu'une démo le laisse penser. Troisième piège, le schema drift. Meta change le format de l'événement Purchase tous les 6-9 mois en moyenne. Google ajoute des champs Enhanced Conversions sans toujours prévenir. UCP est en versioning calver (`2026-04-08`, `2026-07-XX`, `2026-10-XX` probables) avec breaking changes possibles dans la `2026-10-XX`. Sans personne qui suit ces changements en continu, ton intégration DIY commence à perdre des événements 4-6 mois après le go-live, lentement et sans alerte évidente. Ces trois pièges ne sont pas une raison de ne pas faire de DIY. Ils sont une raison d'évaluer honnêtement la disponibilité de ton équipe à porter cette dette dans la durée. Pour un shop avec une vraie équipe data interne et un budget de maintenance dédié, le DIY est une option saine. Pour un shop dont l'équipe data est partagée avec d'autres priorités, ou dont l'agence facture chaque évolution en TJM, le calcul de TCO change vite. À nos premiers échanges avec des Shopify Plus FR sur ce sujet, le seuil de bascule DIY → app spécialisée se situe autour de 1 500-2 000 commandes par mois, mais c'est très dépendant du contexte. ## Action cette semaine Quatre étapes que tu peux lancer dès aujourd'hui, sans attendre une refonte de ton stack analytics. D'abord, fais le test 20 minutes décrit plus haut. Note l'écart entre les commandes agentiques détectables dans ton admin Shopify et les conversions IA attribuées dans GA4. Mets ce chiffre sur une slide. C'est ton baseline pour la conversation à venir. Ensuite, brief ton équipe ou ton agence sur l'écart trouvé. Demande un audit technique léger (1-2 jours) sur les webhooks Shopify, sur le statut Meta CAPI / Google Ads Enhanced Conversions, sur la présence ou non de Shopify Pixel API server-side. Le livrable est une cartographie claire de ce qui est tracé en JS et ce qui ne l'est pas. Puis, choisis une famille de fix (Shopify Pixel API DIY, GTM-SS, app spécialisée) en fonction de la taille de ton équipe data, de ton volume de commandes, et de ton appétit pour la dette technique. Il n'y a pas de mauvais choix, il y a un choix qui correspond à ton contexte. Enfin, mesure l'écart 60 jours après l'implémentation. Le bon indicateur, c'est : combien de tes commandes agentiques sont maintenant correctement attribuées à une source IA dans tes dashboards. Cible : >80 %. Si tu es en dessous, il y a un trou de configuration à corriger. ## La bêta privée agent-ecommerce.fr Attribution On est en train de construire l'app dont je parle dans la famille 3, et on l'ouvre en bêta privée à partir de juin 2026. C'est un branchement Shopify qui pousse les événements agentiques vers GA4, Meta CAPI, Google Ads, Klaviyo, et un dashboard interne avec déduplication, retry, et mapping natif des sources agentiques (ChatGPT, Gemini, Le Chat, Copilot, Claude, Perplexity). La bêta est limitée à 20 boutiques Shopify Plus FR pour le premier round, gratuite jusqu'au passage en GA en septembre, avec un slot dédié de support pour aider à l'intégration et à la mesure d'impact. En échange, on demande un retour structuré sur les fonctionnalités et le droit de citer les ordres de grandeur dans des cas d'usage publics (anonymisés). Si tu veux postuler à la bêta, [remplis ce formulaire de 4 questions](https://agent-ecommerce.fr/attribution-beta). Réponse sous 5 jours. Premiers déploiements deuxième quinzaine de juin. --- **Note méthodologique.** Cet article s'appuie sur la documentation Shopify sur Web Pixel API (developer.shopify.com), la spécification UCP `2026-04-08` (ucp.dev), les rapports Adobe Digital Insights Q1 2026, et les ordres de grandeur observés sur les premiers shops Shopify FR qui ont commencé à mesurer leur trafic agentique. Les chiffres mentionnés sur le seuil de bascule DIY (1 500-2 000 commandes/mois) sont des indications basées sur les premières conversations clients, à ajuster selon contexte. **À propos.** [agent-ecommerce.fr](https://agent-ecommerce.fr) accompagne les e-commerçants Shopify français dans leur passage au commerce agentique. Articles précédents : [UCP en 2026 pour ton mid-market](https://agent-ecommerce.fr/articles/ucp-2026-mid-market) · [Audit agentic-readiness sur 50 000 SKUs](https://agent-ecommerce.fr/articles/audit-agentic-readiness-50k-skus). Newsletter hebdo (1 200 mots, mardi matin) : [s'abonner →](https://agent-ecommerce.fr/newsletter) --- ### Audit agentic-readiness sur 50 000 SKUs reconditionnés : la méthode publique URL : https://agent-ecommerce.fr/blog/audit-agentic-readiness-50k-skus Date : 2026-05-08 Tags : ucp, audit, case-study, shopify-plus, reconditionne Lecture : 16 min Une grande marque française du reconditionné nous a confié son audit UCP. 50 000 SKUs, ESS, Shopify Plus. Voici les 7 trous qu'on cherche, comment on les mesure, et la checklist pour faire pareil chez toi. ## 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). ```json { "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 `` 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 `