Maillage d’entités & Knowledge Graph : Renforcer sa Sémantique

1. Introduction : du moteur de recherche au moteur de réponse (avec du café dedans)

Pendant plus de vingt ans, nous avons appris à parler aux moteurs de recherche dans leur langue : celle des chaînes de caractères. Nous avons optimisé des <title>, travaillé nos <h1>, nos ancres, nos occurrences, allant même jusqu’à calculer des densités.

Sur un site eCommerce de café, cela donnait des pages « café en grain », « café moulu pas cher », « café de spécialité livraison rapide », avec quelques raffinements sur des requêtes comme « café éthiopien fruité » ou « café en grain pour espresso ». Tant que Google fonctionnait surtout comme un gigantesque index reliant des mots à des documents, cette approche suffisait.

Depuis 2024, et de façon accélérée en 2025 et 2026, la recherche bascule vers des interfaces de réponse : AI Overviews côté Google, et des moteurs « answer engine » comme Perplexity ; côté OpenAI, la recherche intégrée à ChatGPT a aussi élargi l’usage « question → synthèse ».

L’utilisateur ne cherche plus seulement « des liens » : il formule un besoin.

“Quel café de spécialité en grain, plutôt acidulé, pour une Chemex, livré en France ?”

Et il obtient une synthèse : profils aromatiques, origines (Éthiopie, Kenya, etc.), traitements, conseils de préparation… avec, parfois, quelques sources citées en appui.

Dans ce paradigme, le moteur ne se contente plus d’associer des mots à des URLs : il tente de comprendre un univers. Il cherche à identifier les objets (cafés, origines, torréfacteurs, méthodes) et les relations qui les lient (ce café vient de telle région, tel torréfacteur le torréfie, telle méthode convient à tel profil).

Autrement dit, on passe d’un SEO centré sur la page à un SEO centré sur la donnée, et, surtout, sur l’identité : pour être compris durablement, il faut apprendre à nommer, décrire, puis relier.

C’est précisément l’objet de cet article.

À partir d’un cas concret (un site de café de spécialité), nous allons montrer comment :

➡️ Identifier les entités qui composent notre univers métier

➡️ Les structurer avec Schema.org et JSON-LD

➡️ Construire un knowledge graph interne (KGI) cohérent

➡️ Créer un maillage d’entités navigable et crawlable

➡️ Aligner ce graphe avec des référentiels publics (Wikidata, Wikipedia)

L’objectif : Devenir une source de connaissance structurée et exploitable par les moteurs de recherche et de réponse.

La suite est réservée à nos abonnés.
Déjà abonné ? Se connecter

Envie de lire la suite ?

-10% sur nos Abonnements de 6 mois et + avec le code :

JEVEUXPASPAYERPLEINPOT

Apprenez auprès des meilleurs experts, grâce à leurs partages de connaissances et leurs retours d’expérience.

2. Ce qu'est une entité (dans l'univers du café)

Avant de parler de maillage d’entités ou de knowledge graph interne (KGI), il faut poser une base simple : Qu’est-ce qu’une entité, concrètement, pour un moteur comme Google ?

Dans le web sémantique, une entité est une « chose » identifiable de manière univoque ; quelque chose que l’on peut nommer (avec un identifiant stable) et décrire (avec des propriétés). Cette « chose » peut être :

➡️ Une entreprise : une brûlerie, une coopérative, un importateur, un coffee shop…

➡️ Un produit : un café en grain précis (« Éthiopie Yirgacheffe lavé »), une capsule, un blend maison…

➡️ Une personne : le torréfacteur, le fondateur, un barista connu…

➡️ Un lieu : un pays, une région, une ferme, une ville…

➡️ Un évènement : un concours, un atelier, une masterclass…

➡️ Un concept : café de spécialité, process naturel, French press, Chemex, V60…

Ce qui fait une entité, ce n’est pas seulement son nom, c’est le fait que l’on puisse la pointer avec un identifiant unique (URI – Uniform Resource Identifier / IRI – International Resource Identifier), puis la décrire de façon stable.

En pratique, nous manipulons deux familles d’identifiants :

IDs internes (au sein de notre site) :

➡️ https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product

➡️ https://monsupercafe.fr/guides/methode-chemex#guide

➡️ https://monsupercafe.fr/#organization

IDs externes (référentiels publics) :

➡️ https://www.wikidata.org/wiki/Q115 pour l’Éthiopie

➡️ https://www.wikidata.org/wiki/Q… pour une région, une méthode (à récupérer via Wikidata – nous verrons comment plus bas 😉)…

Une fois identifiées, ces entités deviennent des nœuds que l’on relie entre eux. C’est la logique même des graphes de triplets (RDF Triples en anglais).

2.1. Des mots aux entités : Pourquoi la différence est critique

Si nous écrivons sur notre site :

« Nous proposons un café de spécialité, un Éthiopie Yirgacheffe aux notes florales et acidulées, idéal pour la méthode Chemex. »

Un moteur peut l’interpréter de deux manières :

➡️ Lecture « old school » (mots → documents)

Il voit des tokens (« café », « spécialité », « Éthiopie », « Yirgacheffe », « Chemex »)
Il les indexe
Il nous positionne sur des requêtes proches

➡️ Lecture orientée entités (objets → relations)

« café de spécialité » → un concept/catégorie
« Éthiopie » → un pays (entité lieu)
« Yirgacheffe » → une zone (entité lieu)
« Chemex » → dans le langage courant une « méthode » ; en modélisation, on peut représenter l’outil (cafetière) et/ou le protocole (méthode d’extraction)
« Notre produit » → une entité café unique, liée à une origine, un process, des notes, des recommandations

Dans le premier cas, nous jouons avec des mots.

Dans le second, nous construisons un modèle de connaissance dans lequel nous pouvons exprimer des faits et des relations du type :

➡️ Le café X vient de Yirgacheffe

➡️ Yirgacheffe est en Éthiopie

➡️ Ce café est conseillé pour Chemex (outil et/ou protocole)

➡️ Ce café est torréfié par notre organisation

➡️ Notre organisation est située à tel endroit

C’est cette deuxième vision (entités + relations + identifiants stables) qui rend possible un graphe interne, un maillage qui « a du sens », et la réconciliation avec des référentiels externes.

2.2. Triplets : la grammaire minimale des entités

Pour formaliser ces relations, le web sémantique repose sur des triplets :

Sujet – Prédicat – Objet

(entité A) – (relation) → (entité B)

En RDF, c’est très littéral : un triplet a un sujet, un prédicat, et un objet, et le prédicat est un URI (une relation identifiée de façon non ambiguë).

Exemples pédagogiques pour notre site de café :

Café Yirgacheffe — origine → Yirgacheffe
Yirgacheffe — estEn → Éthiopie
Café Yirgacheffe — torréfiéPar → Brûlerie MonSuperCafé
Café Yirgacheffe — profilAromatique → floral / agrumes
Café Yirgacheffe — recommandéPour → Chemex

Ensuite, on « mappe » ces relations vers un vocabulaire (ici Schema.org) lorsque c’est pertinent, ou vers des propriétés génériques lorsque Schema.org n’offre pas de propriété dédiée.

Exemples Schema.org :

Café → propriété countryOfOrigin → Éthiopie
Yirgacheffe → propriété containedInPlace → Éthiopie
Café → propriété manufacturer (ou propriété brand) → Brûlerie MonSuperCafé
Café → propriété additionalProperty → (type PropertyValue : « process » = « lavé », « méthode recommandée » = « Chemex », etc.)

💡 À retenir : Un knowledge graph interne (KGI), au fond, c'est l'ensemble de ces triplets, propres, stables, et reliés.

2.3. Types d'entités et vocabulaire Schema.org (thématique Café)

Pour qu’un moteur comprenne ce que représente une entité, on commence par « typer ». Schema.org fournit un vocabulaire largement suffisant pour l’univers du café, notamment :

➡️ Type Product → cafés, packs, abonnements, équipements, moulins, machines…

➡️ Type Organization → brûlerie, coffee shop, coopérative, importateur…

➡️ Type Person → fondateur, torréfacteur, barista…

➡️ Type Place → pays producteurs, régions, villes…

➡️ Type Event → cuppings, ateliers, festivals, concours…

➡️ Type HowTo → guides d’extraction, conseils de préparation…

À chaque type sont associées des propriétés ; et quand une info n’a pas de propriété « native » (notes aromatiques, process, etc.), additionalProperty + PropertyValue est un excellent mécanisme de modélisation.

2.4. Entités locales vs Entités globales

Dernier point clé : une entité peut exister :

Localement (uniquement chez nous) : notre « blend espresso maison », notre masterclass, notre barista interne…
Globalement (déjà décrite au sein de graphes publics) : le café (Wikidata, Wikipedia), l’Éthiopie (Wikidata, Wikipedia), des régions, des méthodes, des outils, des labels, etc.

