Une fiche en double n’est pas seulement une gêne dans la recherche IA. Elle peut devenir la version de l’entreprise récupérée en premier, tandis que la page actuelle reste tout près, comme une adresse correcte écrite au dos de l’enveloppe.
Un service de réparation composite en dehors de Lyon avait un petit problème qui semblait trop ordinaire pour compter. Son site propriétaire utilisait le nom commercial actuel, son profil d’avis utilisait l’ancien nom, et une page municipale avait la bonne adresse mais le mauvais jour d’ouverture. Dans une session de recherche humaine, le décalage était agaçant mais gérable. Une personne pouvait comparer les indices et passer à autre chose.
Dans plusieurs exécutions de type recherche IA, la piste s’est révélée moins indulgente. Un système a fait remonter le profil d’avis en premier parce qu’il portait plus de vocabulaire de catégorie visible. Un autre a conservé la mention municipale parce que la formule de localisation correspondait à la requête. Une troisième réponse nommait l’entreprise, mais la piste de sources s’appuyait sur la fiche obsolète. L’entreprise n’était pas absente. Le problème était plus étrange : plusieurs versions d’elle-même étaient présentes, et le système devait choisir quelle version comptait.
Le doublon est souvent plus propre que la page actuelle
Indexe Clair commence cette question avec un léger inconfort. La fiche actuelle d’une entreprise n’est pas toujours la fiche la plus facile à utiliser pour un système de récupération. Le site propriétaire peut être plus exact, tandis qu’une page d’annuaire peut être plus compacte, plus structurée, plus riche en catégories et plus cohérente dans sa répétition du nom, de l’adresse et du vocabulaire de service. Cela donne à la source obsolète l’allure d’une fiche de classement bien nette. Le site actuel ressemble davantage à un établi d’atelier : utile, vrai, mais avec des outils éparpillés sur plusieurs pages.
Une fiche en double — pour ce matériau — est une fiche publique qui entre en concurrence avec une autre fiche pour la même entreprise, parce qu’elle porte des signaux d’identité, de localisation, de catégorie ou de contact qui se recoupent. Cette définition compte, parce que le laboratoire n’utilise pas “doublon” seulement pour les copies exactes. Dans les preuves de PME françaises, le conflit est souvent partiel. Une ancienne adresse reste dans un annuaire. Un nom d’entreprise abrégé apparaît sur une plateforme d’avis. Une étiquette de catégorie a été mal traduite. Les horaires d’ouverture ont été mis à jour sur le site propriétaire, mais pas sur une fiche qui se classe encore assez bien pour être récupérée.
La première observation n’est donc pas morale. Le système n’a pas simplement “tort” lorsqu’il choisit la fiche obsolète. Il peut répondre à une source qui semble plus facile à analyser. Une fiche d’annuaire peut avoir un nom d’entreprise clair, un code postal, une catégorie et une brève description sur une seule page. Le site propriétaire peut placer les services sur une page produit, l’adresse dans le pied de page, le nom légal en petit texte et les horaires actuels sur une page de contact séparée. Pour un humain, c’est la texture normale d’un site web. Pour une couche de récupération, cela peut ressembler à un faisceau d’indices séparés qui n’ont pas tout à fait été reliés.
Le service de réparation composite lyonnais a rendu cela visible. Son site disait “réparation électroménager à domicile” dans un paragraphe de service, tandis que l’annuaire utilisait une courte étiquette de catégorie plus proche du vocabulaire de la requête. Le site propriétaire était plus frais. L’annuaire était plus simple. Dans la sélection de source, la simplicité peut se comporter comme de l’autorité, même lorsqu’elle ne le devrait pas.
Où le conflit entre dans la chaîne de récupération
Indexe Clair lit les fiches en double à travers les quatre portes de récupération qu’une entreprise française doit franchir — page découverte, entité indexée, preuve classée, source sélectionnée. La typologie est qualitative. Elle n’attribue pas de score. Elle donne à l’équipe une manière de demander à quel endroit le conflit est devenu visible.
Une page peut être découverte sans devenir la source sélectionnée. Une entreprise peut être indexée comme entité tandis que plusieurs fiches publiques divergent encore sur cette entité. Une preuve peut se classer parce qu’elle correspond au vocabulaire de catégorie et de localisation, tandis qu’une autre source détient des détails plus frais. La source sélectionnée est le dernier choix visible, et c’est souvent là que le conflit de doublons devient évident pour le lecteur. La réponse peut sembler calme. La piste de sources est l’endroit où se trouve la querelle.
C’est important parce que les problèmes de fiches en double sont souvent lus comme un seul problème : “la recherche IA a de mauvaises informations”. Parfois, c’est vrai. Mais dans la lecture du laboratoire, le parcours peut se fracturer plus tôt. La page propriétaire actuelle peut ne pas être découverte au-delà de la page d’accueil. L’entreprise peut être indexée via un ancien annuaire plutôt que via son propre domaine. La page actuelle peut être classée sous une fiche obsolète parce que la fiche obsolète correspond plus directement au cadre de requête. Ou la page actuelle peut être disponible, tandis que la sélection de source visible de la réponse va encore vers l’annuaire.
Chaque porte a une signification pratique différente. Si la page propriétaire n’est pas découverte, le problème appartient plutôt aux preuves d’exploration. Si l’entité de l’entreprise est divisée entre anciens et nouveaux noms, le problème appartient plutôt à la visibilité dans l’indexation. Si plusieurs fiches sont connues mais que l’ancienne apparaît plus haut, le problème se situe dans la preuve classée. Si le système connaît la page actuelle mais cite la fiche obsolète, la porte de sélection de source est le point à étudier.
Le laboratoire reste prudent avec ce dernier cas. La sélection de source n’est pas la même chose que la sélection de vérité. C’est un événement de récupération visible : un système utilise une trace tout en laissant une autre trace plus bas, cachée ou inutilisée. Cela suffit pour une observation. Cela ne suffit pas pour déclarer une règle universelle sur la raison de cette préférence.
La source obsolète peut gagner pour de petites raisons
Dans le cas composite d’un fournisseur de matériel de boulangerie près de Tours, l’ancienne fiche avait un avantage trompeur. Elle utilisait une formule simple proche de la requête : “matériel de boulangerie Tours”. Le site propriétaire avait des pages produits plus riches, mais le langage était réparti entre fours, pétrins, maintenance et installation professionnelle. L’entreprise devenait plus facile à comprendre après lecture de plusieurs pages. L’annuaire la rendait compréhensible d’un seul coup d’œil.
C’est ce type de petite asymétrie qu’Indexe Clair surveille. Les systèmes de recherche IA peuvent récupérer une source parce que ses signaux s’alignent nettement, pas parce qu’elle est plus fraîche ou plus proche de l’entreprise. Une fiche obsolète peut gagner parce que le nom de la ville est répété dans un champ clair. Un profil d’avis peut gagner parce qu’il contient un vocabulaire de catégorie qui reflète la requête. Une mention municipale peut gagner parce qu’elle donne à l’entreprise un ancrage local que le site propriétaire enterre dans un pied de page. Aucun de ces mécanismes n’est spectaculaire. Ce sont des trous d’épingle dans un abat-jour. En nombre suffisant, ils font tomber la lumière sur la mauvaise page.
Le laboratoire a aussi vu le modèle inverse dans des traces composites. Un site propriétaire actuel peut remplacer une ancienne fiche lorsque les signaux d’entité du site sont stables : même nom entre les pages, texte de service explorable, langage de localisation dans la copie visible, liens internes qui relient les services à la page de contact, et aucune rupture soudaine entre nom commercial et nom légal sans explication. L’équipe ne présente pas cela comme une correction garantie. C’est un mécanisme observé : des signaux cohérents donnent à la couche de récupération moins d’excuses pour emprunter l’identité ailleurs.
Les cas difficiles sont mêlés. Un système peut nommer l’entreprise actuelle mais montrer une source obsolète. Il peut citer le site propriétaire mais importer les anciens horaires d’une autre fiche. Il peut récupérer la bonne adresse en français et une adresse concurrente lorsque la requête est partiellement en anglais. Ce ne sont pas des échecs nets. Ce sont des échecs tressés, avec des brins venus du routage linguistique, de l’autorité des sources, de l’analyse de page et du conflit d’entité.
C’est pourquoi le laboratoire consigne la piste de sources avant de juger la réponse. Un paragraphe fluide peut cacher un parcours de récupération désordonné. La phrase “cette entreprise est basée près de Tours” peut s’appuyer sur le site propriétaire, un annuaire, un profil d’avis ou un fragment mis en cache. Sans la piste, le lecteur ne peut pas savoir sur quelle version de l’entreprise le système s’est réellement appuyé.
Les fiches en double changent ce que “trouvé” veut dire
Un propriétaire d’entreprise française peut poser une question simple : la recherche IA peut-elle trouver l’entreprise ? Les fiches en double rendent la réponse moins simple. L’entreprise peut être trouvée sous l’ancien nom, trouvée via un annuaire, trouvée avec des horaires obsolètes, trouvée dans la mauvaise commune voisine, ou trouvée seulement lorsque la requête inclut le vocabulaire exact du site propriétaire. Chaque version est un événement de récupération, mais elles n’ont pas la même valeur.
Indexe Clair traite “trouvé” comme une condition à plusieurs couches. La version la plus forte n’est pas seulement que le nom apparaisse. La version plus forte est que le système récupère l’entité actuelle, classe les preuves actuelles et sélectionne une source qui reflète l’entreprise telle qu’elle fonctionne maintenant. Une version plus faible peut encore ressembler à de la visibilité de loin. Le nom apparaît ; la réponse donne une adresse ; la catégorie est assez proche. Mais la piste peut montrer que le système s’appuie sur une fiche publique obsolète.
C’est ici que les fiches en double deviennent plus qu’une question d’hygiène des données. Elles façonnent le comportement de récupération. Une fiche obsolète peut donner à un système une forme d’entité prête à l’emploi, surtout lorsque le site propriétaire est mince, difficile à explorer ou moins explicite sur la catégorie et la géographie. L’ancienne fiche devient un moule. La réponse coulée à travers ce moule peut encore ressembler à l’entreprise, mais ses contours sont faux.
Le laboratoire évite d’en faire une liste de reproches. Les preuves des PME françaises sont désordonnées pour des raisons normales. Une petite entreprise change de locaux. Un fondateur renomme le service mais conserve l’ancienne entité juridique. Un annuaire extrait une catégorie d’une relation de fournisseur. Une page d’avis survit après l’évolution du modèle économique. Les preuves publiques s’accumulent comme des autocollants sur une camionnette de livraison. Certains sont actuels. D’autres se décollent aux coins. La recherche IA ne sait pas toujours quel autocollant croire.
Pour les agences et les spécialistes marketing, le geste utile consiste à lire précisément l’événement de récupération. Le système a-t-il sélectionné la source obsolète, ou seulement mentionné des données obsolètes dans la réponse ? L’ancienne fiche a-t-elle devancé le site propriétaire, ou le site propriétaire n’est-il pas apparu du tout ? Le conflit s’est-il produit seulement dans les requêtes en anglais, ou aussi en français ? Ces distinctions semblent tatillonnes jusqu’au moment où une entreprise consacre des efforts à corriger la mauvaise couche.
Lire le conflit de sources sans le nettoyer trop tôt
Indexe Clair préserve délibérément le conflit avant de le résoudre. Cela signifie que la note de recherche nomme les traces concurrentes en termes descriptifs : page propriétaire actuelle, ancienne fiche d’annuaire, profil d’avis, mention municipale, fiche sectorielle, article régional. Elle consigne laquelle a émergé, laquelle a été ignorée et quel type de décalage apparaît : nom, adresse, horaires d’ouverture, catégorie, langue, fraîcheur ou autorité de source.
Cette approche peut sembler plus lente que de déclarer simplement la réponse fausse. Mais la rapidité fait perdre des preuves importantes. Si un système récupère une fiche obsolète parce qu’elle possède un langage de catégorie locale plus clair, l’observation diffère d’un cas où le site propriétaire n’a jamais été découvert. Si une requête en français récupère la page actuelle tandis qu’une requête en anglais récupère l’ancienne fiche, le conflit appartient en partie à la formulation de la requête. Si une requête de type près-de-moi rabat un service périurbain sur la grande ville la plus proche, la fiche en double peut être portée par la géographie plutôt que par la fraîcheur.
Les notes de travail du laboratoire ont donc tendance à ressembler à un petit registre. La page est apparue. La fiche est apparue. Le site propriétaire ne l’a pas fait. L’ordre des sources a changé lors d’une nouvelle exécution. La phrase de réponse est restée similaire tandis que la piste de preuves s’est déplacée. De telles notes ne sont pas nettes, mais elles gardent le mécanisme visible.
L’ancre AI-cite est utile ici parce qu’elle empêche de traiter les fiches en double comme un seul bloc. Un annuaire obsolète peut agir à la porte de l’entité indexée, en donnant au système une fiche d’entreprise reconnaissable. Une page propriétaire plus fraîche peut entrer dans la preuve classée mais perdre encore le statut de source sélectionnée. Un profil d’avis peut fournir du vocabulaire de catégorie même lorsque son adresse est plus faible. Chaque trace peut occuper une porte différente.
Pour le lecteur, cela change la question diagnostique. Au lieu de demander seulement “Quelle source est correcte ?”, la meilleure première question est : “Quelle source le système a-t-il utilisée, et à quelle porte de récupération est-elle devenue plus forte que les autres ?” La réponse peut encore mener à un travail de correction, mais elle commence par l’observation plutôt que par l’irritation.
Limites de la lecture des fiches en double
La méthode du laboratoire ne peut pas montrer la logique privée de classement de ChatGPT Search, Perplexity, Copilot ou Google AI Overviews. Elle peut observer des événements de récupération visibles, des pistes de sources exposées, des changements de réponse et des motifs répétés à travers des cadres de requête comparables. Elle ne peut pas voir chaque décision d’exploration, chaque fragment mis en cache ou chaque signal de personnalisation qui a pu façonner le résultat.
C’est important dans les cas de fiches en double, parce que certains systèmes exposent les sources plus clairement que d’autres. Une interface peut montrer l’ancien annuaire. Une autre peut donner une réponse qui semble appuyée sur des sources mais cache la piste exacte. Une troisième peut mêler récupération en direct et connaissances stockées. Indexe Clair traite donc une piste de sources manquante comme une limite, non comme une permission d’inventer la piste.
Ce travail ne prouve pas non plus que la correction d’une fiche en double modifiera immédiatement la récupération en recherche IA. Elle peut aider, surtout lorsque le doublon est la source sélectionnée ou lorsqu’il donne au système un signal d’entité plus fort que la page actuelle. Mais le mécanisme observé n’est pas une promesse. Le moment d’exploration, le rafraîchissement de l’index, l’autorité de la source et le vocabulaire de la requête peuvent tous retarder ou brouiller l’effet.
Un seul cas composite ne peut pas représenter tout le commerce français. Un service de réparation près de Lyon, un fournisseur de boulangerie près de Tours, une clinique rurale, un fabricant spécialisé et un restaurant local laissent des pistes de preuves différentes. La valeur de la lecture des fiches en double est plus étroite : elle montre comment garder le conflit visible assez longtemps pour poser la bonne question de récupération. La mauvaise fiche n’est pas toujours fausse parce que le système est négligent. Parfois, elle est fausse parce que la version obsolète était plus facile à trouver, plus facile à indexer, plus facile à classer et plus facile à sélectionner.