Wikidata et sameAs : comment les IA reconnaissent votre entreprise

Quand une IA lit une page qui nomme « Simafri », elle doit décider de quelle entité il s'agit. Si le nom est seul, rien ne l'y aide : elle rapproche ce qu'elle trouve sous ce nom, et quand deux entités le partagent, elle répond avec la réputation de l'homonyme. Ce que vous pouvez lui donner, c'est un graphe : un identifiant stable, des pages qui le déclarent, et des profils qui renvoient les uns vers les autres.

Ce guide montre comment le poser, sur un cas réel : le site de Simafri, un prestataire informatique des PME, relevé le 14 septembre 2026, avant et après correction.

Trois pièces, et le lien qui les boucle

• L'élément Wikidata : un identifiant stable (la lettre Q suivie d'un numéro) et des propriétés sourcées, dont le site officiel (P856), l'identifiant GitHub (P2037), l'identifiant LinkedIn (P4264), le fondateur (P112) et la date de création (P571). C'est la base de connaissances ouverte où une entité se documente, relue et corrigée par des tiers.
• Le nœud Organization de votre site : le bloc JSON-LD qui décrit l'entreprise, avec son @id, son nom, son adresse, et la propriété sameAs, qui liste les pages dont vous affirmez qu'elles sont vous.
• Vos profils : GitHub, LinkedIn, un annuaire, un espace de publication. Chacun porte la même description et un lien vers le site.

Aucune pièce ne prouve rien seule : n'importe qui peut écrire un sameAs vers un élément Wikidata, et n'importe qui peut créer un élément. Ce qui lève l'ambiguïté, c'est la boucle : le site déclare l'élément Wikidata et les profils, l'élément déclare le site et les profils, et les profils renvoient au site. Un lien dans un seul sens reste une affirmation ; dans les deux sens, il devient une identification.

L'exemple de Simafri, relevé le 14 septembre 2026

Le côté Wikidata était déjà posé. L'élément Q140183772 déclare le site www.simafri.com, l'organisation GitHub simafri, la page LinkedIn simafri, le fondateur et l'année 2012.

Le site, lui, ne renvoyait pas. Sur ses 856 pages publiées, 137 définissaient le nœud Organization de Simafri, et chacune lui donnait un seul sameAs : une page Facebook. Wikidata pointait vers le site, le site ne pointait pas vers Wikidata. L'organisation GitHub n'avait pas de description, et le README de son profil présentait un seul des quatre produits de l'entreprise.

Le nœud, tel que le site le sert depuis :

{
  "@type": "Organization",
  "@id": "https://www.simafri.com/en/#organization",
  "name": "Simafri",
  "url": "https://www.simafri.com/en/",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q140183772",
    "https://github.com/simafri",
    "https://www.linkedin.com/company/simafri/",
    "https://markleex.com/@simafri",
    "https://www.facebook.com/simafri.web"
  ]
}

Pourquoi le trou revient tout seul

Le défaut de Simafri n'était pas un oubli sur une page : c'était 137 copies du même oubli. Sur un site statique, chaque page porte souvent son propre bloc JSON-LD, écrit à la main puis recopié d'une page à l'autre. Une page neuve recopiée d'une ancienne reprend son sameAs, trou compris, et rien ne le signale : la page s'affiche, les liens répondent.

Deux parades, selon votre site. Soit le nœud est défini une seule fois, dans le gabarit, et chaque page y renvoie par son @id. Soit il reste recopié, et un contrôle au build refuse toute page dont le nœud oublie un profil. Simafri a pris la seconde : son build échoue désormais dès qu'une définition du nœud manque de l'un des quatre liens. Le contrôle a été vu échouer sur l'ancienne version (137 fautes), puis passer sur la nouvelle.

Ce que sameAs ne fait pas

sameAs ne liste que des pages qui sont l'entreprise : ses profils officiels, les pages dont elle tient la plume. C'est la ligne qui sépare vos surfaces des corroborations. Un article de presse, un avis, une liste où vous figurez parlent de vous ; ils ne sont pas vous, et ils n'ont pas leur place dans sameAs.

Il ne fait pas non plus recommander. Il dit à un moteur qui vous êtes ; ce qu'il dira de vous dépend toujours de ce que disent les pages, les vôtres et celles des autres. L'identification est la condition, elle ne remplace ni le contenu ni les tiers.

Une seule description, partout

Une boucle d'identification tient mieux quand chaque maillon dit la même chose. Simafri a posé sur GitHub la phrase même de son site, « the technical ally of SMBs: websites, email, management software and custom applications, created, hosted and maintained since 2012 », et non une variante écrite pour l'occasion. Une description qui change d'un profil à l'autre donne au moteur trois versions à concilier, et c'est lui qui choisit.

Dans Epovest, cette description est le Canon du projet, et le registre Surfaces liste chaque page que vous tenez avec ce qu'elle doit en reprendre. Le profil GitHub et les deux pages d'annuaire de Simafri y ont été alignés sur le Canon le jour du relevé, cellule par cellule.

Vérifier votre boucle en dix minutes

1. Votre site : ouvrez le code source de l'accueil et cherchez "sameAs". La liste doit porter vos profils officiels et, si vous en avez un, votre élément Wikidata. Refaites-le sur une page intérieure : c'est souvent là que le trou se cache.
2. Wikidata : cherchez le nom de votre entreprise. Si un élément existe, vérifiez le site officiel (P856) et les identifiants de vos profils. S'il n'existe pas, sa création suit des critères de notoriété : un élément se documente avec des sources.
3. Vos profils : chacun doit porter la même description et un lien vers le site.
4. Datez le geste dans le Logbook et suivez les mêmes questions dans Tracking : ce qui bouge ensuite se lit en face de ce que vous avez fait.

Méthode

Relevé du 14 septembre 2026. Le JSON-LD des 856 pages de simafri.com a été extrait de la sortie de build avant et après la correction ; l'élément Wikidata a été lu par l'API officielle de Wikidata ; les profils, sur leurs pages publiques. Les chiffres sont réutilisables avec attribution.