Wikidata et entités sémantiques : le levier sous-estimé du SEO et du GEO.

Wikidata, Wikipedia et Knowledge Graph Google : quelles relations ?

La confusion entre ces trois objets est massive, y compris dans des briefs SEO produits par des agences sérieuses. Pourtant, ce sont trois choses différentes, qui se nourrissent mutuellement mais n'obéissent pas aux mêmes règles.

Wikipedia est une encyclopédie textuelle. Chaque article est un texte écrit par des contributeurs, organisé en sections, illustré, sourcé. La granularité est l'article. La règle d'admission est la notoriété encyclopédique, qui exclut la majorité des entreprises et des professionnels.

Wikidata est une base de données structurée. Chaque élément est un graphe de propriétés-valeurs, sans rédactionnel. La granularité est l'entité sémantique. La règle d'admission est l'éligibilité aux trois critères de notabilité, plus large que celle de Wikipedia : un sitelink vers un autre projet Wikimedia, une entité clairement identifiable décrite par des sources publiques, ou un besoin structurel pour rendre d'autres déclarations utiles.

Knowledge Graph Google est une base de données privée, propriétaire, qui consomme cette base ouverte, Wikipedia, Google My Business, et de nombreuses autres sources. Elle alimente les Knowledge Panels affichés à droite de la SERP, les AI Overviews, et la désambiguïsation d'entité dans le moteur. Aucun accès direct, aucun statut consultable publiquement, mais une part substantielle de son contenu provient du graphe Wikimedia depuis l'arrêt de Freebase en 2014.

Le bon mental model est le suivant. La base Wikimedia est la couche structurée. Wikipedia est la couche narrative. Knowledge Graph Google est la couche d'affichage propriétaire qui consomme les deux. Un travail SEO/GEO sérieux sur l'entité sémantique commence par la couche structurée, parce que c'est la seule des trois où l'on peut intervenir directement et de manière vérifiable.

Comment Google et les LLM utilisent Wikidata.

Le détail technique compte ici, parce qu'il conditionne la manière de construire une fiche utile plutôt qu'une fiche cosmétique.

Google a documenté l'usage de cette base par son Knowledge Graph dans la documentation officielle de la Knowledge Graph Search API. Le graphe propriétaire s'appuie dessus pour les Knowledge Panels, la désambiguïsation d'entité dans le moteur (savoir si « Apple » désigne le fruit, l'entreprise ou les Beatles), et les AI Overviews. Concrètement, lorsqu'une fiche est suffisamment dense, sourcée, et connectée à un sitelink Wikipedia, elle a une probabilité non nulle de déclencher un Knowledge Panel pour la marque.

Les LLM consomment ce graphe ouvert par deux canaux. D'abord à l'entraînement : tous les modèles publics majeurs (GPT, Claude, Gemini, Llama, Mistral) ont ingéré des dumps complets dans leur corpus. Ensuite au retrieval : les moteurs de réponse comme Perplexity, ChatGPT search ou Google AI Overviews font des appels en temps réel pour vérifier des faits, et c'est l'une des sources les plus dense en données vérifiables et structurées disponibles librement.

Le format SPARQL permet d'interroger le graphe directement et explique pourquoi les LLM le trouvent si pratique. Une requête comme la suivante renvoie en quelques millisecondes la liste de toutes les organisations dont Yonel Sasson est fondateur, ou tous les fondateurs d'agence créée après 2020 en Île-de-France.

# Toutes les organisations dont Yonel Sasson est fondateur
# Endpoint : https://query.wikidata.org/
SELECT ?org ?orgLabel ?foundingDate WHERE {
  ?org wdt:P112 wd:Q139749163 .
  OPTIONAL { ?org wdt:P571 ?foundingDate . }
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "fr,en" .
  }
}

Ce niveau d'interrogation explique pourquoi un LLM préfère citer une entité sémantique bien construite plutôt qu'une page web textuelle équivalente. Le coût cognitif de l'extraction d'information est dix fois plus faible. La probabilité d'erreur factuelle est plus basse. Et l'entité est déjà désambiguïsée par son Q-id.

Conséquence pratique. Si vous voulez qu'un LLM cite votre marque par son nom dans une réponse à une question commerciale, votre Q-item est l'un des trois ou quatre signaux qu'il consultera en priorité, avec votre site officiel et vos profils LinkedIn. Sans cette fiche, vous reposez entièrement sur le crawl HTML, qui est plus coûteux et moins fiable pour identifier une entité.

sameAs et triangulation d'identité : Wikidata + LinkedIn + site officiel.

Le concept de triangulation d'identité est ce qui sépare une fiche cosmétique d'une fiche qui produit du résultat GEO. L'idée est de fermer toutes les boucles entre les trois ancrages publics d'une marque, pour qu'un LLM ou un crawler puisse vérifier l'entité sémantique par n'importe quel point d'entrée.

Concrètement, trois objets doivent se citer mutuellement :

• Le site officiel déclare dans son schema Organization un sameAs vers le Q-item (URL Wikidata) et un sameAs vers LinkedIn (URL de la company page).
• La fiche publique déclare via P856 l'URL du site officiel et via P4264 l'identifiant LinkedIn de l'organisation.
• LinkedIn déclare l'URL du site officiel dans le champ « Site web » de la company page.

Le code minimal côté schema HTML, qui est exactement celui utilisé dans cette page que vous lisez, ressemble à ce qui suit. Notez les sameAs vers Q139749070 et Q139749163.

// Schema Organization + Person avec sameAs Wikidata
// Triangulation d'identité fermée à trois points.
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Getknown",
  "founder": { "@id": "#yonel" },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q139749070",
    "https://www.linkedin.com/company/getknown-fr/"
  ]
}

Sans cette triangulation, le LLM doit faire de l'entity disambiguation à partir de signaux faibles : le nom de domaine, la cohérence du contenu, des co-mentions externes. C'est possible mais coûteux et faillible. Avec la triangulation, l'entité sémantique est verrouillée et toute citation devient vérifiable en une requête.

L'erreur classique est de déclarer un sameAs côté site sans avoir déclaré le site officiel côté fiche publique. La boucle reste ouverte, et le signal perd la moitié de sa force. Toujours fermer la boucle dans les deux sens.

Les erreurs Wikidata les plus fréquentes.

Six erreurs reviennent dans la majorité des fiches d'organisation B2B créées sans expérience préalable. Aucune n'est compliquée à corriger. Toutes coûtent en visibilité et en autorité d'entité sémantique.