SEO d'entités et sémantique

Pendant la majeure partie de l’histoire de la recherche, Google était une machine à faire correspondre des chaînes de caractères. Vous tapiez cheapest flights to tokyo, et le moteur cherchait les documents contenant exactement ces chaînes. Le SEO était donc un jeu consistant à placer les bonnes chaînes aux bons endroits : balises title, H1, texte d’ancre et — au mauvais vieux temps — pieds de page bourrés de mots-clés.

Ce monde a disparu. Depuis le lancement du Knowledge Graph en 2012 et la mise à jour Hummingbird qui a réorganisé le pipeline de classement en 2013, Google migre des chaînes vers les choses. La formulation officielle de leur annonce était littérale : « things, not strings » (des choses, pas des chaînes). Au lieu de demander « quelles pages contiennent ces mots », le Google moderne demande « de quelles entités du monde réel cette requête parle-t-elle, et quelles pages font autorité sur ces entités ? »

Ce changement est le modèle mental le plus important pour le SEO avancé en 2026. Si vous pensez encore en mots-clés, vous optimisez pour un moteur qui n’existe plus. Ce guide vous montre comment penser — et baliser — en entités à la place.

Entités vs mots-clés

Un mot-clé est une chaîne de texte. Une entité est une chose — une personne, une organisation, un lieu, un produit, un concept ou un événement — qui existe indépendamment de toute formulation particulière.

Prenez l’entité Tim Berners-Lee. Les mots-clés tim berners-lee, inventor of the world wide web, creator of HTTP et TBL pointent tous vers la même entité. Google les résout en un seul nœud de son Knowledge Graph, lui attribue un identifiant lisible par machine (un MID du Knowledge Graph comme /m/07d5b, ou un QID Wikidata comme Q80), et le relie à d’autres entités : World Wide Web, CERN, MIT, W3C.

Voici la différence en un seul tableau :

Aspect	Mot-clé (chaîne)	Entité (chose)
Nature	Une séquence de caractères	Un concept du monde réel avec un ID stable
Identité	`nyc` ≠ `new york city`	`nyc` = `new york city` = `Q60`
Ambiguïté	« Jaguar » est une seule chaîne	Animal vs voiture vs OS — trois entités
Relations	Aucune intrinsèque	Connectées dans un graphe (`isA`, `partOf`, `worksFor`)
Usage par Google	Correspondance lexicale	Désambiguïsation + raisonnement + récupération

🧑‍💻 Vue développeur : Considérez les mots-clés comme une entrée string brute et les entités comme des clés étrangères résolues. La recherche, c’était autrefois WHERE body LIKE '%term%'. Désormais, il existe une couche de résolution d’entités en amont — la chaîne de requête est analysée en IDs d’entités, et le classement s’opère en partie sur un graphe de ces IDs. Votre travail consiste à rendre vos pages proprement jointables aux bons nœuds.

Pourquoi cela compte-t-il en pratique ?

Désambiguïsation. Quand Google comprend que votre page sur « Python » parle du langage de programmation (Q28865) et non du serpent (Q472), il cesse de concourir sur des SERP non pertinentes et commence à se classer là où vous avez votre place.
Couverture des synonymes et de l’intention. Vous n’avez plus besoin de répéter quinze variantes de mots-clés. Couvrez bien l’entité et vous vous classez sur la grappe de chaînes qui s’y rattachent.
Raisonnement. Google peut déduire qu’une page couvrant React, JSX, les hooks et le virtual DOM fait réellement autorité sur les frameworks front-end, parce que ces entités sont voisines dans le graphe. La densité de mots-clés ne peut pas simuler cela.

Devenir une entité

Le premier mouvement stratégique consiste à faire de vous-même — votre marque et vos auteurs — des entités reconnues par Google. Une marque non reconnue est invisible pour la couche de raisonnement ; ce n’est qu’une chaîne de plus. Une entité reconnue obtient un Knowledge Panel, gagne des signaux de confiance (le « T » de E-E-A-T) et devient éligible pour être citée comme source.

Google construit une entité à partir de preuves corroborantes à travers le web. Votre travail consiste à l’alimenter en signaux cohérents, lisibles par machine et recoupés. Trois leviers comptent le plus.

1. sameAs — reliez votre entité à des autorités connues

La propriété sameAs dans le balisage schema.org est le moyen le plus direct de dire « l’entité de cette page est la même que ce nœud auquel vous faites déjà confiance ». Pointez-la vers Wikidata, Wikipedia, LinkedIn, GitHub, Crunchbase et les profils sociaux officiels. Wikidata et Wikipedia sont les cibles à plus forte valeur, car le Knowledge Graph de Google est en partie alimenté par eux.

