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 TomTom Search
TomTom Search est très présent dans les logiciels automobiles, de gestion de flotte et de navigation, des secteurs où la précision du géocodage le long d'un itinéraire compte autant que la simple correspondance d'adresses. Sa clé d'API est envoyée comme paramètre de requête, et ses réponses de géocodage se présentent sous la forme d'un tableau results avec un objet position et un bloc address contenant des champs comme freeformAddress et municipality.
Les logiciels de ce secteur sont souvent développés par des équipes qui n'ont pas choisi TomTom à la légère ; la décision s'est généralement accompagnée d'une évaluation préalable des alternatives, ce qui signifie qu'une migration ultérieure est plutôt motivée par les coûts, la planification de la redondance ou un effort plus large de consolidation des fournisseurs que par une insatisfaction envers les données elles-mêmes. Ce contexte compte pour définir le périmètre d'une migration : elle est rarement urgente, et il y a généralement le temps de tester correctement.
L'hôte de compatibilité TomTom de My Geocode reproduit le tableau results, l'objet position et les champs d'adresse exactement tels que TomTom les renvoie, les textes de copyright, de conditions et de confidentialité étant la seule différence. La référence des champs est documentée sur /compatibility/tomtom/. Le code construit autour de results[0].position.lat et results[0].address.freeformAddress devrait continuer de fonctionner une fois l'hôte et la clé changés.
Pour les logiciels de flotte et automobiles en particulier, quelques points méritent une double vérification avant la mise en production :
- Les tâches de géocodage par lots planifiées, car elles constituent une bonne première cible pour tester un nouvel hôte sans toucher aux appels en temps réel destinés aux clients
- La logique de nouvelle tentative et de délai d'expiration ajustée aux temps de réponse propres à TomTom, car ces valeurs sont souvent fixées empiriquement plutôt que documentées et peuvent nécessiter un nouvel ajustement
- Tout code qui lit les champs de confiance ou de qualité de correspondance propres à TomTom, à comparer côte à côte avec les équivalents documentés de l'hôte de compatibilité
L'authentification prend en charge un en-tête X-API-Key, un en-tête Authorization: Bearer, l'authentification HTTP Basic ou un paramètre de requête, ce qui couvre la manière dont votre client TomTom actuel envoie sa clé aujourd'hui.
Côté coûts, la structure supprime l'étape habituelle de négociation d'un contrat entreprise : 2 500 requêtes par jour sont gratuites sans clé, et chaque clé ajoute ses propres 2 500 requêtes gratuites par jour, comptées par réseau. Au-delà de ce quota, 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 de compatibilité, étant facturé de façon identique. Pour une activité de flotte qui effectue du géocodage à un volume significatif, disposer d'un tarif unique plutôt que d'un accord entreprise par paliers simplifie considérablement la prévision des coûts.
Si votre utilisation de TomTom comprend aussi des données d'itinéraire ou de trafic en plus du géocodage, cette partie de la pile sort du périmètre d'une migration limitée au géocodage et peut rester chez TomTom pendant que les appels de recherche d'adresses migrent indépendamment. Découper une migration selon des frontières fonctionnelles nettes comme celle-ci réduit généralement davantage le risque que de tout déplacer en une seule version.