La stratégie gagnante pour un site de café de spécialité :

✅ Définir proprement les entités locales (produits, pages entités, guides, événements) avec des @id stables (qui ne bougent pas dans le temps)

✅ Relier ces entités entre elles (origine, process, notes, recommandations)

✅ Connecter au global quand c’est pertinent (pays, régions, méthodes, organisations) via la propriété sameAs, qui pointe vers une page de référence désambiguïsante (Wikidata/Wikipedia/Crunchbase/site officiel/réseaux sociaux)

"C’est cette articulation (local ↔ global), appuyée par des identifiants stables, qui prépare notre site à “parler graphe”, et qui rend ensuite le maillage d’entités logique, durable et extensible."

🤓 Le mot de l'expert

3. Auditer et extraire les entités de notre site (et ceux de nos concurrents 😇)

Avant de construire un knowledge graph interne (KGI), il faut répondre à une question simple : Quelles entités notre site expose-t-il réellement, et quelles entités sont effectivement détectées par des systèmes d’analyse automatisée ?

En SEO « classique », on audite des pages, des balises, des logs.

En SEO sémantique, on audite des entités et des signaux d’identification (noms, variantes, contexte, relations).

L’objectif de cette étape est double :

1️⃣ Dresser l’inventaire des entités qui composent notre univers (cafés, origines, méthodes, acteurs)

2️⃣ Tester la lecture « machine » de nos contenus via une API d’analyse de langage, en particulier l’API Google Cloud Natural Language (Natural Language Processing, NLP). Elle ne « rejoue » pas exactement Google Search, mais elle constitue un lecteur externe standardisé très utile pour objectiver ce qui ressort d’un texte.

3.1. Ce que nous pensons dire vs ce qu'un modèle extrait

Prenons une fiche produit typique sur un site de café de spécialité :

« Café Éthiopie Yirgacheffe Lavé.

Un café de spécialité aux notes florales et d’agrumes, cultivé à près de 2000 mètres d’altitude et idéal pour les méthodes douces (V60, Chemex). Torréfié chaque semaine dans notre atelier à Montpellier. »

Pour nous, l’entité principale est évidemment le produit (type Product), entouré d’un contexte structurant :

➡️ L’origine (pays/région)

➡️ Le process

➡️ Le profil aromatique

➡️ Les méthodes d’extraction

➡️ La brûlerie (organisation)

Mais un système d’extraction d’entités peut attribuer une importance disproportionnée à des éléments secondaires (une ville, un terme générique, un marqueur de contexte), selon la formulation et la distribution du texte.

D’où l’intérêt de mesurer ce qui est effectivement détecté, plutôt que de le supposer.

3.2. Premier niveau : Inventaire éditorial

Avant de sortir les APIs, commençons par un inventaire « métier » dans un simple tableur (Google Sheets est parfait pour ça).

Pour un eCommerce de café, nous pouvons créer des onglets ou catégories du type :

➡️ Produits : cafés, blends, abonnements, équipements…

➡️ Origines : pays, régions, fermes, coopératives…

➡️ Acteurs : brûlerie, fondateurs, torréfacteurs, baristas…

➡️ Méthodes : V60, Chemex, French Press, Aeropress…

➡️ Éducation : guides, FAQ, glossaire…

Dans chaque onglet, listons a minima :

➡️ Nom de l’entité (label)

➡️ Type cible Schema.org (Product, Place, Organization, Person, HowTo, Event…)

➡️ Propriétés clés (origine, process, altitude, notes aromatiques…)

➡️ Page associée (URL principale)

➡️ Importance business (Stratégique / Important / Secondaire)

Exemple/Échantillon (un zoom sur l’image est conseillé 😉) :

Cet inventaire devient la base de notre future « base d’entités ». Mais à ce stade, il ne dit encore rien de la lecture automatisée : c’est là qu’intervient l’analyse NLP.

3.3. Deuxième niveau : Extraction automatique

3.3.1 Récupérer les ID Wikipedia (URLs) et les ID Knowledge Graph de Google (MID)

L’API Google Cloud Natural Language propose une méthode d’analyse de contenu rédactionnel qui renvoie notamment :

➡️ La liste des entités détectées

➡️ Leur type NLP (PERSON, ORGANIZATION, LOCATION, CONSUMER_GOOD, EVENT, etc.)

➡️ Un score de saillance (salience) indiquant l’importance relative de l’entité dans le document

➡️ Et, lorsque possible, des métadonnées comme une URL Wikipedia (metadata.wikipedia_url), ou encore un identifiant Knowledge Graph (metadata.mid)

💡 À noter : Pour l'alignement public dans votre markup, privilégiez le QID Wikidata (stable, documenté, accessible à tous). Le MID Google est utile côté audit (via API NLP) pour vérifier la reconnaissance par Google, mais n'est pas à exposer systématiquement dans vos données structurées. Sur les entités structurantes (pays, grandes régions, méthodes très répandues), c'est un bonus pour l'audit ; sur les produits, c'est rarement nécessaire.

Démonstration rapide avec l’outil Google :

Nous pouvons déjà nous faire un premier aperçu des résultats renvoyés par l’API grâce à la version de démo mise à disposition (gratuitement) par Google. Utile pour rapidement détecter les entités présentes au sein de son contenu (ou celui de ses concurrents) :

À plus grande échelle : Template Google Sheets de Lazarina Stoy

Je ne peux que renvoyer vers la proposition de Lazarina, qui met à disposition une méthode simple associée à un template Google Sheets très intelligemment conçu, permettant de renseigner URLs et contenu, et de requêter en un clic l’API Google Cloud Natural Language afin d’en ressortir entités, saillance, et identifiants Wiki, entre autres.

Laissez le script faire son travail, dégustez un bon café en patientant (facile celle-là 😏), et découvrez ensuite l’ensemble des entités identifiées au sein du contenu que vous avez soumis :

💡 Pour les volumes importants : Bien évidemment, comme tout script tournant sous Google Sheets, cette méthode rencontre une certaine limite. Pour une analyse de contenu relativement long, ou de listes de plusieurs centaines d'URLs ou de mots-clés, il est préférable d'enfiler sa casquette "Trust Me, I'm a Tech Guy" et d'effectuer l'analyse via un script Python dédié (via Google Colab, ça tourne très bien 🤓).

3.3.2 Récupérer les QID (ID Wikidata)

L’API Google Cloud Natural Language ne renvoyant pas systématiquement les ID Wikidata, la bonne pratique est alors de vérifier directement à la source, au sein de Wikidata lui-même.

Pour cela :

1️⃣ Recherchez l’entité dans Wikidata et vérifiez la bonne désambiguïsation (ville vs district, concept vs produit, etc.)

2️⃣ Utilisez ensuite l’URL au format https://www.wikidata.org/wiki/Qxxx

🎁 Bonus : Il existe également un très bon outil Frenchie (woop woop 🙌 🇫🇷) créé par Olivier de Segonzac (Resoneo), le Wikidata Knowledge Explorer, permettant de découvrir de manière structurée et visuelle les diverses relations entre entités, d’identifier les IDs associés (Wikidata, Wikipedia, Knowledge Graph ID), ou encore de monitorer sa présence en tant que marque.

"Nous parlons souvent de Wikipedia en termes de référentiel externe, mais d’un point de vue purement sémantique, Wikidata est la source (Wikipedia se nourrit notamment des données Wikidata). Avoir son identifiant Wikidata maximise les chances d'apparaître au sein du Knowledge Panel de Google, mais également d’être cité par les différents moteurs de réponse IA. De plus, un ID Wikidata a la particularité d’être “stable”, sous-entendu qu’il ne change pas dans le temps, même si votre nom de marque est amenée à évoluer."

🤓 Le mot de l'expert

⚠️ Important : types NLP vs types Schema.org

Les types renvoyés par l’API NLP relèvent d’une taxonomie d’extraction (utile pour l’audit). Ils ne remplacent pas les types Schema.org (utiles pour la structuration JSON-LD).

⚠️ Préparer le texte avant NLP (sans quoi la saillance serait « bruitée »)

Avant d’envoyer une page, isolez le contenu principal : description produit, blocs origine/process, conseils d’usage. Évitez les éléments tels que la navigation, le footer, les blocs cross-selling, les CGV, etc. Un protocole d’extraction stable est indispensable pour comparer les résultats entre pages.

3.4. Interpréter les résultats : la saillance comme KPI

La saillance (salience) est un score qui varie de 0 à 1 et mesure à quel point une entité est centrale dans un document donné.

Sur une fiche produit café, nous aimerions idéalement voir :

✅ Le produit (ou, à défaut, l’origine précise) parmi les premières entités avec une saillance élevée
✅ Les éléments structurants (origine, process, méthode, notes aromatiques) bien représentés
✅ Le reste (ville, mentions secondaires) relégué plus bas

