Pourquoi les assistants IA hallucinent des adresses (et comment les données géo vérifiées corrigent le problème)

TL;DR: Les assistants IA inventent des adresses plausibles mais erronées à des taux allant de 6 % pour les hôtels de chaîne à 38 % pour les locations de vacances indépendantes. La solution n'est pas de corriger le modèle. Publiez une vérité terrain univoque à l'aide du balisage Schema.org Place, de coordonnées vérifiées et d'un identifiant externe canonique, puis maintenez cette vérité cohérente sur chaque plateforme où l'établissement apparaît.

Demandez à ChatGPT l'adresse d'un hôtel trois étoiles à Porto et il répondra probablement avec un nom de rue, un numéro et un code postal. La réponse sonnera juste. Pour les grandes chaînes, elle sera généralement correcte. Pour l'hôtel-boutique indépendant situé deux rues plus loin, la réponse a une probabilité significative d'être erronée.

Il ne s'agit pas d'un cas marginal. C'est un résultat prévisible du fonctionnement des modèles de langage, et cela a des conséquences directes pour toute entreprise dont l'activité dépend d'être trouvée à un emplacement précis.

La mécanique d'une hallucination de localisation

Un modèle de langage ne stocke pas une base de données d'adresses. Il stocke une distribution statistique sur des tokens. Lorsqu'on lui demande une adresse, il prédit une séquence de tokens qui ressemble à une adresse pour ce type d'établissement dans cette ville.

Si les données d'entraînement contenaient la vraie adresse à de nombreuses reprises, de manière cohérente et dans des sources faisant autorité, la prédiction converge vers la chaîne correcte. Si l'adresse apparaissait rarement, de façon incohérente ou pas du tout, le modèle interpole. Il choisit une rue qui semble convenir au quartier, un numéro qui colle au pâté de maisons, un code postal qui correspond au schéma local.

Le résultat est grammaticalement valide, géographiquement plausible, et souvent totalement faux.

Audit d'échantillon : taux d'hallucination par type de requête

Nous avons soumis 500 requêtes de localisation à trois assistants IA de premier plan en avril 2026. Chaque requête demandait l'adresse d'un établissement précis. Les réponses ont été comparées à l'adresse vérifiée de l'établissement, enregistrée dans MapAtlas GeoEnrich.

Le tableau ci-dessous présente la part des réponses contenant au moins une erreur d'adresse significative (mauvaise rue, mauvais numéro, mauvais code postal ou mauvaise ville). Les chiffres sont indicatifs et spécifiques à cet échantillon.

Type de requête	ChatGPT	Perplexity	Gemini
Hôtel de chaîne	6%	4%	7%
Hôtel-boutique indépendant	19%	14%	22%
Location de vacances	38%	29%	41%
Restaurant indépendant	24%	18%	27%
Monument ou attraction	9%	5%	8%

Source : audit d'échantillon MapAtlas, avril 2026, n=500 requêtes.

Deux tendances se dégagent. Premièrement, le taux d'hallucination évolue en fonction de la rareté et de l'incohérence de l'empreinte web de l'établissement. Les locations de vacances, souvent présentes sur une seule plateforme de réservation sans site vitrine indépendant, sont les plus touchées. Deuxièmement, Perplexity hallucine systématiquement moins, probablement parce que sa couche de retrieval ancre davantage de réponses dans des sources en direct plutôt que dans la mémoire paramétrique.

Un exemple concret

Requête émise en avril 2026 : « Quelle est l'adresse de la guesthouse Casa do Vale à Porto ? »

Réponse hallucinée par un assistant de premier plan :

Casa do Vale se trouve au 142 Rua de Santa Catarina, 4000-442 Porto, Portugal.

Réponse vérifiée à partir des propres registres de l'établissement et de MapAtlas Geocoding :

Casa do Vale, 38 Rua do Vale, 4200-512 Porto, Portugal.

Mauvaise rue, mauvais code postal, mauvais côté de la ville. La réponse hallucinée envoie le voyageur dans un quartier commerçant à trois kilomètres de la guesthouse réelle. L'erreur n'est pas aléatoire. La Rua de Santa Catarina est la rue commerciale la plus célèbre de Porto et apparaît fréquemment dans les données d'entraînement pour les requêtes d'hébergement à Porto. Le modèle a opté pour l'a priori statistique le plus fort pour cette ville.

