Quand sept personnes portent votre nom

Être invisible est un problème. Être pris pour un autre en est un plus grand — car celui qui lit ne sait pas que c'est faux.

Les moteurs de recherche peinent depuis des années à distinguer les personnes qui partagent un nom. La page de résultats le montre honnêtement : dix liens bleus appartenant à des personnes différentes, et c'est vous qui choisissez qui est qui.

Les réponses d'IA ont perdu cette honnêteté. Elles n'offrent pas dix options ; elles donnent une réponse. Et si, en la produisant, les données de plusieurs personnes se sont mêlées, il en sort une personne qui n'existe pas.

Un exemple concret

On a demandé à un moteur de recherche « qui est Murat Tunalı » — et le nom de domaine a été ajouté à la requête explicitement. Voici ce qui est revenu :

Murat Tunalı, né à İzmir en 1982, est un coiffeur pour hommes et un éducateur-écrivain. Alliant l'art classique du barbier à une approche moderne du soin, Tunalı exerce à Bursa comme coiffeur haut de gamme. Il est en outre spécialisé en conseil familial et propose des services de conseil à Istanbul.

Dans ce paragraphe se trouvent au moins trois personnes différentes : un coiffeur à Bursa, un auteur né à İzmir, un conseiller familial à Istanbul. Les trois existent. Les trois sont des personnes différentes. La réponse ne correspond à aucune.

Ce n'est pas une « hallucination » — rien n'a été inventé. Chaque phrase vient de quelque part. Le problème est la fusion : le modèle prend des fragments accrochés au même nom pour une seule identité.

Pourquoi cela arrive

Trois mécanismes se superposent.

Un nom n'est pas une identité. Pour un modèle de langue, « Murat Tunalı » est une chaîne de caractères ; ce qui la lie à une entité, c'est le contexte alentour. Si le contexte est faible, tout ce qui est accroché à la même chaîne se rassemble dans un seul bac.

La recherche ramène le plus proche, pas le plus juste. Une couche de recherche récupère les documents qui ressemblent à la requête. Les pages de sept personnes ressemblent toutes à la requête « Murat Tunalı ». Puis un modèle lit ces sept sources et écrit un seul résumé — et résumer, par nature, c'est fusionner.

Il se sent obligé de répondre. Une page de résultats classique peut dire « voici dix résultats ». Une interface de discussion a dû apprendre à dire « je ne sais pas », et ne le fait pas toujours.

Dans la même expérience, un autre moteur a fait l'inverse : il a dit ne « pas avoir pu atteindre un profil correspondant clairement à cette description » et a listé des suggestions au nom voisin. Mêmes données, comportement différent. La différence tient à la posture du produit face à l'incertitude.

Le plus lourd l'emporte

Ce qui détermine lequel des sept porteurs du nom compte comme « le » bon n'est pas l'exactitude, mais le poids mesurable.

Une mesure : combien d'enregistrements deux domaines homonymes détiennent dans l'archive ouverte d'exploration — l'une des sources qui alimentent les données d'entraînement des grands modèles de langage.

L'archive conserve en outre une série ininterrompue depuis 2007 : 158 instantanés. Livres publiés, pages d'auteur chez les libraires, une entrée de dictionnaire.

En face se tient un site d'un jour. Sa qualité de page est peut-être meilleure — données structurées impeccables, couche multilingue complète, terrain technique propre. Rien de tout cela ne compte. Si vous n'êtes pas dans le corpus, le modèle ne vous connaît pas.

La même mesure a produit une comparaison encore plus tranchante : un site de seulement 238 mots et sans aucune donnée structurée détenait seize enregistrements dans cette archive. La perfection sur la page ne produit pas de présence dans le corpus. L'âge et les mentions la produisent.

Pourquoi ce n'est pas un problème SEO ordinaire

Dans la recherche classique, le problème des homonymes est agaçant mais gérable : l'utilisateur regarde la liste et choisit le bon. S'il clique sur le mauvais résultat, il revient.

Dans une réponse d'IA il n'y a pas de retour. L'utilisateur lit l'unique réponse et poursuit. Si la réponse est fausse, il n'a même pas l'occasion de l'apprendre.

Quand un employeur, un client ou un journaliste se renseigne sur votre nom et que quelqu'un d'autre en sort, le coût relève d'une autre catégorie que « mauvais classement ». Être invisible vous retire de la liste ; être mal présenté vous inscrit sur la mauvaise liste.

Comment vous tester

Découvrir si ce problème est le vôtre prend une demi-heure et ne demande aucun outil.

Un — demandez votre nom. Posez à trois interfaces d'IA différentes la question « qui est X ». Lisez la réponse et marquez chaque phrase : laquelle vous appartient, laquelle non. S'il y a fusion, essayez de remonter à qui vient chaque partie ; on y arrive généralement.

Deux — ajoutez votre domaine à la requête. Dites « qui est X, [votre domaine] ». Si le moteur décrit encore quelqu'un d'autre, le problème dépasse la reconnaissance : il n'arrive pas à vous lier même quand on lui tend votre propre source.

Trois — demandez sans la marque. Sans citer votre nom, posez une question décrivant ce que vous faites et où. C'est votre vraie mesure de visibilité, indépendante du problème des homonymes. Si vos homonymes en sont absents aussi, c'est un terrain libre.

Quatre — regardez l'archive. Combien d'enregistrements votre domaine détient-il dans l'archive ouverte d'exploration, et combien celui de votre homonyme ? Le rapport entre ces deux nombres prédit bien quelle personne un modèle « connaîtra ».

Cinq — essayez la graphie fautive. Si votre nom porte des caractères propres à une langue (ı, ş, ğ, é, ñ, ö), demandez aussi la forme simple. La plupart des systèmes traitent les deux chaînes comme des entités distinctes.