Si, au contraire, l’analyse remonte :

❌ « Montpellier » comme entité la plus saillante
❌ Des termes trop génériques (ex : « café de spécialité »)
❌ « Chemex » à peine détecté

Cela suggère que, dans la formulation actuelle, notre fiche « parle » davantage du contexte (atelier, ville, génériques) que du produit et de ses attributs différenciants.

3.5. Croiser automatisation et expertise métier

L’API NLP n’est pas parfaite ; elle peut mal interpréter des termes très « métier » (micro-lots, fermes peu connues, variantes orthographiques), ou ne pas relier comme nous le ferions « à la main ».

C’est pourquoi l’audit doit rester hybride :

1️⃣ Extraction automatique

Lancer un batch sur vos pages clés (produits, catégories, pages marque, contenus pédagogiques)
Exporter entités + saillances

2️⃣ Relecture métier

Vérifier si les entités jugées importantes sont réellement les bonnes
Identifier les entités manquantes (méthode, process, ferme, coopérative…)
Enrichir l’inventaire (synonymes, alias, variantes → « V60 », « Hario V60 », « V-60 », etc.)

3️⃣ Ajustements éditoriaux

Réécrire les passages où les relations métier doivent être rendues plus explicites (origine précise, coopérative, process, usages)
💡Un outil d’aide à la rédaction comme YourTextGuru peut aider à enrichir le champ lexical et sémantique de vos contenus, ce qui améliore indirectement la détection d’entités par l’API NLP
Relancer l’analyse afin de vérifier l’effet sur l’extraction

3.6. Construire une "base d'entités" à partir de l'audit

À l’issue de cette phase, votre tableur peut devenir une véritable base d’entités.

Exemple pour nos produits de café :

➡️ page_canonique : URL principale

➡️ id_interne : Identifiant stable (URI) de l’entité sur notre site

➡️ label : « Café Éthiopie Yirgacheffe Lavé 250g »

➡️ type_schema : Product

➡️ zones_analysees : « titre » « description courte », « bloc origine », etc.

➡️ entites_NLP_principales : Entités détectées par l’API NLP (Éthiopie, Chemex, V60, Montpellier…)

➡️ score_saillance : Score d’importance relative (0-1)

➡️ pertinence_entites_detectees : Statut (OK / À vérifier / Bruit possible)

➡️ entites_externes_associees : Éthiopie (Wikidata Q115), Yirgacheffe (Wikidata Q3572300), etc.

➡️ alias : Variantes de libellés (ex. « V60 » / « Hario V60 » / « V-60 »)

➡️ priorite_business : Priorisation métier (Stratégique / Important / Opportunité)

Exemple/Échantillon (un zoom sur l’image est conseillé 😉) :

👀 Observation intéressante :

Yirgacheffe (0.0131) et Éthiopie (0.0096) sont les entités les plus saillantes → Cohérent avec le produit
Chemex et V60 sont bien détectés comme méthodes recommandées
Café moulu (0.0046) est un exemple de « bruit » : le produit est vendu en grain, mais le terme apparaît probablement dans la FAQ ou les conseils
Fleur d’oranger, Citron, Bergamote : Notes aromatiques possibles ou bruit sémantique → À qualifier avec expertise métier

💡 Enseignement : L'audit NLP nécessite toujours une relecture métier (section 3.5) pour distinguer signal et bruit.

Ce tableau :

✅ Sert de référence pour la suite (balisage JSON-LD, création du KGI)
✅ Permet de prioriser (commencer par les entités stratégiques dont la lecture est mauvaise)
✅ Crée un pont entre vision métier et lecture machine (via l’API NLP)

À partir de là, nous ne travaillons plus « dans le vide » ; nous savons quelles entités existent, ce qu’elles représentent, et comment un extracteur d’entités les perçoit.

La prochaine étape consiste à les structurer explicitement dans nos pages via Schema.org et JSON-LD, puis à formaliser le graphe des relations entre elles.

4. Structurer les entités avec Schema.org et JSON-LD

À ce stade, nous savons quelles entités nous manipulons (cafés, origines, méthodes, acteurs) et nous avons un premier aperçu de la lecture « machine » via l’audit.

Prochaine étape : rendre ces entités explicitement interprétables par les moteurs via des données structurées, en utilisant le vocabulaire Schema.org (types + propriétés) sérialisé en JSON-LD (format recommandé par Google parmi les formats supportés).

L’objectif n’est plus seulement d’écrire :

« Café Éthiopie Yirgacheffe, idéal pour Chemex »

… mais d’indiquer clairement :

➡️ Qu’il s’agit d’un produit

➡️ Associé à une organisation (marque / fabricant)

➡️ Relié à un pays d’origine

➡️ Enrichi de caractéristiques métier (process, notes aromatiques, méthode recommandée…)

⚠️ Règle de base : Les données structurées doivent correspondre au contenu visible sur la page (sinon, risque de non-éligibilité et/ou de signal de spam).

4.1. Pourquoi Schema.org et JSON-LD ?

Schema.org fournit un vocabulaire commun utilisé par les moteurs.

JSON-LD permet d’embarquer ce vocabulaire sous forme de bloc script, indépendant du HTML.

Avantages concrets :

✅ Découplé du HTML : plus simple à maintenir et à générer
✅ Expressif : possibilité de décrire plusieurs entités et relations dans un même bloc (notamment avec @graph)
✅ Exploitable par les moteurs : Google décrit l’usage des données structurées pour comprendre le contenu et, plus largement, des informations sur le web

4.2. Définir un produit en JSON-LD

Schema.org ne propose pas de type « Coffee » dédié ; on modélise donc le Café en Product.

Voici un exemple de ce à quoi pourrait ressembler le balisage de notre fiche produit Café Yirgacheffe Lavé :

				
					{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product",
  "category": {
    "@type": "DefinedTerm",
    "name": "Café",
    "url": "https://monsupercafe.fr/glossaire/cafe"
  },
  "name": "Café Éthiopie Yirgacheffe - Lavé - 250G",
  "description": "Café de spécialité aux notes florales et d'agrumes, cultivé à près de 2000 mètres d'altitude, et idéal pour les méthodes douces.",
  "image": "https://monsupercafe.fr/media/cafes/ethiopie-yirgacheffe-250g.jpg",
  "sku": "ETH-YIR-250G",
  "gtin13": "3700000000001",
  "brand": {
    "@type": "Organization",
    "name": "MonSuperCafé"
  },
  "weight": {
    "@type": "QuantitativeValue",
    "value": 250,
    "unitCode": "GRM"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g",
    "price": 12.90,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@type": "Organization",
      "name": "MonSuperCafé"
    },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "FR"
      }
    }
  }
}

Imaginez que ce code est la carte d’identité numérique de notre paquet de café, spécialement rédigée pour que Google (et les autres robots) puissent la lire sans ambiguïté.

Voici ce que chaque partie raconte à Google :

L'état civil du produit

➡️ @context & @type : C’est la préface. On dit à Google : « Je vais te parler dans le langage Schema.org, et l’objet que je décris est un produit »

➡️ @id : C’est le « numéro de sécurité sociale » unique de ce produit sur notre site. Cela permet de dire « Ce produit précis » sans le confondre avec une autre page ou un autre café

➡️ category : La catégorie du produit (ici Café). Nous utilisons un DefinedTerm pour pointer vers notre page glossaire qui définit ce qu’est le café

➡️ name : Le nom officiel : « Café Éthiopie Yirgacheffe – Lavé – 250G »

➡️ description : Le résumé court (le pitch) : « Café de spécialité aux notes florales… »

➡️ image : La photo d’identité du produit (l’URL de l’image)

Les références techniques (logistique)

➡️ sku : Le numéro de référence interne (celui utilisé dans l’entrepôt pour gérer le stock)

➡️ gtin13 : Le code-barres officiel. C’est un identifiant universel reconnu mondialement → Pertinent pour Google Shopping

➡️ brand : Le fabricant. Ici, on précise que la marque est une Organisation qui s’appelle « MonSuperCafé »

➡️ weight : Le poids du produit, structuré avec QuantitativeValue (250 grammes). Le code GRM suit la norme UN/CEFACT pour désigner les grammes

Pourquoi QuantitativeValue plutôt qu’un simple texte « 250g » ?

✅ Format structuré et parsable par les machines
✅ Permet des calculs et conversions automatiques
✅ Utilise des codes standards internationaux (UN/CEFACT)

L'offre commerciale (`offers`)

C’est la partie « étiquette de prix » en rayon. Elle dit à Google : « Ok, tu sais ce que c’est, maintenant voici comment on peut l’acheter ».

➡️ url : Le lien direct pour acheter ce produit

➡️ price & priceCurrency : Il coûte 12.90 EUR

➡️ availability : Le feu vert. InStock signifie « En stock ». S’il était épuisé : OutOfStock