Pourquoi les données structurées changent le résultat

Une page de fiche dotée d'un bloc JSON-LD Place ou LodgingBusiness correctement formé donne au modèle quelque chose à extraire plutôt qu'à inventer.

{
  "@context": "https://schema.org",
  "@type": "LodgingBusiness",
  "name": "Casa do Vale",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua do Vale 38",
    "postalCode": "4200-512",
    "addressLocality": "Porto",
    "addressCountry": "PT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 41.1621,
    "longitude": -8.5937
  },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "wikidata",
    "value": "Q00000000"
  }
}

Trois caractéristiques de ce bloc sont déterminantes pour réduire les hallucinations :

Des champs structurés. Le modèle n'a pas à analyser une phrase. La rue, le code postal, la ville et le pays sont des clés distinctes.
Des coordonnées qui correspondent à l'adresse. Un crawler peut vérifier que la latitude et la longitude tombent dans le polygone du code postal. Les incohérences signalent les données comme peu fiables.
Un identifiant externe stable. Wikidata ou un Google Place ID relie la fiche à une entité canonique. Le modèle peut rapprocher l'adresse d'une source faisant autorité plutôt que de s'en remettre à la fréquence dans les données d'entraînement.

Lorsque ces trois conditions sont réunies, l'extraction remplace la génération. La probabilité d'une réponse hallucinée chute nettement.

La couche de cohérence NAP

Le schéma sur la page de fiche est nécessaire mais pas suffisant. Les systèmes IA recoupent l'adresse avec d'autres sources publiques : Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, plateformes de réservation et le web ouvert. Quand celles-ci divergent, la confiance baisse et le modèle devient plus enclin à nuancer ou à générer.

C'est pourquoi la cohérence NAP (Name, Address, Phone) entre plateformes est un meilleur prédicteur de citation que n'importe quel signal isolé. Une fiche avec un schéma parfaitement formé mais une adresse contradictoire sur Google Business Profile obtiendra tout de même de mauvais résultats. Consultez la cohérence NAP pour la recherche IA pour en comprendre la mécanique.

Ce qui tend à réduire le risque d'hallucination

Quatre mesures font le plus bouger l'aiguille dans les audits que nous avons menés :

1. Publier des coordonnées vérifiées à côté de l'adresse. Une adresse écrite est une chaîne de caractères. Les coordonnées sont un fait vérifiable. MapAtlas Geocoding convertit à grande échelle des adresses brutes en latitude et longitude précises et signale les entrées qui ne se résolvent pas proprement.

2. Encapsuler les faits de localisation en JSON-LD. Les types Place, LodgingBusiness, Hotel, Restaurant et LocalBusiness acceptent tous les champs address, geo et identifier. Les champs manquants sont précisément ceux où le modèle commence à deviner.

3. Rapprocher de l'identifiant canonique. Reliez la fiche à un QID Wikidata ou à un Google Place ID. Cela fournit aux systèmes IA une clé primaire pour dédupliquer.

4. Enrichir avec le contexte de proximité. Les hallucinations ne se limitent pas au champ adresse. Les modèles inventent aussi des monuments voisins, des arrêts de transport et des temps de marche. Les données de proximité vérifiées, générées par MapAtlas GeoEnrich, ancrent également ces affirmations. Les FAQ spécifiques à la localisation sont une surface efficace pour exposer ces données.

Le coût business d'une adresse hallucinée

Une adresse erronée remontée par un assistant IA ne fait pas que mettre le modèle dans l'embarras. Elle envoie un véritable client au mauvais endroit. Les effets en aval s'accumulent :

Une réservation annulée, ou pire, un no-show.
Un avis négatif mentionnant la mauvaise localisation, qui devient ensuite une donnée d'entraînement pour la génération suivante du modèle.
Une baisse de la confiance de citation pour la fiche à l'avenir, car le web public contient désormais des signaux contradictoires.

L'asymétrie est importante. Une adresse hallucinée pénalise la fiche même si la fiche elle-même n'y est pour rien. La solution n'est pas de corriger le modèle directement, ce qui n'est pas possible, mais de rendre la vérité terrain suffisamment claire pour que le modèle n'ait aucune raison de générer en premier lieu.

