Un fait erroné produit par l’IA est rarement une simple phrase dont il faut se plaindre. C’est une petite fuite dans le système de preuves, et la réparation commence en trouvant par où l’eau est entrée.
Un réseau régional de plomberie et de chauffage dans l’ouest de la France a eu, un jour, une erreur tenace qui semblait inoffensive jusqu’à ce que l’équipe commerciale explique la marge. Les réponses d’IA décrivaient sans cesse l’entreprise comme faisant « uniquement de la plomberie d’urgence ». Le nom était correct. Plusieurs agences étaient bien situées. L’indicatif téléphonique paraissait plausible. Mais la maintenance de chauffage pour les professionnels, le travail que l’entreprise voulait développer, disparaissait de la description.
C’est un scénario composite, construit à partir de motifs répétés dans des audits de services locaux. Le détail concret compte : une réponse plaçait aussi une agence dans une ville voisine où l’entreprise avait un ancien profil d’avis, mais plus de bureau actuel. L’équipe avait déjà modifié le site. La fausse description revenait quand même. C’est le moment où une correction a besoin d’un registre, pas d’un nouveau tour de réécriture pleine d’espoir.
Un fait erroné a une histoire, même quand on ne peut pas la voir entièrement
Quand une réponse d’IA invente ou répète un mauvais fait sur une entreprise, la réaction est souvent personnelle. « Pourquoi dit-elle cela de nous ? » C’est légitime. Une mauvaise description d’une entreprise ressemble à un inconnu qui lit mal votre badge, puis donne des indications à vos clients.
La question de mesure est plus froide : d’où ce fait erroné pourrait-il venir, et à quelle fréquence revient-il ? La réponse n’est pas toujours possible à connaître entièrement. Certaines descriptions générées mélangent les sources. Certains systèmes ne montrent pas de citations. Certaines erreurs viennent d’anciennes données d’entraînement, d’extraits récupérés, de textes d’annuaires copiés ou de plusieurs signaux faibles pointant dans la même mauvaise direction. Je ne promets pas une histoire d’origine parfaite. Je promets une tentative de réparation traçable.
Un registre de correction est le relevé répété d’un fait erroné sur une entreprise dans les réponses d’IA, parce que l’erreur doit être suivie à travers les prompts, les sources citées et les retests avant qu’une correction puisse être considérée comme fiable.
L’expression « relevé répété » compte. Une réponse hallucinée isolée peut être du bruit. Un fait erroné qui apparaît dans plusieurs moteurs, langues ou types de prompts devient un problème à gérer. S’il revient après la modification du site, c’est que le site n’était pas la source, pas la source la plus forte, ou pas encore assez clair pour dépasser les preuves plus anciennes.
C’est agaçant. C’est aussi utile. L’agacement donne un point de départ au travail.
Ne corrigez pas la phrase en premier
Le geste tentant consiste à réécrire la page où le bon fait existe déjà. Ajouter un paragraphe. Changer un titre. Insérer une ligne sur la page d’accueil. Parfois, cela aide. Mais si le mauvais fait vient d’un annuaire, d’un ancien profil, d’une page partenaire, d’un texte d’avis ou d’une association de catégorie, réécrire la page de l’entreprise peut seulement polir la vérité dans une pièce où le moteur n’entre pas.
Dans le scénario du réseau de chauffage, l’entreprise avait déjà ajouté du vocabulaire de maintenance à sa page de service principale. La fausse réponse continuait de revenir pour plusieurs prompts de ville. Le registre montrait pourquoi la réparation de l’équipe avait raté le problème. Le moteur de réponse citait souvent, ou semblait s’appuyer sur, des profils d’agence et des pages d’annuaire qui mettaient l’accent sur la plomberie d’urgence. Certains profils avaient été créés des années plus tôt pour du dépannage rapide. Ils n’étaient pas techniquement faux, mais ils étaient commercialement incomplets. La réponse d’IA comprimait cette description incomplète en identité.
C’est un mécanisme courant. Un vieux fait partiel devient un fait total actuel. L’entreprise faisait autrefois de l’urgence. La page parle d’urgence. Le modèle répète l’urgence. L’acheteur demande de la maintenance, et la réponse porte encore l’étiquette urgence comme une étiquette restée collée sur un verre après lavage.
Avant de corriger la phrase, je veux que le fait erroné soit noté exactement. Pas « l’IA se trompe sur nous ». C’est trop mou. Écrivez : « Décrit l’entreprise comme urgence uniquement. » Écrivez : « Place l’agence à Saint-Brieuc. » Écrivez : « Nous présente comme revendeur. » Écrivez : « Dit que nous servons seulement les particuliers. » Le registre a besoin de l’affirmation fausse exacte, parce qu’une frustration vague ne peut pas être retestée.
Les quatre origines d’une erreur tenace
J’utilise une classification simple pour les faits erronés hallucinés sur les entreprises. Ce n’est pas une taxonomie scientifique ; c’est un outil de travail qui évite que la réparation devienne théâtrale. Les quatre origines sont : périmée, partielle, empruntée et inférée.
Un fait périmé a été vrai, ou assez vrai dans un ancien contexte. Une ancienne adresse, une ligne de service abandonnée, un précédent statut de partenaire ou une description d’activité dépassée se trouve quelque part dans le champ de preuves. La réponse le répète parce que la page reste récupérable ou a été copiée dans d’autres sources.
Un fait partiel est vrai mais trop étroit. L’entreprise de chauffage fait de la plomberie d’urgence, mais pas seulement. Un éditeur de logiciels revend des licences, mais sa valeur principale est l’intégration. Une agence régionale sert une ville, mais sa zone d’intervention est plus large. Les réponses d’IA transforment souvent les faits partiels en identités complètes, parce que les réponses concises récompensent la compression.
Un fait emprunté vient d’une autre entité. Cela arrive avec des noms d’entreprise proches, des réseaux de franchise, des agences, d’anciennes acquisitions ou des annuaires qui mélangent des sociétés voisines. L’erreur peut sembler inventée, mais elle a un voisin. Sur les marchés locaux, les faits empruntés peuvent être particulièrement tenaces parce que la localisation, la catégorie et des fragments de nom se recouvrent.
Un fait inféré est le plus glissant. Aucune page ne dit directement la mauvaise chose, mais le moteur l’infère à partir de motifs de catégorie. Une entreprise avec beaucoup de pages liées à l’urgence peut être décrite comme urgence uniquement. Un prestataire B2B avec des badges d’éditeurs peut être décrit comme revendeur. Une entreprise avec des fiches partenaires en anglais et peu de preuves de cas en français peut être décrite avec le vocabulaire du partenaire.
J’appelle cet ensemble la carte d’erreurs PPEI : périmée, partielle, empruntée et inférée. Elle donne à chaque fait erroné une piste de réparation probable au lieu de traiter toutes les hallucinations comme le même tour de machine.
Une erreur périmée exige du nettoyage et des preuves actuelles plus fortes. Une erreur partielle exige des descriptions plus complètes là où le fait partiel apparaît. Une erreur empruntée exige une désambiguïsation de l’entité. Une erreur inférée exige un meilleur équilibre des signaux, pour que le système ait moins de raisons de compléter l’histoire de travers.
Une boucle de correction doit survivre à la modification
Beaucoup d’entreprises s’arrêtent trop tôt. Elles trouvent le fait erroné, modifient une page et supposent que la correction a eu lieu. C’est compréhensible. Dans l’édition ordinaire, une fois la page modifiée, la page est modifiée. En visibilité IA, la réponse peut ne pas changer tant que la meilleure preuve n’a pas été récupérée, pondérée et répétée assez souvent pour modifier le motif. Parfois, cela change vite. Parfois non. Parfois un moteur se met à jour tandis qu’un autre conserve l’ancienne forme.
Ma boucle de correction comporte quatre étapes simples. Je les écris ici en prose parce que les listes donnent à ce travail une apparence plus propre qu’il ne l’est.
D’abord, isoler le fait erroné exact et les prompts qui le produisent. Le libellé compte. « Urgence uniquement » peut apparaître dans des prompts larges comme « meilleur plombier », mais pas dans des prompts « contrat de maintenance chauffage ». Ou bien il apparaît en français mais pas en anglais. Ou encore la version anglaise porte une autre erreur parce qu’elle cite des pages partenaires.
Ensuite, tracer les sources. J’ouvre les pages citées quand elles sont affichées. Quand il n’y a pas de citations, je recherche les formulations autour du fait erroné et j’inspecte les sources probables : annuaires, profils, anciens PDF, pages d’avis, pages partenaires, fiches locales. Je note le degré de confiance dans la source : affichée, probable ou inconnue. Cette honnêteté empêche le registre de devenir un roman policier avec une fin trop nette.
Troisièmement, renforcer la meilleure source. Cela peut vouloir dire corriger des profils externes, clarifier des pages d’agence, ajouter des descriptions de service simples, améliorer les preuves de cas, aligner les formulations françaises et anglaises ou rendre les faits de localisation moins ambigus. La meilleure source doit énoncer le bon fait sous une forme récupérable et résumable. Un beau paragraphe qui cache le fait dans des formulations floues n’est pas une correction.
Quatrièmement, retester les mêmes prompts après que le changement a eu le temps d’entrer dans le circuit de réponse. Je ne modifie pas le jeu de prompts dans le même mouvement, parce que je ne pourrais plus savoir si la réponse s’est améliorée ou si le test a bougé. De nouveaux prompts peuvent être ajoutés, mais les anciens restent comme groupe de contrôle.
La boucle est volontairement sobre. Les faits erronés adorent les réactions dramatiques. Ils se traitent mieux avec des lignes datées.
La correction peut exiger plus que votre propre site
La maîtrise de ses propres supports a ses limites rassurantes. L’entreprise possède son site. Elle peut posséder certains profils. Elle ne possède pas toutes les pages qui la décrivent. Un registre de correction rend cela visible sans le transformer en désespoir.
Pour le réseau de chauffage, plusieurs sources faibles se trouvaient hors du site principal. Des fiches d’agence mettaient l’accent sur les appels d’urgence. Certaines descriptions étaient copiées depuis d’anciens profils. Une page de localisation sur une plateforme externe portait une indication de zone d’intervention qui faisait ressembler une ville voisine à une agence. Aucune de ces sources n’expliquait seule toutes les mauvaises réponses. Ensemble, elles donnaient au moteur un contour de travers.
La réparation avait donc deux pistes. L’entreprise a renforcé ses propres pages d’agence et de maintenance avec des descriptions de service claires, une couverture par ville et du vocabulaire de maintenance professionnelle. Elle a aussi corrigé les profils externes auxquels elle avait accès et noté dans le registre ceux qu’elle ne pouvait pas modifier. Pour les sources hors de son contrôle, l’équipe a créé de meilleures preuves concurrentes : des profils publics plus clairs, de meilleurs résumés de cas et une formulation cohérente entre les lieux.
Il n’y a rien de magique ici. Une correction n’est pas une demande criée au modèle. C’est un changement dans le champ de preuves. Le moteur a besoin d’assez d’éléments plus solides pour arrêter de choisir l’ancien raccourci.
Je surveille aussi les surcorrections. Une équipe agacée d’être étiquetée urgence uniquement peut supprimer partout le vocabulaire d’urgence. Cela peut abîmer une visibilité légitime pour les prompts de dépannage urgent. Le but n’est pas d’effacer la vérité partielle. Le but est de la remettre à sa juste proportion. « Plomberie d’urgence et maintenance chauffage planifiée » envoie un signal différent de « plombier d’urgence 24/7 », et cette distinction compte.
Le retest prouve la réparation ou expose la source suivante
Le retest est le moment où l’orgueil doit rester tranquille. Parfois, la correction fonctionne dans un moteur et échoue dans un autre. Parfois, le fait erroné disparaît des prompts larges mais reste dans les prompts de localisation. Parfois, la source citée change mais l’erreur de description survit. Ce dernier cas est particulièrement irritant. Il signifie que le mauvais fait peut être inféré depuis plusieurs sources, et non copié depuis une seule.
Dans le scénario du réseau de chauffage, le premier retest a amélioré les réponses aux prompts de maintenance en français pour deux villes. L’entreprise était nommée avec une meilleure description et, dans certaines exécutions, ses propres pages de service étaient citées. Mais un prompt sur une ville voisine décrivait encore l’entreprise comme urgence uniquement et la plaçait maladroitement en dehors de sa vraie structure d’agences. Le registre pointait vers une fiche externe restante. Pas une victoire nette. Une prochaine réparation utile.
C’est pourquoi je préfère les registres de correction aux « listes de correctifs ». Une liste de correctifs suppose que le travail se termine quand la tâche est cochée. Un registre suppose que la réponse doit être observée à nouveau. La visibilité IA ne devient pas maîtrisable parce qu’on fait une modification parfaite. Elle devient maîtrisable parce que les réponses répétées montrent si la modification est entrée dans le motif.
Il y a aussi un bénéfice psychologique. L’équipe cesse de débattre à partir de captures d’écran. Une personne n’agite plus la mauvaise réponse ; une autre n’agite plus la page modifiée. Tout le monde regarde les mêmes lignes : fait erroné, prompt, source, correction, résultat du retest. La conversation devient moins théâtrale.
Une information d’entreprise hallucinée n’est pas toujours supprimable sur commande. Mais elle est souvent classable, assez traçable pour être travaillée, et testable après réparation. C’est déjà beaucoup mieux que de crier contre la boîte de réponse.
La note de mesure — Signal : le même fait erroné sur l’entreprise revient après la modification du site. Distorsion : traiter l’hallucination comme une mauvaise phrase isolée au lieu d’un problème de motif de sources. Registre : noter l’affirmation fausse exacte, le prompt, le moteur, la langue, la source citée ou probable, la correction effectuée et le résultat du retest. Prochain test : classer l’erreur comme périmée, partielle, empruntée ou inférée, puis réparer d’abord la source la plus forte.