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.
Retirer en toute sécurité les anciennes clés d'API après une migration
Retirer la clé d'API d'un ancien fournisseur ressemble à une petite étape presque administrative à la fin d'une migration, mais se tromper de moment, dans un sens comme dans l'autre, a un coût réel. Si vous la retirez trop tôt, avant que chaque système dépendant n'ait réellement migré, quelque chose qui appelle encore l'ancienne clé cesse de fonctionner de manière inattendue. Si vous la retirez trop tard, ou jamais, un identifiant inutilisé mais toujours valide reste en circulation comme un risque de sécurité que personne ne surveille activement.
La procédure la plus sûre traite le retrait des clés comme un petit projet à part entière, avec une séquence définie, et non comme un détail ajouté à la fin du travail principal de migration :
- Vérifiez d'abord l'absence totale de trafic sur l'ancienne clé, au lieu de simplement croire que la migration est terminée. La plupart des fournisseurs offrent une certaine visibilité sur l'utilisation d'une clé donnée ; vérifiez-la directement plutôt que de supposer que, parce que la liste de contrôle de la migration est cochée, l'ancienne clé est réellement devenue silencieuse.
- Laissez l'ancienne clé valide mais inutilisée pendant une période d'observation définie après avoir estimé la migration terminée, au lieu de la désactiver dès la mise en service du nouveau fournisseur. Cette période, généralement de quelques semaines selon vos schémas de trafic et vos cycles de publication, permet de repérer tout point d'appel oublié, toute mise à jour d'application mobile retardée ou toute tâche par lots rarement exécutée qui fait encore référence à l'ancien identifiant.
- Désactivez d'abord l'ancienne clé au lieu de la supprimer, si votre fournisseur fait cette distinction. Une clé désactivée qui existe toujours en tant qu'enregistrement est plus facile à réactiver brièvement en cas d'imprévu qu'une clé entièrement supprimée, ce qui vous donne une marge de sécurité pendant la période d'observation sans la prolonger indéfiniment.
- Supprimez ou révoquez définitivement l'ancienne clé à une date précise fixée à l'avance, et consignez-le. Une clé désactivée indéfiniment reste une surface d'attaque que quelqu'un pourrait réactiver si le compte lui-même était un jour compromis ; un identifiant réellement retiré doit finir par être supprimé pour de bon, et non laissé dans un état d'attente permanent.
- Recensez tous les endroits où l'ancienne clé était stockée, y compris les systèmes de gestion de configuration, les gestionnaires de secrets, les fichiers de variables d'environnement et toute documentation ou tout support d'intégration des nouveaux arrivants qui pourrait y faire référence, car une clé retirée qui reste écrite quelque part comme « la clé d'API » sème la confusion chez la prochaine personne qui lira cette documentation, longtemps après que la clé elle-même a cessé de fonctionner.
Pour une migration vers My Geocode, la nouvelle clé peut être encadrée et surveillée dès le premier jour grâce aux en-têtes de quota présents sur chaque réponse, X-Quota-Used, X-Key-IPs-Used et d'autres documentés sur /docs/rate-limits/, ce qui permet de confirmer facilement que la nouvelle clé porte bien le trafic attendu avant de lancer le compte à rebours du retrait de l'ancienne. Traiter le retrait des identifiants avec ce degré de rigueur représente un léger surcroît de procédure pour une réduction significative du risque opérationnel comme de l'exposition résiduelle en matière de sécurité.