Estimation du coût du remplacement d'une API tierce
Comment évaluer le remplacement d'une API tierce : lacunes sémantiques, exécution parallèle et hypothèses sous-jacentes aux particularités de l'ancien fournisseur. La nouvelle API n'en a qu'apparemment l'air.
L’API du nouveau fournisseur semble identique jusqu’à ce que vous commenciez à migrer les données.
L’argumentaire en faveur du changement de fournisseur est toujours le même : la nouvelle API est plus épurée, plus rapide et moins chère. Le piège, c’est que les particularités de l’ancienne API sont essentielles au bon fonctionnement du système. Le code accumule depuis deux ans des particularités telles que « ceci est une chaîne de caractères, mais il s’agit en réalité d’une date dans leur format », « ceci renvoie la valeur null alors qu’elle signifie zéro », « ceci limite le débit de manière silencieuse ». Un remplacement en bonne et due forme implique de reproduire chacune de ces particularités en fonction du comportement du nouveau fournisseur, qui présente des différences que personne n’a documentées.
Le devis doit prévoir une phase de fonctionnement en parallèle : l’ancien et le nouveau fournisseur fonctionnent simultanément, avec une comparaison des résultats, jusqu’à ce que l’équipe soit certaine que le nouveau fournisseur offre les mêmes performances. Cette phase est souvent plus longue que la mise en œuvre. Les projets qui ne prévoient pas cette phase mettent en service le nouveau fournisseur et ne découvrent les lacunes que lorsque les données d’un client se heurtent à un cas de bord.
Ce qui se dit dans la salle
Backend : « Le nouveau SDK est plus performant. Les appels de base prennent chacun une journée. »
Chapeau : « Qu’en est-il des données historiques qu’ils conservent pour nous ? »
SRE : « Allons-nous faire fonctionner les deux fournisseurs en parallèle, ou procéder à une migration ? »
Backend : « Leur format de webhook est différent. Il en va de même pour l’authentification. »
Question : « Comment vérifions-nous l’équivalence ? En comparant les réponses sur une semaine ? »
Questions qu’il convient de se poser avant de voter
- Y a-t-il des données historiques chez l’ancien fournisseur que nous devons récupérer ?
- Différences en matière d’authentification : clés API, OAuth, requêtes signées ?
- Webhooks : les événements correspondent-ils clairement, ou faut-il les adapter ?
- Période de double exploitation : quelle durée, et à partir de quand peut-on considérer que c’est « suffisamment bon » pour passer à l’autre système ?
- Limites de débit et modèle tarifaire chez le nouveau fournisseur : identiques ou différents ?
- Retour en arrière : peut-on revenir en arrière si le nouveau fournisseur s’avère moins performant ?
Les appels de base sont simples ; c’est la preuve d’équivalence qui demande du travail. Si l’exécution duale et le déplacement des données sont tous deux réels, cela représente plusieurs aspects : séparer ces éléments et évaluer la vérification indépendamment de la mise en œuvre.
Prévoyez un budget pour l’exécution en parallèle et le contrôle d’équivalence. L’API, qui semble simple, est la partie la moins coûteuse.
Tout comme l’estimation d’une migration de base de données, le code est rapide et c’est la mise en œuvre qui demande du travail. Consultez les autres exemples d’estimations concrètes, ou lancez une session gratuite de Planning Poker une fois que le plan de double exécution est esquissé.