Données structurées produit et e-commerce dans les réponses IA.

Ce qu'un assistant d'achat lit dans une fiche produit

Un assistant d'achat lit cinq choses dans une fiche produit : l'identité du produit (nom, marque, identifiant), le prix avec sa devise, la disponibilité, la note agrégée avec son nombre d'avis, et les conditions de livraison et de retour. Tout le reste, description, arguments, visuels, sert au lecteur humain ; pour le moteur, ces cinq données décident si la fiche peut entrer dans une réponse de type « quel produit choisir », et à quelle place.

Le niveau documenté varie selon les éditeurs. Google décrit précisément les données structurées Product et Offer qu'il exploite pour ses résultats marchands, et ses fonctionnalités d'achat, y compris dans AI Mode, s'appuient sur le Shopping Graph alimenté par Merchant Center. OpenAI a indiqué, au lancement des résultats d'achat dans ChatGPT au printemps 2025, que ceux-ci reposent sur des métadonnées structurées fournies par des tiers et sur des avis, puis a ouvert un dispositif de flux produits pour les marchands. Perplexity a lancé un programme marchand qui permet de lui transmettre des données produit. Anthropic n'a rien documenté de spécifique aux produits. Le détail de ces dispositifs évolue vite ; ce qui ne change pas, c'est la nature des données attendues.

D'où une conséquence pratique : une fiche produit se lit par trois canaux, et il faut être lisible par les trois. Le HTML avec son balisage JSON-LD, que les robots de recherche IA explorent ; les flux marchands, que vous transmettez aux plateformes ; et les sources tierces, comparatifs, marketplaces et sites d'avis, que les moteurs citent massivement pour les questions de choix. C'est la déclinaison, pour un catalogue, des quatre conditions décrites dans notre méthode complète.

Les trois canaux doivent dire la même chose. Un prix différent entre la page et le flux, une disponibilité à jour dans le flux mais périmée dans le balisage, un nom de produit différent sur une marketplace : chacune de ces divergences est, pour un moteur, une raison de préférer une source plus cohérente, souvent un concurrent ou un comparatif.

Product : l'identité du produit et ses variantes

Le bloc Product décrit ce qui est vendu, indépendamment du prix. Les propriétés qui comptent sont celles qui permettent de reconnaître le produit sans ambiguïté : name, brand, gtin13 ou gtin, mpn, sku, image, description. Le GTIN, code-barres du produit, est l'identifiant le plus précieux : il permet à un moteur de rapprocher votre fiche des fiches du même produit ailleurs, donc de comparer votre prix et votre disponibilité à ceux des autres vendeurs.

Tableau : faites défiler horizontalement.

Les variantes (tailles, couleurs, contenances) sont le premier point de confusion. Google documente depuis 2024 le type ProductGroup, qui regroupe les variantes avec hasVariant et déclare les axes de variation avec variesBy ; chaque variante est un Product avec son propre GTIN, son prix et sa disponibilité. Déclarer un seul Product avec un prix unique pour vingt variantes, ou vingt Product avec le même GTIN, produit dans les deux cas une information fausse, et un moteur qui compare des prix le remarque.

Offer : prix, disponibilité, livraison, retours

Le bloc Offer porte tout ce qui change dans le temps : le prix (price, priceCurrency), la disponibilité (availability, avec les valeurs normalisées InStock, OutOfStock, PreOrder, BackOrder), l'état (itemCondition), la validité du prix (priceValidUntil) et le vendeur. Google documente en plus deux objets que les assistants d'achat utilisent pour répondre aux questions de conditions : OfferShippingDetails pour les frais et délais de livraison par zone, et MerchantReturnPolicy pour la durée et les frais de retour. Pour un prix barré, Google attend un objet UnitPriceSpecification de type StrikethroughPrice plutôt qu'un texte.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://www.alpir.example/sacs/cairn-40#product",
  "name": "Sac à dos de randonnée Cairn 40 L",
  "brand": { "@type": "Brand", "name": "Alpîr" },
  "gtin13": "…",
  "sku": "ALP-CAIRN-40-GRIS",
  "color": "Gris ardoise",
  "image": ["https://www.alpir.example/img/cairn-40-face.jpg", "https://www.alpir.example/img/cairn-40-dos.jpg"],
  "description": "Sac de randonnée de 40 litres, 1,1 kg, dos ventilé, housse de pluie incluse, conçu pour deux à trois jours en autonomie.",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": 4.6,
    "reviewCount": 212,
    "bestRating": 5
  },
  "offers": {
    "@type": "Offer",
    "url": "https://www.alpir.example/sacs/cairn-40",
    "price": 139.00,
    "priceCurrency": "EUR",
    "priceValidUntil": "2026-09-30",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition",
    "seller": { "@type": "Organization", "name": "Alpîr" },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": { "@type": "MonetaryAmount", "value": 0, "currency": "EUR" },
      "shippingDestination": { "@type": "DefinedRegion", "addressCountry": "FR" },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": { "@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "DAY" },
        "transitTime": { "@type": "QuantitativeValue", "minValue": 2, "maxValue": 4, "unitCode": "DAY" }
      }
    },
    "hasMerchantReturnPolicy": {
      "@type": "MerchantReturnPolicy",
      "applicableCountry": "FR",
      "returnPolicyCategory": "https://schema.org/MerchantReturnFiniteReturnWindow",
      "merchantReturnDays": 30,
      "returnMethod": "https://schema.org/ReturnByMail",
      "returnFees": "https://schema.org/FreeReturn"
    }
  }
}

