Un modèle de données d'entités représente les objets métiers du monde réel sous forme d'enregistrements de données identifiables de manière unique, dotés d'attributs, de relations et d'une source précise. Pour votre entreprise, cela signifie que l'organisation, la marque, la personne, le lieu, le service, le produit, la référence et le moyen de contact ne sont pas saisis à nouveau sur chaque sous-page, mais modélisés une seule fois et utilisés de manière cohérente.
Au Tyrol du Sud, notamment dans les PME, les informations contradictoires résultent rarement de négligence. Dans le cadre de mon travail auprès des petites et moyennes entreprises, je rencontre plus fréquemment un autre problème : le site web affiche des horaires d’ouverture différents de ceux de la fiche Google My Business, une brochure utilise un nom de marque obsolète et la version italienne mentionne un contact qui n’est plus en fonction. Le contenu est présent, mais la source et la responsabilité restent floues.
Un modèle de données d'entités clair réduit la duplication des efforts. Il crée une source unique de vérité pour les données clés de l'entreprise et fournit une base fiable pour votre site web, les moteurs de recherche, les traductions, les interfaces et les systèmes d'IA.
Ce qu'un modèle de données d'entités peut apporter à votre entreprise
Une entité est un objet clairement défini sur lequel votre entreprise gère des informations. Une organisation est une entité. Un lieu est une autre entité. Un service, un produit ou une référence spécifique peut également être considéré comme une entité distincte.
La différence cruciale avec le texte d'une page ordinaire réside dans l'identité : une entité conserve son identifiant unique même si son nom, sa description, son URL ou sa langue changent. Cela permet à différents systèmes de faire référence au même objet de manière fiable.
Un identifiant stable répond à la question « De quel objet s'agit-il ? ». Le nom canonique répond à la question « Comment appelle-t-on actuellement cet objet ? ».
Un enregistrement d'entité utilisable contient au moins :
- Identifiant stable : un identifiant permanent et unique qui ne dépend pas d'un nom traduit.
- Nom canonique : Nom principal officiel de l'entité.
- Nom alternatif : Anciens noms, formes abrégées, noms commerciaux ou variantes courantes.
- PROPRIÉTÉS : Par exemple, adresse, description, adresse e-mail, horaires d'ouverture ou zone de service.
- Relation: un lien clair avec d'autres entités, comme par exemple « le lieu appartient à l'organisation ».
- Système source : la principale source où la valeur en question est maintenue.
- Langue: l'étiquetage des valeurs dépendantes de la langue, par exemple l'allemand ou l'italien.
- Statut: Brouillon, approuvé, obsolète ou archivé.
- Responsabilité: La personne ou le rôle qui examine et approuve les modifications.
- Date de l'inspection : la date de la dernière inspection professionnelle.
Cette structure transforme les données éparses du site web en informations exploitables pour l'entreprise. Un logiciel peut automatiser la production. L'IA peut aider à vérifier, traduire ou détecter les incohérences. Toutefois, aucun logiciel ne peut remplacer la décision de l'entreprise quant à la source faisant autorité et à la personne responsable de la qualité des données.
Les huit entités principales du modèle de données d'entités
1. Organisation
L'organisation décrit l'entité juridique ou économique qui représente l'entreprise. Les champs pertinents comprennent la dénomination sociale, la forme juridique, l'adresse, le numéro d'identification fiscale ou le numéro de TVA, les informations relatives à la création de l'entreprise, les coordonnées des principaux contacts et la direction responsable.
Les relations typiques comprennent :
- L'organisation pilote la marque.
- L'organisation dispose d'un local.
- L'organisation emploie ou représente la personne.
- L'organisation propose un service ou un produit.
- L'organisation propose un moyen de contact.
2. Marque
La marque ne se confond pas automatiquement avec l'entité juridique. Une entreprise peut exploiter plusieurs marques ; inversement, une marque peut être utilisée par plusieurs entreprises. Les éléments clés comprennent le nom officiel, les variantes orthographiques, le positionnement, le logo, le ton employé, le propriétaire de la marque et les versions linguistiques approuvées.
Cette distinction est particulièrement importante lors d'un changement d'image. Si le nom de la marque change, l'organisation peut rester inchangée. Une stratégie de marque et une architecture de marque solides en constituent le fondement professionnel.
3. Personne
Une personne peut être un fondateur, un directeur général, un interlocuteur, un auteur, un chef de projet ou un expert du domaine. Sa fiche doit comprendre son nom, son rôle, ses responsabilités, une photo de profil, une courte biographie, les langues parlées, l'organisation à laquelle elle est rattachée et ses coordonnées.
Les données personnelles nécessitent des autorisations explicites. Toutes les informations internes n'ont pas leur place sur le site web ni dans des données structurées. Le modèle de données de l'entité doit donc distinguer les éléments internes, protégés et accessibles au public.
4. Emplacement
Un établissement doit posséder sa propre identité si son adresse, ses horaires d'ouverture, son numéro de téléphone, les services proposés ou ses responsabilités diffèrent de ceux du siège social. Les champs pertinents comprennent le nom de l'établissement, son adresse, ses coordonnées géographiques, son fuseau horaire, ses horaires d'ouverture, les langues proposées et l'organisation à laquelle il est rattaché.
La relation doit être sans ambiguïté : « Le site de Bolzano appartient à l’organisation A » et « Des services de conseil sont disponibles sur le site de Bolzano ». Ce modèle de données d’entité empêche que les heures d’ouverture ou les numéros de téléphone ne soient appliqués par erreur à toutes les succursales.
5. puissance
Un service désigne une activité ou une offre clairement définie, comme une stratégie de marque, le développement web ou le conseil. Les champs pertinents comprennent le nom, la description du service, le public cible, le prestataire, la zone géographique desservie, les langues disponibles, le responsable et les références pertinentes.
Un service ne se résume pas à un simple titre sur une page. Une même donnée peut apparaître sur une page de service, dans un profil de localisation, dans une référence et dans des données exploitables par machine. J'aborderai plus en détail la manière dont les pages de service sont liées aux informations structurées appropriées dans l'article consacré au schéma de service et à JSON-LD.
6. Produit
Un produit est une offre concrète et identifiable, dotée de sa propre identité. Il peut s'agir, par exemple, d'une gamme de produits, d'une solution logicielle ou d'un article physique. Les champs pertinents peuvent inclure le nom du produit, le fabricant, la marque, la description, les variantes, la référence, la disponibilité, le prix et le canal de distribution.
Les services et les produits doivent rester distincts, même s'ils sont vendus ensemble. Le conseil est un service. Une plateforme logicielle standardisée est un produit. Cette relation pourrait être décrite, par exemple, comme suit : « La mise en œuvre du service soutient le produit X ».
7. Référence
Un document de référence consigne les travaux effectivement réalisés. Ce document doit inclure le nom du projet, l'approbation du client, la période, les services fournis, les responsables, la situation initiale, le résultat et les supports utilisables.
La référence prend tout son sens grâce aux relations établies. Le site web peut alors non seulement afficher une image du projet, mais aussi expliquer quelle organisation a bénéficié du soutien, quels services ont été fournis, quel lieu était concerné et quelle personne en était le responsable professionnel.
8. Méthode de contact
Un canal de contact est un moyen spécifique de joindre votre entreprise : numéro de téléphone, adresse e-mail, formulaire, messagerie instantanée, service d’assistance ou interlocuteur direct. Chaque canal de contact doit avoir un objectif, un public cible, les langues disponibles, les horaires de disponibilité, la localisation associée et une personne ou un organisme responsable.
Le modèle de données d'entité permet ainsi de distinguer si un numéro de téléphone est destiné aux demandes générales, aux ventes, à l'assistance ou à un lieu précis. Un moyen de contact doit non seulement être correct, mais aussi clairement associé à un objectif.
Modélisation des entités commerciales en sept étapes
Étape 1 : Données d'inventaire
Commencez par rassembler toutes les sources où apparaissent les données de l'entreprise : site web, fiche Google My Business, CRM, ERP, signatures électroniques, listes de prix, PDF, profils sur les réseaux sociaux et documents internes. Mettez en évidence les incohérences au lieu de choisir immédiatement une version supposément correcte.
L'évaluation initiale révèle souvent qu'il n'y a pas de manque d'informations. Généralement, plusieurs variantes existent sans hiérarchie discernable.
Étape 2 : Séparer les entités les unes des autres
Pour chaque enregistrement de données, vérifiez quel objet du monde réel il décrit. Un test utile consiste à déterminer si cet objet peut évoluer indépendamment des autres.
- Le lieu peut-il être déplacé sans que l'organisation change de nom ? Dans ce cas, le lieu constitue une entité distincte.
- Une personne peut-elle quitter l'entreprise tout en conservant son dossier de performance ? Si oui, la personne et son dossier de performance ne doivent pas être fusionnés en une seule fiche de données.
- Est-il possible de renommer la marque tout en conservant la même entité juridique ? Si oui, la marque et l’organisation doivent être distinctes.
Étape 3 : Attribuer des identifiants stables
Dans le modèle de données d'entité, utilisez des identifiants indépendants des noms, des langues et des URL actuelles. Un format interne pourrait ressembler à ceci, par exemple :
- org-0001 pour l'organisation
- marque-0001 pour la marque
- place-0001 pour le premier emplacement
- personne-0001 pour une personne
- service-0001 pour un service
L'identifiant « service-0001 » reste inchangé même si « Digitalberatung » est ultérieurement renommé « Digitale Prozessberatung ». Une URL descriptive peut changer ; l'identité interne, quant à elle, doit rester stable.
Étape 4 : Modéliser explicitement les relations
Ne vous contentez pas de stocker les relations sous forme de descriptions. « Maria Huber gère le site de Merano » doit être structurée comme une relation entre la personne 0001 et le lieu 0002. Les types de relations pertinents incluent, par exemple :
- gehört zu
- est exploité par
- est proposé par
- est disponible à
- est responsable de
- marque d'occasion
- performances documentées
- est une voie de contact pour
Étape 5 : Identifier les principales sources
Tous les champs ne doivent pas nécessairement provenir du même système. Les données juridiques de l'entreprise peuvent provenir du système administratif, les prix des produits du système ERP et les textes courts validés du système du site web. L'essentiel est que chaque champ important ait une source principale unique.
Le site web peut afficher des données, mais ne doit pas constituer systématiquement la source de toutes les informations. Un système source est préférable, dans lequel les modifications sont décidées et contrôlées par des experts.
Étape 6 : Définir la logique du langage
Un site web multilingue n'a pas besoin d'une copie complète de toutes les données. Il est préférable de diviser les propriétés du modèle de données d'entité en deux groupes :
- Valeurs neutres sur le plan linguistique : Identifiant stable, numéro de téléphone, géocoordonnées, adresse e-mail, lien organisationnel et numéro d'article interne.
- Valeurs dépendantes de la langue : Nom, brève description, description du service, intitulé du poste, URL, appel à l'action et, le cas échéant, informations sur les heures d'ouverture.
La traduction ne doit pas devenir une entité distincte. « Conseil en image de marque » et « consulenza di marca » désignent deux valeurs linguistiques pour un même service. Toutefois, l’architecture de l’information et l’intention de recherche doivent être planifiées séparément pour chaque langue, comme je l’explique dans le guide du référencement multilingue.
Étape 7 : Réguler la maintenance et la mise en service
Définissez un rôle professionnel et responsable pour chaque type d'entité. Par exemple, l'équipe de direction pourrait être responsable des données organisationnelles, le responsable marketing de la marque et le responsable du site des horaires d'ouverture et des moyens de contact locaux.
Un processus de maintenance clair suffit à de nombreuses PME :
- Une modification est demandée.
- La personne responsable vérifie l'exactitude technique.
- Des variantes linguistiques sont ajoutées ou mises à jour.
- Les données seront publiées.
- Le site web et les autres canaux adopteront la version publiée.
- Les modifications et les dates des tests sont documentées.
Modèle de données d'entité : Exemple d'une entreprise du Tyrol du Sud
Le modèle de données d'entités simplifié ci-dessous représente une entreprise artisanale multilingue fictive. Cet exemple ne constitue pas un modèle de production complet, mais plutôt un point de départ pour la modélisation individuelle.
Les ensembles de données centraux
- Organisation org-0001 : Alpenwerk Holz GmbH, dont le siège social est situé à Bolzano.
- Marque-0001 : Alpenwerk, géré par org-0001.
- Emplacement place-0001 : L'atelier Bolzano appartient à org-0001.
- Emplacement place-0002 : Showroom Merano, appartient à org-0001.
- Personne personne-0001 : Maria Huber, directrice générale et responsable du conseil.
- Service service-0001 : Conception d'intérieur personnalisée, ou "Arredamento su misura", proposée par org-0001.
- Produit product-0001 : Série de meubles Larix, proposée sous la marque-0001.
- Référence référence-0001 : Conception intérieure de l'hôtel Bergblick, service occupé-0001.
- Méthode de contact contact-0001 : Adresse e-mail générale pour l'allemand et l'italien.
- Méthode de contact contact-0002 : Numéro de téléphone du showroom de Merano pendant les heures d'ouverture locales.
Une entrée d'entité pour le service
{
"id": "service-0001",
"canonicalName": {
"de": "Innenausbau nach Maß",
"it": "Arredamento su misura"
},
"provider": "org-0001",
"availableAt": ["place-0001", "place-0002"],
"responsiblePerson": "person-0001",
"references": ["reference-0001"],
"sourceSystem": "company-content",
"status": "approved",
"reviewedAt": "2026-02-15"
}L'ensemble de données distingue l'identité, la langue et le lien de parenté. La correction du nom italien ne modifie ni l'identifiant stable ni le lien avec l'organisation, la personne ou les lieux.
Quelle entité a besoin de sa propre page ?
Toutes les entités du modèle de données n'ont pas besoin d'une URL publique. La décision dépend des avantages pour les utilisateurs, les moteurs de recherche et les processus métier.
Page personnelle
Une page dédiée est utile si l'entité a sa propre intention de recherche distincte, un contenu suffisant et une prochaine étape clairement définie. Exemples typiques :
- Profil de l'organisation ou de l'entreprise
- marque importante
- Un lieu avec ses propres horaires d'ouverture et services
- performance clé
- Produit nécessitant une explication
- références exhaustives
- expert d'intérêt public
Module de contenu réutilisable
Un module de contenu est adapté aux informations qui doivent figurer sur plusieurs pages. Il peut s'agir des personnes à contacter, des horaires d'ouverture, des coordonnées, d'une brève description des services, d'un plan d'accès et d'informations sur la marque.
Le module ne contient pas de copie gérée manuellement. Il accède au même enregistrement d'entité partagé.
Seuls les ensembles de données structurés
Certaines entités restent en arrière-plan. Un canal de contact technique, une responsabilité interne ou une variante de nom archivée peuvent ne pas nécessiter de page visible. L'enregistrement des données demeure pertinent car il documente les relations, les approbations et l'origine de l'information.
Du modèle de données d'entités à JSON-LD et Schema.org
Le modèle de données d'entités interne et JSON-LD ont des finalités différentes. Le modèle de données d'entités organise les connaissances de votre entreprise. JSON-LD est un format de sortie qui permet de rendre disponibles des informations sélectionnées, lisibles par machine, sur un site web.
Schema.org fournit des types et des propriétés à cet effet. Par exemple, une organisation interne peut être représentée par ` Organization` , une personne par ` Person` , un lieu par ` Place` , un service par ` Service` , un produit par ` Product` et un moyen de contact par ` ContactPoint` . Il convient de déterminer les types et propriétés appropriés dans un cas précis en examinant l'ensemble des données.
L'identifiant interne « org-0001 » peut être traduit en un identifiant web unique. L'exemple JSON-LD abrégé suivant illustre la logique de base :
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.alpenwerk.example/#organization",
"name": "Alpenwerk Holz GmbH",
"brand": {
"@type": "Brand",
"@id": "https://www.alpenwerk.example/#brand",
"name": "Alpenwerk"
},
"location": [
{
"@id": "https://www.alpenwerk.example/standorte/bozen/#place"
},
{
"@id": "https://www.alpenwerk.example/standorte/meran/#place"
}
],
"contactPoint": {
"@type": "ContactPoint",
"@id": "https://www.alpenwerk.example/#contact-general",
"contactType": "customer service",
"availableLanguage": ["de", "it"]
}
},
{
"@type": "Service",
"@id": "https://www.alpenwerk.example/leistungen/innenausbau/#service",
"name": "Innenausbau nach Maß",
"provider": {
"@id": "https://www.alpenwerk.example/#organization"
}
}
]
}L' attribut @id permet de lier des objets associés sans répéter les mêmes informations à chaque page. Google explique comment lier des éléments associés, marqués séparément, sur une même page grâce à @id . Cela n'implique pas l'obligation d'utiliser des identifiants uniques sur plusieurs pages. Source : Google Search Central.
Pour votre architecture, les identifiants web permanents restent utiles si plusieurs pages ou systèmes référencent la même entité. Ce choix repose sur votre modèle de données d'entités et non sur une tentative de reproduire le format d'un moteur de recherche.
Avant et après : Ce que change le modèle de données d'entité
Auparavant : les informations étaient mises à jour page par page.
- Le nom de l'entreprise apparaît sous plusieurs orthographes différentes sur le site web.
- Les horaires d'ouverture sont modifiés séparément dans le pied de page, sur la page de contact et sur la page de localisation.
- Les versions allemande et italienne existent en tant que copies largement indépendantes du contenu.
- Une personne qui quitte l'entreprise reste visible comme personne de contact dans les anciennes références.
- JSON-LD contient des valeurs différentes de celles affichées dans le contenu de la page.
- Il n'est pas précisé quelle version fait foi.
Ensuite : les entités fournissent les valeurs de liaison.
- L'organisation et la marque possèdent chacune une identité stable et un nom canonique.
- Chaque établissement gère sa propre adresse, ses horaires d'ouverture et ses moyens de contact.
- Les valeurs neutres sur le plan linguistique sont conservées une seule fois ; les textes reçoivent des variantes linguistiques contrôlées.
- Les services sont associés à des prestataires, des personnes, des lieux et des références.
- Les composants de page et l'accès JSON-LD aux données d'entités partagées.
- Le système source et les responsabilités sont documentés pour chaque type d'entité.
D’après mon expérience, le principal avantage ne réside pas dans la structure technique, mais dans la clarté des processus : un changement est décidé une seule fois, vérifié une seule fois, puis mis en œuvre de manière cohérente.
Modèle de données d'entité : Liste de contrôle pour les PME
- L'organisation et la marque ont-elles des ensembles de données distincts si elles ne sont pas identiques ?
- Chaque entité importante possède-t-elle un identifiant stable ?
- Existe-t-il un nom canonique défini pour chaque entité ?
- Existe-t-il des documents sur les noms alternatifs et antérieurs ?
- Les personnes, les lieux, les services, les produits et les références sont-ils liés ?
- Existe-t-il un système source principal défini pour chaque domaine central ?
- Les valeurs neutres vis-à-vis de la langue et les valeurs dépendantes de la langue sont-elles séparées ?
- Chaque établissement a-t-il ses propres horaires d'ouverture et moyens de contact ?
- La responsabilité de l'installation, des essais et de l'homologation est-elle réglementée ?
- Existe-t-il un statut et une date pour la dernière inspection ?
- Le contenu visible et la sortie lisible par machine correspondent-ils ?
- Les entités archivées seront-elles conservées au lieu que leurs identifiants soient réutilisés pour de nouveaux objets ?
Questions et réponses sur le modèle de données d'entité
Quel format de carte d'identité convient à une PME ?
Un format simple et persistant comme org-0001 , place-0001 ou un UUID contrôlé est souvent suffisant. L'essentiel est que l'identifiant reste unique, ne soit pas traduit et soit conservé même après un changement de nom.
Chaque langue a-t-elle besoin de sa propre entité ?
Non. « Consulting en image de marque » et « Consulenza di marca » sont généralement des termes qui varient selon la langue pour désigner le même service. Les deux expressions linguistiques font donc référence au même identifiant unique, tandis que les textes, les URL et les métadonnées sont gérés séparément pour chaque langue.
Que se passe-t-il lorsqu'un nom est changé ?
Le nouveau nom canonique remplace l'ancien nom principal, tandis que l'identifiant stable reste inchangé. Il convient de documenter l'ancien nom comme une désignation alternative ou antérieure et de rediriger les URL concernées de manière contrôlée.
Chaque emplacement nécessite-t-il son propre ensemble de données ?
Oui, dès que l'adresse, les horaires d'ouverture, le mode de contact, les services proposés ou le secteur de responsabilité diffèrent. Un enregistrement de localisation distinct empêche la transmission accidentelle d'informations locales à toutes les succursales.
Qui devrait être responsable des données de l'entité ?
La responsabilité incombe à la personne possédant les compétences techniques requises, et non automatiquement à l'administrateur du site web. La direction peut diffuser les données organisationnelles, tandis que les administrateurs du site sont responsables des horaires d'ouverture et des informations de contact locales.
À quelle fréquence les entreprises doivent-elles être auditées ?
Les données susceptibles d'évoluer, telles que les personnes de contact, les horaires d'ouverture et les moyens de contact, doivent être vérifiées après chaque modification importante et à intervalles réguliers. Pour les données de référence stables, un contrôle annuel documenté constitue une pratique courante qui doit être adaptée à chaque activité.
Un modèle de données d'entités est-il identique à des données structurées ?
Non. Le modèle de données d'entités représente l'organisation interne des connaissances de votre entreprise, tandis que les données structurées constituent une sortie sélectionnée et lisible par machine pour le site web. Un balisage JSON-LD techniquement correct ne peut compenser durablement un modèle de données interne inadéquat.
Une petite entreprise a-t-elle vraiment besoin d'un logiciel complexe pour cela ?
Non. Une petite ou moyenne entreprise (PME) peut démarrer avec une structure de données maîtrisée, des identifiants uniques et des responsabilités clairement définies. Le choix du logiciel n'intervient qu'une fois les entités, les sources, les langages et les processus de maintenance clarifiés par des professionnels.
D’abord le modèle de données d’entité, puis l’automatisation.
Un modèle de données d'entités n'est pas une fin en soi. Il doit permettre à votre entreprise de gagner du temps, de réduire les erreurs et de fournir des informations fiables aux personnes comme aux machines.
Par conséquent, ne commencez pas par JSON-LD, les plugins ou l'automatisation par IA. Commencez par les réalités concrètes de votre entreprise : quelle est la structure juridique de votre activité ? Quelle marque utilisez-vous ? Qui est responsable de quel service ? Quels services propose chaque point de vente ? Quel canal de contact est utilisé pour quel objectif ?
Une fois ces questions résolues, nous pourrons les intégrer à notre stratégie web et à notre développement technique afin de concevoir un système fiable de gestion et de réutilisation du contenu. Il en résultera une réduction de la duplication du contenu, des responsabilités mieux définies et une information cohérente pour les clients, les moteurs de recherche et les systèmes d'IA.
