E-commerce
26 août 2026
Vous passez des heures à peaufiner vos fiches produit : descriptions, photos haute résolution, avis clients. Pourtant, quand un agent IA cherche un sac pour ordinateur de 15 pouces à moins de 60 € livrable en trois jours, il ne verra jamais cette belle page. Il consulte uniquement des champs structurés, des flux de données brutes où chaque attribut porte un libellé et un type précis. Pas de prix typé ? Pas de dimension chiffrée ? Votre article disparaît de la comparaison avant même qu’on juge sa qualité. Depuis que Google et Adyen ont lancé leurs outils de commerce agentique en 2026, cette exigence est passée du statut de bonne pratique à celui de prérequis strict. Cet article vous explique ce qu’un agent lit vraiment, quelles sont les quatre classes de données indispensables et comment structurer vos flux pour rester dans la course.
Sommaire
Ce que lit vraiment un agent IA au lieu de votre page produit
Un agent IA ne navigue jamais sur votre boutique comme le ferait un client. Il ne charge pas de JavaScript, ne scrute pas de mise en page, n’interprète aucune intention cachée dans un slogan. Il consomme des enregistrements structurés, des lignes de données où chaque fait porte une étiquette claire et un type connu : un nombre déclaré comme prix, une devise codée en ISO 4217, une date au format ISO 8601, un état tiré d’une liste fixe d’options autorisées.
Ces données arrivent par trois canaux. Le premier est le flux produit au format CSV, TSV ou XML, soumis à un consommateur ou hébergé sur une URL actualisée. Le deuxième est la donnée structurée dans la page elle-même, balisée en JSON-LD, microdata ou RDFa selon le vocabulaire schema.org. Le troisième est une API catalogue qui répond à une requête par des enregistrements plutôt que par un document HTML.
Résultat : une seule requête renvoie des valeurs déjà étiquetées et typées. L’agent applique ensuite des règles de contrainte, contrainte de budget, de taille, de délai de livraison, de condition. Il ne forme aucune impression subjective en lisant votre description : il vérifie si une valeur respecte une règle. Pas de valeur ? Pas de test possible, donc élimination immédiate.
200+ ecommerçants accompagnés
Les quatre classes de champs qui décident de votre visibilité
Quatre catégories de données déterminent si votre produit peut entrer dans la comparaison. Manquer une seule d’entre elles ne le classe pas en bas de liste : il le retire purement et simplement de la course.
Identifiant stable (GTIN, code-barres EAN, MPN fabricant, SKU interne) : l’agent reconnaît le même article chez plusieurs marchands et déduplique les occurrences. Sans identifiant, un produit apparaît comme plusieurs références distinctes ou ne correspond à aucun article connu.
Prix et devise (champs price et priceCurrency) : l’agent teste la contrainte budgétaire. Un prix affiché uniquement sous forme de texte rendu, du type « à partir de 39 € », ne fournit aucune valeur unique à comparer. L’article est écarté.
État de disponibilité (champ availability, valeur énumérée comme InStock ou OutOfStock) : l’agent filtre ce qui est achetable immédiatement. Sans ce champ, articles disponibles et ruptures se mélangent jusqu’à l’échec au panier.
Structure de variante (item_group_id plus axes de déclinaison comme taille ou couleur) : l’agent sépare une variante d’un produit différent. Sans structure claire, la mauvaise taille est sélectionnée ou toutes les variantes se confondent.
Un GTIN administré sous les règles GS1 se résout à l’échelle mondiale, permettant à l’agent de comparer trois offres pour le même objet. Un SKU interne ne déduplique rien. Cette logique s’étend aux champs de spécifications techniques : un adjectif vague comme « compact » ne satisfait aucune contrainte de dimension chiffrée. Pour en savoir plus sur les données clés à suivre, consultez notre guide Analytics e-commerce : quoi suivre et pourquoi ?
Pourquoi une page complète pour un humain reste vide pour une machine
Votre fiche produit affiche toutes les informations nécessaires. Pourtant, un parseur n’en voit qu’une fraction. Première raison : les images. Des dimensions imprimées sur un schéma, une grille de compatibilité sous forme de tableaux, des instructions d’entretien photographiées sur une étiquette : tout cela est invisible pour un script qui lit le HTML brut. Le texte alternatif rédigé pour l’accessibilité ne répète que rarement les chiffres clés.
Ensuite viennent les contenus masqués derrière une interaction. Les onglets de spécifications, les accordéons, les panneaux d’avis clients arrivent par une requête asynchrone déclenchée après le chargement initial. Ils existent dans le DOM seulement une fois que le navigateur a exécuté le JavaScript de la page. Un parseur qui ne rend pas la page reçoit la coquille vide, aucun tiroir n’est ouvert.
Enfin, le texte libre de spécifications échoue autrement. Une phrase comme « convient à la plupart des cadres standard » a du sens pour un acheteur qui visualise son besoin, mais elle ne porte ni valeur numérique ni unité de mesure. L’agent ne peut pas tester cette assertion contre une contrainte de largeur exprimée en centimètres. Si vous cherchez à améliorer votre référencement naturel et la lisibilité machine de vos fiches, notre article SEO pour sites e-commerce : stratégies qui fonctionnent vraiment vous aidera à structurer vos contenus.
Comment un agent teste une contrainte de prix ou de taille
L’agent assemble un ensemble de contraintes depuis la requête utilisateur : plafond budgétaire, taille minimale ou maximale, délai de livraison, état neuf ou reconditionné. Il teste ensuite chaque attribut de chaque article contre chaque contrainte. Ce n’est pas un jugement d’ensemble, c’est une série de vérifications binaires : la valeur respecte-t-elle la règle, oui ou non ?
Prenons le prix. Si votre flux contient un champ price avec la valeur 45.00 et un champ priceCurrency avec EUR, l’agent peut vérifier si 45,00 € est inférieur à 60 €. La comparaison fonctionne parce que les deux nombres partagent le même type et la même unité. En revanche, si le prix n’apparaît que dans une description textuelle, l’agent ne peut extraire aucune valeur unique. L’article est écarté avant toute évaluation qualitative.
Même logique pour les dimensions. Une contrainte « sac pour ordinateur de 15 pouces » exige une largeur, une hauteur ou une diagonale exprimée en nombre et en unité. Un champ additionalProperty contenant « width : 38 cm » satisfait directement la règle. L’adjectif « spacieux » ne satisfait rien. C’est pour cette raison que les spécifications techniques doivent être portées par des champs typés plutôt que noyées dans des paragraphes de description.
Les trois canaux par lesquels vos données produit voyagent
Vos informations produit circulent vers les agents par trois routes distinctes, chacune avec ses conventions et ses limites. Le flux produit reste le canal historique : vous soumettez un fichier CSV, TSV ou XML à une plateforme qui l’ingère, ou vous hébergez ce flux sur une URL accessible selon un calendrier fixe. Le format suit souvent les conventions établies par RSS 2.0 ou Atom 1.0 pour l’XML, ou bien un schéma tabulaire simple pour les fichiers délimités.
La donnée structurée dans la page marque les mêmes faits directement dans le HTML, grâce à JSON-LD, microdata ou RDFa. Vous déclarez un type Product et un type Offer selon le vocabulaire schema.org, vous renseignez les propriétés name, price, priceCurrency, availability et image. Un parseur qui charge la page récupère ces balises sans exécuter de script.
Enfin, une API catalogue répond à une requête HTTP par un ensemble d’enregistrements structurés, généralement au format JSON. C’est la voie la plus récente, celle que privilégient les outils de commerce agentique pour interroger votre inventaire en temps réel. Si votre plateforme Shopify expose une API produit compatible, l’agent peut interroger directement votre stock sans passer par un export planifié. Pour comprendre comment Google Shopping exploite ces flux, lisez notre guide Qu’est-ce que Google Shopping pour l’e-commerce ?
Pourquoi les identifiants GTIN et MPN sont indispensables
Un identifiant stable permet à l’agent de reconnaître qu’il s’agit du même produit physique, quel que soit le marchand qui le propose. Le GTIN, administré sous les règles GS1 et souvent matérialisé par un code-barres EAN ou UPC, se résout à l’échelle mondiale. Un agent qui lit trois offres portant le même GTIN sait qu’il compare trois prix pour un objet identique. Il peut alors classer les offres par prix, délai de livraison ou frais de port.
Sans GTIN ni MPN fabricant, l’agent traite chaque occurrence comme un produit distinct. Trois marchands vendent le même casque audio ? L’agent voit trois références sans lien entre elles. Impossible de détecter la meilleure offre, impossible de dédupliquer les résultats. Le client final reçoit une liste confuse, et vous perdez la possibilité de vous démarquer par le prix ou le service.
Le SKU interne ne remplace pas le GTIN : il ne circule qu’à l’intérieur de vos systèmes, ne se résout nulle part ailleurs et ne déduplique rien. Utilisez-le pour lier votre catalogue à votre gestion de stock, mais ajoutez toujours un GTIN ou un MPN dans vos flux publics. Si vous gérez plusieurs canaux de vente, notre article À quoi sert vraiment un order management system en e-commerce ? vous explique comment orchestrer ces identifiants à grande échelle.
Comment structurer les variantes pour éviter la confusion
Un même produit décliné en plusieurs tailles, couleurs ou finitions doit être représenté de manière claire dans vos flux. L’agent a besoin de savoir que ces variantes appartiennent à un seul groupe logique, sans quoi il les traite comme des produits totalement différents. Le champ item_group_id rassemble toutes les déclinaisons sous un même identifiant parent.
Ensuite, chaque variante porte des champs d’axe : size pour la taille, color pour la couleur, material pour la matière. Ces champs permettent à l’agent de séparer une variante « taille M, bleu » d’une variante « taille L, rouge ». Si ces axes sont absents ou mélangés dans la description, l’agent ne peut pas distinguer la bonne référence. Il sélectionne la première ligne rencontrée, quelle que soit la taille demandée.
Pire encore, sans structure de variante, plusieurs déclinaisons peuvent s’effondrer en une seule ligne ambiguë. Votre catalogue affiche alors un prix flou, une disponibilité contradictoire et aucune correspondance avec la requête de l’utilisateur. Structurer les variantes correctement dès le départ vous épargne ces erreurs et améliore le taux de conversion, car l’agent envoie le client vers la bonne référence du premier coup.
Prix et devise : pourquoi « à partir de » échoue toujours
Un agent IA ne peut tester une contrainte de budget que si le prix est fourni sous forme de nombre unique, accompagné d’un code devise normalisé. Le champ price contient 45.00, le champ priceCurrency contient EUR : la comparaison avec un plafond de 60 € fonctionne immédiatement. En revanche, une mention « à partir de 39 € » ou « dès 39 € » ne livre aucune valeur exploitable.
L’agent ne sait pas si le prix final sera 39 €, 45 € ou 60 €. Il ne peut pas résoudre l’ambiguïté, donc il élimine l’article de la liste des candidats. Même problème si le prix n’apparaît que sur la page rendue, calculé par JavaScript en fonction d’options choisies : le parseur qui ne rend pas la page ne voit rien.
Assurez-vous que chaque ligne de votre flux porte un prix précis pour la variante concernée. Si vous vendez des produits configurables avec options payantes, créez une ligne par combinaison tarifaire ou indiquez le prix de base dans le flux et les suppléments dans des champs dédiés. L’essentiel est de fournir une valeur testable contre une contrainte numérique. Pour optimiser vos campagnes publicitaires et vous assurer que vos prix sont bien diffusés, consultez notre article Marketing e-commerce et publicité : quelles différences ?
État de disponibilité : filtrer ce qui est achetable maintenant
Le champ availability indique si l’article peut être acheté immédiatement. Les valeurs autorisées sont tirées de l’énumération schema.org ItemAvailability : InStock, OutOfStock, PreOrder, Discontinued, LimitedAvailability. Un agent qui reçoit InStock sait que l’article est disponible, il peut donc le proposer en réponse à une requête urgente.
Sans ce champ, l’agent ne peut pas distinguer un produit en stock d’une rupture temporaire ou d’un article en précommande. Tous les produits se retrouvent mélangés dans les résultats, et le client découvre la rupture seulement au moment de valider son panier. Le taux d’abandon explose, et votre réputation en prend un coup.
Mettez à jour l’état de disponibilité aussi souvent que votre stock évolue. Si vous utilisez un système de gestion de commandes connecté à votre flux, automatisez cette synchronisation pour que le champ availability reflète l’état réel en temps réel. Cela garantit que l’agent ne propose que des articles réellement disponibles, ce qui améliore l’expérience client et réduit les déceptions au panier.
Spécifications techniques : passer du texte libre aux champs typés
Les descriptions produit rédigées en prose sont précieuses pour convaincre un humain, mais elles restent opaques pour un agent. Une phrase comme « dimensions généreuses pour tous vos documents » ne porte ni largeur, ni hauteur, ni unité de mesure. L’agent qui cherche un sac de 38 cm de large ne peut pas vérifier cette contrainte, donc l’article est écarté.
La solution consiste à extraire chaque fait technique et à le porter dans un champ dédié. Utilisez le type schema.org PropertyValue ou le champ additionalProperty pour déclarer width, height, depth, weight avec leur valeur numérique et leur unité. Par exemple : « width : 38, unitCode : CMT » pour 38 centimètres. L’agent lit directement ces propriétés et les teste contre les contraintes de la requête.
Même logique pour la compatibilité, la puissance, la capacité, la résolution ou tout autre attribut mesurable. Si vous vendez de l’électronique, indiquez la diagonale d’écran en pouces, la capacité de batterie en milliampères-heure, le poids en grammes. Si vous vendez du textile, précisez la composition en pourcentages, les dimensions de chaque taille en centimètres. Plus vos spécifications sont typées, plus l’agent peut affiner ses recommandations. Pour comprendre comment ces données influencent votre visibilité naturelle, lisez notre guide Qu’est-ce que le SEO e-commerce et comment cela fonctionne ?
Qstomy et les flux produit : de la donnée structurée à la recommandation en temps réel
Qstomy est un agent IA Shopify qui accompagne vos clients depuis la découverte produit jusqu’au suivi de colis et au service après-vente. Contrairement aux outils de flux classiques qui se contentent d’exporter vos données vers des plateformes publicitaires, Qstomy consomme vos données structurées en temps réel pour guider chaque visiteur vers l’achat. Il s’appuie sur les mêmes champs typés, identifiants GTIN, prix avec devise, disponibilité et variantes, pour recommander le bon produit au bon moment.
Résultat : l’agent répond instantanément aux questions de disponibilité, propose des alternatives quand un article est en rupture, suggère des produits complémentaires pertinents et accompagne le client jusqu’à la validation du panier. Il gère également le suivi de colis, les demandes de retour et les questions sur vos politiques commerciales, le tout sans quitter la conversation. Vous réduisez le taux d’abandon, augmentez le panier moyen et libérez votre équipe support des tâches répétitives.
Plus de 100 marchands font déjà confiance à Qstomy pour convertir leurs visiteurs en acheteurs. En structurant correctement vos flux produit, vous maximisez la capacité de l’agent à comparer, recommander et convertir, que ce soit sur votre boutique ou sur les canaux externes où vos produits sont diffusés.
Checklist, en bref et questions fréquentes
Checklist flux produit prêt pour les agents IA
Identifiant stable : GTIN ou MPN renseigné pour chaque produit
Prix et devise : champs price et priceCurrency typés, une valeur unique par variante
Disponibilité : champ availability avec valeur énumérée (InStock, OutOfStock…)
Structure de variante : item_group_id et axes de déclinaison (taille, couleur) clairement séparés
Spécifications techniques : dimensions, poids, capacité portés en champs typés avec unités
En bref
Les agents IA ne lisent jamais vos pages produit rendues : ils comparent des champs typés dans vos flux et vos données structurées. Quatre classes de données sont obligatoires pour rester visible : identifiant stable, prix avec devise, état de disponibilité et structure de variante. Tout fait technique enfermé dans une image, un onglet masqué ou une description en prose reste invisible. Structurez vos flux dès maintenant pour répondre aux exigences du commerce agentique et garantir que vos produits entrent dans la comparaison.
Questions fréquentes
Un agent IA peut-il lire les dimensions dans une image produit ?
Non. Les dimensions imprimées sur un schéma ou une photo sont invisibles pour un parseur. Vous devez les déclarer dans des champs typés, par exemple additionalProperty avec valeur numérique et unité.
Pourquoi mon produit disparaît-il des résultats alors que ma fiche est complète ?
Si le prix, la disponibilité ou l’identifiant manquent dans votre flux structuré, l’agent élimine l’article avant toute comparaison. Une page visuellement complète ne garantit pas la présence de champs typés exploitables.
Faut-il un GTIN pour tous les produits, même artisanaux ou faits main ?
Les produits sans code-barres universel peuvent utiliser un MPN fabricant ou un SKU interne, mais ils ne bénéficieront pas de la déduplication entre marchands. Si vous avez accès à un GTIN, ajoutez-le systématiquement.
Quelle est la
Pour aller plus loin : Comment aider un client bloqué par 3D Secure au paiement - Qstomy.
Enzo
26 août 2026
