Données structurées et recherche IA : ce qui compte vraiment

Ce que les données structurées apportent vraiment aux assistants IA

Chaque assistant IA qui répond à une question comme « meilleur dentiste près de chez moi » ou « où acheter cette pièce » envoie d’abord un robot d’indexation — un programme qui visite les pages web et en copie le contenu — pour lire votre site. Sans étiquettes, ce robot voit un mur de texte et doit deviner le sens : « 05 55 01 34 » est-il un numéro de téléphone ou une référence produit ? Les données structurées suppriment cette incertitude en enveloppant les faits dans un petit bloc de code appelé JSON-LD, discrètement présent sur la page, qui indique en somme : ceci est le numéro de téléphone, ceci est le prix, ceci est l’heure d’ouverture.

La documentation officielle d’OpenAI confirme que son robot, GPTBot, récupère les pages web publiques à peu près comme le ferait un moteur de recherche classique OpenAI, et les recommandations de Google sur les données structurées précisent explicitement que ces étiquettes aident un programme à « comprendre le contenu de la page » Google Search Central. Aucune des deux entreprises n’a indiqué ignorer cet étiquetage : en pratique, le même bloc JSON-LD que vous ajouteriez pour la recherche classique est aussi lu par les assistants vers lesquels vos clients se tournent désormais. Si vous ne l’avez jamais ajouté, les assistants qui répondent aujourd’hui aux questions sur votre entreprise travaillent à partir de suppositions, pas de faits.

Les quatre types de schema qui méritent votre temps

Schema.org recense des centaines de types d’éléments, de Recipe à Movie en passant par Airport, mais une petite ou moyenne entreprise n’a besoin que de quatre d’entre eux pour couvrir presque tous les faits qu’un assistant pourrait citer. Ajoutez ceux-ci, et ne vous préoccupez pas du reste.

• Organization — établit votre entreprise comme une entité unique et nommée, avec un logo et des liens vers vos profils sociaux officiels, pour qu’un assistant comprenne que le compte Instagram et le site web appartiennent tous deux à « La Boulangerie de Dolores ».
• LocalBusiness — une extension d’Organization conçue pour toute entreprise ayant une adresse physique ou une zone de service ; elle porte vos horaires, votre numéro de téléphone et votre quartier, exactement les détails dont un assistant a besoin pour répondre à « est-ce ouvert en ce moment ».
• Product et Offer — attachent un prix réel, une devise et une disponibilité à ce que vous vendez, pour qu’un assistant cite votre chiffre exact plutôt qu’une moyenne approximative de quelques concurrents.
• FAQPage — un ensemble de questions-réponses dans le format exact que les assistants aiment reprendre et citer mot pour mot à un utilisateur.

Ce qu’apporte une confirmation lisible par une machine à la résolution d’entité

Imaginez Dolores, propriétaire d’une boulangerie à Lyon. Elle a une fiche Google Business Profile, une page Yelp, un compte Instagram et un site web — quatre mentions distinctes de « La Boulangerie de Dolores » éparpillées sur internet. Avant de pouvoir la recommander en toute confiance, un assistant doit résoudre ce qu’on appelle la résolution d’entité : déterminer si ces quatre mentions décrivent bien la même entreprise réelle, ou si l’une d’elles renvoie à une autre boulangerie du même nom dans une autre ville.

Les données structurées offrent un raccourci à l’assistant. Une propriété schema.org appelée sameAs permet à Dolores de lister les adresses de son Instagram, Facebook et Yelp directement dans le balisage Organization de son propre site — une confirmation lisible par une machine, écrite de sa main, que ces comptes lui appartiennent schema.org. C’est un signal plus fort qu’un assistant déduisant une correspondance à partir de noms et d’adresses similaires trouvés sur des sources qu’il ne connaît pas parfaitement ; c’est Dolores elle-même qui atteste du lien, dans un format qu’aucune machine ne peut mal interpréter.

Cela compte d’autant plus que la concurrence sur un nom s’intensifie. Une unique « Boulangerie de Dolores » dans une ville de huit mille habitants se résout facilement. Un « Cabinet dentaire Rive Gauche » en concurrence avec quatre cliniques aux noms proches a besoin de chaque détail distinctif — l’adresse exacte, le numéro de téléphone exact, les liens sociaux confirmés — pour éviter qu’un assistant ne le confonde avec un concurrent de la rue voisine.

Un exemple de code JSON-LD à copier et adapter cette semaine

