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 la dépendance à un seul petit fournisseur enseigne sur le risque fournisseur
Une dépendance à une seule API est facile à négliger précisément parce qu'elle fonctionne discrètement pendant longtemps. Un appel de géocodage qui renvoie des résultats corrects chaque jour depuis deux ans ne ressemble pas à un risque ; il ressemble à un problème résolu. Le risque ne devient visible que le jour où quelque chose change du côté du fournisseur, un endpoint abandonné, une refonte tarifaire, un rachat de l'entreprise ou simplement une panne du service, et à ce moment-là, le coût de n'avoir aucune solution de rechange en place se paie déjà dans la précipitation plutôt que par une migration planifiée.
Les petits fournisseurs présentent ce risque de façon plus aiguë que les grands, non parce qu'ils seraient moins fiables au quotidien, mais parce qu'ils disposent généralement de moins de redondance dans leurs propres opérations et d'un modèle économique plus sensible au départ d'un gros client ou à tout changement de financement. Ce n'est pas une critique d'un petit fournisseur en particulier ; c'est un fait structurel lié à la taille de l'entreprise, qui s'applique à de nombreux services par ailleurs excellents.
La leçon pratique n'est pas forcément d'éviter les petits fournisseurs. Elle consiste à construire une architecture qui ne suppose pas qu'un fournisseur est permanent, quelle que soit sa taille. Quelques habitudes concrètes y aident :
- Gardez la logique propre à chaque fournisseur derrière une interface interne dans votre propre code, afin qu'une fonction d'analyse lise votre propre structure de données normalisée plutôt que directement les noms de champs d'un fournisseur précis dispersés dans la base de code
- Testez régulièrement que votre intégration pourrait réellement migrer, même si vous ne prévoyez pas de le faire prochainement, car une portabilité supposée mais non testée n'est pas une portabilité réelle
- Tenez à jour le coût en temps d'ingénierie d'une migration complète comme une connaissance permanente de l'organisation, et non comme un chiffre calculé pour la première fois en pleine crise
Une approche fondée sur la compatibilité modifie quelque peu ce calcul, car elle réduit la part du coût de migration qui réside dans votre propre code d'analyse. My Geocode exploite 17 hôtes de compatibilité qui reproduisent exactement la forme des requêtes et des réponses de grands fournisseurs, dont Google Maps Platform, Mapbox, HERE, ipstack et d'autres, documentés sur /compatibility/. La partie la plus risquée d'une migration forcée, réécrire la logique d'analyse sous la pression du temps, peut donc souvent être évitée si le fournisseur que vous quittez dispose déjà d'un hôte de compatibilité correspondant.
Cela dit, la leçon plus profonde sur le risque fournisseur reste valable quel que soit le fournisseur ou la plateforme que vous utilisez, y compris celle-ci : la position la plus saine est celle où changer de fournisseur est une option réelle et testée plutôt que théorique. Mener un petit essai avec un autre fournisseur avant d'en avoir besoin, même pour une fraction de votre trafic, transforme le risque fournisseur d'une inquiétude abstraite en une capacité concrète et répétée. Le test coûte relativement peu, et le bénéfice n'apparaît que le jour où vous en avez réellement besoin.