La semaine dernière, un client m'a demandé : « Nous avons un fichier schemas.ts dans notre base de code, mais plus personne ne sait pourquoi il est là ni ce que fait chaque bloc. » Ce n'est pas un cas isolé. Dans au moins la moitié des projets que je découvre, un fichier JSON-LD orphelin traîne quelque part, posé par un développeur il y a des années — sans documentation, sans objectif clair, et souvent sans que quiconque sache s'il est encore correct.
C'est dommage, car les données structurées sont exactement le type d'informations dont les systèmes d'IA comme ChatGPT, Perplexity et les AI Overviews de Google sont friands. C'est un contexte lisible par les machines qui dit : « voici qui nous sommes, voici où nous sommes, voici les réponses aux questions fréquentes ». Sans ce contexte, un modèle de langage doit deviner à partir d'un texte non structuré. Avec, il dispose d'une source directe et fiable.
Dans cet article, je vous présente les trois types de schema les plus utilisés — Organization, LocalBusiness et FAQPage — avec des exemples concrets que vous pouvez mettre en place dès aujourd'hui.
Pourquoi les données structurées comptent encore à l'ère de l'IA
Les données structurées (JSON-LD, le plus souvent) existent depuis 2011 grâce à schema.org, fondé conjointement par Google, Bing, Yahoo et Yandex. L'objectif était simple à l'époque : aider les moteurs de recherche à comprendre le contenu pour afficher des résultats enrichis — avis étoilés, horaires d'ouverture, blocs FAQ dépliables dans les résultats de recherche.
Ce qui a changé, c'est que le « lecteur » de vos données structurées n'est plus seulement un robot d'indexation qui prépare une liste de résultats. C'est aussi désormais un modèle de langage qui analyse votre contenu pour formuler une réponse à un utilisateur qui ne viendra même pas sur votre site. Si quelqu'un demande à ChatGPT « quelles entreprises à Utrecht, aux Pays-Bas, font du conseil en IA », la probabilité que votre JSON-LD soit repris dans la réponse est bien plus élevée que celle qu'un texte marketing soit correctement interprété.
C'est que les données structurées ne laissent place à aucune ambiguïté. Une phrase comme « Nous sommes au cœur d'Utrecht » oblige un modèle à interpréter et à faire des suppositions. Un objet PostalAddress avec addressLocality: "Utrecht" n'a pas besoin d'interprétation : c'est un fait directement exploitable.
Pour la stratégie d'ensemble derrière ce type d'optimisation, je vous invite à lire aussi ce que recouvre précisément le GEO — les données structurées ne sont qu'une pièce d'un puzzle plus vaste.
Les trois types de schema dont vous aurez presque toujours besoin
Organization : qui êtes-vous, vraiment ?
Le schema Organization est la base. Il répond à la question que les systèmes d'IA ont le plus souvent du mal à trancher : qu'est-ce que cette entreprise, et pourquoi lui faire confiance ? Ce schema a sa place sur votre page d'accueil, et idéalement vous le répétez (ou y faites référence) sur chaque page via votre gabarit.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "WeArkMedia",
"url": "https://wearkmedia.nl",
"logo": "https://wearkmedia.nl/logo.png",
"description": "Développement web natif IA et optimisation GEO/AEO pour les entreprises qui veulent être trouvées par ChatGPT, Perplexity et les AI Overviews de Google.",
"sameAs": [
"https://www.linkedin.com/company/wearkmedia",
"https://twitter.com/wearkmedia"
],
"contactPoint": {
"@type": "ContactPoint",
"email": "hallo@wearkmedia.nl",
"contactType": "customer service"
}
}
Un point essentiel : sameAs n'est pas décoratif. Ce champ relie votre entreprise à des sources externes vérifiables — votre page LinkedIn, votre page Wikipédia (si elle existe), votre profil Crunchbase. Les modèles d'IA s'appuient sur ces renvois croisés pour déterminer si une entité est « réelle ». Un schema Organization sans sameAs, c'est comme un profil LinkedIn sans relations : techniquement valide, mais peu convaincant.
Ne recopiez pas la description de votre méta-description. Rédigez une phrase précise sur ce que vous faites et pour qui — pas « nous sommes une agence de premier plan », mais concrètement : quoi, pour qui, pourquoi autrement.
LocalBusiness : indispensable si votre implantation physique doit être trouvée
Si vous avez un lieu physique — un bureau, une boutique, un cabinet —, LocalBusiness (ou un sous-type plus précis comme ProfessionalService, Restaurant, Store) est essentiel. Ce schema est la raison directe pour laquelle les assistants IA peuvent répondre aux questions du type « près de chez moi ».
{
"@context": "https://schema.org",
"@type": "ProfessionalService",
"name": "WeArkMedia",
"image": "https://wearkmedia.nl/kantoor.jpg",
"address": {
"@type": "PostalAddress",
"streetAddress": "Vredenburg 40",
"addressLocality": "Utrecht",
"postalCode": "3511 BD",
"addressCountry": "NL"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 52.0907,
"longitude": 5.1214
},
"telephone": "+31-30-1234567",
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
"opens": "09:00",
"closes": "17:30"
}
],
"priceRange": "€€€"
}
Deux erreurs fréquentes. D'abord, on oublie les coordonnées geo, alors que ce sont précisément elles que les systèmes utilisent pour calculer une distance lors de requêtes « le plus proche ». Ensuite, le @type est souvent trop générique. N'utilisez pas LocalBusiness par défaut s'il existe un sous-type plus précis — Google et les systèmes d'IA peuvent, avec un type spécifique (comme Dentist, Accountant ou MarketingAgency lorsqu'il est disponible), mieux répondre à l'intention.
C'est précisément le sujet que je développe plus en détail dans le GEO pour les entreprises locales — j'y explique aussi comment gérer plusieurs établissements.
FAQPage : le schema le plus sous-estimé pour l'AEO
S'il existe un type de schema qui influence directement le fait que vous soyez cité dans une réponse d'IA, c'est bien FAQPage. Pourquoi ? Parce qu'il fournit littéralement la structure question-réponse dont un modèle de langage a besoin pour réutiliser votre contenu dans sa propre réponse — souvent mot pour mot.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Combien coûte un site web natif IA ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Un site natif IA est livré par phases. Le coût dépend du nombre de pages, du nombre de langues et des connexions avec vos systèmes existants. Demandez un devis basé sur votre propre périmètre, avec un chiffrage en heures par phase."
}
},
{
"@type": "Question",
"name": "Les données structurées fonctionnent-elles aussi sans équipe technique ?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Oui. La plupart des CMS et frameworks prennent en charge le JSON-LD via des extensions ou de simples extraits de code. Vous n'avez pas besoin d'un développeur dédié pour implémenter un schema Organization ou FAQPage."
}
}
]
}
Le piège ici, c'est de remplir le schema FAQPage avec des questions marketing (« Pourquoi nous choisir ? ») plutôt qu'avec les questions que les gens posent réellement à un moteur de recherche ou à un assistant IA. Regardez la section « Autres questions posées » de Google, ou testez vous-même dans ChatGPT et Perplexity les questions qui reviennent sur votre sujet. Rédigez des réponses autonomes — une réponse doit être compréhensible sans relire la question, car c'est exactement ainsi qu'un modèle de langage l'extrait.
Je l'ai détaillé dans le guide pratique de l'AEO, notamment pour déterminer quelles questions méritent une réponse.
Du fichier isolé au système qui fonctionne : mise en œuvre pratique
Où placer cela dans votre base de code ?
Si vous avez déjà un fichier lib/schemas.ts (ou équivalent), la structure logique consiste à exporter des fonctions qui génèrent des objets JSON-LD à partir de votre contenu, et non des chaînes statiques. Par exemple :
// lib/schemas.ts
export function generateOrganizationSchema() {
return {
"@context": "https://schema.org",
"@type": "Organization",
name: "WeArkMedia",
url: "https://wearkmedia.nl",
// ...
};
}
export function generateFAQSchema(faqs: { question: string; answer: string }[]) {
return {
"@context": "https://schema.org",
"@type": "FAQPage",
mainEntity: faqs.map((faq) => ({
"@type": "Question",
name: faq.question,
acceptedAnswer: {
"@type": "Answer",
text: faq.answer,
},
})),
};
}
Cela évite que vos schemas se déconnectent de votre contenu — un problème fréquent lorsque le texte de la FAQ est modifié sur la page, mais que le schema associé ne suit pas. L'incohérence entre contenu visible et données structurées est exactement ce qu'il faut éviter : elle fragilise la confiance de Google comme des robots d'IA.
Testez et validez avant la mise en ligne
Utilisez le test des résultats enrichis de Google et le validateur de Schema.org avant de publier. Une faute de frappe dans @type (par exemple Organisation avec l'orthographe britannique au lieu de Organization) fait échouer le schema en silence, sans message d'erreur sur votre site ; vous ne vous en apercevez qu'en vous demandant pourquoi rien ne fonctionne.
N'oubliez pas non plus de vérifier que votre robots.txt ne bloque pas les robots d'IA qui devraient justement lire ces données — consultez le guide robots.txt et robots d'IA si vous doutez de votre configuration.