La règle est la même que pour toute donnée structurée : ce que dit le balisage doit être ce que dit la page, et les deux doivent être ce que dit le flux. Le prix balisé est le prix affiché, toutes taxes comprises pour un acheteur particulier ; la disponibilité balisée est celle du stock au moment où la page est servie, pas celle d'un cache de la veille.

Avis et notes sur une fiche produit

La note agrégée et les avis sont lus par tous les assistants d'achat, et ils pèsent dans les réponses de recommandation autant que le prix. Sur une fiche produit, le balisage AggregateRating (note, nombre d'avis, échelle) et Review (auteur, date, texte, note) est accepté par Google à condition que les avis soient collectés auprès de vos clients et portent sur le produit de la page ; les avis copiés depuis d'autres sites ne doivent pas être balisés. La restriction sur les avis auto-attribués, qui vise Organization et LocalBusiness, ne s'applique pas aux produits.

Ce qui fait la valeur d'un avis pour un moteur est détaillé dans l'article consacré aux avis clients ; pour une fiche produit, retenez trois points. Le nombre d'avis doit être affiché avec la note : « 4,6 sur 5 » ne veut rien dire sans « sur 212 avis ». Les avis doivent être datés et, si possible, rattachés à la variante concernée. Et les avis négatifs doivent rester visibles ; une fiche qui n'affiche que des cinq étoiles est traitée avec méfiance par un lecteur humain, et n'apporte aucun fait exploitable à un modèle qui cherche des points faibles à mentionner.

Les flux marchands : la deuxième porte d'entrée

Un flux marchand est un fichier, ou une API, qui transmet votre catalogue à une plateforme sous un format qu'elle impose. Merchant Center, chez Google, est le plus ancien et le mieux documenté : il alimente Shopping, les résultats marchands de la recherche classique et, d'après Google, les fonctionnalités d'achat d'AI Mode. OpenAI et Perplexity ont ouvert des dispositifs comparables, dont les spécifications sont publiques mais récentes ; vérifiez-les au moment de vous engager, et considérez-les comme des canaux à surveiller plutôt que comme des acquis.

Le point clé est la cohérence entre le flux et la page. Google vérifie que le prix et la disponibilité du flux correspondent à ceux de la page de destination, refuse les offres en cas d'écart, et recommande le balisage Product sur la page précisément pour cette vérification. Il n'y a aucune raison de penser que les autres plateformes seront plus tolérantes. La seule façon de tenir cette cohérence à l'échelle d'un catalogue est de générer page, balisage et flux depuis la même source, et de contrôler les écarts avant publication.

Ce qui fait écarter une fiche, et comment le mesurer

Dans nos audits de sites marchands, les fiches absentes des réponses d'achat partagent quelques défauts, dont aucun n'est spectaculaire. Chacun se vérifie sur un échantillon de dix fiches en moins d'une heure.

• Un prix et une disponibilité injectés en JavaScript après le chargement, invisibles dans le HTML initial et absents du JSON-LD.
• Une disponibilité balisée « en stock » sur des produits épuisés depuis des semaines, parce que le balisage est mis en cache.
• Un GTIN absent, erroné ou partagé entre plusieurs variantes.
• Une description copiée du fabricant, identique à celle de vingt autres vendeurs : rien ne justifie de citer la vôtre.
• Aucune information de livraison ni de retour, ni dans le texte ni dans le balisage.
• Une note affichée sans nombre d'avis, ou des avis sans date.
• Des images bloquées aux robots par une règle du CDN ou un domaine d'images interdit.
• Un flux marchand dont les prix diffèrent de ceux des pages, avec des offres refusées que personne ne surveille.

La mesure suit la logique de la part de citation, appliquée à un catalogue. On constitue un panel de questions d'achat réelles (« quel X pour Y », « X ou Y », « meilleur X à moins de Z euros »), on les passe chaque semaine dans les moteurs, et l'on relève trois choses : si un produit du catalogue est nommé, si le prix et la disponibilité cités sont exacts, et quelle source le moteur a utilisée, votre fiche, un comparatif ou une marketplace. Ce dernier point dit où porter l'effort ; les stratégies de contenu pour les questions de choix sont développées dans l'article GEO pour l'e-commerce.

Ce qu'il faut retenir