Pas besoin d’un développeur pour écrire cela de zéro ; il suffit de remplir un modèle. Un bloc JSON-LD pour une entreprise locale se place dans une seule balise script, marquée du type application/ld+json, et commence par une ligne déclarant son vocabulaire comme celui de schema.org. À l’intérieur, le type est défini sur LocalBusiness, suivi d’un champ name avec le nom exact de votre entreprise et d’un champ image pointant vers votre logo.

Vient ensuite une adresse, écrite comme un objet imbriqué de type PostalAddress, décomposée en streetAddress, addressLocality (votre ville), addressRegion (votre région) et postalCode — quatre champs distincts et étiquetés plutôt qu’une simple ligne de texte, car c’est ce qui permet à un assistant de répondre à « est-ce près de chez moi » sans confondre un code postal avec un numéro d’appartement. Suivent un champ telephone et un champ priceRange (aussi simple que « €€ » pour un tarif moyen). Un champ openingHoursSpecification liste vos jours et horaires dans un format structuré plutôt qu’une phrase, de sorte que « fermé le dimanche » ne puisse pas être lu par erreur comme « fermé le lundi ». Enfin, un champ sameAs contient une liste d’adresses : votre Instagram, votre page Facebook, votre fiche Yelp, et tout autre profil qui vous représente sans ambiguïté.

Une fois rédigé, ce bloc se colle une seule fois, près du début du code de votre page d’accueil, et on n’y touche plus. Si vous utilisez un créateur de site comme Squarespace, Wix ou Shopify, la plupart proposent désormais un champ dédié au code personnalisé ou aux données structurées, permettant de l’ajouter sans toucher au reste du site.

Ce que vous pouvez laisser de côté

Tous les types schema.org ne méritent pas votre attention, et vouloir tous les cocher gaspille un temps mieux investi dans les quatre présentés plus haut.

• Le balisage BreadcrumbList, qui décrit l’arborescence de votre site (Accueil > Menu > Gâteaux), aide les résultats de recherche classiques à afficher un fil d’Ariane mais n’apprend rien à un assistant sur les faits concernant votre entreprise — passez-le, sauf s’il existe déjà d’un projet précédent.
• AggregateRating sans avis réels sous-jacents. Les propres recommandations de Google sur les données structurées interdisent explicitement le balisage qui présente de façon trompeuse des notes que vous n’avez pas réellement Google Search Central, et un assistant qui répète une note gonflée que vous ne pouvez pas justifier est un risque pour votre réputation, pas un avantage.
• Un balisage profondément imbriqué ou dupliqué sur chaque page. Votre identité Organization n’a besoin d’être déclarée clairement qu’une seule fois, en général sur la page d’accueil ; la répéter de façon incohérente sur des dizaines de pages crée des versions contradictoires qu’un assistant doit ensuite réconcilier, ce qui est pire que de la déclarer une seule fois, correctement.
• Les types schema.org tout juste apparus et rarement pris en charge. Le vocabulaire lui-même recense des centaines de types conçus pour des usages très spécifiques comme les recettes de cuisine ou les aéroports schema.org ; si un type ne fait pas partie de la poignée dont on sait, documentation à l’appui, que les moteurs de recherche et les assistants l’utilisent réellement, l’étiquette ne vous sert à rien aujourd’hui.

Comment vérifier que vos données structurées fonctionnent vraiment

Ajouter le code n’est que la moitié du travail ; confirmer qu’il est lisible en est l’autre moitié. L’outil gratuit de Google, le test de résultats enrichis, permet de coller l’URL d’une page ou le code lui-même et de voir exactement quels types il détecte et quels champs manquent Google. Le lancer après chaque modification permet de repérer une coquille — une simple virgule manquante peut faire échouer tout un bloc silencieusement — avant qu’elle ne vous coûte quoi que ce soit.

Ce test vous dit que le code est valide. Il ne vous dit pas si ChatGPT a réellement utilisé vos horaires confirmés dans une réponse, ni si Perplexity continue de citer un concurrent en premier. C’est une question distincte, et c’est précisément celle à laquelle Growli a été conçu pour répondre : nous suivons ce que les assistants disent réellement d’une entreprise sur l’ensemble des plateformes, et signalons où l’écart entre un code correct et une réponse correcte persiste encore. Consultez comment ça marche si vous voulez vérifier vos propres résultats plutôt que de supposer que le balisage fait son travail.

FAQ