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.
Héberger soi-même Nominatim ou utiliser un hôte compatible hébergé
Auto-héberger Nominatim est une voie légitime et bien documentée, et de nombreuses organisations le font avec succès, en particulier celles qui ont de solides raisons de garder leur infrastructure de géocodage entièrement au sein de leur propre réseau. Mais le compromis est réel et mérite d'être énoncé clairement plutôt qu'éludé : vous prenez en charge le téléchargement et l'import d'un extrait de données OpenStreetMap, le provisionnement d'assez d'espace disque et de mémoire pour servir les requêtes à une vitesse acceptable, la mise à jour raisonnablement régulière de ces données au fil des évolutions d'OpenStreetMap, et l'exploitation du serveur avec le niveau de disponibilité dont votre application a besoin.
Rien de tout cela n'est difficile au sens d'obscur ou de non documenté. C'est difficile au sens où cela ne s'arrête jamais. Une instance Nominatim auto-hébergée qui fonctionnait bien le jour de son lancement peut perdre en pertinence un an plus tard si personne n'a planifié le processus de mise à jour, et comprendre pourquoi une adresse précise a cessé de correspondre correctement suppose de maîtriser à la fois le logiciel Nominatim et les conventions des données OpenStreetMap sous-jacentes.
Un remplacement compatible (drop-in) hébergé supprime entièrement cette couche opérationnelle, au prix d'un passage de votre trafic de géocodage par l'infrastructure d'un tiers plutôt que par la vôtre. C'est là la véritable décision à prendre, et non la question de savoir si une option est tout simplement meilleure.
L'hôte de compatibilité Nominatim de My Geocode reproduit exactement la structure de réponse que renvoie une instance Nominatim auto-hébergée ou publique : display_name, lat et lon sous forme de chaînes, et un objet d'adresse reprenant la nomenclature de champs d'OpenStreetMap, comme suburb et postcode, seuls les textes de copyright, de conditions et de confidentialité étant différents. Les détails de référence se trouvent sur /compatibility/nominatim/. Un code écrit pour une instance auto-hébergée ne devrait nécessiter qu'un changement d'hôte et d'authentification, puisque la structure des champs est conservée.
Quelques questions auxquelles il vaut la peine de répondre honnêtement avant de choisir l'une ou l'autre voie :
- Votre organisation a-t-elle une raison précise de conformité ou de résidence des données que l'auto-hébergement satisfait et qu'un service hébergé ne satisferait pas
- Combien de temps d'ingénierie consacrez-vous actuellement à la maintenance de l'instance auto-hébergée, et combien vaudrait ce temps s'il était employé ailleurs
- Votre volume de trafic est-il assez élevé et régulier pour justifier déjà les coûts d'infrastructure, ou fluctue-t-il d'une manière qu'un coût prévisible par requête ou par abonnement absorbe plus proprement
Si la réponse penche vers l'abandon de l'infrastructure auto-hébergée, l'authentification côté hébergé utilise une clé envoyée via X-API-Key, Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, qui remplace la politique d'utilisation fondée sur le User-Agent qu'attend une instance Nominatim publique. La tarification comprend 2 500 requêtes gratuites par jour sans clé, 2 500 requêtes gratuites supplémentaires par clé et par jour, comptées par réseau, puis du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois, le même tarif que pour tous les autres endpoints de la plateforme. Pour de nombreuses équipes, comparer les coûts de serveur, le temps de maintenance et le volume de requêtes à cette tarification est le moyen le plus rapide de trancher la question dans un sens ou dans l'autre.