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.
Remapper les résultats en cache après un changement de fournisseur
La mise en cache est une optimisation judicieuse et courante pour le géocodage, car les mêmes adresses sont souvent recherchées à plusieurs reprises et il y a peu de raisons de payer ou d'attendre une nouvelle recherche à chaque fois. Mais un cache constitué pendant des mois ou des années à partir des résultats d'un fournisseur pose un problème précis lors d'une migration : que deviennent toutes ces données en cache une fois que le fournisseur qui les a produites change ?
La position générale la plus sûre est que les résultats en cache liés à la précision des coordonnées, aux conventions de formatage des adresses ou à la confiance de correspondance d'un fournisseur donné ne doivent pas être silencieusement considérés comme équivalents aux résultats d'un nouveau fournisseur, même si ce dernier est globalement précis. La précision des coordonnées, en particulier, peut différer subtilement d'un fournisseur à l'autre, et une application qui stocke en cache une latitude et une longitude avec plusieurs décimales peut dépendre de caractéristiques de précision propres au fournisseur qui a produit ce chiffre à l'origine.
Quelques approches pratiques, à peu près par ordre croissant de rigueur :
- Étiquetez les entrées en cache avec leur fournisseur d'origine. Si votre cache n'enregistre pas déjà quel fournisseur a produit un résultat donné, ajoutez ce champ avant de migrer, afin de pouvoir distinguer à l'avenir les anciennes et les nouvelles entrées au lieu de traiter tout le cache comme un seul ensemble indifférencié
- Définissez une expiration pour les anciennes entrées en cache. Plutôt que d'invalider tout le cache d'un coup, ce qui peut provoquer un pic soudain de requêtes en direct vers le nouveau fournisseur, laissez les anciennes entrées expirer naturellement selon le TTL que votre cache utilise déjà, afin que la transition vers des résultats frais du nouveau fournisseur se fasse progressivement
- Revérifiez de façon sélective les entrées en cache à forte valeur. Pour les adresses particulièrement importantes, comme un site principal de l'entreprise ou une adresse de livraison fréquemment utilisée, il vaut la peine de refaire explicitement la recherche auprès du nouveau fournisseur plutôt que d'attendre l'expiration naturelle du cache, car ce sont les entrées où un écart subtil serait le plus remarqué
Comme les résultats de géocodage direct, en particulier, peuvent varier d'un fournisseur à l'autre dans leur formatage exact et leur précision, c'est un cas où tester un échantillon significatif de vos véritables adresses en cache auprès du nouveau fournisseur avant de basculer complètement est plus utile que de tester avec des adresses synthétiques ou choisies à la main. Les vraies données en cache reflètent vos vrais usages, cas limites compris.
Les hôtes de compatibilité de My Geocode renvoient les données avec la même structure de champs que le fournisseur d'origine : tout code qui lit et stocke des entrées de cache par nom de champ ne devrait donc pas avoir besoin d'être restructuré pendant une migration, seules les valeurs elles-mêmes pouvant différer légèrement d'un fournisseur à l'autre pour une adresse donnée. Les en-têtes de quota présents sur chaque réponse, dont X-Quota-Used et X-Credits-Remaining, documentés sur /docs/rate-limits/, méritent aussi d'être pris en compte dans un plan d'invalidation du cache, car une vague soudaine d'absences en cache se traduit directement par un pic de volume de requêtes, et cadencer cette vague en fonction de votre quota est un élément modeste mais réellement utile de la planification d'une migration.
Traiter la migration du cache comme un petit projet à part entière, plutôt que comme un détail qui se réglerait automatiquement une fois le changement de fournisseur en production, évite toute une catégorie de problèmes subtils de qualité des données, bien plus difficiles à diagnostiquer après coup qu'à anticiper.