Une entité numérique est une personne, une organisation, une marque ou un objet que plusieurs pages décrivent de manière assez cohérente pour être distingué d’un homonyme. Ce n’est pas un badge attribué par un moteur. C’est le résultat d’informations visibles, reliées, vérifiables et maintenues.
Réponse en bref
Pour rendre une personne ou une organisation identifiable, créez une page canonique qui présente uniquement des faits confirmés, reliez-la aux contenus dont elle est réellement l’auteur ou l’éditeur, puis reproduisez ces informations dans des données structurées cohérentes. Utilisez Person, Organization, ProfilePage, Article et sameAs seulement lorsqu’ils décrivent le contenu visible et des profils détenus. Un graphe JSON-LD ne compense pas une biographie vide, des coordonnées contradictoires ou des références inventées.
Le problème : plusieurs fragments, aucune source de vérité
Une identité se fragmente vite :
- le site utilise deux variantes du nom ;
- une ancienne activité reste affichée sur un profil ;
- une page auteur ne correspond pas à la biographie publique ;
- les coordonnées diffèrent entre le site et une fiche locale ;
- le JSON-LD affirme une relation absente de la page ;
- un article pointe vers un profil non détenu.
Chaque fragment peut être techniquement valide. L’ensemble reste ambigu. Le premier chantier n’est donc pas le schema : c’est la définition d’une source de vérité éditoriale.
Le registre d’identité
Créez un tableau avec quatre colonnes :
| Fait | Preuve | Représentation publique | Maintenance |
|---|---|---|---|
| nom affiché | pièce ou validation du propriétaire | page À propos, byline, name | revue annuelle |
| rôle actuel | contrat, activité ou validation explicite | bio courte, page de profil | à chaque changement |
| site officiel | contrôle du domaine | url, canonical, profils | surveillance technique |
| profils externes | accès au compte et URL publique | liens visibles, sameAs | revue semestrielle |
| organisation liée | preuve de la relation | texte visible, worksFor si pertinent | à la fin de la relation |
La preuve peut rester privée. La représentation publique ne doit pas révéler un document sensible ; elle doit simplement ne pas dépasser ce qui a été validé.
Choisir une page canonique
Pour une personne
Une page auteur ou À propos peut devenir le point central si son sujet principal est la personne. Elle doit présenter :
- le nom public exact ;
- un rôle actuel confirmé ;
- les sujets réellement couverts ;
- les articles ou projets publics associés ;
- les profils externes détenus ;
- une date de mise à jour ;
- un moyen de signaler une correction.
Google documente ProfilePage pour les pages dont le sujet principal est une personne ou une organisation affiliée au site. La propriété mainEntity identifie l’entité décrite.
Pour une organisation
La page d’accueil ou une page dédiée peut représenter l’organisation. Les informations visibles peuvent inclure le nom, l’URL, le logo, le téléphone, l’adresse lorsqu’elle est publique et les profils officiels. Les propriétés Organization doivent rester cohérentes avec cette page.
Ne publiez pas une adresse personnelle uniquement pour remplir un champ. Une propriété recommandée n’est pas une obligation et la minimisation des données reste prioritaire.
Relier les articles à leur auteur
Chaque article doit afficher une byline et mener vers une page qui aide à identifier l’auteur. Dans les données structurées Article ou BlogPosting, l’auteur peut être une Person ou une Organization avec un nom et une URL.
Une structure simple :
Article
├─ author → /a-propos/
├─ publisher → organisation éditrice réelle
└─ mainEntityOfPage → URL canonique de l’article
/a-propos/
└─ ProfilePage.mainEntity → Person
└─ sameAs → profils externes validés
Réutilisez un @id stable lorsqu’il simplifie le graphe, mais ne créez pas des relations qui ne sont pas expliquées dans la page.
Utiliser sameAs avec discipline
sameAs peut pointer vers une autre page qui identifie sans ambiguïté la même personne ou organisation. Avant d’ajouter une URL, vérifiez :
- le profil est public ;
- le propriétaire en contrôle l’accès ;
- le nom et le rôle sont cohérents ;
- le profil n’est pas une page de recherche ou un homonyme ;
- la relation est acceptable publiquement.
Un lien visible dans la page reste utile au lecteur. Le placer uniquement dans le JSON-LD rend la relation plus difficile à contrôler.
Contrôler la cohérence NAP
Pour une organisation locale, le contrôle NAP compare le nom, l’adresse et le téléphone entre toutes les surfaces publiques. Il ne s’agit pas de répéter mécaniquement trois champs, mais d’éviter que plusieurs versions incompatibles décrivent la même entité.
Comparez au minimum :
- la page de contact et le pied de page ;
- les liens
tel:et les numéros visibles ; - le JSON-LD
OrganizationouLocalBusiness; - Google Business Profile et les autres profils détenus ;
- les mentions légales lorsque l’information doit être publique.
Documentez les variantes légitimes : siège et établissement, standard et ligne commerciale, nom légal et marque. Une différence expliquée n’est pas une incohérence. En revanche, un ancien numéro, une adresse fermée ou une marque orthographiée différemment doit être corrigé à la source.
Exemple JSON-LD minimal
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"url": "https://www.exemple.fr/a-propos/",
"dateModified": "2026-07-13",
"mainEntity": {
"@id": "https://www.exemple.fr/#personne",
"@type": "Person",
"name": "Nom public validé",
"url": "https://www.exemple.fr/a-propos/"
}
}
Cet exemple omet volontairement profession, employeur, profils, image et récompenses. Ajoutez une propriété seulement lorsqu’elle est vraie, visible, utile et maintenable.
Contrôler la cohérence
Identité
- orthographe identique du nom ;
- rôle compatible entre les pages ;
- biographie sans chiffre non prouvé ;
- une seule URL canonique par profil.
Relations
- chaque auteur mène à une page réelle ;
- l’éditeur déclaré correspond au site ;
- les profils externes sont détenus ;
- les relations professionnelles sont encore valides.
Technique
- JSON-LD valide ;
- propriétés conformes au contenu visible ;
- URLs absolues et accessibles ;
- dates exactes ;
- absence de doublons contradictoires dans les templates.
Maintenance
- propriétaire du registre identifié ;
- revue planifiée ;
- historique des corrections ;
- retrait rapide d’un profil perdu ou d’une relation terminée.
Corriger une information fausse dans une réponse IA
Une adresse ancienne, un rôle inexistant ou une offre retirée se corrigent à partir d’un fait précis et d’une référence fiable. Contester une réponse dans une conversation ne modifie pas automatiquement les sources ni les autres réponses du produit.
Un protocole en cinq étapes
- Qualifier l’erreur. Distinguez fait inexact, information périmée, homonyme et omission. Une appréciation comme « le meilleur prestataire » ne se corrige pas avec une fiche d’identité. Conservez question et réponse complètes, date, langue, produit, mode visible et citations. L’absence de citation ne révèle pas l’origine de l’information.
- Retrouver la preuve. Ouvrez chaque source citée et le passage concerné. Une page correcte peut être mal interprétée ; un ancien PDF peut contredire la page actuelle. Rédigez le fait exact, son périmètre et sa source publique autoritative. Les preuves confidentielles restent privées ; l’absence de preuve publiable doit être signalée.
- Corriger la référence. Alignez page canonique, documents publics, profils détenus et JSON-LD fidèle au texte visible. Pour une page tierce, demandez la correction du passage avec sa preuve. Une redirection n’est appropriée que vers un véritable équivalent ; renvoyer une ancienne information vers l’accueil ne résout pas la contradiction.
- Contrôler et signaler. Vérifiez statut HTTP, contenu accessible, canonique, robots et pare-feu. Utilisez une demande de réexploration disponible après une modification réelle. Un signalement dans l’assistant documente une erreur, sans prouver sa correction globale. Une atteinte à une personne ou une question juridique appelle une revue compétente.
- Retester. Fixez un intervalle ou un événement vérifiable, puis rejouez le même corpus dans les mêmes conditions. Gardez toutes les réponses et le nombre total d’essais, y compris les erreurs techniques. Une réponse corrigée ne garantit pas toutes les formulations ni tous les modes.
Le registre de correction
| Champ | Contenu à conserver |
|---|---|
| Observation | Fait exact et référence opaque de la réponse conservée |
| Vérité attendue | Formulation, périmètre, source publique et passage |
| Action | Correction détenue, demande à un tiers, réexploration ou signalement |
| État prouvé | Publié, soumis, exploré, indexé ou retesté, séparément |
| Retest | Réponse exacte/partielle/fausse/non vérifiable et source citée |
Exemple fictif : une organisation travaille désormais à distance, mais un assistant évoque un accueil physique. Le renseignement ancien figure dans un PDF détenu et un annuaire. Le PDF est corrigé ; l’annuaire reçoit une demande ; les sources et les réponses sont retestées séparément. Tant que l’annuaire reste inchangé, le registre indique « demande envoyée », pas « erreur supprimée ». Le guide GEO détaille la distinction entre accès, indexation et citation.
Ce que l’entité numérique ne prouve pas
Un graphe cohérent ne prouve pas une expertise, un diplôme, une clientèle ou une reconnaissance. Il aide à représenter des faits déjà établis. De même, sameAs n’est pas un moyen de s’approprier une page tierce. Une donnée structurée valide n’assure ni affichage enrichi, ni citation dans un moteur de réponse.
Limites
Les moteurs utilisent de nombreux signaux et ne publient pas une procédure d’enregistrement universelle des entités. Schema.org fournit un vocabulaire, pas une certification. Certaines informations légitimes doivent rester privées. Le registre d’identité aide à maintenir la cohérence mais ne remplace ni une preuve publique, ni une revue juridique des données personnelles.
Articles liés
- Données structurées auteur et article
- Guide GEO : rendre un contenu utile aux moteurs de réponse
- Protéger les données sensibles lors de l’usage d’un assistant IA
Prochaine étape
Créez le registre d’identité, retirez les faits sans preuve, puis alignez une page canonique et son JSON-LD. Pour préparer une revue, indiquer l’entité et les pages concernées.
Sources vérifiées
- Source externe, developers.google.com , consultée le 30 septembre 2026
- Source externe, developers.google.com , consultée le 30 septembre 2026
- Source externe, developers.google.com , consultée le 30 septembre 2026
- Source externe, developers.google.com , consultée le 30 septembre 2026
- Source externe, schema.org , consultée le 30 septembre 2026
- Source externe, schema.org , consultée le 30 septembre 2026