Remplacer Mapbox par un Pelias auto-hébergé : sortir de la facturation à la requête

Sur une plateforme de transport, l’adresse est partout. Le vendeur saisit un point de départ, l’acheteur une destination, le conducteur déclare son trajet, et chacun de ces champs déclenche une autocomplétion — c’est-à-dire une requête de géocodage à chaque frappe au clavier.

Facturé à la requête, c’est le pire modèle de coût qu’on puisse imaginer : la facture suit le trafic, donc elle grossit exactement quand la plateforme marche bien. Et elle grossit aussi quand un robot décide d’explorer le formulaire, ou quand un bug de front relance la recherche trois fois par caractère.

Nous avons remplacé Mapbox par Pelias, un moteur de géocodage libre, hébergé sur notre propre cluster Kubernetes chez OVH. Le résultat tient en une phrase : une facture de plusieurs milliers d’euros ramenée à zéro, et un coût qui ne dépend plus du trafic.

Cet article raconte aussi ce que ce chantier a réellement demandé, parce que c’est la partie qu’on ne lit jamais dans les retours d’expérience.

Pourquoi Pelias

Pelias est un moteur de géocodage open source construit autour d’Elasticsearch. Il fait ce qu’on attend : géocodage direct (une chaîne de caractères vers des coordonnées), géocodage inverse (des coordonnées vers une adresse), et autocomplétion. Il accepte plusieurs sources de données, il est conçu pour être reconstruit et réindexé, et il n’appartient à personne.

Les alternatives ne manquaient pas — l’API Adresse du gouvernement, Nominatim, d’autres fournisseurs commerciaux. Pelias l’a emporté sur trois critères : il tient la charge d’une autocomplétion, on choisit ses sources de données, et surtout on peut intervenir dans le classement des résultats. Sur une marketplace, la pertinence d’une adresse ne se juge pas dans l’absolu : elle se juge sur ce que les utilisateurs cherchent réellement.

Construire un index France, concrètement

Pelias ne se « configure » pas, il se construit. L’index français que nous exploitons agrège plusieurs sources, chacune apportant ce que les autres n’ont pas :

• la Base Adresse Nationale, pour les adresses françaises officielles
• la BD TOPO de l’IGN, en complément sur le bâti et la voirie
• OpenStreetMap, pour les lieux et les points d’intérêt
• OpenAddresses, en couverture supplémentaire
• Who’s on First, pour la hiérarchie administrative — c’est ce qui permet de savoir qu’une rue appartient à une commune, qui appartient à un département, qui appartient à une région
• GeoNames, et l’interpolation de numéros de voirie pour les adresses absentes des référentiels

Chaque source arrive dans son propre format, avec ses propres trous. L’assemblage n’est pas une formalité : c’est l’essentiel du travail.

Le détail qui coûte trois semaines : les codes postaux

Voici le genre de problème qu’on ne peut pas anticiper.

Une fois l’index construit, une partie des communes — les enregistrements locality et localadmin — n’avait aucun code postal. Sur un formulaire d’expédition, c’est rédhibitoire : l’utilisateur tape « Bordeaux », choisit la proposition, et le champ code postal reste vide.

Nous avons écrit un outil qui répare ça de façon reproductible :

1. il interroge Elasticsearch pour lister toutes les communes françaises sans code postal, via l’API de défilement, parce qu’elles se comptent en dizaines de milliers ;
2. il les rapproche du fichier officiel des codes postaux de La Poste, d’abord par code INSEE — la seule correspondance fiable — puis par nom normalisé ;
3. pour ce qui reste, il interroge en dernier recours la Base Adresse Nationale et l’IGN, avec un cache pour ne pas refaire deux fois la même requête ;
4. il produit un CSV réimportable directement par l’importateur CSV de Pelias.

Les villes à arrondissements — Paris, Lyon, Marseille — sont traitées à part, avec leur code postal générique rattaché au nom de base.

