Données structurées : ce que les moteurs lisent vraiment sur une fiche produit

Le balisage de données structurées occupe une place étrange dans les priorités d’une équipe e-commerce. Tout le monde sait qu’il faut en avoir, presque personne ne le regarde après l’avoir posé, et il est presque toujours partiellement faux. La raison de cette négligence est facile à comprendre : un balisage se pose une fois, il passe la validation, et il n’émet plus jamais aucun signal. Rien ne se casse visiblement quand il devient inexact. C’est exactement pour cela que les erreurs y prospèrent, et ce sont des erreurs de synchronisation, pas de syntaxe.

Je veux distinguer d’emblée deux questions qu’on confond systématiquement. La première est « mon balisage est-il valide » : elle porte sur la conformité au vocabulaire, la présence des champs requis, la bonne imbrication. Un outil de validation y répond en trente secondes. La seconde est « mon balisage est-il vrai » : elle porte sur la correspondance entre les valeurs déclarées et la réalité de la page. Aucun outil de validation n’y répond, et c’est celle qui détermine le résultat.

Valide ou vrai : deux questions distinctes

Champ	Erreur fréquente	Conséquence	Correctif
price	Balisage généré au build, prix rafraîchi côté client	Résultat enrichi abandonné	Même source, même instant — ou pas de champ
availability	Cache plus long que le bloc de stock	Clic vers une rupture, déception imputée à la marque	Synchroniser sur la source de stock
aggregateRating	Note de la marque reprise sur chaque fiche	Risque d’action manuelle	Avis visibles, propres au produit balisé
gtin / mpn	Absent	Pas de rapprochement inter-vendeurs	Ajouter l’identifiant normalisé

Un champ absent coûte un affichage. Un champ faux coûte du crédit de confiance sur le domaine entier — et c’est le seul des deux qui ne se voit pas à la validation.

La validation ne vérifie pas l’exactitude

Le mécanisme mérite d’être décrit, parce qu’il explique la plupart des pertes d’affichage.

Un moteur qui rencontre un balisage produit ne le prend pas pour argent comptant. Il le compare au contenu visible de la page. Si la page affiche un prix et que le balisage en déclare un autre, l’incohérence est détectée. Si la page indique une rupture de stock et que le balisage annonce le produit disponible, l’incohérence est détectée.

La conséquence est graduelle et donc difficile à diagnostiquer. Une incohérence isolée est tolérée. Une incohérence systématique conduit le moteur à cesser d’utiliser le balisage — les résultats enrichis disparaissent sans notification, et l’équipe conclut à un changement d’algorithme. Une incohérence massive ou manifestement intentionnelle expose à une action manuelle.

Ce qu’il faut retenir : la validation syntaxique est un seuil minimal, pas un objectif. Un balisage qui valide et qui ment est pire qu’un balisage absent, parce qu’il consomme du crédit de confiance.

Le prix et la disponibilité, presque toujours désynchronisés

C’est de très loin l’erreur la plus répandue, et elle est presque toujours d’origine architecturale plutôt qu’humaine.

Elle se produit dès que le balisage et le contenu affiché suivent des chemins différents. Le cas typique d’un site à génération statique : les pages sont construites la nuit, le balisage encode le prix et le stock de ce moment, tandis que le prix affiché est rafraîchi côté client à chaque visite. Le visiteur voit le bon prix ; le moteur lit l’ancien. Autre cas fréquent : le balisage est mis en cache à un horizon plus long que le bloc de prix, avec le même effet.

La règle qui évite cela est simple à énoncer et exigeante à tenir : le balisage et l’affichage doivent provenir de la même source, au même instant. Si le prix affiché est calculé côté client, le balisage doit l’être aussi, ou bien la page ne doit pas déclarer de prix du tout. Un champ absent est infiniment préférable à un champ faux.

La disponibilité mérite une attention particulière parce qu’elle change plus souvent que le prix, et parce qu’elle a un effet direct sur l’expérience : un client qui clique sur un résultat annonçant un produit en stock et qui atterrit sur une rupture attribue la déception à la marque, pas au moteur.