Voici un balisage Organization pour une entreprise fictive d’outils de développement. Placez-le en JSON-LD dans votre <head> ou avant </body>, idéalement sur votre page d’accueil et votre page À propos :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.dev/#organization",
  "name": "Acme Dev Tools",
  "url": "https://acme.dev/",
  "logo": "https://acme.dev/logo.png",
  "foundingDate": "2019-04-01",
  "description": "Acme builds open-source observability tooling for distributed systems.",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://en.wikipedia.org/wiki/Acme_Dev_Tools",
    "https://www.linkedin.com/company/acme-dev-tools",
    "https://github.com/acme-dev",
    "https://www.crunchbase.com/organization/acme-dev-tools",
    "https://x.com/acmedev"
  ]
}
</script>

Et le balisage Person correspondant pour un auteur — notez que l’auteur worksFor l’organisation, ce qui relie deux entités entre elles :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://acme.dev/team/jane-doe/#person",
  "name": "Jane Doe",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://acme.dev/#organization" },
  "url": "https://acme.dev/team/jane-doe/",
  "knowsAbout": ["Distributed tracing", "OpenTelemetry", "Go"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe",
    "https://orcid.org/0000-0002-1825-0097"
  ]
}
</script>

💡 Astuce : Les valeurs @id sont des ancres internes qui permettent à votre graphe de schéma de se référencer lui-même. Utiliser un fragment d’URL stable comme #organization signifie que vos blocs Article, Person et BreadcrumbList peuvent tous renvoyer à un seul nœud organisation canonique au lieu de le redéfinir. C’est exactement ainsi qu’un graphe doit être modélisé — définir une fois, référencer partout.

2. about / mentions — déclarez ce que votre contenu couvre

about dit « cette page parle principalement de l’entité X ». mentions dit « cette page fait référence à l’entité Y ». Utilisez de vrais IDs d’entités pour qu’il n’y ait aucune ambiguïté :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "OpenTelemetry vs Jaeger: choosing a tracing backend",
  "author": { "@id": "https://acme.dev/team/jane-doe/#person" },
  "publisher": { "@id": "https://acme.dev/#organization" },
  "about": {
    "@type": "Thing",
    "name": "OpenTelemetry",
    "sameAs": "https://www.wikidata.org/wiki/Q98961422"
  },
  "mentions": [
    { "@type": "SoftwareApplication", "name": "Jaeger",
      "sameAs": "https://www.wikidata.org/wiki/Q60803298" },
    { "@type": "Thing", "name": "Distributed tracing",
      "sameAs": "https://www.wikidata.org/wiki/Q105749746" }
  ]
}
</script>

3. NAP et nommage cohérents

Le NAP — Nom, Adresse, Phone (téléphone) — doit être identique octet pour octet partout : votre site, Google Business Profile, LinkedIn, Crunchbase, les annuaires. Un NAP incohérent fragmente votre entité en plusieurs candidats faiblement soutenus, et Google peut échouer à les fusionner. Traitez les faits canoniques de votre entité comme une source unique de vérité dans la configuration :

# entity.yml — the one place your NAP lives; render everything from this
name:    "Acme Dev Tools, Inc."
url:     "https://acme.dev/"
phone:   "+1-415-555-0142"
address:
  street:  "500 Howard St, Suite 400"
  city:    "San Francisco"
  region:  "CA"
  postal:  "94105"
  country: "US"

⚠️ Attention : « Acme Dev Tools » vs « Acme Dev Tools, Inc. » vs « ACME » sont trois chaînes différentes pour un système de correspondance naïf. Choisissez une seule raison sociale et un seul nom courant, et utilisez-les de façon cohérente. La même discipline s’applique à votre domaine : ne dispersez pas l’autorité de marque entre acme.dev, acme.io et getacme.com, sauf si vous avez une stratégie de redirection délibérée.

Autorité thématique

Les entités ne vivent pas seules — elles vivent en grappes. OpenTelemetry est connecté à distributed tracing, aux spans, au protocole OTLP, à Prometheus, aux stratégies d’échantillonnage, aux bibliothèques d’instrumentation. L’autorité thématique consiste à couvrir de manière démontrable tout ce voisinage d’entités et les questions que les utilisateurs posent à leur sujet, plutôt qu’à se classer sur un unique mot-clé volumineux.

L’ancienne méthode des mots-clés produisait dix pages minces ciblant chacune une expression (opentelemetry tutorial, opentelemetry vs jaeger, opentelemetry python…), se cannibalisant souvent les unes les autres. La méthode des entités produit une grappe de contenu (content cluster) : un pilier complet plus des pages de soutien reliées entre elles, couvrant ensemble chaque sous-entité et sous-question significative.

	Approche par mots-clés	Approche par entités / thématique
Unité de planification	Une expression de recherche	Un sujet et ses sous-entités
Logique du nombre de pages	Une page par mot-clé	Pages mappées à une carte de connaissances
Liens internes	Aléatoires / par intuition de pertinence	Structurés autour des relations d’entités
Indicateur de succès	Se classer sur le mot-clé	Dominer le sujet sur toute la SERP
Risque	Cannibalisation, contenu mince	Lacunes de couverture

Pour construire la carte, exploitez les entités que Google associe déjà à votre sujet :

