Le 19 août 2026, la première page de résultats française de « knowledge panel » compte neuf résultats organiques. Six d'entre eux parlent du panel de sondage d'Ipsos, une solution d'études de marché : la page de connexion en rang 1, la fiche solution sur ipsos.com en rang 2, la page d'accueil du panel en rang 3, le portail membres en rang 4, la page à propos en rang 6, l'application sur Google Play en rang 7. Trois seulement parlent de la fonctionnalité de Google : Peak Ace en rang 5, la documentation officielle de Google en rang 8, SEO Supernova en rang 9.
Le terme qui désigne l'encadré par lequel Google affiche son identification des entités est donc, sur sa propre page de résultats, majoritairement attribué à une autre entité. Et Google classe sa propre documentation en rang 8, derrière les six pages du panel de sondage.
Ce n'est pas une anecdote de mot-clé. C'est le sujet même de cet article, observable en position zéro : deux organisations portent le même nom, aucune des deux n'a tort, et le moteur doit trancher. Un moteur à dix liens bleus tranche en montrant les deux. Un moteur génératif ne peut pas.
Ce que j'ai mesuré le 19 août 2026. J'ai relevé la page de résultats de « knowledge panel » en France et en français, récupéré le texte des neuf pages classées pour y chercher toute phrase reliant l'identité d'entité aux moteurs génératifs, interrogé l'API publique de Wikidata pour compter combien d'entités portent le même nom que dix-huit marques françaises connues, envoyé la même question à un modèle de langage sur quatre de ces marques pour observer ce qu'il fait de l'homonymie, et relu ce que Google publie sur la désambiguïsation des organisations. Les deux mesures sont reproductibles, les API sont publiques et gratuites.
Sur les neuf pages classées, le corpus utile fait 230 phrases de plus de quarante caractères. Le motif de sujet (entité, knowledge panel, knowledge graph, désambiguïsation, sameAs, Wikidata) apparaît dans 79 d'entre elles : ces pages parlent bien du sujet. Le motif des moteurs génératifs apparaît dans 2 phrases seulement, et les deux sont du mobilier d'interface chez Peak Ace, un menu d'agence et une rangée de boutons de partage listant ChatGPT et Perplexity à côté de WhatsApp. Aucune phrase de corps rédactionnel, sur les neuf pages, ne relie l'identification d'une entité au fonctionnement des moteurs génératifs.
Ce que Google publie sur la désambiguïsation des organisations
La documentation du balisage Organization est plus explicite que sa réputation. Sa phrase d'ouverture : « Adding organization structured data to your home page can help Google better understand your organization's administrative details and disambiguate your organization in search results. »
Le mot est posé par Google, et il est posé comme la finalité du balisage. La phrase suivante va plus loin en nommant les propriétés concernées : « Some properties are used behind the scenes to disambiguate your organization from other organizations (like iso6523 and naics), while others can influence visual elements in Search results (such as which logo is shown in Search results and your knowledge panel). »
Deux familles de propriétés, donc, et une distinction que la littérature française sur le knowledge panel ne fait presque jamais. Les propriétés visibles agissent sur l'apparence du résultat, logo en tête. Les propriétés invisibles agissent sur l'identification, et Google en nomme deux : iso6523, un identifiant normalisé d'organisation, et naics, le code de la nomenclature d'activités nord-américaine. Ce sont des identifiants administratifs, pas des éléments de marque.
Le détail du champ iso6523Code mérite d'être lu, parce qu'il est rarement expliqué. Un identifiant ISO 6523 se compose de deux parties : un ICD, pour International Code Designator, qui déclare quel schéma d'identification est utilisé, puis l'identifiant lui-même, les deux séparés par un deux-points. Google donne trois valeurs d'ICD courantes : 0060 pour le numéro DUNS de Dun & Bradstreet, 0088 pour le Global Location Number de GS1, 0199 pour le Legal Entity Identifier défini par l'ISO 17442. La documentation recommande d'ailleurs explicitement ce champ plutôt que les champs dédiés : sur duns comme sur leiCode, elle écrit « We encourage using the iso6523Code field with prefix 0060: instead » et « with prefix 0199: instead ».
Observation à faire pour un lecteur français : les trois schémas nommés par Google sont internationaux, et aucun n'est le SIREN. Cela ne veut pas dire qu'un identifiant français ne peut pas être déclaré, cela veut dire que la documentation ne le documente pas, et qu'il faut donc s'appuyer sur les schémas qu'elle nomme si l'on veut rester dans le périmètre décrit.
La documentation grand public des knowledge panels ajoute le cadre général : « Knowledge panels are information boxes that appear on Google when you search for entities (people, places, organizations, things) that are in the Knowledge Graph. » Et la phrase qui refroidit les ardeurs : « Knowledge panels are automatically generated, and information that appears in a knowledge panel comes from various sources across the web. » Le panneau n'est pas un formulaire à remplir. Une nuance existe toutefois, et elle est utile : « We also know that entities whose information is included in knowledge panels (like prominent individuals or the creators of a television show) are self-authoritative, and we provide ways for these entities to provide direct feedback. »
Même geste que d'habitude sur la documentation « AI features and your website », celle qui décrit les surfaces génératives de Google. Sur la page entière, balises et menu de navigation compris : entity 0, entities 0, knowledge graph 0, knowledge panel 0, disambiguation 0, sameAs 0, brand 0. Sept termes, sept zéros. Contrôle de sanité sur le même fichier, pour vérifier que la mesure n'est pas un artefact d'extraction : « AI Overviews » y apparaît 14 fois et « structured data » 11 fois.
Ce zéro se lit dans les deux sens, comme toujours. Il ne prouve pas que l'identification d'entité est sans effet sur les réponses génératives de Google. Il établit que Google ne présente nulle part l'identité d'entité comme une clé d'entrée dans ses surfaces IA, alors que la documentation Organization, elle, nomme la désambiguïsation en toute première phrase. Les deux documents parlent de deux mondes que Google ne relie pas publiquement.
Pourquoi dix liens bleus tolèrent l'ambiguïté et pas une réponse générée
Voici le mécanisme, et c'est le coeur du sujet.
Une page de résultats classique est un objet pluriel. Quand deux entités portent le même nom, elle peut afficher les deux et laisser l'arbitrage au lecteur, qui dispose du contexte que le moteur n'a pas : il sait, lui, s'il cherche un panel de sondage ou une fonctionnalité de Google. C'est exactement ce que fait la page de résultats de « knowledge panel » relevée en ouverture. Le moteur n'a pas tranché. Il a servi six pages d'une entité et trois d'une autre, et il a délégué.
Une réponse générative est un objet singulier. Elle ne peut pas servir six phrases sur une entité et trois sur une autre sans devenir incohérente. Elle doit choisir une entité, puis rédiger comme si le choix allait de soi. Et surtout, elle ne montre pas qu'elle a choisi. Le lecteur reçoit une réponse assurée, sans la trace de l'arbitrage qui l'a produite.
Cette différence a une conséquence directe sur la façon dont l'homonymie vous coûte quelque chose. En référencement classique, porter un nom ambigu coûte des positions : vous partagez la page avec vos homonymes. Dans un moteur génératif, porter un nom ambigu produit l'un de trois résultats, et deux sont mauvais. Soit le moteur vous identifie et répond sur vous. Soit il identifie votre homonyme et répond sur lui, avec aplomb, sans signaler l'erreur. Soit il n'arrive pas à trancher et refuse de répondre.
Le troisième cas est le plus intéressant, parce qu'il est le seul mesurable de l'extérieur sans connaître la vérité terrain. C'est ce que j'ai testé plus bas.
Un mot sur l'étage de récupération, qui vient s'ajouter au problème et qui a déjà été décrit ici : la recherche de passages travaille sur des chaînes de caractères et sur des vecteurs, pas sur des identités. Une requête contenant votre nom de marque ramène des passages contenant cette chaîne, quelle que soit l'entité dont ils parlent. Comme chaque passage est évalué pour lui-même, hors du document qui le portait, rien dans le passage ne dit à quelle entité il se rapporte si le passage ne le dit pas lui-même. C'est le même raisonnement que celui qui rend un titre de section inutile s'il ne se suffit pas une fois détaché, appliqué cette fois à l'identité plutôt qu'au sujet.
Combien d'entités portent déjà le nom de votre marque
Wikidata expose une API publique, sans clé et sans compte, qui répond à la question. Le point d'entrée wbsearchentities renvoie les entités dont le libellé correspond à une chaîne, dans la langue demandée.
curl -s "https://www.wikidata.org/w/api.php?action=wbsearchentities\
&search=Alan&language=fr&uselang=fr&limit=50&format=json&type=item"
J'ai passé dix-huit marques françaises connues dans cette requête, puis compté, pour chacune, le nombre d'entités dont le libellé est exactement le nom de la marque, casse ignorée. Huit des dix-huit noms sont portés par plus d'une entité.
Les trois cas les plus chargés sont éloquents. Pour « Orange », 31 entités portent exactement ce libellé, et l'opérateur de télécommunications (Q1431486) arrive en quatrième position du classement propre à Wikidata, derrière la commune du Vaucluse, une ville du Texas et une ville du New Jersey. Pour « Free », 16 entités, et l'opérateur français (Q2467627) arrive en douzième position, derrière un groupe de musique britannique, un nom de famille, un album de Dana International et une chanson de Stevie Wonder. Pour « Alan », 13 entités, et l'assureur santé français (Q54880786) arrive en vingt-deuxième position, derrière un prénom masculin, une commune de Haute-Garonne, un nom de famille et quatre localités turques.
À l'autre bout, les marques créées récemment avec un nom inventé ne rencontrent pas ce problème. Doctolib renvoie deux résultats au total, dont un seul portant le libellé exact, et c'est l'entreprise. Swile, PayFit, Back Market, Leboncoin : une seule entité au libellé exact, en première position.
label entites portant rang de l'entite
ce label exact entreprise
Orange 31 4
Free 16 12
Alan 13 22
Doctolib 1 1
Swile 1 1
Précision de méthode nécessaire, parce que la lecture inverse serait fausse : ce classement est celui de la recherche interne de Wikidata, pas celui d'un moteur de recherche ni d'un moteur génératif. Il ne mesure pas ce que ChatGPT ou Google font de ces noms. Il mesure une chose plus modeste et plus solide : combien de candidats existent, dans la base d'entités ouverte la plus utilisée, pour un nom donné. C'est le dénominateur du problème, pas son résultat.
Ce dénominateur suffit pourtant à poser une question utile en réunion : combien d'entités documentées portent déjà le nom que le service marketing vient de choisir. La commande ci-dessus y répond en une seconde, avant le dépôt de marque.
Le test : la même question, quatre marques, un moteur
Compter les homonymes ne dit pas ce qu'un moteur en fait. J'ai donc envoyé la même question, dans la même forme, à propos de quatre marques dont l'ambiguïté mesurée diffère. La question est volontairement pauvre en indices : « Combien coûte X par mois ? » Elle ne dit pas que X est une entreprise, ne donne pas de secteur, ne donne pas de pays. Elle ressemble à ce qu'un utilisateur tape vraiment.
Modèle interrogé : GPT-4.1 mini, sans recherche web, le 19 août 2026. Le choix de couper la recherche web est délibéré : il isole ce que le modèle sait des entités de ce qu'il pourrait aller chercher, et c'est la couche où la confusion d'entité se joue en premier.
marque homonymes reponse du modele
Alan 13 demande de precision
Free 16 repond : operateur telecom
Doctolib 1 repond : prise de rendez-vous
Swile 1 repond : titres-restaurant
Sur les quatre, une seule question est restée sans réponse, et c'est celle qui portait sur la marque la plus ambiguë. Le modèle a répondu : « Pour pouvoir vous répondre précisément, pourriez-vous me préciser de quel Alan vous parlez ? Par exemple, s'agit-il d'une assurance santé Alan, d'un abonnement à un service ou autre chose ? »
Le refus est instructif à deux titres. D'abord parce qu'il est explicite : le modèle nomme l'ambiguïté au lieu de la masquer, ce qui est le meilleur des trois cas décrits plus haut. Ensuite parce qu'il est coûteux. Une question commerciale, posée par quelqu'un qui envisage d'acheter, revient sans réponse et avec une demande de travail supplémentaire adressée à l'utilisateur. Dans une page de résultats, la même personne aurait vu une liste et cliqué. Ici, elle doit reformuler.
Deux vérifications complémentaires confirment que le nom seul est bien la variable. Interrogé sur « Alan : de quoi s'agit-il ? », le modèle demande également une précision. Interrogé avec un indice de type minimal, « Que fait l'entreprise Alan ? », il répond correctement et en détail : assurance santé numérique, siège à Paris, plusieurs centaines de collaborateurs, présence en Espagne et en Belgique. Deux mots, « l'entreprise », suffisent à débloquer la réponse. C'est précisément le travail que l'homonymie fait porter à l'utilisateur.
Ce que ce test ne prouve pas
Le résultat le plus honnête de cette série est celui de Free, et il contredit la lecture simple.
Free porte 16 homonymes au libellé exact, davantage qu'Alan, et son entité d'entreprise est mal classée dans Wikidata, en douzième position derrière un groupe de rock. Sur le papier, c'est le cas le plus ambigu du lot. Le modèle a pourtant répondu sans hésiter, et sur le bon opérateur, avec des tarifs de forfaits mobiles et de Freebox.
L'ambiguïté du nom ne prédit donc pas l'échec à elle seule. La variable qui sépare Free d'Alan n'est pas le nombre d'homonymes, c'est la notoriété : un opérateur télécom présent depuis des décennies dans la presse et les forums français occupe tellement de place dans les données que la question « combien coûte Free par mois » n'a en pratique qu'une lecture plausible. L'homonymie coûte quelque chose à ceux qui ne sont pas déjà écrasants sur leur nom.
Ce qui, pour la plupart des entreprises qui liront ceci, est exactement le cas.
Les autres limites doivent être posées franchement. Quatre marques ne font pas un échantillon, et une exécution par marque ne fait pas une mesure stable : la même question reposée peut donner une autre réponse. Un seul modèle a été interrogé, dans une seule de ses configurations, un seul jour. La recherche web était désactivée, ce qui exclut la couche de récupération et ne dit donc rien de ce que ferait le même modèle branché sur le web. Et le sens de la causalité n'est pas établi : notoriété, ancienneté, clarté du modèle économique et ambiguïté du nom varient ensemble sur ces quatre cas, sans qu'aucun ne soit isolé.
Ce test est donc une observation reproductible, pas une démonstration. Établir une causalité demanderait le dispositif déjà décrit ici pour le GEO : un plan d'expérience avec groupe témoin, dont le avant-après n'est pas un. Le protocole minimal serait de faire varier le seul nom, à notoriété constante, ce qu'aucune marque réelle ne permet.
Ce que sameAs fait, et ce que Google en dit de moins
Il existe une propriété faite exactement pour ce problème, et sa définition officielle est sans ambiguïté sur son intention. Schema.org définit sameAs ainsi : « URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website. » La page indique par ailleurs un usage mesuré par Google sur son index web en juillet 2026 : plus de dix millions de domaines.
L'adverbe compte : unambiguously. Dans le vocabulaire de schema.org, sameAs n'est pas un champ de liens sociaux, c'est une déclaration d'identité, et les exemples donnés sont Wikipedia, Wikidata et le site officiel.
La documentation de Google est nettement plus tiède sur la même propriété. Dans le tableau des propriétés d'Organization, sameAs est décrit ainsi : « The URL of a page on another website with additional information about your organization, if applicable. For example, a URL to your organization's profile page on a social media or review site. »
L'écart entre les deux définitions vaut d'être noté sans être surinterprété. Schema.org parle d'identité et cite Wikidata ; Google parle d'informations complémentaires et cite les réseaux sociaux et les sites d'avis. Ce n'est pas une contradiction, Google restant libre de documenter l'usage qu'il fait d'un vocabulaire tiers. Mais cela signifie que la lecture « je remplis sameAs, donc je suis identifié » ne s'appuie sur aucun engagement de Google. Le seul endroit où Google promet un effet de désambiguïsation, ce sont les identifiants administratifs cités plus haut, et il le formule comme une aide, pas comme une garantie.
Cette prudence est la même que celle qui s'impose sur l'ensemble du balisage schema.org côté GEO, et pour la même raison de fond : le balisage n'est pas le mécanisme, il est une déclaration que le mécanisme peut lire ou ignorer. Rappel de méthode déjà posé ici : une étude qui teste l'ajout d'un balisage ne démontre rien sur son retrait.
L'API Knowledge Graph, et l'avertissement qu'elle porte
Google expose une API de recherche dans son graphe de connaissances, qui permet de vérifier si une entité y figure et sous quel identifiant. Elle est toujours en ligne et documentée.
Deux réserves figurent dans sa propre documentation, et elles sont à connaître avant d'en faire un outil de suivi. La première est un avertissement en toutes lettres : « This API is not suitable for use as a production-critical service. Your product should not form a critical dependence on this API. » La seconde est une orientation de migration : « we are migrating this API to Cloud Enterprise Knowledge Graph », avec la consigne, pour les nouveaux venus, d'utiliser directement le produit Cloud plutôt que cette API.
L'API reste donc utile pour un contrôle ponctuel, et déconseillée comme brique de tableau de bord. Ce qui rejoint ce qui a déjà été écrit ici sur la mesure de la visibilité générative et son bruit de fond : les instruments disponibles sont incomplets, et le premier travail consiste à savoir ce que chacun ne mesure pas.
La checklist de cohérence d'entité pour une marque
Rien de ce qui suit ne garantit un knowledge panel, et la documentation de Google est claire sur ce point, ces encadrés sont générés automatiquement. Ce qui suit réduit le nombre de lectures possibles de votre nom.
Vérifier le dénominateur avant de nommer. La requête Wikidata donnée plus haut, sur le nom envisagé, avant le dépôt. Trente et un homonymes documentés se voient en une seconde et se corrigent difficilement après cinq ans de communication.
Déclarer les identifiants administratifs. iso6523Code, avec l'un des ICD nommés par Google, et naics le cas échéant. Ce sont les deux propriétés que Google associe explicitement à la désambiguïsation, et ce sont celles que presque personne ne remplit.
Traiter sameAs comme une déclaration d'identité. Au sens de schema.org : la page Wikipedia si elle existe, l'entrée Wikidata, le site officiel, puis les profils. Pas une liste de réseaux sociaux à laquelle on ajoute le reste.
Fixer un nom et un seul. name pour le nom officiel, alternateName pour l'acronyme ou le nom commercial. La documentation Organization demande d'ailleurs d'utiliser le même nom que celui du site.
Faire cohabiter le nom et la catégorie dans le texte. C'est la contrepartie rédactionnelle du test ci-dessus. Si deux mots, « l'entreprise Alan », suffisent à débloquer une réponse, alors les passages de votre site ont intérêt à porter cette apposition plutôt que le nom nu. « Alan, assureur santé » est un passage autoportant ; « Alan » ne l'est pas. Le principe est le même que pour une ancre de lien interne, qui doit rester lisible hors de son contexte.
Se rappeler que l'essentiel se joue ailleurs que chez vous. Les mentions qui vous identifient sont majoritairement hors de votre domaine, comme l'ont montré les signaux d'autorité qui ne survivent pas à l'extraction et le poids des plateformes tierces dans ce qui est cité. Une fiche Wikidata correcte, des mentions presse qui accolent le nom et le métier, des avis dont le verbatim circule : ce sont des passages que vous n'écrivez pas mais qui portent votre identité.
Vérifier que le contenu est lisible sans exécution. Rappel utile, une fiche d'identité rendue en JavaScript n'existe pas pour les moteurs en récupération directe, ce que le test de rendu décrit ici permet de contrôler en une commande.
Ce qu'il faut retenir
Le nom de votre marque n'est pas un identifiant. C'est une chaîne de caractères que plusieurs entités peuvent porter, et Wikidata donne gratuitement le nombre de concurrents sur cette chaîne.
En référencement classique, l'homonymie coûte des positions et le lecteur arbitre. Dans une réponse générative, il n'y a pas d'arbitrage visible : le moteur choisit une entité et rédige, ou renonce et vous renvoie la question. Sur la petite série testée ici, le renoncement n'a frappé qu'une marque sur quatre, et pas la plus ambiguë sur le papier, ce qui indique que la notoriété absorbe une partie du problème. Elle l'absorbe pour Free. Elle ne l'absorbera pas pour vous.
Le travail utile n'est donc pas de réclamer un knowledge panel, que Google génère automatiquement et ne promet à personne. Il est de réduire le nombre de lectures possibles de votre nom : identifiants administratifs déclarés, sameAs traité comme une déclaration d'identité, et surtout des passages où le nom ne circule jamais seul. Le moteur ne devine pas votre catégorie. Il la lit, ou il ne la lit pas.
Si vous voulez savoir ce que les moteurs génératifs disent aujourd'hui de votre marque et de ses homonymes, c'est l'un des points examinés dans un audit GEO. Et pour la vue d'ensemble des différences de mécanisme entre les deux disciplines, la comparaison entre SEO et GEO reprend le sujet de plus haut.