➡️ seller : Le commerçant qui vend le produit. Ici, c’est encore « MonSuperCafé »

➡️ shippingDetails : Informations sur la livraison. Nous précisons que le produit est expédié en France (addressCountry: "FR")

Pourquoi OfferShippingDetails ?

✅ Indique clairement la zone de livraison → important pour Google Shopping
✅ Peut être enrichi avec coûts de livraison, délais, transporteurs
✅ Aide les moteurs à filtrer les offres disponibles dans une zone géographique

💡 Note importante sur category : Nous utilisons un DefinedTerm pour lier le produit au concept Café. Cette catégorisation sera encore plus robuste lorsque nous construirons notre knowledge graph interne et connecterons cette catégorie à des référentiels externes comme Wikidata (section 6).

Visuellement, cela nous donne :

"Si vous ajoutez review et aggregateRating, (conseillé dans le cadre d’une fiche produit défini par le markup Product), assurez-vous que ces avis existent réellement et sont visibles sur la page (conformité Google ⚠️)."

🤓 Le mot de l'expert

4.3. Définir l'organisation et relier via @graph et @id

Principe clé : Définissez votre organisation une fois, puis réutilisez son @id partout → le maillage commence ici !

Notez également l’utilisation du mécanisme @graph pour encapsuler plusieurs types Schema.org (ici Organization et WebSite) et dessiner la relation entre nos @id et entités.

				
					{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://monsupercafe.fr/#organization",
      "name": "MonSuperCafé",
      "description": "Torréfacteur artisanal de cafés de spécialité basé à Montpellier",
      "url": "https://monsupercafe.fr/",
      "logo": "https://monsupercafe.fr/media/logo-monsupercafe.jpg",
      "sameAs": [
        "https://www.instagram.com/monsupercafe",
        "https://www.facebook.com/monsupercafe",
        "https://www.youtube.com/@MonSuperCafe"
        /* + Wikipedia/Wikidata/Crunchbase de l’organisation si existant */
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://monsupercafe.fr/#website",
      "url": "https://monsupercafe.fr/",
      "name": "MonSuperCafé",
      "publisher": {
        "@id": "https://monsupercafe.fr/#organization"
      }
    }
  ]
}

Ce morceau de code est différent du précédent. Si le précédent était la carte d’identité d’un produit spécifique, celui-ci est le passeport de l’entreprise et du site web.

Il ne décrit pas quelque chose que nous vendons, mais qui nous sommes.

Voici ce qu’il raconte à Google, divisé en deux parties grâce à la commande @graph (qui permet de lister plusieurs entités distinctes mais connectées) :

L'entité "Organisation" (l'entreprise réelle)

C’est la première partie du bloc ("@type": "Organization"). Elle décrit notre entreprise en tant que personne morale.

➡️ @id (…/#organization) : C’est le point clé. Nous créons une « ancre ». À l’avenir, n’importe quelle autre page de notre site pourra dire : « Je suis vendu par #organization », sans avoir à répéter toutes ses infos (name, description, etc.)

➡️ name, description, url : C’est notre présentation officielle : « Nous sommes MonSuperCafé, torréfacteur à Montpellier… »

➡️ logo : L’image officielle qui doit apparaître dans le Knowledge Panel de Google (la fiche d’infos au-dessus ou à droite des résultats de recherche)

➡️ sameAs : C’est crucial. Nous disons à Google : « Regarde, ce profil Instagram, cette page Facebook et cette chaîne YouTube, c’est aussi MOI ». C’est ce qui permet à Google de relier tous nos comptes et profils afin de comprendre notre notoriété globale

💡 À noter : sameAs doit référencer une page qui identifie votre organisation, pas un article générique. Également, logo et sameAs contribuent à clarifier l'identité et la cohérence des signaux, sans promettre un Knowledge Panel (qui dépend de nombreux facteurs).

L'entité "WebSite" (le site web)

C’est la seconde partie ("@type": "WebSite"). Elle décrit l’objet technique « site web ».

➡️ @id (…/#website) : Là aussi, nous créons une ancre unique pour notre site

➡️ name : Le nom du site (souvent proche du nom de l’entreprise, mais pas toujours)

➡️ publisher (l’éditeur) : C’est ici que la magie opère

Ce champ dit : « L’éditeur responsable de ce site web est l’entité définie par l’ID #organization ».
Google comprend donc le lien hiérarchique : L’entreprise (1) possède et publie le site web (2).

Visuellement, cela nous donne :

En résumé : À quoi ça sert ?

Ce script est généralement placé sur la page d’accueil (ou dans l’en-tête de toutes les pages). Il sert à asseoir son autorité de marque.

Contrairement au markup Produit qui aide à vendre un article, ce markup aide Google à comprendre que MonSuperCafé est une véritable marque, avec un logo, des réseaux sociaux et une existence légale, et pas juste un site anonyme.

C’est la base de votre réputation aux yeux du moteur de recherche.

4.4. Joindre le Product à l'Organization

À ce stade, nous pouvons aisément mailler le produit à l’organisation. Gardons à l’esprit que nous traitons ici une page produit, et donc que l’entité principale est en toute logique notre produit.

Au lieu de répéter toutes les informations de l’organisation, nous utilisons simplement son @id :

				
					{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product",
  "name": "Café Éthiopie Yirgacheffe - Lavé - 250G",
  "description": "Café de spécialité aux notes florales et d'agrumes.",
  "image": "https://monsupercafe.fr/media/cafes/ethiopie-yirgacheffe-250g.jpg",
  "sku": "ETH-YIR-250G",
  "gtin13": "3700000000001",
  "brand": {
    "@id": "https://monsupercafe.fr/#organization"
  },
  "weight": {
    "@type": "QuantitativeValue",
    "value": 250,
    "unitCode": "GRM"
  },
  "offers": {
    "@type": "Offer",
    "price": 12.90,
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "seller": {
      "@id": "https://monsupercafe.fr/#organization"
    },
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "FR"
      }
    }
  }
}

Notez la différence :

❌ Avant (redondance) :

				
					"brand": {
  "@type": "Organization",
  "name": "MonSuperCafé",
  "url": "https://monsupercafe.fr/",
  "logo": "https://monsupercafe.fr/media/logo-monsupercafe.jpg",
  "sameAs": [...]
}

✅ Après (référence) :

				
					"brand": {
  "@id": "https://monsupercafe.fr/#organization"
}

Même chose pour seller :

				
					"seller": {
  "@id": "https://monsupercafe.fr/#organization"
}

Avantages :

✅ Pas de duplication d’informations

✅ Maintenance simplifiée : Si vous changez le nom de votre organisation, vous ne modifiez qu’un seul endroit

✅ Compréhension claire : Google comprend que c’est la même entité Organisation référencée partout (brand, seller, publisher)

✅ Cohérence du graphe : Les relations entre entités deviennent explicites

Visuellement, cela nous donne :

4.5. La gestion des @id : le système nerveux du KGI

C’est la partie la plus stratégique. Les @id (identifiants uniques) agissent comme des câbles qui relient les entités entre elles.

Le Maillage « Page ↔︎ Produit » (la boucle fermée)

➡️ L’entité WebPage déclare : « Je suis une page dont l’entité principale est #product » (via la propriété mainEntity)

➡️ L’entité Product répond : « Je suis l’entité principale de la page #webpage » (via la propriété mainEntityOfPage)

Intérêt : Cette double validation élimine toute ambiguïté. Google sait exactement quel est le sujet central de l’URL.

Le Maillage « Site ↔︎ Page » (l’ancrage global)

➡️ L’entité WebPage déclare : « Je suis une partie de l’entité #website » (via isPartOf)

Intérêt : Nous connectons cette fiche produit isolée à la puissance et à l’autorité de notre domaine principal (défini dans notre header).

Le Maillage « Marque ↔︎ Produit » (l’autorité)

➡️ Le brand et le seller ne sont pas juste du texte « MonSuperCafé ». Ils pointent vers l’ID #organization.

Intérêt : Nous disons à Google : « Ce n’est pas n’importe quel vendeur, c’est l’organisation officielle décrite dans le header, celle qui a des profils sociaux vérifiés et un logo officiel ».

Cela renforce fortement l’E-E-A-T (Autorité & Confiance).

💡 Principe fondamental : Chaque @id est un nœud dans votre graphe. Plus vous créez de connexions explicites entre ces nœuds, plus votre knowledge graph interne devient riche et exploitable.

4.6. Erreurs fréquentes à éviter

❌ Redéfinir la même entité partout au lieu de réutiliser un @id
❌ Utiliser des @type sans @id (= blocs isolés, peu « fusionnables »)
❌ Marquer des infos non présentes/visibles sur la page

✅ Best practice : Pensez « entités réutilisables » dès le début. Chaque entité importante (organisation, pays, méthode, région) mérite son @id stable.