Un champ absent coûte un affichage enrichi. Un champ faux coûte la confiance accordée au domaine — et celle-ci se reconstruit beaucoup plus lentement qu’elle ne se perd.

Les avis, seul terrain à risque de sanction

Le balisage d’avis est le plus tentant, parce que les étoiles dans les résultats de recherche ont un effet visible sur le taux de clic. C’est aussi le seul endroit du balisage produit où l’erreur expose à une sanction plutôt qu’à une simple perte d’affichage.

Trois règles, et elles ne souffrent pas d’exception. Les avis balisés doivent être visibles sur la page par le visiteur : baliser une note qui n’apparaît nulle part est du contenu trompeur. Ils doivent porter sur le produit balisé : reprendre la note globale de la marque, ou celle d’une gamme, sur chaque fiche est une pratique fréquente et fautive. Et la note doit refléter les avis réellement collectés, sans filtrage des avis négatifs.

Le cas ambigu le plus courant concerne les produits à variantes. Faut-il agréger les avis de toutes les tailles d’un même modèle ? La réponse dépend de la manière dont le produit est modélisé : si les variantes appartiennent à un même produit parent et que la page présente ce parent, l’agrégation est légitime. Si chaque variante a sa propre page indexable, l’agrégation ne l’est pas.

Les champs sous-utilisés qui changent l’affichage

Au-delà du minimum requis, quelques champs produisent un effet disproportionné sur la présentation dans les résultats. Ils sont peu coûteux à ajouter et souvent omis.

Les identifiants normalisés — code-barres, référence fabricant — permettent au moteur de rapprocher votre offre de la même référence chez d’autres vendeurs. C’est ce qui autorise l’apparition dans les comparaisons de prix. Pour une marque en propre, la référence interne joue ce rôle à condition d’être stable dans le temps.

Les conditions de livraison et de retour peuvent être déclarées de manière structurée. Elles se traduisent par des mentions visibles dans les résultats — livraison gratuite, retour sous trente jours — qui influencent le clic autant que le prix. Peu de marques les balisent.

Les variantes doivent être modélisées explicitement plutôt qu’aplaties en produits indépendants, faute de quoi le moteur voit plusieurs produits distincts au prix identique et à la description quasi identique, ce qui pose un problème de duplication.

Ce que les moteurs génératifs changent au rôle du balisage

Le rôle du balisage se déplace, et il se déplace dans un sens qui augmente son importance.

Un moteur de recherche classique utilise les données structurées pour présenter : il affiche des étoiles, un prix, un fil d’ariane. Un moteur génératif les utilise pour extraire : il compose une réponse en s’appuyant sur des faits, et un balisage exact lui fournit ces faits sous une forme non ambiguë, là où il devrait sinon les inférer du texte de la page avec le risque d’erreur que cela suppose.

L’exigence d’exactitude s’en trouve renforcée. Une réponse générative qui annonce un prix erroné parce que le balisage l’était produit un dommage direct — et le lecteur n’a aucun moyen de savoir d’où vient l’erreur. C’est un prolongement de ce qui gouverne plus largement la citabilité par ces moteurs¹ : ce qui est structuré, daté et vérifiable est repris ; ce qui est ambigu est ignoré ou déformé.

Le contrôle quotidien qui empêche le balisage de dériver

Je termine par la recommandation opérationnelle, parce qu’elle est la seule qui empêche le balisage de dériver après sa pose.

Il faut un contrôle automatisé qui, sur un échantillon de fiches, compare le balisage au contenu rendu. Le prix déclaré est-il celui qui s’affiche. La disponibilité déclarée correspond-elle à l’état réel du stock. La note agrégée correspond-elle aux avis présents sur la page. Ce contrôle s’exécute quotidiennement, en dehors du cycle de développement, parce que la dérive vient du contenu et non du code.

C’est une demi-journée de travail. Elle transforme un balisage qui se dégrade silencieusement en un balisage surveillé — et elle rend enfin visible la seule chose que la validation ne dit pas : est-ce vrai aujourd’hui.

---

Footnotes

1. Sur la manière dont les moteurs génératifs sélectionnent et citent des sources, et sur ce qui rend un contenu extractible, voir Se faire citer par les moteurs génératifs : ce qui remplace le référencement. ↩