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.
Google Maps Platform est souvent la première API de géocodage qu'une équipe intègre, surtout parce que c'est le nom le plus connu du secteur. Son modèle d'authentification est désormais familier à la plupart des développeurs : une clé d'API liée à un compte de facturation dans un projet Google Cloud, envoyée en paramètre de requête à chaque appel. Ses réponses de géocodage reviennent sous forme d'objet JSON avec un tableau results, un champ status, une chaîne formatted_address et un objet imbriqué geometry.location contenant la latitude et la longitude.
Ce qui inquiète généralement les équipes à l'idée de changer, c'est le code d'analyse construit autour de ce format exact. Composants d'adresse, limites de la fenêtre d'affichage, identifiants de lieux : tout cela est lu par des fonctions dispersées dans le code, et réécrire ces fonctions est le genre de tâche que personne ne veut planifier. C'est précisément le problème qu'un hôte compatible est conçu pour éviter.
My Geocode exploite un hôte compatible Google Maps qui reproduit champ par champ le format de requête et de réponse de géocodage de Google. Le seul texte de la réponse qui nous appartient est celui relatif aux droits d'auteur, aux conditions et à la confidentialité ; tout le reste, y compris les noms de champs et leur imbrication, correspond à ce que votre code attend déjà. En pratique, migrer signifie changer un nom d'hôte et une clé, sans toucher à un analyseur. Les détails se trouvent sur /compatibility/google-maps/.
Ce qui reste identique :
Ce qui change :
Comme une clé peut être envoyée dans un en-tête X-API-Key, un en-tête Authorization: Bearer, via l'authentification HTTP Basic ou en paramètre de requête, une bibliothèque cliente qui s'authentifie déjà à sa manière continue généralement de fonctionner sans modification. Cette souplesse compte plus qu'il n'y paraît, car une grande partie des difficultés de migration vient en pratique de bibliothèques qui supposent une manière bien précise de transmettre les identifiants.
Côté tarifs, le modèle est simple : 2 500 requêtes par jour sont gratuites depuis n'importe quelle adresse sans clé, et chaque clé dispose aussi de 2 500 requêtes gratuites par jour, décomptées par réseau. Au-delà, c'est du crédit prépayé à 0,0001 € par requête ou un forfait Unlimited à 50 € par mois, et chaque endpoint, y compris chaque hôte compatible, coûte le même prix. Il n'y a pas de paliers distincts à négocier selon le produit que vous appelez.
Des champs supplémentaires facultatifs (altitude du sol, signaux de menace IP et informations réseau) sont disponibles sur tout hôte compatible en ajoutant mg_extras=1 ou un en-tête X-MG-Extras, sans casser le format dont dépend le reste de votre code. Vous disposez ainsi d'une voie vers des données plus riches plus tard, sans seconde migration.
Si votre intégration utilise aussi le géocodage inverse, la saisie semi-automatique d'adresses ou la recherche de codes postaux, le même changement d'hôte et de clé s'applique, mais il vaut la peine de comparer le format exact des requêtes et des réponses de ces endpoints avec votre code actuel avant la bascule, car les conventions de formatage des adresses varient selon les pays. Tester une partie du trafic de production sur le nouvel hôte avant la bascule complète est une bonne façon de confirmer que le format correspond à vos attentes. Consultez /docs/compatibility/ pour la référence complète des champs de tous les hôtes compatibles.