Dans la section suivante, nous allons passer à l’étape supérieure : construire et visualiser l’ensemble de notre knowledge graph interne (KGI), avec tous ces @id reliés entre eux de manière cohérente.

5. Construire et visualiser son knowledge graph interne (KGI)

À ce stade, nous avons :

✅ Identifié nos entités (cafés, origines, méthodes, acteurs)
✅ Commencé à les structurer avec Schema.org et JSON-LD

La question devient : « Comment organiser tout cela dans un ensemble cohérent, pilotable et exploitable ? »

C’est le rôle du knowledge graph interne (KGI).

L’objectif d’un KGI n’est pas de « faire joli », mais de :

➡️ Rendre explicite la structure de notre univers café

➡️ Vérifier que les relations métier sont bien représentées

➡️ Identifier les « trous dans la raquette » (entités orphelines, relations manquantes)

➡️ Préparer un socle solide pour les moteurs de recherche… et les moteurs de réponse IA

5.1. Construire son graphe

L’approche la plus simple, la plus flexible, et souvent la plus rentable au début est l’approche via tableur (+ schéma visuel → optionnel) : vous formalisez votre univers sous forme de triplets, puis vous le visualisez.

Pour ce faire, créez un onglet Triplets (ou Relations) dans votre Google Sheets, avec des colonnes qui séparent clairement :

➡️ L’identifiant (URI)

➡️ Le libellé

➡️ La relation (propriété Schema.org quand elle existe, sinon prédicat métier interne)

Colonnes que je préconise :

Colonne	Description
`subject_id`	URI de l’entité source
`subject_label`	Nom lisible de l’entité source
`predicate`	Relation (ex: `schema:countryOfOrigin` ou `kgi:recommendedFor`)
`object_id`	URI de l’entité cible
`object_label`	Nom lisible de l’entité cible
`status`	État (À créer / En cours / À valider / À publier / Publié)

Exemple/Échantillon relatif à notre cas d’étude (un zoom sur l’image est conseillé 😉) :

Pourquoi cette structure est solide :

✅ Flexibilité : Possibilité de commencer avec des prédicats métier (kgi:*) sans se bloquer sur Schema.org
✅ Compatibilité : Un fichier CSV suffit pour fabriquer un graphe avec des outils de visualisation
✅ Industrialisation : Vous préparez l’étape de génération automatique de JSON-LD, exports, contrôles

💡 À noter : Pour cet article, j'utilise la construction de ma base de données avec Google Sheets et la mise en forme visuelle via Mermaid. Il existe bien évidemment d'autres approches pour centraliser les entités, comme s'appuyer sur un référentiel JSON, ou sur une approche orientée graphe, via des solutions comme Neo4j, Gephi, ou encore GraphDB.

Ici, l'essentiel n'est pas l'outil : c'est la clarté des entités, des IDs et des relations.

5.2. Visualiser le graphe pour détecter les opportunités

Même un graphe simple, visualisé, permet de répondre à des questions très opérationnelles :

🔍 Quels sont nos hubs sémantiques (origines, méthodes, acteurs) ?

🔍 Quels produits sont isolés (pas d’origine précise, pas de process, pas de méthode, pas de contenus reliés) ?

🔍 Quelles relations manquent (une méthode citée mais sans guide, une région mentionnée mais jamais modélisée comme entité) ?

🔍 Où notre univers est incohérent (un café « espresso » relié uniquement à des méthodes filtre, etc.) ?

La visualisation devient :

➡️ Un tableau de bord sémantique

➡️ Un support de discussion (SEO / contenu / métier)

➡️ Un outil de priorisation (quelles pages enrichir en priorité, quelles entités créer, quels liens ajouter)

5.3. Et l'ontologie dans tout ça ?

À ce stade, nous avons identifié des entités, commencé à les relier, et posé un graphe interne. Mais un knowledge graph ne tient pas sans cadre ; il repose sur un modèle de domaine qui définit :

➡️ Les types d’entités

➡️ Leurs sous-catégories

➡️ Et les relations autorisées entre elles

Ce modèle conceptuel, le web sémantique l’appelle une ontologie.

L’objet de cet article n’est pas d’entrer dans la définition et la création d’une ontologie ; toutefois, il est utile de préciser « en surface » ce que ce modèle représente, de sorte à éviter tout abus de langage et de confusion (notamment entre un knowledge graph et une ontologie).

Voici une (rapide) définition des termes à ne pas confondre :

Pourquoi c'est crucial en SEO (même si vous restez "pragmatique")

En SEO, nous utilisons déjà un vocabulaire standardisé : Schema.org fournit des types et propriétés qui permettent de structurer un univers sans construire une ontologie formelle complète (au sens strict du web sémantique, avec axiomes et inférences OWL/RDFS).

Mais pour un KGI exploitable, nous avons besoin d’au moins une mini-ontologie interne, même légère, qui répond à des questions simples :

➡️ Un Product doit-il avoir au moins un countryOfOrigin ?

➡️ Une Place doit-elle être rattachée à une autre Place/Country (containedInPlace) ?

➡️ Une méthode (guide HowTo) doit-elle être reliée à des produits « recommandés pour » ?

➡️ Quelle relation exprime l’origine « région/ferme » quand Schema.org ne propose pas un équivalent exact (→ d’où la création de nos kgi:* dans notre table dédiée aux triplets au sein de notre spreadsheet) ?

C’est ce cadre qui évite les graphes incohérents, les relations « au hasard », et les entités orphelines.

💡 En résumé : Votre ontologie interne, même basique, est le "code de la route" de votre KGI. Elle garantit que toutes les entités sont reliées de manière cohérente et prévisible.

Maintenant que notre graphe interne est structuré, la question devient : « Comment le relier au monde extérieur ? » Ou plus précisément : « Comment aligner nos entités locales avec les référentiels publics pour maximiser la compréhension par les moteurs ? »

C’est l’objet de la section suivante.

6. Relier le graphe interne au knowledge graph public

Notre knowledge graph interne (KGI) décrit déjà notre univers café : produits, origines, méthodes, acteurs… et les relations qui les structurent. Mais, pour un moteur, une question reste centrale : l’identité.

Quand notre site mentionne « Éthiopie », « Arabica », « Yirgacheffe », ou « Chemex », parle-t-il exactement des mêmes entités que celles déjà connues dans les graphes publics ?

Tant que cette « réconciliation » n’est pas explicite, le moteur doit gérer l’ambiguïté : homonymes, variantes de transcription, entités locales vs entités globales. Or, le Knowledge Graph de Google est précisément conçu pour relier « des personnes, des lieux, et des choses », et répondre à des questions factuelles à partir d’entités.

Relier notre graphe interne au graphe public consiste donc à poser des ponts d’identité : « mon entité locale ↔ l’entité globale correspondante ».

6.1. Wikipedia, Wikidata, MID : trois référentiels complémentaires

Plutôt que de les opposer, il est utile de comprendre leur rôle :

1️⃣ Wikipedia : ancrage éditorial et désambiguïsation

Une page Wikipedia (quand elle existe) aide à stabiliser le sens d’une entité : définition, contexte, synonymes, homonymes. C’est particulièrement utile sur des termes ambigus (ex. « Yirgacheffe » peut désigner une ville ou un district).

2️⃣ Wikidata : identifiant stable (QID) + structure

Wikidata fournit un identifiant stable et langue-agnostique (un QID → « Q… »), très pratique pour relier vos entités à un référentiel externe structuré (pays, régions, espèces botaniques, méthodes…).

3️⃣ Google Knowledge Graph MID (Machine ID) : identifiant côté Google

Certaines APIs Google exposent un identifiant d’entité (MID) quand Google reconnaît l’entité. Par exemple :

L’API Google Cloud Natural Language peut renvoyer metadata.mid et parfois une URL Wikipedia associée
La Knowledge Graph Search API renvoie des MID au format /m/... dans ses réponses JSON

💡 Usage recommandé : Le MID est utile côté audit (via API NLP) pour vérifier la reconnaissance par Google. Pour le markup public, privilégiez le QID Wikidata via sameAs (plus stable, documenté, accessible à tous).

"L’objectif n’est pas de tout “wikidata-iser”, mais de brancher nos entités locales (nos produits, nos contenus, nos acteurs internes) sur une colonne vertébrale d’entités globales (pays, régions, méthodes, concepts, variétés) pour réduire l’ambiguïté."

🤓 Le mot de l'expert

6.2. Implémenter l'alignement des entités pour une architecture sémantique optimale

En Schema.org, sameAs doit être réservé aux cas où il s’agit de la même entité (identité stricte). Google illustre notamment son usage pour relier une Organization à des pages externes pertinentes (profils officiels, pages de référence).

