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 HERE Geocoding and Search
HERE Geocoding and Search est très présent dans les logiciels automobiles et logistiques, des secteurs où un compte entreprise avec un interlocuteur attitré et un contrat d'assistance est la norme. L'authentification repose généralement sur une clé d'API ou un jeton OAuth, et les réponses reviennent sous forme de tableau items où chaque élément porte un objet position et un bloc address structuré avec des champs comme label, countryCode et houseNumber.
Cette structure est généralement bien documentée en interne dans les entreprises qui en dépendent, car HERE est souvent choisi précisément pour la qualité de son analyse d'adresses dans une région donnée ou pour son intégration de calcul d'itinéraires ailleurs dans la pile. Une migration qui casse le format de réponse casse d'un coup tout ce code en aval, c'est pourquoi la compatibilité compte ici davantage que le coût du changement de compte lui-même.
L'hôte compatible HERE de My Geocode reproduit le tableau items et ses champs imbriqués position et address exactement tels que HERE les renvoie, seul le texte relatif aux droits d'auteur, aux conditions et à la confidentialité étant remplacé. Consultez /compatibility/here/ pour la référence des champs. Dans la plupart des cas, la modification nécessaire dans le code de l'application porte sur le nom d'hôte et la clé, et sur rien dans le code qui lit items[0].position ou items[0].address.label.
Les équipes d'entreprise qui quittent HERE ont souvent intégré le géocodage dans plusieurs services plutôt qu'un seul : il est donc utile de commencer par recenser chaque point d'appel. Traitements par lots, formulaires de validation d'adresses, routage des livraisons et outils d'administration ont tendance à appeler la même API indépendamment les uns des autres. Les migrer un service à la fois, en commençant par un service à faible trafic, est une façon judicieuse de valider le nouvel hôte en conditions réelles avant de basculer les appels les plus volumineux.
Côté authentification, une clé émise par My Geocode 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. Si votre bibliothèque cliente HERE existante s'authentifie déjà d'une manière particulière, la diriger vers le nouvel hôte avec une nouvelle clé suffit généralement, puisque la bibliothèque elle-même n'a pas besoin de changer.
Les tarifs suppriment un niveau de négociation que comportent souvent les contrats d'entreprise. Il n'y a pas de structure de compte par paliers : 2 500 requêtes par jour sont gratuites sans clé, chaque clé ajoute 2 500 autres requêtes gratuites par jour, décomptées par réseau, et au-delà c'est du crédit prépayé à 0,0001 € par requête ou une clé Unlimited à 50 € par mois. Chaque endpoint, y compris cet hôte compatible, coûte le même prix : il n'y a donc pas de négociation séparée pour le volume de géocodage par rapport au volume de recherche ou de suggestions automatiques.
Si une partie de votre utilisation de HERE concerne les suggestions automatiques plutôt que le géocodage pur, il vaut la peine d'en faire une étape de migration à part entière, car les endpoints de type saisie semi-automatique ont leur propre format de réponse et un schéma de requête qui dépend d'une saisie partielle, et ils méritent des tests séparés plutôt que d'être intégrés à la bascule du géocodage. La consommation du quota sur chaque requête, y compris sur l'hôte compatible, est visible dans des en-têtes de réponse comme X-Quota-Used et X-Credits-Remaining, documentés sur /docs/rate-limits/.