Le problème Nominatim apparaît quand une adresse, un lieu, un reverse geocoding ou un résultat OpenStreetMap devient une décision métier, alors que l'équipe traite encore l'appel `/search` comme une simple commodité gratuite.
Le vrai enjeu n'est pas de recevoir des coordonnées, mais de décider quelle requête peut utiliser l'instance publique, quelle réponse doit être mise en cache, quel résultat peut entrer dans le SI et quand il faut passer par un fournisseur ou une instance dédiée.
Vous allez comprendre comment cadrer `/search`, `/reverse`, `/lookup`, `/status`, requête libre, requête structurée, `format=jsonv2`, GeoJSON, GeocodeJSON, `addressdetails`, `extratags`, `namedetails`, `accept-language`, `countrycodes`, `layer`, `featureType`, `viewbox`, `bounded`, `osm_type`, `osm_id` et `place_id`.
Contrairement à ce que laisse croire un test rapide en navigateur, le risque est de transformer une ressource communautaire à capacité limitée en dépendance de production. Le signal faible se voit quand le support corrige les mêmes adresses, que le cache est absent ou que les requêtes périodiques deviennent normales.
Pour cadrer cette architecture, notre accompagnement en intégration API aide à relier Nominatim, OpenStreetMap, référentiel adresse, CRM, OMS, TMS, datawarehouse, support et monitoring. Le sujet se rattache aussi à la landing API cartographie et géolocalisation et à la page intégrateur Nominatim.
Pour qui Nominatim mérite un connecteur
Identifier les usages vraiment adaptés
Nominatim mérite un connecteur pour les outils internes, prototypes responsables, portails à trafic modéré, back-offices territoriaux, enrichissements ponctuels et produits qui exploitent OpenStreetMap sans exiger un SLA commercial immédiat.
Il devient moins adapté quand l'usage ressemble à un moteur de recherche d'adresses à fort trafic, un autocomplete client, un service de tracking, une revente d'API ou un batch récurrent de géocodage massif.
Le bon signal de priorité est simple: si un résultat Nominatim modifie une commande, une tournée, une fiche client ou une zone de service, alors le flux mérite un contrat de run, pas un appel direct depuis le navigateur.
Le cadrage doit aussi nommer les volumes prévus, même modestes. Entre 200 recherches humaines par mois et 20 000 enrichissements automatiques, la même API officielle existe, mais le montage responsable change complètement.
Séparer service public, fournisseur tiers et self-hosting
L'instance publique `nominatim.openstreetmap.org` sert surtout des usages raisonnables, directement déclenchés par un utilisateur, avec identification correcte, cache et attribution. Elle n'est pas une infrastructure illimitée.
Un fournisseur tiers peut convenir quand le besoin demande plus de débit, support, SLA, filtrage, batch ou conditions commerciales. Une instance dédiée devient pertinente quand l'entreprise veut maîtriser import OSM, configuration, ranking, données externes et disponibilité.
Si le flux dépasse 1 requête par seconde ou alimente des clients payants, alors l'architecture doit être relue avant lancement. Cette décision protège la communauté OSM, la continuité de service et la réputation du produit.
La décision doit être prise avant la mise en ligne, pas après le premier blocage. Un usage modeste peut rester public avec cache, tandis qu'un usage récurrent doit assumer son coût technique.
1. Comprendre search, reverse, lookup et status
Utiliser chaque endpoint pour sa vraie responsabilité
L'endpoint `/search` sert à rechercher des objets OpenStreetMap par nom, type ou adresse. L'endpoint `/reverse` part d'une coordonnée pour retrouver l'objet OSM le plus proche. L'endpoint `/lookup` retrouve des détails d'adresse à partir d'identifiants OSM.
L'endpoint `/status` permet de vérifier l'état du serveur, tandis que `/details` existe pour le debugging et ne doit pas être aspiré automatiquement. Le connecteur doit donc distinguer parcours produit, diagnostic et maintenance.
Par exemple, un formulaire interne peut appeler `/search` après validation utilisateur, une application terrain peut utiliser `/reverse` sur une position ponctuelle, et un back-office peut appeler `/lookup` pour relire un objet déjà choisi.
Ne pas demander à Nominatim ce qui relève d'Overpass
Nominatim renvoie les meilleurs résultats correspondant à une recherche. Il ne sert pas à télécharger tous les objets d'un type dans une zone, ni à faire une extraction complète de POI, de commerces ou de codes postaux.
Pour obtenir tous les objets OSM d'une catégorie sur un périmètre, Overpass ou un extrait OSM sont plus adaptés. Cette frontière doit être écrite dans le runbook, car c'est une source fréquente d'abus involontaire.
Si une demande métier commence par "liste tous les restaurants dans cette ville", alors Nominatim n'est pas le bon outil. La bonne décision consiste à basculer vers extraction OSM, fournisseur spécialisé ou base interne.
Conserver le contexte de chaque appel
Un résultat Nominatim n'a de valeur que si le contexte reste traçable: endpoint, paramètres, langue, pays, layer, featureType, viewbox, format, date, instance appelée, User-Agent, cache et décision aval.
Cette trace permet de comprendre pourquoi deux réponses diffèrent entre navigateur, curl, serveur ou instance dédiée. `accept-language`, `countrycodes`, `bounded` et `viewbox` peuvent changer fortement les résultats.
Le runbook doit donc traiter le payload de requête comme une donnée métier. Sans lui, le support voit une adresse contestée, mais l'équipe technique ne sait plus quelles hypothèses ont orienté la réponse.
Le contexte doit aussi préciser si la requête vient d'un humain, d'un batch, d'un worker ou d'une reprise. Cette distinction conditionne le débit autorisé, le cache et la priorité de traitement.
2. Cadrer requêtes libres, structurées et filtres
Choisir entre `q` libre et recherche structurée
La recherche libre avec `q` accepte une description ou une adresse complète. La recherche structurée sépare `amenity`, `street`, `city`, `county`, `state`, `country` et `postalcode` quand l'adresse est déjà découpée.
Le connecteur doit refuser le mélange entre `q` et paramètres structurés. Cette confusion produit des résultats inattendus dans les anciennes versions et peut devenir une erreur dans les versions plus récentes.
Si l'utilisateur saisit une ligne libre, `q` reste naturel. Si le SI possède déjà rue, ville, code postal et pays, la recherche structurée facilite le mapping, la validation et les messages d'erreur.
Utiliser les filtres sans enfermer le résultat
Le paramètre `countrycodes` filtre réellement les résultats par pays, tandis que le paramètre `country` dans une recherche structurée reste une chaîne de recherche plus souple. Cette différence doit être comprise par le produit.
Le paramètre `layer` permet de limiter address, poi, railway, natural ou manmade. Le paramètre `featureType` cible country, state, city ou settlement dans la couche address. Ces filtres changent la décision, pas seulement la performance.
Si 5 % des adresses valides disparaissent après ajout d'un filtre sur 7 jours, alors le filtre doit être revu avant généralisation. Le coût caché se voit dans abandon, tickets support et corrections back-office.
Les tests doivent inclure noms incomplets, accents absents, codes postaux voisins, communes homonymes et adresses transfrontalières. Ces cas révèlent vite si le filtre aide vraiment l'utilisateur ou l'enferme trop tôt.
Cadrer `viewbox`, `bounded` et recherche locale
Le paramètre `viewbox` influence l'ordre des résultats autour d'une zone. Avec `bounded=1`, la zone devient une restriction plus stricte. Ce choix peut améliorer un parcours local ou masquer un résultat légitime hors périmètre.
Une marketplace locale, une application municipale et un outil national ne doivent pas utiliser la même logique. Le périmètre de recherche doit refléter l'intention et rester visible dans les logs.
Par exemple, une recherche "rue de la gare" dans une application communale peut être bornée, alors qu'un support national doit garder une recherche plus ouverte pour éviter les faux rejets.
Le même principe vaut pour un produit B2B multi-pays. Une équipe locale peut privilégier une zone, mais un back-office central doit garder la capacité de corriger un pays ou une ville mal renseignés.
3. Modéliser formats, OSM IDs et place_id
Choisir un format de sortie stable
Nominatim peut répondre en `xml`, `json`, `jsonv2`, `geojson` ou `geocodejson`. Le choix du format doit dépendre du modèle aval, de la stabilité attendue et de la facilité à présenter une adresse au métier.
Le format `geocodejson` est souvent intéressant quand l'équipe veut des catégories d'adresse plus stables. Les autres formats exposent davantage la diversité des tags OSM, ce qui peut être utile mais plus difficile à gouverner.
Si plusieurs applications consomment Nominatim, alors le middleware doit exposer un schema interne unique plutôt que laisser chaque front interpréter `display_name`, `class`, `type`, `importance` ou `address`.
Ce schema doit être versionné comme un contrat API interne. Une évolution du format de sortie ou du mapping ne doit pas changer silencieusement les champs utilisés par CRM, ERP, OMS ou outil terrain.
Préserver `osm_type`, `osm_id` et `place_id` sans confusion
Un résultat peut contenir une référence d'objet OSM avec type node, way ou relation, ainsi qu'un `place_id` interne à l'instance. Les OSM IDs sont plus portables, tandis que `place_id` dépend du serveur.
Le connecteur doit donc conserver les deux quand ils existent, mais il ne doit pas utiliser `place_id` comme identifiant universel entre instances. Cette erreur casse les reprises au moment d'une migration ou d'un self-hosting.
Si une fiche client est reliée à un lieu, la clé interne doit pointer vers l'objet métier, pas directement vers `place_id`. Le résultat Nominatim devient une preuve, pas la source unique de vérité.
Cette séparation facilite les corrections. Quand OSM évolue ou qu'une instance dédiée réimporte les données, le métier conserve son identifiant stable et peut comparer ancienne preuve, nouvelle réponse et décision gardée.
Limiter les détails aux besoins réels
Le paramètre `addressdetails=1` ajoute la décomposition de l'adresse. Le paramètre `extratags=1` peut exposer wikipedia, horaires ou autres informations. Le paramètre `namedetails=1` ajoute les variantes de noms. Ces options enrichissent, mais elles alourdissent le payload.
Les sorties polygonales GeoJSON, KML, SVG ou WKT doivent être réservées aux cas où la géométrie complète change une décision. Une coordonnée ou une bounding box suffit souvent pour valider une adresse.
Si le payload moyen dépasse 500 Ko sans être exploité par le métier, alors il faut retirer les détails, simplifier la géométrie ou déplacer l'appel vers un traitement différé avec cache.
Le paramètre `polygon_threshold` doit aussi être cadré quand une géométrie est nécessaire. Une simplification trop forte peut dégrader une zone, tandis qu'une géométrie complète peut rendre le service inutilisable.
4. Respecter la politique d'usage publique
Traiter la limite publique comme une contrainte produit
La politique d'usage de l'instance publique demande de rester sous une limite très basse, avec un maximum absolu de 1 requête par seconde, un User-Agent ou Referer identifiable, l'attribution OSM et le respect de l'ODbL.
Cette règle n'est pas un détail technique. Elle doit influencer UX, cache, proxy, batch, retries, monitoring et choix fournisseur. Un service qui dépasse la limite peut être bloqué et perdre sa capacité de recherche.
Si plus de 80 % du budget de requêtes est consommé par un seul écran pendant 10 minutes, alors cet écran doit être corrigé, caché ou déplacé vers une architecture dédiée avant extension.
Le monitoring doit donc remonter le budget par parcours, pas seulement par serveur. Une page publique, un back-office support et un script de nettoyage ne doivent pas partager le même niveau de priorité.
Refuser autocomplete, scraping et requêtes systématiques
La politique interdit l'autocomplete côté client construit sur l'API publique, les requêtes systématiques, les grilles de reverse geocoding, les listes complètes de codes postaux, les extractions de tous les POI et le scraping de `/details`.
Le produit doit donc différencier une recherche volontaire déclenchée par l'utilisateur d'un mécanisme automatique. Chaque touche frappée dans un champ ne doit pas appeler Nominatim public.
Par exemple, un champ d'adresse peut attendre une validation explicite ou utiliser un fournisseur adapté à l'autocomplete. Nominatim public ne doit pas devenir le moteur caché d'une saisie assistée grand public.
Cette règle doit apparaître dans les tickets produit. Si une fonctionnalité demande une suggestion à chaque frappe, alors le choix technique doit être fournisseur compatible, index interne ou autre moteur, pas l'API publique.
Cadrer les petits batchs exceptionnels
Les batchs réguliers ou massifs ne sont pas encouragés sur l'instance publique. Les petits traitements ponctuels doivent rester sur une seule machine, un seul thread, avec cache local et rythme très réduit si le traitement dure.
Le runbook doit dire quand arrêter. Si le fichier grandit, si le traitement devient périodique, ou si plusieurs workers apparaissent, alors il faut basculer vers fournisseur tiers, instance dédiée ou base OSM interne.
Si un batch dépasse 5 000 lignes ou revient chaque semaine, alors la décision doit être de changer d'architecture. La politique publique ne doit pas être négociée par un simple paramètre de retry.
Les petits batchs tolérables doivent garder un journal précis: taille du fichier, rythme, machine, thread, cache, erreurs, reprise et motif métier. Sans ce journal, le traitement devient vite impossible à défendre.
5. Décider proxy, cache, fournisseur ou instance
Mettre un proxy devant les usages applicatifs
Un proxy serveur permet de contrôler User-Agent, Referer, cache, quotas internes, logs, anonymisation, bascule fournisseur et repli. Il évite que chaque client appelle l'instance publique avec sa propre logique.
Le proxy doit refuser les patterns dangereux: autocomplete direct, requêtes en boucle, reverse en grille, absence de cache, payload trop large, debug activé ou appel sans contexte utilisateur.
Si le proxy reçoit plus de 100 requêtes identiques sur 24 heures sans cache hit, alors le problème vient de l'application. La correction doit précéder toute augmentation de capacité.
Le proxy peut aussi masquer les informations sensibles avant l'appel. Une adresse complète liée à un client identifiable ne doit pas être envoyée sans revue privacy, surtout dans des parcours où la donnée personnelle est évitable.
Concevoir un cache par décision
Le cache doit distinguer recherche utilisateur, adresse validée, reverse terrain, lookup d'objet OSM et résultat incertain. Chaque famille a une durée utile, une preuve et un risque de péremption différents.
Une adresse validée peut rester en cache longtemps avec sa date, son OSM ID et son statut. Une recherche ambigüe doit rester courte ou non publiée. Une coordonnée terrain peut demander une fraîcheur différente.
Le bon seuil consiste à imposer une date visible dès qu'un résultat sert une décision au-delà de 7 jours. Le support sait alors si l'écart vient d'OSM, du cache ou d'une correction interne.
Le cache doit aussi stocker la raison du rafraîchissement: expiration normale, correction support, changement de mapping, migration d'instance ou reprise après incident. Cette information évite de recalculer tout le stock par réflexe.
Prévoir fournisseur ou self-hosting avant le pic
Les besoins plus élevés doivent être anticipés: fournisseur tiers, instance Nominatim dédiée, import régional, tuning, base PostgreSQL/PostGIS, réplication, monitoring et stratégie de mise à jour des données OSM.
Le self-hosting n'est pas seulement une installation. Il implique disque, RAM, imports, mises à jour, sauvegardes, supervision, logs, politiques de ranking et compréhension des données OSM disponibles dans le territoire ciblé.
Si le service devient un élément de conversion, tracking, livraison ou relation client payante, alors le go-live doit inclure une alternative activable sans mise à jour applicative. Cette exigence est aussi prévue par la policy publique.
La trajectoire self-hosting doit être chiffrée honnêtement. Une instance dédiée apporte du contrôle, mais elle ajoute import, stockage, surveillance, mises à jour OSM, sauvegardes et compétences d'exploitation.
6. Brancher Nominatim au SI métier
Relier chaque résultat à un objet interne
Une intégration Nominatim robuste rapproche les résultats avec client, adresse, commande, site, établissement, point de service, intervention, ticket support, zone ou événement mobile selon l'usage réel.
Le modèle doit conserver requête, endpoint, format, OSM type, OSM ID, place_id, coordonnées, addressdetails, display_name, statut métier, source, date, cache et trace de corrélation.
Si un résultat ne peut pas être relié à un objet interne, il doit rester en observation ou analytics. Le publier comme vérité métier crée une donnée que personne ne saura corriger.
Construire un pipeline observable
Le pipeline doit séparer préparation de requête, appel REST, contrôle policy, cache, validation de réponse, normalisation, rapprochement, stockage, exposition et alerte. Une erreur peut venir de chacun de ces points.
Les entrées doivent garder payload, paramètres, pays, langue, instance et contexte utilisateur. Les sorties doivent distinguer réponse brute, résultat normalisé, statut de confiance, coût opérationnel et décision aval.
Cette instrumentation donne un owner au monitoring, au rollback et au support. Elle évite les analyses où produit, data et opérations discutent d'une adresse sans partager la même preuve.
Les événements internes doivent être publiés quand une adresse change de statut. Acceptée, refusée, ambiguë ou recalculée, chaque transition doit être visible dans les outils qui portent la relation client.
Prévoir les reprises sans créer de doublon
Une reprise Nominatim doit pouvoir rejouer une recherche, un reverse, un lookup ou une correction de mapping sans écraser silencieusement les décisions déjà publiées dans les outils aval.
Le connecteur doit stocker version de règle, date logique, résultat précédent, résultat nouveau, motif de changement et action autorisée. Cette chronologie protège support, data et métier.
Si une reprise modifie plus de 3 % des adresses actives, alors la synchronisation aval doit passer en validation métier. La correction technique peut sinon devenir un incident commercial.
La reprise doit rester idempotente. Même requête, même instance, même version de mapping et même date logique doivent produire une décision stable ou une divergence explicitement tracée, jamais un doublon silencieux.
7. Traiter qualité OSM, langue et ambiguïtés
Assumer une donnée OSM vivante
Nominatim indexe OpenStreetMap. La qualité dépend donc des contributions, du pays, des adresses présentes, des tags, des limites administratives et des choix de configuration de l'instance utilisée.
Le connecteur doit distinguer résultat trouvé, résultat accepté, résultat ambigü et résultat refusé. Un résultat plausible n'est pas automatiquement une adresse utilisable pour livraison, facturation ou engagement contractuel.
Si le taux de corrections support dépasse 4 % sur 30 jours, alors le dictionnaire de règles doit être revu: pays, layer, featureType, langue, seuil d'acceptation et fallback.
Cette revue doit regarder les résultats refusés autant que les résultats acceptés. Les faux positifs disent souvent plus sur la qualité du mapping que les recherches qui tombent naturellement juste.
Gérer `accept-language` et différences de contexte
Nominatim peut retourner des résultats différents selon l'en-tête ou le paramètre `accept-language`. Un navigateur envoie souvent une langue, tandis qu'un outil en ligne de commande peut ne rien envoyer.
Cette différence doit être normalisée côté middleware. Le support ne doit pas comparer une réponse issue du navigateur avec une réponse serveur sans connaître la langue et les paramètres exacts.
Par exemple, un portail bilingue peut stocker un libellé stable dans le SI et garder les variantes d'affichage pour l'interface. Le résultat technique ne doit pas changer la clé métier.
Décider quoi faire des résultats ambigus
Les doublons, dédupes, POI proches, rues homonymes, communes voisines et frontières administratives créent des cas où Nominatim propose un bon candidat sans garantir qu'il soit le bon pour le métier.
Le modèle doit exposer décision, raison de rejet, candidats alternatifs et action autorisée. Une adresse ambiguë doit devenir un statut maîtrisé, pas un résultat silencieusement accepté.
Si deux candidats sont à moins de 50 mètres avec des OSM IDs différents et des noms similaires, alors le connecteur doit demander une revue plutôt que fusionner automatiquement. Ce cas revient souvent autour des bâtiments et POI.
8. Plan d'action Nominatim
Prioriser le premier parcours responsable
D'abord, il faut choisir un usage court: recherche interne, reverse terrain ponctuel, validation d'adresse modérée, lookup d'objet OSM ou prototype de rapprochement. Le périmètre doit dire quelle décision dépend du résultat.
La fiche de cadrage doit lister endpoint, instance, paramètres, format, User-Agent, attribution, cache, limite, owner, fallback, données personnelles interdites et preuve support. Si cette fiche manque, le projet démarre avec une dette éthique et technique.
En priorité, l'équipe doit refuser autocomplete public, batch régulier, extraction de tous les POI, tracking client et revente. Ces usages exigent une autre architecture avant le développement.
Prototyper avec les vrais paramètres
Ensuite, le prototype doit utiliser les vrais pays, langues, viewbox, countrycodes, layer, featureType, formats et volumes approximatifs. Un test sur trois adresses connues ne révèle pas les difficultés de production.
Le prototype doit comparer au moins 3 scénarios: adresse exacte, adresse ambiguë et résultat introuvable. Cette comparaison montre si le mapping sait distinguer accepté, à confirmer et refusé.
Si le prototype ne produit pas une décision d'acceptation, de rejet ou de reprise, alors il reste une démonstration technique. La sortie attendue doit être une règle, pas seulement une coordonnée.
Développer proxy, cache et observabilité
Puis, le connecteur doit intégrer proxy, cache, timeout, retries sobres, backoff, User-Agent explicite, journalisation, contrôle policy, monitoring, erreurs lisibles et repli quand le service public n'est pas disponible.
Le passage serveur doit être obligatoire pour les décisions sensibles. L'interface peut déclencher une recherche, mais le backend doit maîtriser débit, cache, traces, anonymisation et choix d'instance.
Le scénario dégradé doit être écrit comme un comportement normal: afficher une adresse à confirmer, utiliser un cache récent, différer un batch, basculer fournisseur ou escalader au support.
Fixer des seuils de go-live
Le go-live doit exiger des seuils mesurables: 100 % des appels critiques traçables, zéro autocomplete public, cache actif, attribution visible, User-Agent explicite et moins de 2 % d'adresses critiques sans décision.
Ces seuils doivent être reliés à une action. Si l'attribution manque, on bloque le lancement; si le cache est absent, on limite le périmètre; si les ambiguïtés montent, on ajoute une revue métier.
Si le taux d'erreurs dépasse 1 % sur 24 heures pour un parcours critique, alors le flux doit repasser en mode contrôlé. Le seuil protège support, conversion et respect de la policy.
La recette doit aussi vérifier latence, cache hit, statut `/status`, fallback, qualité des réponses, langue, OSM IDs, place_id et action support. Un code HTTP 200 ne valide pas le métier.
Organiser les 30 premiers jours
Plus tard seulement, l'équipe peut élargir parcours, pays ou volumes. Les 30 premiers jours doivent mesurer appels, erreurs, cache hit, requêtes refusées, corrections manuelles, tickets support et usages non conformes.
Le rituel de suivi doit produire des décisions: augmenter un cache, réduire un formulaire, déplacer un batch, changer de fournisseur, préparer self-hosting ou retirer un usage qui ne respecte pas la politique.
Cette cadence évite de transformer Nominatim en boîte noire de géocodage. Le connecteur reste un actif de run, avec une valeur mesurée, des limites connues et une trajectoire d'amélioration.
La décision d'élargir doit rester liée à un bénéfice observé: moins de corrections d'adresse, meilleur taux de validation, support plus rapide ou réduction d'un traitement manuel auparavant coûteux.
9. Erreurs fréquentes Nominatim
Les pièges qui mènent au blocage
- Brancher directement l'instance publique depuis le front, sans proxy, cache, User-Agent explicite, attribution et capacité de bascule rapide.
- Construire un autocomplete sur chaque frappe avec Nominatim public, alors que cet usage est explicitement interdit par la politique d'usage.
- Utiliser Nominatim pour télécharger tous les POI ou tous les codes postaux d'une zone, alors que ce besoin relève d'extraits OSM ou d'Overpass.
- Stocker seulement `display_name` et coordonnées, puis perdre `osm_type`, `osm_id`, `place_id`, paramètres, langue et source qui expliquent le résultat.
- Confondre `place_id` avec un identifiant stable entre instances, puis découvrir la dette au moment d'une migration vers fournisseur ou self-hosting.
Ces erreurs ne bloquent pas toujours le prototype. Elles deviennent visibles quand le trafic monte, que l'accès public est ralenti ou retiré, ou que le support doit expliquer une adresse qui semblait évidente.
Le signal faible le plus utile se voit quand l'équipe ajoute des retries pour compenser le débit, puis des workers pour compenser les retries. À ce moment, l'architecture est déjà en conflit avec l'usage attendu.
Le bon arbitrage consiste à refuser une nouvelle famille d'appels tant que endpoint, limite, cache, owner, fallback et preuve ne sont pas écrits. La ressource OSM reste alors respectée.
Le tableau de décision peut rester très simple: type attendu, exemple valide, exemple refusé, message utilisateur et action support. En 30 minutes, cette grille évite souvent plusieurs semaines de corrections dispersées.
Éviter les mélanges entre adresse et recherche de lieux
Une erreur plus discrète consiste à traiter adresse postale, POI, commune, bâtiment, frontière et résultat naturel comme une seule catégorie. Nominatim peut renvoyer plusieurs types d'objets qui n'ont pas la même valeur.
Cette confusion crée des interfaces rassurantes mais difficiles à défendre. Une commune, un café, une rue et un bâtiment peuvent tous être trouvés, mais ils ne doivent pas déclencher la même règle métier.
Si une règle ne peut pas dire quel `class`, quel `type`, quel `layer` et quel niveau d'adresse sont acceptés, alors le connecteur doit être relu avant extension. La qualité de run commence par cette frontière.
La documentation doit montrer des exemples acceptés et refusés. Une commune trouvée, un commerce homonyme, une rue incomplète et un bâtiment sans numéro doivent conduire à des statuts différents.
10. Recette, rollback et support Nominatim
Tester les familles d'appels avant ouverture
La recette doit couvrir recherche libre, recherche structurée, reverse, lookup, status, résultat introuvable, résultat ambigu, pays filtré, langue différente, viewbox, bounded, cache expiré et instance indisponible.
Chaque cas doit produire une preuve: endpoint, paramètres, User-Agent, format, statut HTTP, durée, cache hit, OSM ID, place_id, résultat retenu, résultat rejeté, décision métier et action support.
Un seuil de sortie protège le lancement: 100 % des appels critiques traçables, aucune requête interdite, moins de 2 % de résultats ambigus non classés et fallback documenté pour chaque parcours.
Préparer un rollback sans mise à jour applicative
Le rollback ne doit pas demander une mise à jour mobile ou front. L'application doit pouvoir changer d'instance, réduire un formulaire, désactiver un reverse ou basculer fournisseur côté serveur.
Si 3 incidents critiques touchent Nominatim en 24 heures, si le cache est contourné, ou si plus de 5 % des réponses publiées changent après reprise, alors le mode contrôlé doit s'activer.
Cette approche garde les usages fiables ouverts. Elle évite le faux choix entre débrancher toute la géolocalisation et laisser un parcours critique abuser d'une ressource publique.
Le rollback doit être testé avant lancement avec un vrai changement de configuration. Si la bascule fournisseur ou instance prend plus de 20 minutes en recette, elle prendra trop longtemps pendant un incident.
Donner au support une lecture actionnable
La fiche support doit traduire les résultats Nominatim en statuts lisibles: adresse confirmée, lieu ambigu, pays filtré, résultat introuvable, cache utilisé, instance indisponible ou usage refusé par policy.
Le support doit pouvoir répondre à quatre questions: quelle requête a été envoyée, quelle instance a répondu, pourquoi le résultat a été accepté, et quelle action est autorisée quand l'utilisateur conteste.
Si une personne qui n'a pas participé au projet ne peut pas expliquer un cas simple en moins de 15 minutes, alors l'intégration fonctionne techniquement mais n'est pas encore prête pour un run autonome.
Les réponses support doivent rester cohérentes avec la politique publique. Une adresse introuvable ne doit pas déclencher un script de recherche massif, mais une correction ciblée, un fournisseur adapté ou une consigne métier.
Mesurer la stabilité après mise en production
Les 30 premiers jours doivent suivre par parcours: appels, latence, erreurs, cache hit, requêtes bloquées par policy interne, ambiguïtés, corrections manuelles, tickets support et régressions de conversion.
Cette mesure décide les extensions. Un parcours stable peut être élargi, tandis qu'un parcours ambigu doit être limité, corrigé ou déplacé vers fournisseur ou instance dédiée avant de toucher plus d'utilisateurs.
Après ce premier mois, l'équipe doit pouvoir dire quels usages restent compatibles avec l'instance publique, lesquels demandent un fournisseur et lesquels justifient une instance Nominatim contrôlée.
Le bon résultat n'est pas seulement une coordonnée trouvée. Le bon résultat est une décision géographique traçable, respectueuse de la politique OSMF, compréhensible par le support et soutenable dans le temps.
Questions fréquentes Nominatim
À quoi sert l'API Nominatim ? Nominatim sert à rechercher des objets OpenStreetMap avec `/search`, à faire du reverse geocoding avec `/reverse`, à relire des détails d'adresse avec `/lookup` et à vérifier l'état du serveur avec `/status`.
Peut-on utiliser l'instance publique Nominatim pour un service commercial ? L'instance publique a une capacité limitée et une politique d'usage stricte. Un service commercial, intensif, de tracking, de revente ou de géocodage régulier doit prévoir fournisseur tiers ou instance dédiée.
Dawap peut-il accompagner une intégration Nominatim ? Oui. Dawap accompagne le cadrage, le développement et l'industrialisation de flux Nominatim pour search, reverse, lookup, cache, proxy, respect de la policy, observabilité, fallback et instance dédiée.
Guides complémentaires après Nominatim
La ressource API Overpass OpenStreetMap complète Nominatim quand le besoin porte sur l'extraction d'objets OSM par tags, zones et catégories plutôt que sur le géocodage des meilleurs résultats.
La ressource API Geoapify apporte un angle utile lorsque l'équipe veut comparer Nominatim avec des services packagés de geocoding, autocomplete, places, routing, matrix, isoline, cache, quotas et coûts.
La ressource API Pelias aide à explorer une autre approche open source du géocodage, plus orientée moteur composable, données multiples et personnalisation de l'index.
La landing API cartographie et géolocalisation relie ce sujet aux offres de cadrage géographique, tandis que la page intégrateur Nominatim précise comment transformer Nominatim en connecteur maintenable et conforme.
Conclusion opérationnelle Nominatim
Une intégration Nominatim réussie ne se juge pas à une coordonnée reçue. Elle se juge à la capacité de choisir le bon endpoint, respecter la policy, conserver la preuve et protéger les usages sensibles.
Le bon ordre reste stable: choisir le parcours prioritaire, cadrer les paramètres, mettre un proxy, activer le cache, tracer les OSM IDs, refuser les usages interdits et préparer une alternative.
Cette discipline garde Nominatim à sa bonne place: un moteur de géocodage OpenStreetMap puissant, mais toujours relié à des seuils, des propriétaires, des règles de production et des preuves visibles.
Si vous voulez brancher Nominatim dans un SI sans abuser de l'instance publique ni fragiliser vos données, notre accompagnement Integration API peut cadrer les endpoints, le proxy, le cache, l'observabilité, les reprises, la conformité d'usage et la trajectoire vers fournisseur ou instance dédiée.