Contrairement à un balisage classique qui se contente de lister des données à plat, le markup que nous allons construire crée un graphe interconnecté. Il ne dit pas seulement à Google « ceci est un produit », il lui explique comment ce produit s’insère dans notre site, dans notre entreprise, et dans le monde réel.

Approche 1 : Markup "auto-suffisant" (pour débuter)

Voici la structure du markup complet, avec tous les éléments intégrés dans le @graph :

				
					{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#webpage",
      "url": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g",
      "name": "Café Éthiopie Yirgacheffe Lavé 250g - Achat en ligne | MonSuperCafé",
      "inLanguage": "fr-FR",
      "isPartOf": {
        "@id": "https://monsupercafe.fr/#website"
      },
      "mainEntity": {
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#breadcrumb",
      "itemListElement": [
        {
          "@type": "ListItem",
          "position": 1,
          "name": "Accueil",
          "item": "https://monsupercafe.fr/"
        },
        {
          "@type": "ListItem",
          "position": 2,
          "name": "Nos Cafés",
          "item": "https://monsupercafe.fr/cafes/"
        },
        {
          "@type": "ListItem",
          "position": 3,
          "name": "Éthiopie Yirgacheffe",
          "item": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g"
        }
      ]
    },
    {
      "@type": "Product",
      "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product",
      "mainEntityOfPage": {
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#webpage"
      },
      "category": {
        "@type": "DefinedTerm",
        "@id": "https://monsupercafe.fr/glossaire/cafe#concept",
        "name": "Café",
        "url": "https://monsupercafe.fr/glossaire/cafe",
        "sameAs": [
          "https://www.wikidata.org/wiki/Q8486",
          "https://fr.wikipedia.org/wiki/Café"
        ]
      },
      "name": "Café Éthiopie Yirgacheffe - Lavé - 250G",
      "description": "Café de spécialité aux notes florales et d'agrumes, cultivé à près de 2000 mètres d'altitude, et idéal pour les méthodes douces.",
      "image": "https://monsupercafe.fr/media/cafes/ethiopie-yirgacheffe-250g.jpg",
      "sku": "ETH-YIR-250G",
      "gtin13": "3700000000001",
      "brand": {
        "@id": "https://monsupercafe.fr/#organization"
      },
      "weight": {
        "@type": "QuantitativeValue",
        "value": 250,
        "unitCode": "GRM"
      },
      "offers": {
        "@type": "Offer",
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#offer",
        "price": 12.90,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "url": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g",
        "seller": {
          "@id": "https://monsupercafe.fr/#organization"
        },
        "shippingDetails": {
          "@type": "OfferShippingDetails",
          "shippingDestination": {
            "@type": "DefinedRegion",
            "addressCountry": "FR"
          }
        }
      },
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": 4.7,
        "reviewCount": 3,
        "bestRating": 5,
        "worstRating": 1
      },
      "review": [
        {
          "@type": "Review",
          "name": "Très aromatique et équilibré",
          "reviewBody": "Notes florales bien présentes, acidité douce et finale d'agrumes. Excellent en Chemex.",
          "datePublished": "2025-11-18",
          "author": {
            "@type": "Person",
            "name": "Camille D."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 5
          }
        },
        {
          "@type": "Review",
          "name": "Parfait pour méthodes douces",
          "reviewBody": "Très propre et délicat, sans amertume. Je recommande aussi en V60.",
          "datePublished": "2025-12-02",
          "author": {
            "@type": "Person",
            "name": "Julien R."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 4
          }
        },
        {
          "@type": "Review",
          "name": "Un Yirgacheffe fidèle",
          "reviewBody": "Profil typique, floral et citronné. Très bon rapport qualité/prix.",
          "datePublished": "2026-01-29",
          "author": {
            "@type": "Person",
            "name": "Sophie L."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 5
          }
        }
      ],
      "countryOfOrigin": {
        "@type": "Country",
        "@id": "https://monsupercafe.fr/origines/ethiopie#country",
        "name": "Éthiopie",
        "url": "https://monsupercafe.fr/origines/ethiopie",
        "sameAs": [
          "https://www.wikidata.org/wiki/Q115",
          "https://fr.wikipedia.org/wiki/Éthiopie"
        ]
      },
      "additionalProperty": [
        {
          "@type": "PropertyValue",
          "name": "Region",
          "value": "Yirgacheffe",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe#region",
            "name": "Yirgacheffe",
            "url": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe",
            "sameAs": [
              "https://www.wikidata.org/wiki/Q3572300",
              "https://fr.wikipedia.org/wiki/Yirgachefe_(woreda)"
            ]
          }
        },
        {
          "@type": "PropertyValue",
          "name": "Process",
          "value": "Process lavé",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/guides/process-lave#guide",
            "name": "Process lavé",
            "url": "https://monsupercafe.fr/guides/process-lave",
            "sameAs": "https://fr.wikipedia.org/wiki/Café#Séchage_ou_lavage"
          }
        },
        {
          "@type": "PropertyValue",
          "name": "Méthode recommandée",
          "value": "Chemex",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/guides/methode-chemex#guide",
            "name": "Chemex",
            "url": "https://monsupercafe.fr/guides/methode-chemex",
            "sameAs": [
              "https://www.wikidata.org/wiki/Q5090371",
              "https://fr.wikipedia.org/wiki/Chemex"
            ]
          }
        }
      ]
    }
  ]
}

Voici l’analyse détaillée de la mécanique de ce code :

1. La structure en `@graph` : le maillage interne

L’utilisation de la racine @graph est fondamentale. Au lieu de jouer avec des blocs isolés (Page, Fil d’Ariane, Produit), nous jouons avec des nœuds d’un même réseau. Google reçoit un seul « paquet » d’informations où tout est déjà relié.

2. L'enrichissement sémantique : le knowledge graph externe

C’est ici que notre markup devient « intelligent ». Regardons les différents points d’alignement :

a) La catégorie Café (`category`)

				
					"category": {
  "@type": "DefinedTerm",
  "@id": "https://monsupercafe.fr/glossaire/cafe#concept",
  "name": "Café",
  "url": "https://monsupercafe.fr/glossaire/cafe",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q8486",
    "https://fr.wikipedia.org/wiki/Café"
  ]
}

Sans alignement : Google lit le mot « café ». Il comprend que c’est un item de la catégorie café, mais doit deviner le contexte exact.

Avec DefinedTerm + sameAs, nous communiquons à Google :

➡️ L’ID Wikidata (Q8486) qui représente le concept « Café (boisson) »

➡️ L’URL Wikipedia française correspondante

➡️ Notre page glossaire qui définit le terme dans notre contexte métier

L’impact SEO :

1️⃣ Désambiguïsation : Nous évitons toute confusion (café boisson vs café établissement vs café couleur)

2️⃣ Connexion au Knowledge Graph : Notre produit est « raccroché » au concept universel de café tel que Google le connaît déjà

b) Le pays d'origine (`countryOfOrigin`)

				
					"countryOfOrigin": {
  "@type": "Country",
  "@id": "https://monsupercafe.fr/origines/ethiopie#country",
  "name": "Éthiopie",
  "url": "https://monsupercafe.fr/origines/ethiopie",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q115",
    "https://fr.wikipedia.org/wiki/Éthiopie"
  ]
}

Même logique : l’Éthiopie est définie complètement avec son alignement Wikidata (Q115) et Wikipedia.

c) Les attributs métier (`additionalProperty`)

Dans la section additionalProperty, nous utilisons des DefinedTerm pour :

➡️ La région/district (Yirgacheffe) → QID Wikidata Q3572300 + lien Wikipedia

➡️ Le process (Lavé) → lien section Wikipedia

➡️ La méthode recommandée (Chemex) → QID Wikidata Q5090371 + lien Wikipedia

Chaque DefinedTerm est défini avec :

➡️ Son @id unique

➡️ Son name et url

➡️ Son alignement sameAs vers Wikidata/Wikipedia

🤔 Sans DefinedTerm : Google lit le mot « Chemex ». Il doit deviner s’il s’agit d’une cafetière, d’une gare ferroviaire, ou d’une entreprise.

😃 Avec DefinedTerm + sameAs : Nous communiquons à Google l’ID Wikidata (Q5090371) et l’URL Wikipedia. Google sait exactement de quoi nous parlons.

L’impact SEO est double :

1️⃣ Désambiguïsation : nous levons le doute. Nous disons « Je parle précisément de cet objet défini dans la base de connaissance mondiale »

2️⃣ Connexion au Knowledge Graph de Google : en utilisant Wikidata, nous connectons nos données (notre café) aux données de Google. Nous « accrochons » notre produit à sa propre compréhension du monde. Si un utilisateur cherche « café pour Chemex« , notre produit est mathématiquement pertinent car il est relié au concept même de Chemex

3. Le fil d'ariane (`BreadcrumbList`)