L’encart People Also Ask (Autres questions posées) et « Recherches associées » — chacun est en réalité une sous-question ou une sous-entité.
La table des matières de Wikipedia et le « Voir aussi » de votre entité centrale — un graphe d’entités gratuit et organisé par des humains.
Le panneau des propriétés de Wikidata — les véritables arêtes du graphe (subclass of, uses, has part).
Une extraction programmatique rapide des entités liées du Knowledge Graph :

curl -s "https://kgsearch.googleapis.com/v1/entities:search" \
  --data-urlencode "query=OpenTelemetry" \
  --data-urlencode "types=Thing" \
  --data-urlencode "limit=10" \
  --data-urlencode "key=$GOOGLE_KG_API_KEY" -G \
  | jq '.itemListElement[].result | {name, id: ."@id", desc: .description}'

💡 Astuce : Une règle empirique utile — pour qu’un sujet gagne en autorité, votre grappe devrait répondre à chaque question qu’un collègue compétent pourrait poser à son sujet dans une conversation de 30 minutes. Si une sous-question n’a ni page ni section, c’est une lacune de couverture qu’un concurrent comblera.

Le bénéfice se cumule. Une fois que Google vous fait confiance comme autorité sur distributed tracing, les nouvelles pages de cette grappe se classent plus vite, car la confiance s’attache à votre entité au sein du sujet, et pas seulement aux URL individuelles.

Étapes pratiques

Voici le flux de travail, de bout en bout. Chaque étape est assez concrète pour être mise sur un ticket.

1. Réalisez un inventaire d’entités. Listez les entités que votre site est (marque, produits, auteurs, lieux) et les entités sur lesquelles vous voulez faire autorité (vos sujets centraux et leurs sous-entités). Pour chacune, trouvez ou créez la référence canonique — un QID Wikidata s’il en existe un, un @id interne sinon.

We ARE:        Acme Dev Tools (Q123456789), Jane Doe (no QID → /team/jane-doe/#person)
We OWN:        distributed tracing, OpenTelemetry, observability, OTLP, span sampling
Gaps to fill:  span sampling (no page), OTLP (only a passing mention)

2. Balisez les entités avec schema. Ajoutez Organization + Person à vos pages d’identité, et Article avec about/mentions aux pages de contenu, le tout relié via @id. Générez et validez le JSON-LD avec le générateur de Schema, puis confirmez-le avec le test des résultats enrichis de Google et le validateur Schema.org. C’est la discipline des données structurées traitée en profondeur dans la Couche 4 : contenu et structure.

3. Organisez les liens internes par entité, pas par caprice. Chaque page de soutien devrait pointer vers le haut vers son pilier et en travers vers les entités sœurs, avec un texte d’ancre descriptif qui nomme l’entité (distributed tracing, pas cliquez ici). C’est ainsi que vous rendez votre grappe lisible comme un graphe :

        [ Pillar: Distributed Tracing ]
        /        |          |         \
 [OpenTelemetry][Jaeger][Span sampling][OTLP]
        \________cross-links between siblings________/

4. Gagnez des mentions faisant autorité. sameAs est votre affirmation ; la corroboration par des tiers est la preuve. Faites-vous citer, profiler et lier par des sources auxquelles Google fait déjà confiance — conférences, README GitHub de projets populaires, publications sectorielles et, lorsque c’est réellement justifié, une entrée Wikidata. Les mentions de marque sans lien comptent aussi ; Google les lit comme des signaux d’association d’entité.

5. Mesurez et itérez. Suivez si un Knowledge Panel apparaît pour votre marque, si vous figurez dans « D’après des sources sur le web » et les AI Overviews, et quelles pages de la grappe se classent. Comblez les lacunes ; approfondissez les nœuds faibles ; rafraîchissez la date updated quand vous le faites.

Inventaire d’entités terminé (we-are + we-own + lacunes)
Schémas Organization et Person avec sameAs complet déployés
about/mentions sur chaque page de contenu importante
NAP cohérent sur toutes les propriétés
Liens internes structurés autour du graphe d’entités
Au moins une nouvelle mention tierce faisant autorité par trimestre

Points clés à retenir

✅ Google classe les entités (choses), pas les mots-clés (chaînes) — optimisez pour le concept, pas pour l’expression exacte.
✅ Faites de votre marque et de vos auteurs des entités reconnues avec les schémas Organization/Person et des liens sameAs vers Wikidata, LinkedIn, GitHub et Crunchbase.
✅ Utilisez about et mentions avec de vrais IDs d’entités pour indiquer précisément à Google ce que chaque page couvre.
✅ Gardez votre NAP et votre nommage cohérents octet pour octet afin que Google ne scinde jamais votre entité en deux.
✅ Construisez une autorité thématique en couvrant tout le voisinage d’entités d’un sujet dans une grappe de contenu reliée, plutôt qu’un mot-clé par page.
✅ Générez et validez votre balisage avec le générateur de Schema et appliquez-le via la Couche 4 : contenu et structure.