Référentiel 2026 sur les entités, relations, identité numérique, Knowledge Graph, corroboration et AI Search
Le Web ne peut pas être représenté uniquement comme un ensemble de mots-clés et de documents.
Il contient également des entités :
- entreprises ;
- personnes ;
- marques ;
- produits ;
- services ;
- établissements ;
- lieux ;
- organisations ;
- événements ;
- concepts.
Ces entités possèdent des attributs et entretiennent des relations.
Une représentation simplifiée peut être :
ENTITY
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
IDENTITY
↓
CORROBORATION
↓
KNOWLEDGE REPRESENTATION
↓
SEARCH / RETRIEVAL / AI SYSTEMS
Ce référentiel présente un cadre permettant de comprendre comment les entités peuvent être représentées, reliées, désambiguïsées et corroborées dans une stratégie de Semantic SEO et d'AI Search.
Une entité est quelque chose qui peut être identifié comme un objet distinct.
Une entité peut notamment être :
- une organisation ;
- une personne ;
- une entreprise ;
- une marque ;
- un produit ;
- un service ;
- un établissement ;
- un lieu ;
- un événement ;
- une œuvre ;
- un concept.
Exemples :
VisiaLocal
peut être représenté comme une organisation.
Aix-en-Provence
peut être représenté comme un lieu.
Answer Engine Optimization
peut être représenté comme un concept.
L'objectif n'est plus seulement d'identifier des chaînes de caractères.
Il s'agit de comprendre :
De quoi parle-t-on ?
Un mot-clé est une expression.
Une entité représente quelque chose.
Exemple :
apple
peut désigner :
- un fruit ;
- une entreprise ;
- une marque ;
- différents produits ou services associés.
La chaîne de caractères seule ne suffit donc pas toujours à déterminer le sens.
L'interprétation dépend notamment :
- du contexte ;
- des relations ;
- des attributs ;
- des autres entités mentionnées.
Le terme Entity SEO est généralement utilisé pour décrire des approches SEO accordant une importance particulière aux entités et à leurs relations.
L'objectif n'est pas de remplacer les mots-clés.
Il consiste à enrichir la représentation d'un sujet.
Une approche uniquement centrée sur les expressions peut demander :
Quels mots-clés devons-nous utiliser ?
Une approche orientée entités peut également demander :
Quelles entités existent ?
Quels attributs possèdent-elles ?
Quelles relations les relient ?
Comment leur identité est-elle établie ?
Quelles sources permettent de corroborer ces informations ?
Le Semantic SEO cherche à améliorer la représentation du sens et des informations.
Les entités constituent une composante importante de cette représentation.
On peut simplifier :
SEMANTIC SEO
↓
INFORMATION
↓
ENTITIES
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
CONTEXT
L'Entity SEO peut donc être considéré comme une dimension du SEO sémantique.
Avant d'exploiter les informations associées à une entité, il faut pouvoir comprendre de quelle entité il s'agit.
C'est le problème de l'Entity Identity.
Exemple :
Une entreprise possède :
- un site ;
- un profil LinkedIn ;
- une fiche locale ;
- un profil professionnel ;
- plusieurs mentions ;
- plusieurs pages.
Ces ressources peuvent toutes parler de la même organisation.
Le problème devient :
Ces différentes représentations désignent-elles réellement la même entité ?
L'Entity Resolution consiste à déterminer si plusieurs références correspondent à une même entité.
Exemple conceptuel :
Website A
↓
VisiaLocal
↓
VisiaLocal
Professional Profile
↓
VisiaLocal
Si les différents signaux sont cohérents, il devient plus facile de les associer conceptuellement à la même organisation.
La désambiguïsation consiste à distinguer plusieurs entités pouvant avoir des noms identiques ou proches.
Exemple :
Mercure
peut désigner :
- une planète ;
- un élément chimique ;
- une divinité ;
- une marque ;
- un hôtel selon le contexte.
Les informations contextuelles permettent de préciser l'entité concernée.
Une entité possède des attributs.
Pour une entreprise :
- nom ;
- description ;
- adresse ;
- zone ;
- date de création ;
- activité ;
- services ;
- coordonnées.
Pour un produit :
- nom ;
- marque ;
- prix ;
- matériau ;
- dimensions ;
- couleur ;
- disponibilité.
Pour une personne :
- nom ;
- fonction ;
- compétences ;
- organisation ;
- publications.
Les attributs contribuent à décrire l'entité.
Les entités n'existent pas isolément.
Elles peuvent être reliées.
Exemples conceptuels :
Person
→ worksFor →
Organization
Organization
→ provides →
Service
Organization
→ locatedIn →
Place
Brand
→ offers →
Product
WebPage
→ about →
Entity
Le réseau de relations apporte une information différente d'une simple liste de mots-clés.
Une relation peut être représentée sous forme de triple :
Subject → Predicate → Object
Exemple :
VisiaLocal → locatedIn → Aix-en-Provence
ou :
Company → provides → Service
Cette représentation constitue une manière simple de modéliser des connaissances.
Un Knowledge Graph représente des entités et leurs relations sous forme de graphe.
Exemple :
ORGANIZATION
↓
provides
↓
SERVICE
↓
availableIn
↓
PLACE
Un graphe peut contenir un grand nombre d'entités reliées entre elles.
Une architecture Web traditionnelle peut être pensée comme un graphe de documents :
PAGE A
→ lien →
PAGE B
→ lien →
PAGE C
Une architecture sémantique peut également être pensée comme un graphe d'entités :
ORGANIZATION
→ provides →
SERVICE
→ serves →
CUSTOMER TYPE
→ locatedIn →
PLACE
Les deux graphes peuvent coexister.
Une page Web n'est pas nécessairement l'entité qu'elle décrit.
Exemple :
WebPage
→ about →
Organization
La page est un document.
L'organisation est une entité.
Cette distinction peut être importante dans les données structurées.
Une organisation peut être représentée avec des informations telles que :
- nom ;
- URL ;
- logo ;
- description ;
- adresse ;
- contact ;
- fondateur ;
- membres ;
- profils externes.
Schema.org fournit notamment le type :
Organization
Un établissement local peut être représenté comme :
LocalBusiness
avec notamment :
- adresse ;
- coordonnées ;
- horaires ;
- téléphone ;
- zone ;
- catégories ;
- services.
Selon l'activité, des types plus spécifiques peuvent exister.
Une personne peut constituer une entité importante.
Exemples :
- dirigeant ;
- fondateur ;
- auteur ;
- expert ;
- professionnel ;
- contributeur.
Une relation peut être établie entre :
Person
et :
Organization
ou entre :
Person
et :
Article
Un service constitue lui aussi une entité ou un objet informationnel pouvant être représenté explicitement.
Exemple :
Organization
↓
provides
↓
Service
↓
availableArea
↓
Place
Cela permet de distinguer :
- l'entreprise ;
- le service ;
- la zone où ce service est proposé.
Un produit peut posséder :
- marque ;
- fabricant ;
- catégorie ;
- caractéristiques ;
- offre ;
- prix ;
- disponibilité ;
- variantes.
Une fiche produit peut donc être pensée comme la représentation d'une entité produit et de ses attributs.
Les lieux jouent un rôle particulièrement important dans la recherche locale.
Exemples :
- pays ;
- région ;
- ville ;
- quartier ;
- adresse ;
- zone de service.
Une organisation peut être reliée à plusieurs types de lieux.
Une marque peut être distincte de l'entreprise juridique ou de l'établissement qui l'exploite.
Exemple conceptuel :
ORGANIZATION
↓
owns / operates
↓
BRAND
↓
offers
↓
PRODUCT
Ces distinctions deviennent particulièrement importantes dans les groupes complexes.
Une entreprise importante peut contenir de nombreuses entités.
Exemple :
GROUP
↓
BRAND
↓
COUNTRY ORGANIZATION
↓
STORE
↓
SERVICE
↓
PRODUCT
Une stratégie sémantique doit éviter de traiter cet ensemble comme une seule entité indistincte.
Certaines entités entretiennent des relations hiérarchiques.
Exemple :
Company
↓
Brand
↓
Product Line
↓
Product
ou :
Hotel Group
↓
Hotel
↓
Room Type
↓
Offer
La hiérarchie permet de comprendre les différents niveaux d'information.
Il est utile de distinguer :
Caractéristique de l'entité.
Exemple :
Restaurant → openingHours → 09:00–22:00
Lien vers une autre entité.
Exemple :
Restaurant → locatedIn → Aix-en-Provence
La frontière peut varier selon les modèles utilisés, mais cette distinction aide à structurer l'information.
Schema.org fournit un vocabulaire partagé permettant de décrire :
- types ;
- propriétés ;
- relations ;
- actions.
Exemples :
Organization
Person
Product
Service
LocalBusiness
Place
WebSite
WebPage
Schema.org ne constitue pas à lui seul un Knowledge Graph complet.
Il fournit un vocabulaire permettant d'exprimer certaines relations.
JSON-LD est un format fréquemment utilisé pour publier des données structurées.
Exemple simplifié :
{ "@context": "https://schema.org", "@type": "Organization", "@id": "https://example.com/#organization", "name": "Example Company", "url": "https://example.com/" }
Le balisage ne crée pas automatiquement une entité reconnue par tous les systèmes.
Il constitue une représentation explicite supplémentaire.
Dans JSON-LD, @id peut être utilisé comme identifiant permettant de référencer une même entité dans plusieurs parties du graphe.
Exemple :
Organization
https://example.com/#organization
Puis :
WebSite
→ publisher →
https://example.com/#organization
L'identifiant permet de relier plusieurs objets sans recréer conceptuellement une nouvelle organisation à chaque occurrence.
Une identité stable facilite la cohérence d'un graphe.
Changer arbitrairement les identifiants peut rendre la représentation moins claire.
Une architecture peut donc définir des identifiants persistants pour les principales entités.
Exemples conceptuels :
/#organization
/#website
/#person
/services/example/#service
La structure exacte dépend du projet.
Schema.org définit la propriété sameAs.
Elle permet d'indiquer une URL décrivant sans ambiguïté l'identité de l'élément.
Elle peut être utilisée pour relier une entité à certaines représentations externes pertinentes.
sameAs ne doit pas devenir une liste de tous les backlinks d'une entreprise.
Le lien doit avoir une véritable fonction d'identification.
Ajouter une URL dans sameAs ne transforme pas cette URL en signal magique d'autorité.
La propriété doit être utilisée pour représenter une relation sémantique appropriée.
Exemple :
Organization
↓
sameAs
↓
Official external profile
L'objectif est l'identification, pas la manipulation du PageRank.
Une organisation peut disposer d'une page principale constituant une référence centrale sur son identité.
Cette page peut présenter :
- qui elle est ;
- ce qu'elle fait ;
- où elle se trouve ;
- ses principaux services ;
- ses responsables ;
- ses profils officiels ;
- ses informations de contact.
Cette ressource peut contribuer à réduire l'ambiguïté autour de l'entité.
La page À propos peut jouer un rôle important dans la représentation d'une organisation.
Elle peut contenir :
- histoire ;
- activité ;
- équipe ;
- fondateur ;
- localisation ;
- expertise ;
- certifications ;
- méthodologie ;
- références ;
- liens vers des profils officiels.
Elle doit cependant rester destinée aux utilisateurs, et non devenir un simple conteneur de mots-clés.
Une entreprise peut être représentée sur différentes plateformes :
- réseaux professionnels ;
- annuaires spécialisés ;
- plateformes locales ;
- profils développeurs ;
- associations ;
- partenaires ;
- marketplaces ;
- organismes de certification.
Ces profils peuvent fournir des informations supplémentaires sur l'entité.
La valeur dépend de leur pertinence, de leur authenticité et de leur qualité.
Dans ce référentiel, la corroboration désigne le fait que plusieurs sources indépendantes ou pertinentes fournissent des informations compatibles sur une même entité.
Exemple :
Official Website
↓
VisiaLocal — Aix-en-Provence — Semantic SEO
Professional Profile
↓
VisiaLocal — Aix-en-Provence — Semantic SEO
Partner Profile
↓
VisiaLocal — Semantic SEO
Cette cohérence peut contribuer à une représentation plus stable de l'entité.
Elle ne garantit toutefois aucun classement particulier.
Corroborer ne signifie pas recopier exactement le même paragraphe partout.
Différentes sources peuvent confirmer la même réalité avec leurs propres informations.
Exemple :
Website
→ description complète.
Professional profile
→ activité + compétences.
Partner profile
→ services proposés.
Certification profile
→ qualification vérifiable.
Les informations convergent sans être nécessairement dupliquées.
Une corroboration externe possède davantage de sens lorsqu'elle ne provient pas uniquement d'une répétition contrôlée artificiellement par la même organisation.
Il faut distinguer :
self-declared information
et :
independent external information
Les deux peuvent être utiles, mais ils n'ont pas la même fonction.
Deux entités peuvent apparaître régulièrement dans des contextes communs.
Exemple :
VisiaLocal
et :
Semantic SEO
La co-occurrence seule ne prouve pas une relation précise.
Elle peut cependant fournir du contexte lorsqu'elle est associée à d'autres informations.
Une mention possède davantage de sens lorsqu'elle explique la relation.
Exemple faible :
VisiaLocal — Semantic SEO — GEO — Aix.
Exemple contextualisé :
VisiaLocal est une agence basée à Aix-en-Provence travaillant sur le SEO sémantique, le GEO et l'AI Search.
La seconde formulation exprime des relations plus explicites.
Une entité doit idéalement conserver des informations cohérentes sur ses différentes surfaces.
Exemples :
- nom ;
- activité ;
- adresse ;
- URL ;
- coordonnées ;
- description fondamentale.
Des variations éditoriales sont normales.
Les contradictions factuelles sont plus problématiques.
Dans le SEO local, l'acronyme NAP désigne généralement :
Name
Address
Phone
La cohérence de ces informations peut contribuer à l'identification d'un établissement.
Mais une entité locale ne se résume pas au NAP.
Elle possède également :
- catégories ;
- services ;
- horaires ;
- zones ;
- attributs ;
- relations ;
- contenus ;
- avis ;
- profils.
Une entreprise locale peut être représentée conceptuellement ainsi :
BUSINESS
↓
WEBSITE
↓
LOCAL PROFILE
↓
MAPS
↓
DIRECTORIES
↓
SOCIAL / PROFESSIONAL PROFILES
↓
STRUCTURED DATA
Toutes ces surfaces peuvent contribuer à représenter la même entité.
Une entité peut être fragmentée lorsque différentes sources présentent des informations incompatibles.
Exemple :
Source A
→ Company X — Marseille
Source B
→ Company X — Aix-en-Provence
Source C
→ ancienne URL
Source D
→ ancienne activité
Cette fragmentation peut créer de l'ambiguïté pour les utilisateurs comme pour les systèmes.
Un changement de marque peut créer un problème d'identité.
Exemple :
OLD BRAND
↓
becomes
↓
NEW BRAND
Les systèmes doivent progressivement comprendre que :
- l'ancien nom ;
- le nouveau nom ;
- l'ancien domaine ;
- le nouveau domaine ;
- les profils externes ;
correspondent à une transition d'identité.
Une migration correctement structurée peut donc avoir une dimension sémantique en plus de sa dimension technique.
Les fusions et acquisitions peuvent produire des graphes complexes.
Exemple :
Company A
↓
acquiredBy
↓
Company B
L'ancienne entité peut continuer à exister comme marque ou être absorbée.
Les pages, profils et données structurées doivent refléter la réalité.
La relation entre une personne et une organisation peut être importante.
Exemples :
Founder
→ founded →
Organization
Employee
→ worksFor →
Organization
Author
→ authorOf →
Article
Ces relations contribuent à contextualiser l'expertise et la provenance des informations.
Une déclaration d'expertise peut être représentée par :
- biographies ;
- publications ;
- certifications ;
- travaux ;
- expériences ;
- contributions ;
- profils professionnels.
Une simple déclaration :
Nous sommes experts.
apporte moins d'information qu'un ensemble de faits vérifiables permettant à l'utilisateur d'évaluer cette expertise.
Google utilise le concept E-E-A-T dans ses Search Quality Rater Guidelines.
Il correspond à :
- Experience ;
- Expertise ;
- Authoritativeness ;
- Trust.
E-E-A-T n'est pas un score public attribué à chaque site.
La représentation claire :
- des auteurs ;
- de l'organisation ;
- des sources ;
- de l'expérience ;
- de la responsabilité éditoriale ;
peut néanmoins contribuer à rendre un contenu plus transparent pour les utilisateurs.
Le terme Entity Authority peut être utilisé comme concept descriptif pour parler de la reconnaissance ou de la crédibilité associée à une entité.
Il ne doit pas être présenté comme une métrique officielle de Google.
Une autorité perçue peut dépendre de nombreux éléments :
- réputation ;
- expertise ;
- références ;
- mentions ;
- sources ;
- publications ;
- ancienneté ;
- pertinence thématique.
Une organisation peut être associée à plusieurs sujets.
Exemple :
VisiaLocal
↓
Semantic SEO
↓
Entity SEO
↓
Structured Data
↓
AEO
↓
GEO
↓
AI Search
L'objectif n'est pas de répéter ces termes partout.
Il est de produire suffisamment d'informations utiles et cohérentes pour établir des relations thématiques compréhensibles.
Un sujet n'est pas nécessairement une entité commerciale.
Exemple :
Semantic SEO
est un sujet ou concept.
VisiaLocal
est une organisation.
La relation peut être :
VisiaLocal
→ worksOn →
Semantic SEO
Cette distinction permet de construire une architecture plus précise.
Une architecture orientée entités peut commencer par identifier :
- les entités principales ;
- leurs attributs ;
- leurs relations ;
- les informations nécessaires ;
- les pages permettant de représenter ces informations.
On passe alors de :
KEYWORD
↓
PAGE
à :
REALITY
↓
ENTITY
↓
INFORMATION
↓
RELATIONSHIPS
↓
CONTENT
↓
PAGE
Le mot-clé reste utile pour comprendre la demande.
Mais il n'est plus nécessairement le point de départ unique.
Les liens internes peuvent relier des documents qui représentent des entités ou concepts liés.
Exemple :
Organization page
→ Service page
→ Methodology page
→ Case study
→ Person page
Le texte d'ancrage et le contexte du lien peuvent aider l'utilisateur à comprendre la relation.
L'objectif premier reste la navigation et la compréhension.
Dans ce référentiel, le Semantic Internal Linking désigne une architecture de liens basée sur des relations informationnelles réelles.
Exemple :
Service
→ expliqué par →
Methodology
Service
→ démontré par →
Case Study
Article
→ authoredBy →
Person
Le lien devient alors également l'expression d'une relation conceptuelle.
Les liens externes peuvent fournir :
- sources ;
- définitions ;
- preuves ;
- références ;
- contexte.
Un lien vers une source primaire peut aider le lecteur à vérifier une affirmation.
L'objectif n'est pas d'ajouter artificiellement des liens externes.
Chaque lien doit avoir une fonction informationnelle.
Google peut afficher des Knowledge Panels pour certaines entités.
La présence d'un Knowledge Panel ne doit pas être considérée comme une condition nécessaire à l'existence d'une entité.
De nombreuses entités peuvent être comprises ou représentées sans disposer d'un Knowledge Panel visible.
Google utilise un Knowledge Graph pour organiser certaines informations autour d'entités et de leurs relations.
Cependant, l'architecture exacte, les critères d'intégration et les systèmes internes ne sont pas entièrement publics.
Il faut donc éviter d'affirmer :
Cette technique crée une entité dans le Knowledge Graph de Google.
Une formulation plus rigoureuse est :
Cette technique aide à fournir une représentation explicite et cohérente de l'entité sur le Web.
Wikidata constitue une base de connaissances structurée et collaborative.
Certaines entités y possèdent des identifiants.
Cependant, créer une entrée Wikidata uniquement dans un objectif SEO sans respecter les règles de la plateforme n'est pas une stratégie appropriée.
Une entité doit respecter les critères et politiques du projet.
Wikipedia peut être une source importante d'information sur certaines entités.
Mais Wikipédia n'est pas un annuaire SEO.
Une entreprise ne doit pas chercher à créer artificiellement une page encyclopédique uniquement pour obtenir un signal d'entité.
Les critères de notoriété et les règles éditoriales doivent être respectés.
Les connaissances sur une entité peuvent provenir de nombreuses sources :
- site officiel ;
- organismes publics ;
- publications ;
- bases de données ;
- profils professionnels ;
- presse ;
- partenaires ;
- certifications ;
- plateformes sectorielles ;
- données structurées.
Toutes les sources n'ont pas la même fonction ni le même niveau de fiabilité.
Les données de première partie peuvent fournir les attributs nécessaires à la représentation des entités.
Exemple :
BUSINESS DATA
↓
services
↓
zones
↓
products
↓
people
↓
processes
↓
attributes
↓
ENTITY MODEL
Une stratégie Entity SEO peut donc commencer par la connaissance réelle de l'entreprise.
Dans le framework VisiaLocal, Business First-Party Knowledge désigne les connaissances factuelles qu'une organisation possède directement sur sa propre activité.
Exemples :
- ce qu'elle vend ;
- ce qu'elle fait ;
- où elle intervient ;
- qui intervient ;
- comment le service fonctionne ;
- quelles conditions s'appliquent.
Ces informations peuvent ensuite être transformées en attributs et relations.
Ce terme est utilisé ici comme modèle méthodologique.
Il ne s'agit pas d'une terminologie officielle de Google.
Une Answer Unit peut répondre à une question concernant un attribut ou une relation.
Exemple :
Question
Dans quelles villes l'entreprise intervient-elle ?
Entity
Organization
Relationship
servesArea
Answer
L'entreprise intervient principalement à Aix-en-Provence, Marseille et dans les communes environnantes selon le type de prestation.
La réponse visible et la représentation sémantique peuvent donc décrire la même réalité.
Une question peut être représentée comme une interrogation sur un graphe.
Exemple :
Qui dirige cette entreprise ?
peut correspondre conceptuellement à :
Organization
→ founder / employee / executive →
Person
L'Entity SEO fournit la représentation.
L'AEO travaille sur la capacité à fournir la réponse.
Les systèmes génératifs peuvent avoir besoin d'identifier :
- la bonne entité ;
- ses attributs ;
- ses relations ;
- ses sources.
Une représentation cohérente peut donc être utile dans une stratégie GEO.
Cela ne garantit cependant aucune citation dans une réponse générative.
AI Search peut combiner :
- recherche ;
- retrieval ;
- Knowledge Graphs ;
- documents ;
- données structurées ;
- modèles de langage ;
- sources externes.
Les architectures exactes varient.
Mais l'identification correcte des entités reste un problème fondamental de recherche d'information.
Une information ne peut généralement être exploitée depuis le Web que si elle peut être découverte ou récupérée.
Une architecture orientée entités peut faciliter la compréhension contextuelle des informations récupérées.
Exemple :
PASSAGE
Elle intervient dans toute la région.
Question :
Qui est « elle » ?
Sans contexte d'entité, le passage peut être ambigu.
Une formulation contextualisée :
Example Company intervient dans toute la région Provence-Alpes-Côte d'Azur.
est plus autonome.
Une information doit parfois rappeler l'entité concernée.
Cela ne signifie pas répéter le nom de l'entreprise dans chaque phrase.
Il s'agit d'éviter les passages dont le sens dépend entièrement d'un contexte absent.
Un réseau peut posséder :
BRAND
↓
LOCATION A
LOCATION B
LOCATION C
Chaque établissement peut avoir :
- adresse ;
- horaires ;
- services ;
- équipe ;
- caractéristiques ;
- zone ;
- avis.
Il faut distinguer les attributs de la marque et ceux de chaque établissement.
Une entreprise locale peut être représentée comme :
ORGANIZATION
↓
operates
↓
LOCAL BUSINESS
↓
locatedAt
↓
ADDRESS
↓
locatedIn
↓
CITY
et :
LOCAL BUSINESS
↓
provides
↓
SERVICE
Cette représentation permet de distinguer organisation, établissement, lieu et service.
Un commerce électronique peut contenir :
ORGANIZATION
↓
owns
↓
BRAND
↓
offers
↓
PRODUCT
↓
hasVariant
↓
PRODUCT VARIANT
↓
associatedWith
↓
OFFER
Les informations peuvent ensuite inclure :
- prix ;
- stock ;
- livraison ;
- caractéristiques ;
- avis.
Un créateur peut être représenté comme :
PERSON
↓
creates
↓
CONTENT
↓
publishedOn
↓
PLATFORM
et :
PERSON
↓
associatedWith
↓
ORGANIZATION / BRAND
Cela peut être pertinent pour les sites personnels, médias et marques personnelles.
Une grande entreprise peut présenter une architecture beaucoup plus complexe :
GROUP
↓
SUBSIDIARY
↓
BRAND
↓
COUNTRY
↓
LOCATION
↓
SERVICE
↓
PRODUCT
↓
OFFER
Une stratégie sémantique à grande échelle nécessite donc une gouvernance de l'identité et des relations.
Une entité internationale peut être représentée dans plusieurs langues et plusieurs pays.
Il faut distinguer :
- traduction ;
- localisation ;
- filiale ;
- établissement ;
- domaine ;
- marché ;
- langue.
Une version française d'une page ne constitue pas nécessairement une nouvelle entité entreprise.
Plus une organisation possède d'entités, plus la gouvernance devient importante.
Il peut être nécessaire de définir :
- identifiants ;
- noms officiels ;
- relations ;
- propriétaires de données ;
- sources de vérité ;
- processus de mise à jour.
Cette problématique dépasse le SEO.
Elle touche à l'architecture de l'information.
Une organisation peut définir une source de référence pour certaines informations.
Exemple :
Opening hours
↓
Business database
↓
Website
↓
Local platforms
↓
Structured data
Cela réduit le risque de contradictions.
Les entités évoluent.
Exemples :
- nouvelle adresse ;
- nouveau dirigeant ;
- nouvelle marque ;
- fermeture ;
- nouveau service ;
- acquisition ;
- rebranding.
Une représentation sémantique doit donc être maintenue.
Un audit orienté entités peut examiner :
Quelle est l'entité ?
Quelles informations la décrivent ?
À quelles autres entités est-elle reliée ?
Où ces informations sont-elles publiées ?
Les informations sont-elles cohérentes ?
Les principales relations sont-elles représentées lorsque cela est pertinent ?
Les profils importants correspondent-ils à la même entité ?
Existe-t-il des sources externes pertinentes ?
Les informations sont-elles encore actuelles ?
Une organisation peut établir un inventaire :
| Entity | Type | Canonical Resource | Main Relationships |
|---|---|---|---|
| Company | Organization | About page | provides Services |
| Founder | Person | Profile page | worksFor Company |
| Service A | Service | Service page | provider Company |
| Location A | LocalBusiness | Location page | branchOf Company |
L'objectif est de rendre visible l'architecture réelle de l'organisation.
Une Entity Map peut représenter les relations importantes.
Exemple :
COMPANY
├── PERSON │ └── founderOf → COMPANY │ ├── SERVICE A │ └── provider → COMPANY │ ├── SERVICE B │ └── provider → COMPANY │ └── LOCATION └── branchOf → COMPANY
Une Entity Map peut servir de base à une architecture de contenu ou de données structurées.
Dans ce référentiel, un Entity Gap correspond à une entité réelle importante qui n'est pas correctement représentée dans la présence numérique.
Exemple :
Une entreprise possède trois services majeurs.
Deux disposent de pages et de descriptions précises.
Le troisième n'est presque jamais mentionné.
Il existe alors un écart entre :
Business Reality
et :
Digital Entity Representation
Un Relationship Gap apparaît lorsque deux entités existent publiquement mais que leur relation n'est pas clairement exprimée.
Exemple :
une personne possède une page.
une entreprise possède une page.
mais rien n'indique clairement que cette personne est la fondatrice de l'entreprise.
Les deux entités existent.
La relation est absente.
Un Corroboration Gap correspond ici à une information importante uniquement auto-déclarée alors que des sources externes pertinentes pourraient légitimement la confirmer.
Cela ne signifie pas qu'il faut fabriquer des mentions.
La corroboration doit provenir de relations ou sources réelles.
L'Entity Coverage peut être utilisée comme notion de travail pour examiner si les principales entités d'une organisation sont correctement représentées.
L'objectif n'est pas :
créer le plus d'entités possible.
L'objectif est :
représenter correctement les entités réellement importantes.
Multiplier artificiellement les noms d'entités dans un texte n'améliore pas nécessairement sa qualité.
L'Entity SEO n'est pas une technique de densité de noms propres.
Une entité doit apparaître lorsqu'elle contribue réellement à l'information.
On peut appeler Entity Stuffing une pratique consistant à accumuler artificiellement :
- marques ;
- personnalités ;
- lieux ;
- concepts ;
- organisations ;
dans le seul objectif de créer des associations.
Cette pratique ne constitue pas une stratégie sémantique de qualité.
Les relations doivent être réelles et pertinentes.
Créer de nombreux profils artificiels ou sites contrôlés uniquement pour répéter la même affirmation n'est pas équivalent à une corroboration indépendante.
Il faut distinguer :
distribution légitime de l'information
et :
fabrication artificielle de preuves
Une stratégie durable privilégie les relations réelles.
Une erreur fréquente consiste à réduire l'Entity SEO au balisage Schema.org.
Mais :
ENTITY SEO
peut inclure :
- contenu ;
- architecture ;
- identité ;
- liens ;
- profils ;
- sources ;
- relations ;
- données structurées ;
- corroboration ;
- maintenance.
JSON-LD n'est qu'une couche.
Toutes les stratégies orientées entités ne nécessitent pas la construction d'un Knowledge Graph technique complexe.
Un site local peut déjà améliorer fortement sa représentation en clarifiant :
- son organisation ;
- ses services ;
- ses personnes ;
- ses établissements ;
- ses zones ;
- leurs relations.
La sophistication doit correspondre au besoin.
Les fondamentaux restent importants :
- crawl ;
- indexation ;
- contenu utile ;
- architecture ;
- liens ;
- performance ;
- accessibilité ;
- qualité.
L'approche entité ajoute une dimension de représentation et de relations.
Elle ne supprime pas les fondamentaux.
Une stratégie d'entités ne peut pas garantir :
- Knowledge Panel ;
- Knowledge Graph inclusion ;
- classement ;
- citation IA ;
- rich result ;
- visibilité dans AI Overviews.
Les systèmes externes déterminent leurs propres résultats.
Le framework conceptuel peut être résumé en douze étapes.
Identifier les entités réelles.
Déterminer leur type.
Définir leur identité.
Documenter leurs caractéristiques.
Identifier leurs relations.
Vérifier les informations.
Déterminer où elles doivent être représentées.
Utiliser les structures et données appropriées.
Relier les ressources pertinentes.
Identifier les sources externes légitimes.
Observer la représentation et la visibilité.
Actualiser le graphe lorsque la réalité évolue.
Ce framework constitue un modèle méthodologique.
Il ne représente pas un protocole officiel de Google.
REAL-WORLD ENTITY
↓
IDENTITY
↓
FIRST-PARTY KNOWLEDGE
↓
ATTRIBUTES
↓
RELATIONSHIPS
↓
CONTENT REPRESENTATION
↓
STRUCTURED DATA
↓
INTERNAL CONNECTIONS
↓
EXTERNAL REPRESENTATIONS
↓
CORROBORATION
↓
KNOWLEDGE REPRESENTATION
↓
SEARCH / RETRIEVAL
↓
AEO / GEO / AI SEARCH
↓
MEASUREMENT
↓
MAINTENANCE
Une stratégie orientée entités peut être résumée par cinq questions :
Qui ou quoi est cette entité ?
Quelles informations la décrivent ?
À quelles autres entités est-elle reliée ?
Quelles sources permettent de confirmer son identité et ses attributs ?
Ces informations restent-elles cohérentes dans le temps ?
Le référentiel First-Party Data répond notamment à :
Quelles informations l'entreprise possède-t-elle ?
Le référentiel Entity SEO répond ensuite :
Quelles entités ces informations décrivent-elles et quelles relations révèlent-elles ?
On peut représenter :
FIRST-PARTY DATA
↓
BUSINESS KNOWLEDGE
↓
ENTITY
↓
ATTRIBUTE
↓
RELATIONSHIP
↓
PUBLIC REPRESENTATION
L'Entity SEO aide à définir :
de quoi parle la réponse.
L'AEO aide à définir :
comment l'information répond à la question.
Exemple :
ENTITY
Restaurant
↓
ATTRIBUTE
openingHours
↓
QUESTION
Êtes-vous ouvert dimanche ?
↓
ANSWER UNIT
Oui. Le restaurant est ouvert le dimanche de 12 h à 14 h.
Le GEO s'intéresse notamment à la visibilité dans les environnements génératifs.
Une source correctement contextualisée peut aider un système à identifier :
- l'entité ;
- le fait ;
- la relation ;
- la provenance.
On peut représenter :
ENTITY
↓
INFORMATION
↓
SOURCE
↓
RETRIEVAL
↓
GENERATIVE SYSTEM
↓
ANSWER
La sélection finale reste contrôlée par le système.
Les environnements AI Search peuvent combiner différentes formes de représentation :
- documents ;
- passages ;
- graphes ;
- données structurées ;
- résultats Search ;
- bases de connaissances ;
- retrieval ;
- modèles génératifs.
Une architecture d'entités constitue donc une manière de rendre les informations plus explicitement organisées.
Une Semantic SEO Agency peut intégrer plusieurs couches :
BUSINESS REALITY
↓
FIRST-PARTY DATA
↓
ENTITY MODEL
↓
SEMANTIC ARCHITECTURE
↓
CONTENT
↓
ANSWER UNITS
↓
STRUCTURED DATA
↓
CORROBORATION
↓
SEO / AEO / GEO
↓
AI SEARCH
L'Entity SEO constitue alors une couche structurante de l'ensemble.
Ce référentiel distingue :
- Entity ;
- Entity Resolution ;
- Knowledge Graph ;
- Schema.org ;
- JSON-LD ;
@id;sameAs.
- Entity SEO ;
- Semantic SEO ;
- AI Search ;
- GEO ;
- AEO.
- Entity Gap ;
- Relationship Gap ;
- Corroboration Gap ;
- Entity Coverage ;
- Entity Map dans le contexte méthodologique présenté ;
- framework Entity SEO VisiaLocal.
Ces derniers constituent des outils conceptuels.
Ils ne doivent pas être attribués à Google comme standards officiels.
Documentation générale sur Search :
https://developers.google.com/search/docs
https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
https://developers.google.com/search/docs/appearance/structured-data/organization
https://developers.google.com/search/docs/appearance/structured-data/local-business
https://developers.google.com/search/docs/appearance/ai-features
https://schema.org/Organization
https://schema.org/LocalBusiness
W3C JSON-LD:
https://www.w3.org/TR/json-ld11/
Ce référentiel est proposé et maintenu par VisiaLocal.
VisiaLocal est une agence d'ingénierie sémantique travaillant notamment sur :
- Semantic SEO ;
- Entity SEO ;
- Knowledge Graph ;
- First-Party Data ;
- Structured Data ;
- Schema.org / JSON-LD ;
- AEO ;
- GEO ;
- Local Search ;
- AI Search.
L'objectif de ce repository est de documenter une approche du référencement dans laquelle une entreprise n'est plus représentée uniquement comme un ensemble de pages et de mots-clés, mais comme un ensemble d'entités, d'attributs, de relations et de sources.
Les processus internes, systèmes de scoring, modèles clients, règles de priorisation, automatisations et architectures propriétaires de VisiaLocal ne sont pas documentés publiquement.
Pour citer ce référentiel :
VisiaLocal — Entity SEO & Knowledge Graph: référentiel sur les entités, relations, identité numérique, corroboration et AI Search (2026).
Les corrections factuelles, nouvelles sources primaires, discussions terminologiques et contributions permettant d'améliorer ce référentiel sont les bienvenues.
VisiaLocal — Agence d'Ingénierie Sémantique, SEO, GEO & AEO
Aix-en-Provence, France.