Comment vérifier votre propre exposition

Le MapAtlas AEO Checker gratuit évalue une fiche sur 29 signaux structurés, dont le schéma d'adresse, la présence de coordonnées, la cohérence NAP et les identifiants externes. Les fiches qui passent ces contrôles ont nettement moins de chances d'être mal représentées dans les réponses IA. Celles qui échouent sont justement celles où le modèle doit deviner.

Les hallucinations de localisation ne sont pas une bizarrerie propre à tel ou tel assistant. Elles sont la conséquence prévisible d'un entraînement sur un web ouvert où le même établissement apparaît avec des adresses légèrement différentes dans des dizaines de sources. La solution consiste à publier une vérité terrain unique dans un format que les systèmes IA peuvent extraire, et à maintenir cette vérité cohérente partout ailleurs où l'entreprise est représentée.

Pour aller plus loin :

Questions fréquemment posées

Qu'est-ce qu'une hallucination d'adresse par une IA ?

Une hallucination d'adresse par une IA survient lorsqu'un grand modèle de langage renvoie une adresse postale, un code postal ou des coordonnées précises qui semblent plausibles mais qui ne correspondent pas à l'emplacement réel de l'établissement, du monument ou du bien décrit. Il ne s'agit pas d'une simple erreur d'arrondi. Le modèle a synthétisé une adresse qui n'existe pas, qui appartient à un autre lieu ou qui combine une vraie rue avec la mauvaise ville. Pour les fiches locales, c'est particulièrement préjudiciable car l'utilisateur peut se déplacer au mauvais endroit avant de réaliser que la réponse était fabriquée.

Pourquoi les assistants IA hallucinent-ils des adresses ?

Les modèles de langage génèrent du texte en prédisant le token suivant le plus probable, et non en consultant une base de faits. Lorsqu'une adresse est sous-représentée, incohérente sur le web ou bloquée au crawling, le modèle comble le vide avec une chaîne statistiquement plausible : un nom de rue qui sonne juste pour la ville, un format de code postal qui correspond à la région, un numéro qui paraît typique. Sans source structurée de vérité pour ancrer la réponse, le modèle n'a aucun moyen de distinguer un fait mémorisé d'un fait généré.

À quelle fréquence les hallucinations de localisation se produisent-elles en pratique ?

Dans un audit réalisé par MapAtlas en avril 2026 sur 500 requêtes de localisation couvrant hôtels, locations de vacances, restaurants et monuments, les taux d'hallucination au niveau de l'adresse allaient d'environ 6% pour les chaînes hôtelières bien connues à 38% pour les locations de vacances indépendantes. Les requêtes génériques sur des monuments s'en sortaient le mieux, les requêtes long tail sur des fiches locales le moins bien. Le taux est indicatif et varie selon le modèle, la langue et la fraîcheur des données sous-jacentes, mais la tendance est constante : moins un établissement expose de données structurées, plus le modèle invente.

Les données structurées Schema.org réduisent-elles les hallucinations ?

Oui, à condition que les données soient vérifiées et cohérentes entre les sources. Publier un bloc JSON-LD Place ou LodgingBusiness avec des coordonnées géographiques exactes, une adresse postale validée et des références croisées vers des identifiants faisant autorité comme Wikidata ou Google Place ID donne au modèle un point d'ancrage qu'il peut extraire et citer. Un schéma incohérent, par exemple des coordonnées qui contredisent l'adresse écrite, tend à réduire la confiance plutôt qu'à la renforcer.

Comment auditer mes fiches pour évaluer le risque d'hallucination ?

Soumettez l'URL de la fiche au MapAtlas AEO Checker gratuit sur mapatlas.eu/ai-seo-checker. L'outil évalue 29 signaux structurés utilisés par les systèmes IA pour ancrer les faits de localisation, notamment les coordonnées géographiques, le schéma Place, la cohérence NAP entre plateformes et la présence de champs de contexte de proximité. Les pages qui n'ont pas ces signaux obtiennent un score élevé de risque d'hallucination car le modèle doit deviner au lieu d'extraire.