Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage
Les automatisations sans code construites autour d'une étape de géocodage demandent une autre approche de migration que le code sur mesure. Voici comment gérer ce changement.
Migrer depuis OpenStreetMap Nominatim
Nominatim occupe une place inhabituelle parmi les options de géocodage, car c'est à la fois un logiciel open source que vous pouvez exécuter vous-même et une instance de démonstration publique que chacun peut interroger directement, régie par une politique d'utilisation qui attend un en-tête User-Agent descriptif et un rythme de requêtes raisonnable plutôt qu'une clé d'API formelle. Sa réponse JSON comprend une chaîne display_name, une paire lat et lon sous forme de chaînes plutôt que de nombres, et un objet address suivant les conventions de balisage propres à OpenStreetMap, comme road, suburb et postcode.
Les équipes se heurtent généralement à un mur avec l'instance publique dès que leur trafic dépasse ce qu'une ressource communautaire partagée est censée absorber, et l'auto-hébergement de Nominatim est une vraie option mais une option lourde : il faut télécharger et importer un volumineux extrait de données OpenStreetMap, planétaire ou régional, maintenir ces données à jour et faire tourner soi-même l'infrastructure serveur indéfiniment. Ce compromis, du travail d'infrastructure et de maintenance en échange du contrôle, mérite d'être considéré honnêtement avant de s'engager dans l'une ou l'autre voie.
L'hôte de compatibilité Nominatim de My Geocode reproduit exactement la structure des champs display_name, lat, lon et d'adresse, les textes de copyright, de conditions et de confidentialité étant le seul contenu qui diffère de la sortie de Nominatim. Les détails de référence se trouvent sur /compatibility/nominatim/. Le code écrit pour l'instance publique de Nominatim, y compris ses champs de coordonnées de type chaîne, devrait analyser les réponses de l'hôte de compatibilité sans modification.
Ce qui change réellement dans cette migration précise :
- Plus d'obligation d'en-tête User-Agent liée à une politique d'utilisation partagée ; l'authentification utilise à la place une clé, envoyée via un en-tête
X-API-Key, un en-têteAuthorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête - Un quota quotidien prévisible au lieu d'une limite de débit non précisée sur une ressource partagée : 2 500 requêtes gratuites par jour sans clé, et 2 500 autres gratuites par clé et par jour, comptées par réseau
- Aucune infrastructure à faire tourner ni extrait de données OpenStreetMap à maintenir, puisque le service hébergé s'en charge
Au-delà du quota gratuit, la tarification repose sur du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, et chaque endpoint, y compris cet hôte de compatibilité, est facturé au même prix que tous les autres de la plateforme.
Pour les équipes qui appréciaient particulièrement l'ancrage de Nominatim dans les données géographiques ouvertes, il est bon de savoir que les noms de champs fondés sur les conventions d'OpenStreetMap, comme suburb et postcode plutôt que des termes plus génériques, sont repris dans la structure de cet hôte de compatibilité : le vocabulaire d'adresse que votre code attend déjà devrait donc rester cohérent de l'autre côté de la migration.