Géocodage immobilier : fiabiliser les adresses difficiles
Adresses sans numéro, translittérations, projets neufs : découvrez une méthode concrète pour fiabiliser le géocodage immobilier et éviter les erreurs de carte.
Géocoder un bien sans adresse : la méthode pour éviter les mauvais points sur la carte
Un point mal placé sur une carte peut paraître anodin. Pour un site immobilier, ça peut pourtant envoyer un acheteur visiter le mauvais quartier, fausser une estimation de proximité ou rendre une recherche géographique inutilisable. Le problème est particulièrement visible quand les adresses ne suivent pas un format uniforme, mais il touche aussi les terrains en construction, les zones rurales et les projets dont la voirie n'est pas encore définie.
Le réflexe est simple : envoyer une adresse à une API de géocodage, récupérer une latitude et une longitude, puis afficher une épingle. Cette approche marche souvent bien dans les centres urbains très documentés. Elle devient fragile dès que l'adresse est descriptive, translittérée ou incomplète. Dans un retour d'expérience portant sur des projets immobiliers au Cambodge, en Thaïlande et à Bali, cette limite a obligé à revoir toute la chaîne de traitement.
Voici une façon plus robuste de faire les choses : normaliser les noms, s'appuyer sur des limites géographiques vérifiables et contrôler les résultats avant de les publier. Le but n'est pas de jeter les API. C'est plutôt de leur enlever la décision finale sur « où se trouve » vraiment un bien.
Pourquoi une adresse ne suffit pas toujours
Un service de géocodage transforme une description textuelle en coordonnées. Mais il ne vérifie pas systématiquement que ce résultat correspond bien à la parcelle recherchée. Quand il manque des éléments, l'API peut renvoyer un point « plausible » à l'échelle d'une ville ou d'un district - trop imprécis pour un usage immobilier.
Entre « obtenir une réponse » et « obtenir la bonne réponse », il y a un monde. Une latitude et une longitude correctement formatées ne suffisent pas à elles seules comme preuve.
Les adresses ne suivent pas partout le même modèle
Dans beaucoup de villes européennes, une adresse tient souvent dans une séquence assez stable : numéro, voie, code postal, commune. Ça facilite la recherche automatisée, même si ça reste imparfait (lieux-dits, voies récemment créées, adresses de chantier, entrées à l'arrière d'un bâtiment, etc.).
Dans les marchés décrits par NovAsia, les informations de localisation prennent parfois d'autres formes : quartier administratif, nom de commune, repère (« près de... »), désignation foncière. Une adresse comme « 200 mètres au sud de la pagode, en face du marché » aide un habitant - mais ce n'est pas forcément une chaîne que le géocodeur peut interpréter correctement et de façon cohérente.
Les subdivisions administratives peuvent aussi couvrir une zone très large. En Thaïlande, par exemple, le système des Moo et des Tambon ne correspond pas à une adresse de rue au sens classique. Le point renvoyé par un service généraliste peut tomber au centre de la subdivision, ce qui peut être cohérent pour une recherche « grand public », mais loin du bâtiment visé. Sur un programme présenté comme en bord de mer, quelques centaines de mètres suffisent à changer le sens de l'information.
La difficulté existe aussi pour les projets neufs, même en Europe. Un immeuble en construction peut ne pas avoir de numéro de rue définitif. Le terrain, lui, est déjà identifié dans un permis, un plan de lotissement ou un document cadastral. Si votre chaîne de données exige une adresse complète avant d'enregistrer le projet, elle écarte une information pourtant exploitable.
La translittération crée des doublons invisibles
Quand un nom passe d'un alphabet à un autre, plusieurs graphies peuvent coexister. Une même zone peut apparaître sous des variantes phonétiques, des abréviations ou des orthographes historiques. Le retour d'expérience cite notamment « Boeng Keng Kang », « BKK » et « Beng Keng Kang », mais aussi des variantes pour des noms de quartiers thaïlandais.
Si vous comparez « à l'orthographe » sans logique métier, vous traitez ces variantes comme des lieux différents. À force d'imports, la base se fragmente : des annonces se retrouvent rattachées à des quartiers distincts, certaines références restent sans correspondance, et les statistiques deviennent moins fiables. « Ajouter plus d'appels API » ne résout pas le problème : ça répète la requête, mais sur des chaînes différentes.
Le niveau de précision doit coller à l'usage
Un point approximatif peut suffire pour afficher une destination à l'échelle d'une région. En revanche, c'est insuffisant si vous promettez une proximité immédiate avec une plage, une station ou une école. La précision nécessaire dépend donc directement de la décision que l'utilisateur prend avec la carte.
Avant de choisir une approche, clarifiez ce que signifie « emplacement correct » pour votre produit :
- Pour une recherche par ville, le centre de la commune peut suffire.
- Pour une recherche par quartier, il faut au minimum vérifier l'appartenance à la bonne unité administrative.
- Pour un terrain ou un programme immobilier, la parcelle (ou son emprise) est souvent plus pertinente qu'un point géocodé.
- Pour une promesse de proximité (« en bord de mer », par exemple), il faut mesurer cette proximité avec une donnée géographique adaptée.
Cette clarification évite de confondre précision « technique » et utilité « métier ». Une coordonnée peut être affichée avec beaucoup de décimales tout en restant inexacte par rapport à ce qui compte pour l'utilisateur.
Construire une chaîne de géocodage plus fiable
Une architecture robuste ne se résume pas à « Google Maps vs Nominatim ». L'idée, c'est de séparer trois choses qui sont souvent mélangées : comprendre le texte reçu, représenter la géographie, puis vérifier que le résultat tient debout. Dans le cas étudié, le traitement s'est organisé en trois étapes : normalisation, stockage spatial adapté, puis validation par règles.
1. Normaliser les noms avant d'interroger un géocodeur
La première étape consiste à transformer une valeur brute en information structurée. Il ne s'agit pas de remplacer toutes les variantes par une seule graphie sortie de nulle part. L'objectif est plutôt de les rapprocher d'un référentiel commun, tout en gardant la saisie d'origine.
Un référentiel local peut associer chaque unité administrative à :
- son nom de référence et son niveau hiérarchique ;
- ses variantes de translittération connues ;
- ses abréviations courantes ;
- ses identifiants stables, quand ils existent ;
- les noms de ses unités parentes : province, district, commune, quartier.
Ensuite, la résolution doit respecter la hiérarchie. Un texte qui ressemble à un quartier ne doit pas être traité comme « certain » juste parce qu'il partage quelques lettres avec un nom connu. Il faut regarder le contexte : province mentionnée, district parent, autres éléments de l'adresse, et candidats géographiques plausibles.
Une distance de Levenshtein peut aider à repérer les fautes et variations de saisie. Elle mesure le nombre de modifications nécessaires pour passer d'une chaîne à une autre. Mais elle ne comprend ni la langue ni la géographie. Le seuil doit donc rester prudent, et la similarité textuelle doit rester un signal parmi d'autres. Deux noms différents peuvent être proches à l'écrit ; deux translittérations équivalentes peuvent aussi être assez éloignées.
En pratique, la sortie de cette étape n'est pas seulement « l'adresse corrigée ». C'est un objet qui conserve la saisie initiale, le nom normalisé, un niveau de confiance et la raison pour laquelle la correspondance a été retenue. Cette traçabilité aide à corriger le référentiel sans perdre l'origine de l'information.
2. Utiliser une géométrie adaptée au bien
Une paire latitude-longitude représente un point. Un terrain, un programme ou une emprise foncière correspond, lui, à une surface. Pour un projet immobilier, la différence compte : un point peut tomber sur une parcelle voisine, à l'intérieur d'un district trop vaste, ou de l'autre côté d'une route.
Quand les documents disponibles donnent les limites du terrain, il est préférable de les stocker comme polygone dans une base spatiale comme PostGIS. Les plans de masse, documents de planification ou données cadastrales peuvent fournir les coordonnées nécessaires, selon leur disponibilité et leur qualité. Un polygone décrit une emprise vérifiable, sans transformer automatiquement une source documentaire imparfaite en vérité absolue : la provenance et la date du document restent essentielles.
Une représentation utile peut combiner plusieurs éléments :
- le polygone de la parcelle (si disponible) ;
- un point représentatif pour afficher une épingle ;
- la limite administrative associée ;
- la source des coordonnées et un niveau de confiance.
Évitez de placer automatiquement l'épingle au centroïde du polygone sans contrôle. Un centroïde peut se retrouver hors d'une forme concave, sur une route ou dans une zone qui n'a rien à voir avec ce que l'utilisateur attend. Le point d'affichage doit répondre à un besoin d'interface ; la géométrie de la parcelle sert aux contrôles spatiaux.
Pour comprendre les types de données et fonctions spatiales disponibles, voir la documentation de PostGIS. Le modèle choisi doit correspondre à vos requêtes : filtrer par zone, calculer une proximité, ou visualiser une emprise n'impliquent pas le même traitement.
3. Valider les coordonnées avec des règles métier
La troisième étape, c'est de tester les résultats avant publication. Un géocodeur peut renvoyer une coordonnée sans signaler qu'elle contredit les autres informations du dossier. Vos contrôles doivent donc porter sur des propriétés vérifiables.
Quelques exemples tirés du cas étudié :
- Si un appartement est déclaré « en bord de mer » à Pattaya ou à Phuket, calculez la distance entre son point (ou sa parcelle) et la géométrie du littoral. Au-delà d'un seuil défini - 400 mètres dans l'exemple source - mettez la fiche en revue plutôt que de la publier automatiquement.
- Si un projet annoncé à Phnom Penh se retrouve en dehors du polygone de la municipalité, bloquez l'import ou demandez une vérification.
- Si un point est très éloigné du polygone administratif associé au nom de quartier, signalez un probable « repli » du géocodeur vers un centre de zone plus large.
Ces règles ne sont pas universelles. Un seuil de 400 mètres peut convenir à une classification dans un contexte précis, et induire en erreur ailleurs. La donnée côtière peut être simplifiée, et l'idée de « proximité de la plage » doit être définie en fonction du produit. Le seuil doit être calibré à partir d'exemples vérifiés, puis ajusté.
Le point clé : rendre l'échec visible. Une coordonnée douteuse ne devrait pas devenir une donnée de production parce qu'une API a renvoyé quelque chose. Mettez-la en attente, marquez-la comme approximative, ou envoyez-la à un opérateur pour contrôle.
Mettre les contrôles en production sans alourdir le système
Un pipeline plus strict améliore la fiabilité, mais il ajoute aussi de la charge : maintenir un dictionnaire de noms, suivre les sources de limites, traiter les cas ambigus et corriger les erreurs. Le bon objectif n'est pas de faire valider manuellement chaque adresse. C'est d'automatiser les cas prévisibles et de réserver l'humain aux situations où il apporte vraiment de la valeur.
Donner un statut à chaque emplacement
Au lieu de stocker uniquement des coordonnées, conservez un statut compréhensible pour le produit et pour l'équipe qui exploite les données. Par exemple :
- Confirmé : géométrie issue d'une source jugée fiable et contrôles réussis.
- Normalisé : adresse rapprochée d'un référentiel, mais géométrie encore approximative.
- À vérifier : candidats multiples, conflit entre la source textuelle et la source géographique, ou contrôle métier échoué.
- Incomplet : emplacement connu à l'échelle d'une commune ou d'un district, sans précision parcellaire.
Ce statut doit aussi s'accompagner d'une provenance, d'une date de mise à jour et d'un indicateur de confiance. L'interface peut alors distinguer une localisation « indicative » d'une parcelle confirmée. C'est mieux qu'une précision affichée qui donne automatiquement à toutes les épingles la même autorité.
Séparer automatisation et décision éditoriale
Les erreurs faciles à détecter doivent être bloquées automatiquement : coordonnées hors de la zone attendue, géométrie invalide, coordonnées absentes, distance incompatible avec une assertion métier. Les cas ambigus vont, eux, en file de révision.
Pour que la correction soit utile, l'interface doit montrer côte à côte : l'adresse d'origine, sa forme normalisée, la carte, les candidats proposés, la source du polygone et la règle qui a déclenché l'alerte. Sans ça, l'opérateur « déplace un point à l'aveugle ». Quand une correction est validée, elle doit aussi enrichir le référentiel. Sinon, la même erreur revient au prochain import.
Et n'oubliez pas d'enregistrer les décisions : qui a corrigé, sur quelle base, et à quelle date. Cette piste d'audit sert autant à corriger des erreurs qu'à expliquer pourquoi deux annonces similaires n'ont pas été traitées pareil.
Mesurer la qualité, pas le nombre d'appels API
Le volume de requêtes envoyées à un géocodeur mesure une activité, pas la qualité du résultat. Les indicateurs plus utiles :
- la part des emplacements validés automatiquement ;
- le taux des résultats envoyés en revue manuelle ;
- la proportion de corrections après publication ;
- la distance constatée entre les coordonnées proposées et les emplacements confirmés ;
- le nombre de doublons administratifs détectés après normalisation.
Ces métriques permettent d'identifier les vrais coûts. Si une nouvelle source réduit le nombre de cas à vérifier sans augmenter les corrections tardives, elle vaut probablement mieux qu'une API plus coûteuse. À l'inverse, un taux élevé de traitement automatique n'est pas un succès si les erreurs passent inaperçues.
Il faut aussi tenir compte des conditions d'utilisation et des limites des sources. Par exemple, Nominatim documente ses règles d'usage et ses capacités. Une API de géocodage n'est pas un référentiel foncier, et ses conditions peuvent limiter certains usages. Les données cadastrales et référentiels administratifs ont aussi leurs droits, leurs niveaux de couverture et leurs dates de mise à jour à vérifier.
Enfin, en Europe, un projet qui manipule des données de localisation doit examiner les informations personnelles éventuellement associées, les finalités du traitement et les durées de conservation. Une coordonnée n'est pas forcément une donnée personnelle, mais elle peut le devenir quand elle est reliée à une personne identifiable. Le respect du RGPD dépend du contexte, pas du seul format géographique.
Conclusion : traiter la localisation comme une donnée métier
Le géocodage immobilier ne consiste pas seulement à convertir une adresse en latitude et longitude. Dès que les noms varient, que les adresses manquent, ou que les projets précèdent la voirie, la qualité dépend d'une série de décisions : normaliser les références, choisir une représentation géographique adaptée, vérifier la cohérence et rendre l'incertitude visible.
Commencez par identifier ce que votre carte doit réellement permettre. Ensuite, définissez le niveau de précision requis, les sources acceptables et les règles qui bloquent ou signalent un résultat. Une API reste utile, mais elle ne remplace ni un référentiel local ni des contrôles spatiaux.
Si vous construisez un produit basé sur la localisation, auditez un échantillon de vos résultats actuels : comparez les épingles aux limites administratives, repérez les variantes de noms et mesurez les erreurs qui changent vraiment l'expérience utilisateur. C'est un point de départ concret pour améliorer votre pipeline, sans chercher une précision parfaite quand les données disponibles ne le permettent pas.