Ce n’est pas glorieux, mais c’est exactement ce qui sépare une démonstration d’un service en production. Et c’est rejouable : à chaque reconstruction de l’index, on relance le script.

Le deuxième piège : « Londres » ne trouvait pas London

Celui-là est plus subtil, et il a demandé de mettre les mains dans le moteur lui-même.

Pelias construit sa requête Elasticsearch sur un champ unique : la forme par défaut du nom du lieu. Concrètement, un utilisateur francophone qui tape Londres ne trouve rien, parce que le document s’appelle London — la traduction française existe bien dans l’index, mais dans un autre champ, que la requête n’interroge pas.

Nous avons donc modifié la couche de requête de l’API : la recherche principale ne vise plus un seul champ mais plusieurs à la fois, et quand l’appelant précise une langue, le champ de nom correspondant est ajouté à la liste. « Londres » retrouve London, « Bruxelles » retrouve Brussels, sans casser le comportement par défaut.

C’est une modification de quelques lignes. La trouver a pris beaucoup plus longtemps que l’écrire : il a fallu comprendre comment Pelias assemble sa requête, où intervient le parseur d’adresses, et lesquelles des dizaines de fixtures de tests devaient être mises à jour en conséquence.

Le troisième : les abréviations de voie

Personne n’écrit « avenue » en entier dans un champ d’adresse. On tape « av », « av. », « ave ». Idem pour boulevard, chemin, allée, chaussée, impasse, lotissement.

Sans traitement, le moteur considère ces formes comme des mots différents. Nous maintenons donc des fichiers de synonymes appliqués à l’indexation et à la recherche — sur les noms de lieux, sur les voies, et sur les entités administratives. C’est un travail d’entretien plus que d’ingénierie, mais c’est ce qui fait qu’une adresse est trouvée au premier essai plutôt qu’au troisième.

Ce qu’on récupère en maîtrisant le moteur

Une fois le moteur chez soi, des choses deviennent possibles qui ne l’étaient pas :

• Corriger le moteur quand son comportement ne convient pas, comme pour les noms traduits — chez un fournisseur, on ouvre un ticket et on attend
• Ajuster le classement pour privilégier les couches utiles au métier plutôt que la pertinence générique du moteur
• Enrichir les données avec ses propres référentiels, et les mettre à jour quand on le décide
• Ne plus avoir de quota, donc ne plus concevoir le front en fonction du prix d’une frappe au clavier

C’est le vrai gain, et il est plus difficile à chiffrer que la facture : sur un champ d’adresse, un résultat pertinent au premier essai évite un abandon de formulaire.

Kubernetes chez OVH : un coût fixe

L’instance tourne sur un cluster Kubernetes managé chez OVH. Pelias est un ensemble de services — l’API, le parseur d’adresses, l’interpolation, le service de hiérarchie administrative, et Elasticsearch — ce qui en fait un candidat naturel à l’orchestration.

Le modèle économique change de nature : on ne paie plus des requêtes, on paie des ressources. Un pic de trafic ne se traduit plus par une ligne de facture, mais au pire par un nœud supplémentaire, que l’on décide. Et la reconstruction périodique de l’index, qui est le moment le plus gourmand, se programme quand l’infrastructure est disponible.

À qui je ne le conseille pas

Soyons honnêtes : ce chantier a demandé énormément de travail. Forker l’API et le parseur, comprendre comment la requête Elasticsearch est assemblée, construire l’index, diagnostiquer les résultats incohérents, écrire les outils d’enrichissement, préparer le déploiement — ce n’est pas une migration de fin de semaine.

Le calcul est simple : si votre facture de géocodage se compte en dizaines d’euros par mois, payez sans hésiter, vous n’amortirez jamais l’effort. Si elle se compte en milliers, si elle croît avec votre activité, et si la qualité des adresses touche directement votre conversion, alors l’auto-hébergement devient une décision structurelle — pas une économie de bout de chandelle.

Pour Cocolis, où l’adresse est au cœur même du produit, la réponse était évidente.