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.
Gérer les différences de schéma de réponse pendant une migration
Même le fournisseur de remplacement le plus soigneusement choisi différera de l'original sur au moins quelques points de détail, et repérer ces différences avant qu'elles n'apparaissent en production est un exercice bien différent de celui qui consiste à les découvrir après qu'un client a signalé un problème. Une approche structurée de la comparaison des schémas détecte la plupart de ces différences tôt, à moindre coût et sans drame.
Un bon point de départ consiste à distinguer trois catégories de différences, car chacune appelle une réponse différente :
Différences de présence des champs. Un champ lu par votre code peut être présent dans la réponse d'un fournisseur et absent, ou présent seulement sous condition, dans celle d'un autre. C'est la catégorie la plus facile à détecter par comparaison statique : prenez un exemple de réponse de chaque fournisseur pour la même entrée et comparez directement les listes de champs.
Différences de type ou de format des champs. Une même valeur conceptuelle peut être représentée différemment : une coordonnée sous forme de deux champs numériques séparés ou d'une seule chaîne combinée, un score de confiance sous forme de nombre entre 0 et 1 ou de catégorie (« high », « medium », « low »), ou un horodatage dans un format complètement différent. Pour les détecter, il faut lire les valeurs réelles, pas seulement les noms des champs.
Différences sémantiques sous des noms de champs identiques. C'est la catégorie la plus difficile : deux fournisseurs utilisent exactement le même nom de champ mais lui donnent un sens subtilement différent, comme un champ « accuracy » qu'un fournisseur calcule d'après la correspondance des composants d'adresse et qu'un autre calcule selon une méthodologie interne entièrement différente. Une comparaison fondée uniquement sur les noms de champs ne le détectera pas ; il faut comprendre ce qu'une valeur représente réellement dans chaque système, généralement en lisant attentivement la documentation des deux fournisseurs plutôt qu'en supposant qu'un nom commun implique un sens commun.
Un processus concret : prenez un échantillon représentatif de requêtes historiques réelles, couvrant idéalement au moins vos schémas de requête les plus courants et vos cas limites délicats connus, exécutez-les auprès de l'ancien et du nouveau fournisseur, et comparez les résultats de manière systématique plutôt qu'en jetant un œil à quelques exemples. Automatiser cette comparaison, même avec un simple script qui signale toute différence structurelle ou toute différence de valeur significative, vaut le temps de mise en place pour toute intégration qui dépasse une très petite taille.
Les hôtes compatibles de My Geocode sont conçus précisément pour réduire au minimum les deux premières catégories de différences avec le fournisseur que chacun reproduit, en reproduisant exactement la présence et le format des champs, à l'exception des mentions de droits d'auteur, des conditions et de la confidentialité, comme le documente chaque hôte sur /docs/compatibility/. Il reste donc la troisième catégorie, les différences sémantiques sous un même nom de champ, comme principal point à tester directement même avec un hôte compatible, puisqu'une correspondance de format ne garantit jamais totalement une correspondance de méthodologie sous-jacente.
Prévoir un vrai temps pour ce travail de comparaison avant de considérer une migration comme terminée, plutôt que de juger suffisant un test réussi sur une poignée d'adresses courantes, est l'un des moyens les plus fiables d'éviter le genre de problème subtil de qualité des données qui met des semaines à être remarqué et plus longtemps encore à être rattaché à sa véritable cause.