Schema Organization et Person : comment structurer vos nœuds d’entité en 2026 ?
Rédigé par Ulysse Berthelot – Co-Fondateur & Président chez iaba · Mis à jour le · Temps de lecture ≈ 12 min
Un schema Organization Person mal renseigné, c’est une entreprise que Google et ChatGPT voient comme un texte flou, pas comme une entité. Voici, propriété par propriété, ce que vos nœuds JSON-LD doivent réellement contenir en 2026.
- Les nœuds Organization et Person déclarent l’identité factuelle de l’entreprise et de ses dirigeants aux IA (ChatGPT, Perplexity, Gemini, AI Overviews).
- Les propriétés clés à renseigner :
name,logo,address,sameAs,identifier,founder,knowsAbout. - Une étude de Princeton mesure jusqu’à 40 % d’augmentation de visibilité IA quand les contenus s’appuient sur des sources d’autorité et une structuration entités-first.
Le schema Organization et le schema Person sont deux formats de données structurées JSON-LD, issus du vocabulaire Schema.org, qui déclarent officiellement l’identité d’une entreprise et de ses dirigeants aux moteurs de recherche et aux intelligences artificielles. En renseignant précisément des propriétés comme sameAs, knowsAbout, l’adresse et les identifiants légaux (SIREN, TVA), les marques consolident leur entité sémantique et facilitent leur reconnaissance factuelle par ChatGPT, Perplexity, Gemini et Google AI Overviews.
En 2026, Google et les grands modèles de langage n’indexent plus des chaînes de caractères, ils indexent des entités. Une entreprise, un fondateur, un domaine d’expertise : chacun est un nœud connecté à d’autres nœuds dans un graphe. Le rôle des balises schema Organization Person est précisément d’exposer ces nœuds dans un langage que les machines comprennent sans ambiguïté. C’est le premier pilier d’une stratégie globale d’entity building, et le socle du Protocole GEO-4 que nous appliquons chez iaba sur nos accompagnements clients.
Définition GEO : le GEO désigne l’optimisation de la visibilité d’une marque dans les moteurs génératifs (ChatGPT, Perplexity, Gemini, Claude, Google AI Overviews). Le schema Organization Person en est la couche déclarative : sans nœuds propres, aucune IA ne peut vous citer avec confiance.
Pourquoi les balises Schema Organization et Person sont-elles cruciales pour les IA ?
Les balises Schema Organization et Person lèvent l’ambiguïté sur l’identité d’une entreprise et de ses dirigeants. Elles fournissent aux IA une source de vérité structurée qui alimente la compréhension sémantique de la marque, condition préalable à toute citation par un moteur génératif.
Un moteur génératif ne « lit » pas votre site comme un humain : il extrait des faits et cherche à les croiser avec d’autres sources. Sans balisage, votre entreprise n’est qu’une suite de mots-clés dans un texte. Avec un nœud Organization complet, elle devient une entité identifiée, avec un nom canonique, une adresse, des identifiants légaux et un réseau de profils vérifiables. La différence est cruciale : c’est ce qui permet à Perplexity ou ChatGPT de vous citer avec une confiance suffisante.
+40 % de visibilité potentielle dans les IA. L’étude de Princeton sur le Generative Engine Optimization mesure jusqu’à 40 % d’augmentation de citations dans les moteurs génératifs quand les contenus s’appuient sur des sources d’autorité et une structuration sémantique.
Chez iaba, sur nos accompagnements multi-clients, nous constatons régulièrement que les pages sans schema Organization sont plus rarement reprises dans les réponses des moteurs génératifs que les mêmes pages une fois structurées. Ce n’est pas magique : le balisage n’ajoute pas d’autorité, il la rend lisible. Sans cette lisibilité, l’autorité accumulée reste invisible pour les IA.
⚡ Un schema Organization Person, c’est votre carte d’identité machine. Sans elle, vous êtes anonyme aux yeux des IA — même si votre site est excellent.
Attention néanmoins : renseigner ces nœuds n’entraîne jamais automatiquement l’apparition d’un knowledge panel ni l’entrée dans le Knowledge Graph de Google. Ces reconnaissances dépendent d’un consensus de sources externes (Wikipedia, Wikidata, presse) et de critères de notabilité que nous avons appris à mesurer, sur le terrain, en travaillant des dossiers Wikidata réels. Ce que le balisage garantit, c’est la compréhension sémantique : première marche indispensable, mais pas une promesse de panel.
Quelles propriétés JSON-LD définir pour un nœud Organization complet ?
Un nœud Organization complet renseigne au minimum : name, url, logo, description, address, contactPoint, sameAs et un identifiant légal (identifier, taxID, vatID ou duns). Ces propriétés forment le socle factuel exploitable par Google et les LLM.
Le piège classique consiste à se contenter de trois propriétés minimales (@type, name, url) générées automatiquement par un plugin SEO. Ce niveau de balisage ne raconte rien à une IA. La documentation officielle Schema.org Organization liste plus de 80 propriétés exploitables : votre travail consiste à sélectionner celles qui prouvent l’existence, l’activité et la crédibilité de l’entreprise.
📝 En résumé : cette vidéo décompose l’implémentation d’un schema Organization champ par champ et montre comment le tester dans les outils Google. Complément utile au texte ci-dessous.
Comment bien renseigner les informations légales et l’adresse (NAP, SIREN) ?
La cohérence NAP (Name, Address, Phone) est un signal d’entité de premier ordre. Les moteurs comparent en permanence l’adresse et le téléphone déclarés dans votre schema avec ceux de votre fiche Google Business Profile entité, de vos profils LinkedIn, de vos mentions presse. Toute divergence est un signal de doute qui affaiblit l’entité.
Concrètement, votre nœud Organization doit contenir :
name: nom légal de l’entreprise (identique partout : site, GBP, Kbis, LinkedIn).address: un sous-nœudPostalAddressavecstreetAddress,postalCode,addressLocality,addressCountry.telephone: au format international+33....email: email de contact générique de l’entreprise.contactPoint: un sous-nœudContactPointpar type de contact (customer service, sales…).
Pour les identifiants légaux français, la propriété identifier (ou plus précisément PropertyValue imbriqué) permet de déclarer le SIREN, la TVA intracommunautaire ou un identifiant DUNS. Ces attributs sont un signal fort de notabilité juridique : ils prouvent que l’entité existe dans un registre officiel, ce qu’aucun spammeur ne peut simuler.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "iaba",
"url": "https://iaba.tech",
"logo": "https://iaba.tech/logo.png",
"description": "Agence de Generative Engine Optimization (GEO).",
"address": {
"@type": "PostalAddress",
"streetAddress": "…",
"postalCode": "31000",
"addressLocality": "Toulouse",
"addressCountry": "FR"
},
"telephone": "+33766424677",
"email": "contact@iaba.tech",
"identifier": [
{ "@type": "PropertyValue", "propertyID": "SIREN", "value": "XXXXXXXXX" },
{ "@type": "PropertyValue", "propertyID": "VAT", "value": "FRXXXXXXXXXXX" }
]
}Comment utiliser la propriété sameAs pour valider l’entité Organization ?
La propriété sameAs est le pont entre votre site et le reste du web sémantique. Elle liste les URLs officielles où cette même entité existe : LinkedIn, Wikidata, Wikipedia, Crunchbase, réseaux sociaux vérifiés, pages presse de référence. C’est par ce faisceau que Google et les IA construisent un consensus de sources autour de votre marque.
Ce qui compte
LinkedIn Company Page, Wikidata (Q…), Wikipedia, comptes sociaux vérifiés, GitHub/Behance selon secteur, profils presse.
Ce qu’il faut éviter
Annuaires spam, faux profils, pages orphelines, agrégateurs sans autorité. Un lien sameAs faible dilue le signal.
La règle
Chaque URL sameAs doit renvoyer, de son côté, vers votre site. La bidirectionnalité fait la validité de l’entité.
Sur le terrain, la question de Wikidata mérite d’être traitée honnêtement : la plateforme applique des critères de notabilité stricts. Toutes les entreprises n’y ont pas leur place, et une création prématurée finit en suppression. C’est un vrai retour d’expérience — nous avons vu des créations Wikidata refusées faute de sources secondaires suffisantes. La bonne approche : construire d’abord le consensus de sources par les RP digitales, puis proposer Wikidata quand la notabilité est démontrée par les mentions presse.
Attention : ne jamais lister dans sameAs une URL qui ne vous appartient pas ou dont vous n’êtes pas certain qu’elle pointe vers la même entité. Un sameAs mensonger est un signal négatif détecté par les moteurs.
Quelles propriétés JSON-LD structurer pour le nœud Person (Dirigeant) ?
Le nœud Person déclare l’identité d’un dirigeant, d’un fondateur ou d’un auteur. Ses propriétés clés en 2026 sont name, jobTitle, image, sameAs, worksFor, alumniOf et knowsAbout. Ces attributs alimentent l’E-E-A-T et associent l’expertise humaine à la marque.
Le nœud Person, tel que défini par Schema.org, est aussi important que l’Organization pour les IA. Pourquoi ? Parce que les moteurs génératifs cherchent à identifier qui parle, avec quelle légitimité. Un article publié par une personne balisée en Person, elle-même reliée à une Organization crédible, hérite d’un signal E-E-A-T beaucoup plus fort qu’un article anonyme.
Comment connecter l’entité Person à l’Organization via « founder » ou « employee » ?
La connexion se fait par deux propriétés miroirs. Dans le nœud Organization, on utilise founder (ou employee) pour pointer vers la Person. Dans le nœud Person, on utilise worksFor (ou affiliation) pour pointer en retour vers l’Organization. Cette bidirectionnalité est ce qui fait qu’une IA comprend que l’un est le fondateur de l’autre — et pas simplement un contact anonyme.
La question de savoir s’il faut structurer les propriétés comme deux nœuds séparés ou dans un même @graph relève d’un autre sujet (l’architecture d’imbrication). Ici, retenez seulement que chaque nœud doit contenir la référence croisée vers l’autre — c’est cette redondance contrôlée qui verrouille l’entité.
Comment exploiter l’attribut knowsAbout pour prouver l’expertise ?
La propriété knowsAbout déclare les domaines d’expertise réels d’une personne, en langage machine. C’est le cœur technique du signal E-E-A-T côté données structurées : elle transforme une bio marketing en affirmation vérifiable par les IA.
La bonne pratique consiste à ne pas se contenter de chaînes de caractères libres, mais à pointer vers des URI d’entités canoniques — typiquement des URLs Wikipedia ou Wikidata. Ces liens transforment un mot-clé en concept sémantique reconnu.
{
"@type": "Person",
"name": "Ulysse Berthelot",
"jobTitle": "Co-Fondateur & Président de iaba",
"image": "https://iaba.tech/wp-content/uploads/2026/06/Ulysse-Berthelot-1.jpg",
"url": "https://iaba.tech/ulysse-berthelot",
"worksFor": { "@type": "Organization", "name": "iaba", "url": "https://iaba.tech" },
"alumniOf": [
{ "@type": "EducationalOrganization", "name": "ESG Business School Bordeaux" }
],
"sameAs": [
"https://www.linkedin.com/in/ulysse-berthelot-14893214b/"
],
"knowsAbout": [
"https://en.wikipedia.org/wiki/Search_engine_optimization",
"https://en.wikipedia.org/wiki/Knowledge_graph",
"https://www.wikidata.org/wiki/Q4059174",
"Generative Engine Optimization",
"Schema.org"
]
}« Renseigner
knowsAboutavec des URI Wikipedia plutôt que du texte libre, c’est la différence entre dire à une IA ‘je m’y connais en SEO’ et lui prouver ‘je suis relié au concept canonique X’. Les moteurs génératifs ne jugent pas la première formule, ils vérifient la seconde. »
À quoi ressemble un code JSON-LD complet et commenté pour ces entités ?
Un code JSON-LD complet combine un nœud Organization (identité de l’entreprise, adresse, identifiants, sameAs) et un nœud Person (identité du dirigeant, expertise, worksFor). Chaque propriété est explicitement typée selon le vocabulaire Schema.org, et les nœuds se référencent mutuellement pour verrouiller l’entité.
📝 En résumé : la vidéo passe en revue les quatre schémas les plus utiles pour l’entity building et donne des exemples d’imbrication de base entre Person et Organization.
Voici un exemple complet, à adapter à votre entreprise. Il combine les deux nœuds sans imbrication complexe : deux blocs indépendants, chacun autonome, chacun renvoyant vers l’autre par une propriété miroir.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://iaba.tech/#organization",
"name": "iaba",
"legalName": "iaba SAS",
"url": "https://iaba.tech",
"logo": {
"@type": "ImageObject",
"url": "https://iaba.tech/logo.png",
"width": 512,
"height": 512
},
"description": "Agence française de Generative Engine Optimization (GEO), fondée à Toulouse en 2025.",
"foundingDate": "2025",
"foundingLocation": {
"@type": "Place",
"address": { "@type": "PostalAddress", "addressLocality": "Toulouse", "addressCountry": "FR" }
},
"address": {
"@type": "PostalAddress",
"postalCode": "31000",
"addressLocality": "Toulouse",
"addressCountry": "FR"
},
"telephone": "+33766424677",
"email": "contact@iaba.tech",
"contactPoint": {
"@type": "ContactPoint",
"contactType": "customer service",
"email": "contact@iaba.tech",
"areaServed": "FR",
"availableLanguage": ["fr", "en"]
},
"identifier": [
{ "@type": "PropertyValue", "propertyID": "SIREN", "value": "XXXXXXXXX" }
],
"founder": {
"@type": "Person",
"@id": "https://iaba.tech/ulysse-berthelot#person",
"name": "Ulysse Berthelot"
},
"knowsAbout": [
"Generative Engine Optimization",
"SEO sémantique",
"Schema.org",
"https://en.wikipedia.org/wiki/Knowledge_graph"
],
"sameAs": [
"https://www.linkedin.com/company/iaba-tech",
"https://iaba.tech"
]
}Le nœud Person associé, à placer sur les pages auteur, reprend la logique miroir :
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://iaba.tech/ulysse-berthelot#person",
"name": "Ulysse Berthelot",
"givenName": "Ulysse",
"familyName": "Berthelot",
"jobTitle": "Co-Fondateur & Président",
"image": "https://iaba.tech/wp-content/uploads/2026/06/Ulysse-Berthelot-1.jpg",
"url": "https://iaba.tech/ulysse-berthelot",
"worksFor": {
"@type": "Organization",
"@id": "https://iaba.tech/#organization",
"name": "iaba"
},
"alumniOf": [
{ "@type": "EducationalOrganization", "name": "ESG Business School Bordeaux" }
],
"sameAs": [
"https://www.linkedin.com/in/ulysse-berthelot-14893214b/"
],
"knowsAbout": [
"Generative Engine Optimization",
"SEO sémantique entity-first",
"Schema.org",
"https://en.wikipedia.org/wiki/Knowledge_graph"
]
}Conseil actionnable : les identifiants @id stables (avec ancres #organization, #person) permettent aux deux nœuds de se référencer proprement, y compris quand ils vivent dans deux fichiers ou pages différentes. C’est un détail technique mineur, un signal sémantique majeur.
Avant balisage complet
- Trois propriétés (name, url, @type).
- Aucun identifiant légal.
- Pas de sameAs → entité isolée.
- Pas de lien Organization ↔ Person.
- Aucun signal d’expertise structuré.
Après balisage complet
- 15+ propriétés renseignées, dont SIREN.
- Réseau sameAs vers LinkedIn.
- Lien bidirectionnel founder ↔ worksFor.
knowsAboutpointant vers URI Wikipedia.- Entité prête à être citée par les LLM.
Comment valider la conformité de vos données structurées pour Google et les LLM ?
La validation s’effectue via deux outils officiels : le Rich Results Test de Google, qui vérifie l’éligibilité aux résultats enrichis, et le Schema.org Validator, qui contrôle la conformité stricte au vocabulaire. Utilisez toujours les deux : ils ne détectent pas les mêmes erreurs.
| Outil | Ce qu’il vérifie | Quand l’utiliser |
|---|---|---|
| Rich Results Test | Éligibilité aux résultats enrichis Google (fil d’Ariane, logo, panneau). | Après mise en production, page par page. |
| Schema.org Validator | Conformité stricte au vocabulaire Schema.org, y compris propriétés non couvertes par Google. | Avant déploiement, sur code brut. |
| Google Search Console | Historique des erreurs de balisage détectées en crawl réel. | Suivi mensuel, détection de régressions. |
Attention à une subtilité : le Rich Results Test ne valide que les schémas éligibles à des rich results. Une propriété comme knowsAbout ou foundingLocation ne déclenche pas d’affichage enrichi, mais reste lue par les IA. Elle sera ignorée par le Rich Results Test mais confirmée par le Schema.org Validator. C’est pourquoi le second outil est indispensable pour tout ce qui touche à l’entity building.
Quelles sont les 5 étapes pour un balisage propre ?
-
Cartographier vos entités
Lister : l’entreprise, chaque fondateur, chaque auteur publiant sur le site. Attribuer à chacun un
@idstable. -
Rédiger les nœuds
Créer un JSON-LD par entité, en renseignant toutes les propriétés pertinentes (name, url, logo, address, sameAs, knowsAbout, identifier).
-
Croiser les références
S’assurer que Person.worksFor pointe vers Organization.@id, et que Organization.founder pointe vers Person.@id.
-
Valider techniquement
Passer chaque bloc au Schema.org Validator, puis au Rich Results Test. Corriger toute erreur ou warning.
-
Contrôler la cohérence NAP
Vérifier que name, address, phone, email sont identiques dans le schema, la fiche GBP, LinkedIn et les mentions presse.
Vos nœuds Organization et Person sont-ils prêts pour les IA ?
Nous auditons gratuitement votre balisage entité, votre cohérence NAP et votre réseau sameAs — verdict clair, plan d’action concret.
Un balisage propre n’est que la première pierre. Il vit dans un écosystème plus large : l’hygiène NAP et sameAs, la fiche GBP comme signal d’entité, et le personal branding LinkedIn des fondateurs. Chacun de ces leviers renforce ce que votre schema déclare — ou le contredit s’il est incohérent.
📌 Points clés à retenir
- Le schema Organization Person est la carte d’identité machine de votre entreprise et de ses dirigeants.
- Les propriétés à renseigner en priorité :
name,logo,address,identifier(SIREN),sameAs,founder,worksFor,knowsAbout. sameAsconstruit le consensus de sources externes (LinkedIn, Wikidata, presse).knowsAboutavec URI Wikipedia/Wikidata transforme une bio marketing en fait vérifiable.- Le balisage ne garantit jamais un knowledge panel : il rend l’autorité lisible, pas gagnée.
- Deux outils de validation obligatoires : Rich Results Test + Schema.org Validator.
- La cohérence NAP (site ⇄ GBP ⇄ LinkedIn ⇄ presse) verrouille l’entité aux yeux des IA.
À propos de l’auteur : Ulysse Berthelot
Ulysse Berthelot est co-fondateur et président de iaba, agence pionnière en Marketing IA basée à Toulouse. Passé par Oreegami (certification Expert Marketing Digital co-financée par Google, RNCP niveau 6) et l’ESG Business School Bordeaux, il est l’architecte du Protocole GEO-4, méthodologie propriétaire d’optimisation de la visibilité dans les moteurs génératifs.
Expertises : GEO, AI Overviews, SEO Sémantique, Knowledge Graph Optimization, Schema.org, JSON-LD, RAG, n8n.
FAQ : schema Organization Person
Faut-il mettre le schema Organization sur toutes les pages du site ?
Non. Google recommande de placer le schema Organization sur la page d’accueil (ou une page « À propos » canonique), avec un @id stable. Les autres pages peuvent y faire référence par @id, sans dupliquer le nœud complet. Répéter le bloc entier partout n’apporte rien et alourdit inutilement les pages.
Combien de propriétés sameAs faut-il déclarer ?
Il n’existe pas de nombre magique. Visez la qualité : 5 à 10 profils officiels vérifiables (LinkedIn, Wikidata, Crunchbase, comptes sociaux principaux) valent mieux que 30 URLs d’annuaires faibles. Chaque sameAs doit être bidirectionnel : le profil externe doit renvoyer vers votre site.
Le schema Person doit-il être présent sur chaque article de blog ?
Idéalement oui, sur les articles signés. La balise Person peut être intégrée soit comme nœud complet, soit par référence à un @id canonique (par exemple sur la page auteur du site). Cette structuration renforce le signal E-E-A-T page par page.
Le balisage JSON-LD garantit-il un knowledge panel Google ?
Non, et méfiez-vous de toute promesse contraire. Le knowledge panel dépend d’un consensus de sources externes (Wikipedia, Wikidata, presse) et de critères de notabilité. Le schema Organization Person est une condition nécessaire pour que Google comprenne l’entité, mais pas une condition suffisante pour déclencher un panel.
Peut-on renseigner plusieurs identifiants légaux (SIREN, TVA, DUNS) ?
Oui. La propriété identifier accepte un tableau de PropertyValue. Vous pouvez déclarer simultanément SIREN, numéro de TVA intracommunautaire, DUNS, et tout autre identifiant officiel pertinent. Plus ces identifiants sont nombreux et vérifiables, plus l’entité gagne en solidité juridique perçue.
Faut-il pointer knowsAbout vers Wikipedia ou vers du texte libre ?
Les deux sont valides, mais les URI Wikipedia ou Wikidata sont largement supérieures. Elles transforment un mot-clé (« SEO ») en concept sémantique canonique reconnu par les moteurs. Une bonne pratique : mixer 60 % d’URI et 40 % de chaînes libres pour couvrir les concepts n’ayant pas d’article Wikipedia dédié.
Que faire si le Rich Results Test ne détecte pas mes propriétés ?
C’est normal pour les propriétés qui ne déclenchent pas de rich result (comme knowsAbout ou foundingLocation). Utilisez le Schema.org Validator en complément : il vérifie la conformité complète au vocabulaire, y compris les propriétés « invisibles » côté Google mais lues par les IA.
Un plugin WordPress suffit-il pour un balisage propre ?
Les plugins couvrent le socle (name, url, logo, sameAs basique) mais ne gèrent quasiment jamais correctement identifier, knowsAbout avec URI, ou les références bidirectionnelles founder ↔ worksFor. Pour un balisage exploitable par les IA, l’injection d’un JSON-LD custom (via mu-plugin ou hook) reste la meilleure option.
Passez d’un balisage minimal à un balisage citable par les IA
Notre diagnostic GEO analyse vos nœuds Organization et Person, votre réseau sameAs et votre cohérence entité pour identifier les brèches et prioriser les corrections.
📚 Sources et références
Sources officielles :
- Schema.org — Organization (documentation officielle)
- Schema.org — Person (documentation officielle)
- Google Search Console — Rich Results Test
- Schema.org Markup Validator
Sources académiques :
Sources encyclopédiques :
Vidéos :
- Organization Schema Setup: Step-by-Step Guide — My Online Master
- Schema Markup Basics: Person, Organization, FAQ & Article — Plabon Story
📖 À lire également :