Il est aussi relié via son @id. Il structure la profondeur du site. Il ne sert pas qu’à l’affichage visuel dans les résultats ; il aide les robots à comprendre la structure hiérarchique : Accueil > Catégorie > Produit.

4. Les éléments commerciaux avancés

QuantitativeValue pour le poids :

				
					"weight": {
  "@type": "QuantitativeValue",
  "value": 250,
  "unitCode": "GRM"
}

Pourquoi c’est mieux qu’un simple "weight": "250g" :

✅ Structuré et parsable par les machines
✅ Utilise le code standard UN/CEFACT (GRM = grammes)
✅ Permet des calculs et des conversions automatiques

OfferShippingDetails pour la livraison :

				
					"shippingDetails": {
  "@type": "OfferShippingDetails",
  "shippingDestination": {
    "@type": "DefinedRegion",
    "addressCountry": "FR"
  }
}

Pourquoi c’est important :

✅ Indique clairement la zone de livraison (France)
✅ Pertinent pour Google Shopping et les comparateurs
✅ Peut être enrichi avec des coûts de livraison, délais, etc.

5. Les avis clients (`Review`)

Les 3 reviews sont conservées car ce sont des données propres au produit :

➡️ Elles varient d’un produit à l’autre

➡️ Elles ne peuvent pas être « référencées » ailleurs

➡️ Elles contribuent au rich snippet (étoiles dans les SERPs)

Résumé de la valeur ajoutée

✅ Ce script transforme une simple page de vente en un nœud d’information structuré

✅ Il solidifie l’identité du produit (via GTIN/SKU)

✅ Il prouve qui le vend (via #organization)

✅ Il catégorise le produit (via concept Café aligné)

✅ Il explique ce qu’il contient (via Wikidata)

✅ Il précise les conditions commerciales (poids, livraison) → “Hello Google Shopping ! 👋”

✅ Il situe sa place dans le site (via #website et #breadcrumb)

✅ Il affiche la preuve sociale (avis clients)

C’est une méthode techniquement robuste pour communiquer avec les moteurs de recherche (et de réponse) aujourd’hui.

Visuellement, cela nous donne :

Approche 2 : Markup "KGI optimisé" (architecture mature)

L’approche ci-dessus fonctionne parfaitement, mais elle a un inconvénient : chaque fiche produit redéfinit les mêmes entités (Café, Yirgacheffe, Chemex, Éthiopie, Process lavé…) avec toutes leurs propriétés.

Dans une architecture KGI mature, ces entités sont définies une seule fois sur leurs pages canoniques, et les fiches produit ne font que référencer leurs @id.

Voici la version optimisée du même markup :

				
					{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#webpage",
      "url": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g",
      "name": "Café Éthiopie Yirgacheffe Lavé 250g - Achat en ligne | MonSuperCafé",
      "inLanguage": "fr-FR",
      "isPartOf": {
        "@id": "https://monsupercafe.fr/#website"
      },
      "breadcrumb": {
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#breadcrumb"
      },
      "mainEntity": {
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product"
      }
    },
    {
      "@type": "Product",
      "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#product",
      "mainEntityOfPage": {
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#webpage"
      },
      "category": {
        "@type": "DefinedTerm",
        "@id": "https://monsupercafe.fr/glossaire/cafe#concept"
      },
      "name": "Café Éthiopie Yirgacheffe - Lavé - 250G",
      "description": "Café de spécialité aux notes florales et d'agrumes, cultivé à près de 2000 mètres d'altitude, et idéal pour les méthodes douces.",
      "image": "https://monsupercafe.fr/media/cafes/ethiopie-yirgacheffe-250g.jpg",
      "sku": "ETH-YIR-250G",
      "gtin13": "3700000000001",
      "brand": {
        "@id": "https://monsupercafe.fr/#organization"
      },
      "weight": {
        "@type": "QuantitativeValue",
        "value": 250,
        "unitCode": "GRM"
      },
      "offers": {
        "@type": "Offer",
        "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#offer",
        "price": 12.90,
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "url": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g",
        "seller": {
          "@id": "https://monsupercafe.fr/#organization"
        },
        "shippingDetails": {
          "@type": "OfferShippingDetails",
          "shippingDestination": {
            "@type": "DefinedRegion",
            "addressCountry": "FR"
          }
        }
      },
      "aggregateRating": {
        "@type": "AggregateRating",
        "ratingValue": 4.7,
        "reviewCount": 3,
        "bestRating": 5,
        "worstRating": 1
      },
      "review": [
        {
          "@type": "Review",
          "name": "Très aromatique et équilibré",
          "reviewBody": "Notes florales bien présentes, acidité douce et finale d'agrumes. Excellent en Chemex.",
          "datePublished": "2025-11-18",
          "author": {
            "@type": "Person",
            "name": "Camille D."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 5
          }
        },
        {
          "@type": "Review",
          "name": "Parfait pour méthodes douces",
          "reviewBody": "Très propre et délicat, sans amertume. Je recommande aussi en V60.",
          "datePublished": "2025-12-02",
          "author": {
            "@type": "Person",
            "name": "Julien R."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 4
          }
        },
        {
          "@type": "Review",
          "name": "Un Yirgacheffe fidèle",
          "reviewBody": "Profil typique, floral et citronné. Très bon rapport qualité/prix.",
          "datePublished": "2026-01-29",
          "author": {
            "@type": "Person",
            "name": "Sophie L."
          },
          "reviewRating": {
            "@type": "Rating",
            "ratingValue": 5
          }
        }
      ],
      "countryOfOrigin": {
        "@type": "Country",
        "@id": "https://monsupercafe.fr/origines/ethiopie#country"
      },
      "additionalProperty": [
        {
          "@type": "PropertyValue",
          "name": "Region",
          "value": "Yirgacheffe",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe#region"
          }
        },
        {
          "@type": "PropertyValue",
          "name": "Process",
          "value": "Process lavé",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/guides/process-lave#guide"
          }
        },
        {
          "@type": "PropertyValue",
          "name": "Méthode recommandée",
          "value": "Chemex",
          "valueReference": {
            "@type": "DefinedTerm",
            "@id": "https://monsupercafe.fr/guides/methode-chemex#guide"
          }
        }
      ]
    }
  ]
}

Notez les différences clés :

1. Suppression du BreadcrumbList du `@graph`

Approche 1 :

				
					{
  "@type": "BreadcrumbList",
  "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#breadcrumb",
  "itemListElement": [...]
}

Approche 2 : Le breadcrumb est référencé uniquement dans la WebPage

				
					"breadcrumb": {
  "@id": "https://monsupercafe.fr/cafes/ethiopie-yirgacheffe-250g#breadcrumb"
}

Pourquoi : Le breadcrumb est généralement construit dynamiquement côté serveur ou via un template global. Inutile de le redéfinir dans chaque markup.

2. Suppression du `DefinedTerm` Café du `@graph`

Approche 1 : Le concept Café est défini dans le @graph
Approche 2 : Il est référencé uniquement

				
					"category": {
  "@type": "DefinedTerm",
  "@id": "https://monsupercafe.fr/glossaire/cafe#concept"
}

Pourquoi : Le concept Café est défini sur /glossaire/cafe avec son alignement Wikidata/Wikipedia complet. Pas besoin de le redéfinir ici.

3. Simplification de `countryOfOrigin`

Approche 1 :

				
					"countryOfOrigin": {
  "@type": "Country",
  "@id": "https://monsupercafe.fr/origines/ethiopie#country",
  "name": "Éthiopie",
  "url": "https://monsupercafe.fr/origines/ethiopie",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q115",
    "https://fr.wikipedia.org/wiki/Éthiopie"
  ]
}

Approche 2 :

				
					"countryOfOrigin": {
  "@type": "Country",
  "@id": "https://monsupercafe.fr/origines/ethiopie#country"
}

Ce que nous supprimons : name, url, sameAs (seront lus depuis /origines/ethiopie)

4. Simplification des `valueReference`

Approche 1 (Yirgacheffe) :

				
					"valueReference": {
  "@type": "DefinedTerm",
  "@id": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe#region",
  "name": "Yirgacheffe",
  "url": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q3572300",
    "https://fr.wikipedia.org/wiki/Yirgachefe_(woreda)"
  ]
}

Approche 2 :

				
					"valueReference": {
  "@type": "DefinedTerm",
  "@id": "https://monsupercafe.fr/origines/ethiopie/yirgacheffe#region"
}

⚠️ Importance technique : Le @type doit être conservé même dans l’approche optimisée. Si vous omettez le @type, les validateurs Schema.org peuvent inférer un type générique (Intangible) qui n’est pas accepté pour valueReference.

Visuellement, cela nous donne (les éléments non-configurés via un @id dédié (AggregateRating, Review, OfferShippingDetails…) sont volontairement masqués) :

Ce que nous supprimons dans l’approche 2 :

