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.
Ce que le préavis d'un fournisseur signifie pour votre migration
Le préavis d'un fournisseur, c'est-à-dire l'intervalle entre l'annonce d'un abandon ou d'une fermeture et la date à laquelle il prend effet, est l'une des ressources les plus précieuses, et les plus souvent gaspillées, d'une migration forcée. Il existe précisément pour laisser aux équipes qui intègrent le service le temps de réagir de manière ordonnée, mais un nombre surprenant de migrations finissent quand même bâclées dans les derniers jours, car les premières semaines d'un préavis ont tendance à être consacrées à d'autres priorités avant que l'échéance ne paraisse réelle.
L'erreur de fond consiste à traiter une échéance lointaine comme s'il n'y avait pas d'échéance du tout. Un préavis de plusieurs mois semble, au départ, laisser largement le temps de planifier une migration au moment qui conviendra. Ce moment reste rarement opportun bien longtemps, car d'autres travaux continuent d'arriver à leur propre rythme, et une échéance qui semblait confortablement lointaine a tendance à devenir urgente d'un seul coup.
Une meilleure façon d'utiliser un préavis consiste à partir de la date limite réelle et à remonter le temps en prévoyant le temps de revue et de test dont une migration a réellement besoin, au lieu de partir de « nous avons largement le temps » et de laisser le calendrier se remplir d'autres choses. Pour un préavis de plusieurs mois, un découpage raisonnable pourrait ressembler à ceci :
- Le premier quart de la période : évaluer toute l'étendue de ce qui dépend du service abandonné, inventorier chaque point d'appel et choisir un remplaçant
- La moitié centrale : construire et tester l'intégration de remplacement, y compris la gestion des erreurs, le comportement des quotas et les cas limites propres à vos données
- Le dernier quart : faire tourner les deux fournisseurs en parallèle si possible, surveiller les écarts et achever la bascule en gardant une vraie marge de temps, et non juste avant l'échéance
Cette structure traite la dernière partie du préavis comme une marge pour l'inévitable retard, et non comme la période pendant laquelle le vrai travail est fait, ce qui est précisément là où les migrations bâclées tournent mal.
S'il existe un hôte de compatibilité pour le fournisseur abandonné, cela change la part de la phase centrale, construire et tester l'intégration de remplacement, qui est réellement nécessaire, car un hôte de compatibilité correspondant signifie que le code d'analyse des réponses dont votre application dispose déjà n'a pas du tout besoin d'être réécrit, seulement d'être dirigé vers un nouvel hôte avec de nouveaux identifiants. Les 17 hôtes de compatibilité de My Geocode, listés sur /compatibility/, couvrent exactement ce scénario pour un éventail significatif de fournisseurs, et consulter cette liste tôt dans le préavis, dès la phase d'évaluation, vaut la peine avant d'engager du temps d'ingénierie dans une réécriture complète d'une logique d'analyse qu'un hôte de compatibilité pourrait rendre inutile.
Quel que soit le calendrier réel, la discipline qui compte le plus est de commencer la phase d'évaluation le jour où le préavis arrive, et non la semaine où l'échéance commence à paraître proche.