Données structurées pour les agents d'achat IA : les champs qui décident de votre citation

La plupart des boutiques qui échouent au test de préparation aux agents échouent sur la même chose : le prix, la disponibilité et le nom du produit que voit un client sont assemblés par JavaScript dans le navigateur, et le HTML brut que récupère un agent n'en contient aucun. Les données structurées rendues côté serveur sont ce qui rend une page produit répondable — et cela se vérifie en une commande. Ce guide couvre ce que lisent réellement les agents, quels champs comptent, et comment contrôler vos propres pages.

Ce que voit un agent n'est pas ce que vous voyez

Ouvrez une page produit dans un navigateur et tout y est. Récupérez la même URL avec un client HTTP simple et vous obtiendrez peut-être une coquille : un cadre de page, quelques scripts et des conteneurs vides que le navigateur aurait remplis.

Les assistants et les robots varient dans la quantité de JavaScript qu'ils exécutent, et ceux qui l'exécutent sont plus lents, plus faciles à écarter et moins constants. Miser sur le rendu est un pari que vous perdez en silence — rien ne signale d'erreur, votre produit n'est simplement pas dans la réponse.

Le test qui compte :

curl -s https://votreboutique.com/products/votre-produit | grep -c "application/ld+json"

Si cela renvoie 0, un agent qui lit votre page n'a aucune description structurée du produit. Vérifiez ensuite que le HTML brut contient bien le titre et le prix sous forme de texte — pas comme un emplacement de gabarit.

Les champs qui décident si vous pouvez être cité

Le JSON-LD de produit a de nombreux champs facultatifs et une poignée qui travaillent réellement. À peu près par ordre d'impact :

• name — le nom du produit, identique à celui de la page. Un écart entre le JSON-LD et le texte visible est un signal de qualité contre vous.
• offers.price et offers.priceCurrency — un nombre et un code devise ISO. Un prix sans devise est inutilisable, et une devise incohérente avec la page est pire qu'aucun prix.
• offers.availability — une valeur explicite InStock / OutOfStock. Une disponibilité absente signifie qu'un assistant écarte votre produit d'une réponse « puis-je l'acheter maintenant » ou devine.
• image — au moins une, avec une vraie URL. Les agents construisent de plus en plus des comparaisons visuelles.
• description — la vraie description du produit, non le slogan de la boutique répété sur chaque fiche.
• sku / gtin — les identifiants permettent à un agent de rapprocher votre offre du même produit ailleurs. C'est ainsi que vous apparaissez dans les comparaisons au lieu d'être un article non apparié.
• brand — peu coûteux à inclure, fréquemment utilisé pour filtrer.

C'est sur les variantes que la plupart des catalogues deviennent flous. Si un produit a de vraies variantes à des prix différents, une offre unique avec un seul prix représente mal la page. Exprimez soit la fourchette avec AggregateOffer (lowPrice, highPrice, priceCurrency), soit les variantes comme des offres distinctes avec leurs propres SKU. Prendre le prix d'une variante et le présenter comme celui du produit, c'est ainsi que commencent les réclamations « le site disait 19 EUR ».

Une disponibilité honnête

La disponibilité est le champ le plus susceptible d'être faux, parce que c'est celui qui change. Deux habitudes le gardent utile :

• Refléter l'état réel du stock, y compris « commandable mais pas en stock » si c'est ce que vous voulez dire — schema.org a des valeurs pour la commande en attente et la précommande, et les utiliser vaut mieux qu'un InStock global qui se transforme en e-mail d'annulation.
• Ne pas le mettre en cache jusqu'à l'obsolescence. Si votre page est servie depuis un cache long tandis que le stock bouge, un agent obtient une réponse assurée qui était vraie il y a une heure. C'est le champ pour lequel il vaut la peine de réfléchir à la durée de cache.

Au-delà de la page produit

Le balisage produit vous fait entrer dans les réponses sur les produits. Deux autres types décident si vous entrez dans les questions qui précèdent et suivent l'achat :

• Organization, sur la page d'accueil — qui vous êtes, votre logo, votre URL et des liens sameAs vers les endroits où vous existez aussi. C'est ce qui permet à un modèle de rapprocher votre boutique de vos autres présences au lieu de traiter chacune comme une entité inconnue distincte.
• FAQPage, sur les pages qui répondent réellement à des questions — livraison, retours, tailles, compatibilité. Un assistant qui répond à « est-ce livré en Autriche ? » préfère une réponse structurée à un paragraphe qu'il doit interpréter.

Les deux sont peu coûteux, et les deux visent à être résoluble plutôt que simplement présent. Un agent qui ne peut pas savoir si deux mentions de votre marque désignent la même entreprise restera prudent.

Des règles qui gardent le balisage crédible

Des données structurées en désaccord avec la page sont pires que rien — les moteurs de recherche les traitent comme du spam, et les modèles apprennent à se méfier de la source.

• Ne balisez que ce qui est visible. Un prix dans le JSON-LD qui n'apparaît nulle part sur la page est une infraction, pas un raccourci.
• Un produit par page produit. Baliser une collection entière comme un seul produit sème la confusion partout en aval.
• Pas d'avis inventés. Un AggregateRating avec des chiffres que vous ne pouvez pas justifier est le moyen le plus rapide de perdre tout le balisage — et celui qui déclenche une action manuelle.
• Gardez-le dans le HTML. Un JSON-LD injecté après le chargement par un gestionnaire de balises est exactement aussi invisible que le reste de votre rendu côté client.

Contrôler tout le catalogue, pas une page

Une bonne page produit prouve que le thème en est capable. Elle ne prouve pas que le catalogue est cohérent — et l'incohérence est la norme : produits importés à des dates différentes, variantes ajoutées ensuite, images manquantes sur la longue traîne.

Les contrôles à exécuter sur un échantillon plutôt que sur une seule page :

• Chaque produit échantillonné rend-il son titre et son JSON-LD dans le HTML brut ?
• Chaque offre porte-t-elle un prix et une devise ?
• La disponibilité est-elle présente et précise ?
• Les images existent-elles, et ont-elles un texte alternatif ? Un alt manquant est à la fois un défaut d'accessibilité et une description perdue.
• Le type et la catégorie du produit sont-ils renseignés, pour qu'un agent puisse le situer dans une taxonomie ?

Sichta exécute ces contrôles de façon déterministe sur un échantillon de votre catalogue en direct et signale chaque produit en échec, ce qui est plus actionnable qu'un score unique. L'important n'est pas le chiffre — c'est la liste des produits à corriger.

En bref

Récupérez votre propre page produit avec curl avant de croire quoi que ce soit sur votre préparation aux agents. Assurez-vous que le nom, le prix avec devise et une disponibilité précise figurent dans un JSON-LD rendu côté serveur, exprimez les variantes comme une fourchette ou des offres distinctes plutôt qu'en en choisissant une, ajoutez des identifiants pour être apparié dans les comparaisons, et placez le balisage Organization et FAQPage là où il doit être. Ne balisez jamais ce qui n'est pas sur la page, et contrôlez un échantillon du catalogue plutôt que votre meilleur produit.