❌ name (sera lu depuis la page canonique)
❌ url (déjà dans l’@id)
❌ sameAs (sera lu depuis la page canonique)

Ce que nous gardons dans l’approche 2 :

✅ @type (obligatoire pour la validation Schema.org)
✅ @id (référence vers la définition complète)

Gain : Passage de ~8 lignes à ~3 lignes par entité référencée, tout en restant valide Schema.org.

5. Reviews et données métier conservées

Les reviews restent complètes dans l’approche 2 car :

✅ Ce sont des données propres au produit (pas des entités réutilisables)
✅ Elles changent d’un produit à l’autre
✅ Elles ne peuvent pas être « référencées » ailleurs

Même logique pour :

➡️ aggregateRating (spécifique au produit)

➡️ weight (propre à chaque SKU)

➡️ shippingDetails (peut varier selon le produit)

➡️ sku, gtin13, price (évidemment propres au produit)

6. Différences clés : Entités vs Données

Type	Traitement en approche 2
Entités réutilisables (Café, Éthiopie, Chemex…)	`@type` + `@id` uniquement
Données propres au produit (reviews, price, sku…)	Complètes

💡 Règle simple :
Si la donnée est partagée par plusieurs produits → définir une fois, référencer partout.
Si la donnée est unique au produit → garder complète.

Avantages de l’approche 2 :

✅ Single Source of Truth : Chaque entité définie une seule fois

✅ Maintenance simplifiée : Modifier Café = 1 seul endroit (/glossaire/cafe)

✅ Markup ultra-léger : Fiches produit allégées de 100-150 lignes

✅ Architecture professionnelle : Cohérent avec les principes du web sémantique

✅ Validation Schema.org : Reste 100% valide grâce au @type conservé

Prérequis :

⚠️ Les pages canoniques DOIVENT exister et contenir les définitions complètes :

/glossaire/cafe → DefinedTerm Café avec sameAs Wikidata
/origines/ethiopie → Country avec sameAs Wikidata
/origines/ethiopie/yirgacheffe → DefinedTerm avec sameAs Wikidata
/guides/process-lave → DefinedTerm avec sameAs Wikipedia
/guides/methode-chemex → DefinedTerm avec sameAs Wikidata

Exemple de markup sur /glossaire/cafe :

				
					{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://monsupercafe.fr/glossaire/cafe#webpage",
      "url": "https://monsupercafe.fr/glossaire/cafe",
      "name": "Café - Définition et Histoire | MonSuperCafé",
      "isPartOf": {
        "@id": "https://monsupercafe.fr/#website"
      },
      "mainEntity": {
        "@id": "https://monsupercafe.fr/glossaire/cafe#concept"
      }
    },
    {
      "@type": "DefinedTerm",
      "@id": "https://monsupercafe.fr/glossaire/cafe#concept",
      "name": "Café",
      "url": "https://monsupercafe.fr/glossaire/cafe",
      "description": "Boisson obtenue à partir de graines torréfiées du caféier, arbuste du genre Coffea.",
      "mainEntityOfPage": {
        "@id": "https://monsupercafe.fr/glossaire/cafe#webpage"
      },
      "sameAs": [
        "https://www.wikidata.org/wiki/Q8486",
        "https://fr.wikipedia.org/wiki/Café"
      ]
    }
  ]
}

Visuellement :

💡 Recommandation : Commencez par l'Approche 1 (auto-suffisante) pour valider votre markup, puis migrez progressivement vers l'Approche 2 (KGI optimisé) une fois vos pages canoniques créées.

6.3. Quelles entités aligner en priorité ?

1️⃣ Entités macro : pays, grandes régions, méthodes répandues, concepts structurants
2️⃣ Méthodes/Outils génériques : espresso, Aeropress, V60, Chemex, French press…
3️⃣ Espèces/Variétés : si le discours les exploite (Arabica/Robusta…)
4️⃣ Entités catalogue : en général, on les aligne indirectement via leurs relations (origine, variété, méthode), plutôt que de chercher un QID par produit

💡 Principe : Plus vos entités sont reliées à des référentiels externes stables, plus vous réduisez l'ambiguïté et plus vous facilitez l'exploitation machine : mêmes entités, mêmes relations, mêmes "nœuds" que ceux utilisés par les systèmes. Le Knowledge Graph de Google vise justement à relier des entités et à produire des réponses factuelles quand c'est utile.

En clair, l’alignement n’est pas un luxe « web sémantique ». C’est une manière pragmatique de dire au moteur : « Voici exactement de quelles entités je parle, et comment elles se relient à mon catalogue et à mes contenus. ».

Dans la section suivante, nous allons voir comment traduire ces relations sémantiques en maillage interne navigable : des liens HTML qui reflètent la structure de votre KGI.

[/swpm_protected]

Maillage d’entités & Knowledge Graph interne, ou comment renforcer son Architecture Sémantique – Partie 1

1. Introduction : du moteur de recherche au moteur de réponse (avec du café dedans)

2. Ce qu'est une entité (dans l'univers du café)

2.1. Des mots aux entités : Pourquoi la différence est critique

2.2. Triplets : la grammaire minimale des entités

2.3. Types d'entités et vocabulaire Schema.org (thématique Café)

2.4. Entités locales vs Entités globales

3. Auditer et extraire les entités de notre site (et ceux de nos concurrents 😇)

3.1. Ce que nous pensons dire vs ce qu'un modèle extrait

3.2. Premier niveau : Inventaire éditorial

3.3. Deuxième niveau : Extraction automatique

3.3.1 Récupérer les ID Wikipedia (URLs) et les ID Knowledge Graph de Google (MID)

3.3.2 Récupérer les QID (ID Wikidata)

3.4. Interpréter les résultats : la saillance comme KPI

3.5. Croiser automatisation et expertise métier

3.6. Construire une "base d'entités" à partir de l'audit

4. Structurer les entités avec Schema.org et JSON-LD

4.1. Pourquoi Schema.org et JSON-LD ?

4.2. Définir un produit en JSON-LD

L'état civil du produit

Les références techniques (logistique)

L'offre commerciale (offers)

4.3. Définir l'organisation et relier via @graph et @id

L'entité "Organisation" (l'entreprise réelle)

L'entité "WebSite" (le site web)

En résumé : À quoi ça sert ?

4.4. Joindre le Product à l'Organization

4.5. La gestion des @id : le système nerveux du KGI

4.6. Erreurs fréquentes à éviter

5. Construire et visualiser son knowledge graph interne (KGI)

5.1. Construire son graphe

5.2. Visualiser le graphe pour détecter les opportunités

5.3. Et l'ontologie dans tout ça ?

Pourquoi c'est crucial en SEO (même si vous restez "pragmatique")

6. Relier le graphe interne au knowledge graph public

6.1. Wikipedia, Wikidata, MID : trois référentiels complémentaires

6.2. Implémenter l'alignement des entités pour une architecture sémantique optimale

Approche 1 : Markup "auto-suffisant" (pour débuter)

1. La structure en @graph : le maillage interne

2. L'enrichissement sémantique : le knowledge graph externe

a) La catégorie Café (category)

b) Le pays d'origine (countryOfOrigin)

c) Les attributs métier (additionalProperty)

3. Le fil d'ariane (BreadcrumbList)

4. Les éléments commerciaux avancés

5. Les avis clients (Review)

Résumé de la valeur ajoutée

Approche 2 : Markup "KGI optimisé" (architecture mature)

1. Suppression du BreadcrumbList du @graph

2. Suppression du DefinedTerm Café du @graph

3. Simplification de countryOfOrigin

4. Simplification des valueReference

5. Reviews et données métier conservées

6. Différences clés : Entités vs Données

6.3. Quelles entités aligner en priorité ?

Cliquez ici pour annuler la réponse.

Lu sur le web - Février 2026

L'impact de votre fiche Wikidata sur votre Google Knowledge Panel - étude de cas

Les articles du moment

Netlinking : du catalogue à la méthodologie data driven !

ASO : Optimiser la visibilité & la conversion des apps sur les Stores

L’impact de votre fiche Wikidata sur votre Google Knowledge Panel – étude de cas

LinkedIn dopé à l’IA : un nouveau levier de performance pour les PME B2B

Coder avec l’IA : retour d’expérience et bonnes pratiques du vibe coding

Outils pépites – Février 2026

Lu sur le web – Février 2026

L'offre commerciale (`offers`)

1. La structure en `@graph` : le maillage interne

a) La catégorie Café (`category`)

b) Le pays d'origine (`countryOfOrigin`)

c) Les attributs métier (`additionalProperty`)

3. Le fil d'ariane (`BreadcrumbList`)

5. Les avis clients (`Review`)

1. Suppression du BreadcrumbList du `@graph`

2. Suppression du `DefinedTerm` Café du `@graph`

3. Simplification de `countryOfOrigin`

4. Simplification des `valueReference`