Le résultat de ces cinq étapes n'est pas une liste mais un diagnostic : votre problème est-il l'invisibilité ou la mauvaise identification ? Les deux appellent des remèdes différents. L'invisibilité se résout avec le temps et les mentions. La mauvaise identification ne se résout pas — elle se gère.

Une erreur fréquente

La plupart de ceux qui entendent parler du problème des homonymes ajoutent d'abord des mots-clés : ils écrivent leur nom plus souvent sur la page, en remplissent les titres, le mettent trois fois dans la méta-description.

Cela ne marche pas, car le problème est le contexte, pas la fréquence. Ce dont un moteur a besoin pour distinguer, ce n'est pas combien de fois le nom apparaît, mais avec quoi il apparaît. Ville, métier, technologie, institution, date — voilà ce qui distingue. Un nom répété, non.

De fait, sur le site mesuré, c'était un constat que le nom n'apparaissait pas du tout dans le corps du texte ; mais la correction n'était pas « écris le nom dix fois ». Elle était « écris le nom une fois, avec le métier et la ville, dans une phrase à la troisième personne ».

Ce qui marche

Trois groupes de signaux vous distinguent dans une foule d'homonymes. Aucun ne suffit seul ; les trois agissent ensemble.

1. Séparation explicite dans les données structurées

Schema.org définit pour exactement cette tâche un champ, et la plupart des sites le laissent vide : disambiguatingDescription. Il a été conçu pour séparer des entités qui partagent un nom.

{
  "@type": "Person",
  "name": "Murat Tunalı",
  // Y compris la variante sans caractères particuliers
  "alternateName": ["Murat Tunali", "M. Tunalı"],
  "disambiguatingDescription":
    "Ingénieur systèmes à Istanbul construisant des applications web
     pilotées par l'IA ; sans lien avec les homonymes qui sont auteur
     en développement personnel ou conseiller familial.",
  "jobTitle": "Ingénieur systèmes",
  "knowsAbout": ["Applications web pilotées par l'IA", "Réseaux et sécurité"]
}

Ce champ n'est pas un signal de classement. Son rôle est de dire à un moteur, pendant qu'il tente de vous lier à une entité, quelle entité vous n'êtes pas.

2. Lien de profil bidirectionnel

Le champ sameAs liste vos profils. Mais une liste à sens unique est un signal faible : vous dites « voici mon GitHub », et GitHub ne le confirme pas.

Le bon montage est réciproque — du profil vers le site et du site vers le profil. Un lien à deux bouts appartient à une autre classe de preuve qu'une affirmation à un bout.

Écrire un sameAs que vous ne pouvez pas étayer nuit. Lister un profil qui n'existe pas, ou qui n'est pas le vôtre, ne renforce pas le graphe d'entités ; il le pollue.

3. Une phrase de définition dans le corps du texte

C'est ce que l'on oublie le plus souvent. Une page peut porter votre nom dans la balise <title> et dans les données structurées et ne jamais le mentionner dans le corps du texte.

Quand un modèle de langue découpe votre page en morceaux et les encode, ces morceaux sont tout ce dont il dispose. Si un morceau ne contient pas de nom, ce morceau ne répond pas à « qui est-ce ».

La solution tient en une phrase : troisième personne, une ligne, nom + métier + lieu. Elle peut se glisser sous le récit existant sans troubler le ton du texte.

Ce que ces trois partagent : aucun n'est une astuce de classement. Tous trois facilitent le travail que le moteur essaie déjà de faire — lier correctement l'entité.

Ce que je n'ai pas fait

Ce problème a une solution tentante mais fausse : ouvrir une fiche Wikidata.

Wikidata est l'ancre des graphes d'entités, et y figurer distingue réellement. Quand j'ai regardé pendant la mesure, le champ était entièrement vide — ni moi ni aucun des sept homonymes n'avait de fiche.

Elle n'a pourtant pas été ouverte. Wikidata a un seuil de notoriété, et un site d'un jour avec zéro mention indépendante et zéro œuvre publiée ne l'atteint pas. Une fiche forcée est supprimée et laisse une trace négative sur le domaine.

Le bon ordre est celui-ci : d'abord de vraies mentions s'accumulent dans des sources indépendantes, et ensuite la fiche devient défendable d'elle-même. Imiter le résultat d'un signal au lieu de le produire à la source corrige la mesure, mais pas la vérité.

Combien de temps

La réponse honnête : je ne sais pas, et personne ne sait.

Ce que l'on sait : les corpus d'entraînement se renouvellent périodiquement, les index de recherche se mettent à jour bien plus vite, et qu'une entité devienne « reconnue » dans un modèle dépend de l'accumulation des mentions. Dépasser en un trimestre un acteur installé depuis dix-huit ans n'est pas réaliste.

Ce qui est réaliste, c'est de changer de bataille. Le nom lui-même n'est pas une requête gagnable à court terme. Mais les composés « nom + attribut », et les requêtes de service où la marque n'apparaît pas du tout — voilà un terrain libre. Aucun des homonymes n'est sur ces requêtes.

Dans ma propre mesure, la métrique la plus précieuse n'était pas le taux de citation. C'était l'apparition dans les requêtes sans marque — car celui qui connaît votre nom vous cherche déjà ; le vrai gain est d'être trouvé par quelqu'un qui ne le connaît pas.

Il y a là quelque chose de rassurant. La foule d'homonymes vous enterre peut-être sur une requête, mais cette requête n'était de toute façon pas la plus précieuse. Celui qui cherche votre nom vous connaît le plus souvent déjà. Celui qui ne vous connaît pas n'écrit pas votre nom mais son problème — et sur ce terrain vous ne concourez pas contre sept personnes, vous concourez contre le sujet.