Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Pourquoi une migration devrait prendre un après-midi, pas un trimestre
Un projet de migration estimé à un trimestre de travail d'ingénierie pour changer de fournisseur de données de localisation ne représente généralement pas un trimestre de travail réellement nécessaire. C'est un trimestre de travail créé par des choix de conception faits des années plus tôt : un format de réponse propriétaire qu'il faut démêler champ par champ, un SDK dont les appels de méthodes sont dispersés dans le code à des endroits que personne n'a documentés, une gestion des erreurs construite autour des codes de statut propres à un fournisseur. Aucune de ces complexités n'est inhérente à l'idée de rechercher une adresse ou une IP. Toutes sont héritées de choix qui ont rendu l'intégration initiale pratique, au prix d'une future migration coûteuse.
Nous avons construit 17 hôtes compatibles précisément pour rendre ce trimestre inutile à quiconque dont l'intégration existante parle déjà l'un de ces formats de fournisseur. Si votre code appelle l'endpoint d'une API de géocodage ou d'IP connue et analyse son format de réponse spécifique, diriger ce même code vers notre hôte compatible correspondant devrait nécessiter de changer une URL de base et une clé d'API, et non de réécrire la logique d'analyse qui fonctionne très bien depuis des années. L'authentification accepte une clé sous forme d'en-tête, de jeton bearer, d'authentification HTTP Basic ou de paramètre de requête, si bien que le procédé déjà utilisé par votre code existant est très probablement déjà pris en charge.
Une migration à l'échelle d'un après-midi n'est pas une affirmation que nous faisons à la légère, car nous savons exactement combien d'efforts il nous a fallu pour la rendre vraie : reproduire la forme de réponse d'un autre fournisseur champ par champ, la tester sur de vraies requêtes et maintenir cette forme stable pour que le code existant d'un client n'ait aucune raison de remarquer une différence, hormis la destination de la requête. Ce travail est effectué en amont chez nous, précisément pour qu'il n'ait pas à être refait, en aval, dans le code de chaque client qui veut vérifier si le changement en vaut la peine.
Le constat va au-delà de nos propres hôtes compatibles : une migration qui prend un trimestre est une information de diagnostic sur l'intégration précédente, et non une propriété naturelle du changement de fournisseur en général. Si quitter un fournisseur exige un projet de plusieurs mois, quelqu'un, quelque part, a profité de l'existence de cette friction, qu'elle ait été délibérément créée ou non. Un fournisseur réellement confiant dans ses données, ses tarifs et sa fiabilité n'a aucune raison de rendre le départ difficile, car tout son argument devrait être qu'un client qui l'essaie n'aura pas envie de partir, et non que partir coûte trop cher pour être tenté.
Nous préférons être jugés sur la question de savoir si le produit vaut la peine qu'on reste, évaluée honnêtement, le même après-midi où un client pourrait tout aussi facilement partir. Rendre cet après-midi possible nous a coûté un réel effort d'ingénierie. Nous pensons que cet effort devait être fourni, et que tout fournisseur qui refuse de le fournir vous dit discrètement quelque chose sur la confiance qu'il a réellement dans ce qu'il vend.