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 fonctionnement du système. Le code accumule depuis deux ans des cas du type « ceci est une chaîne de caractères, mais c’est en réalité une date dans leur format », « cela renvoie null alors que cela signifie zéro », « cela limite le débit de manière silencieuse » — et un remplacement en douceur implique de reproduire chacune de ces particularités en fonction du comportement du nouveau fournisseur, qui diffère à des égards que personne n’a documentés.
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 convaincue que le nouveau fournisseur offre des résultats équivalents. 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 limite.
Ce qui se dit dans la salle
Backend : « Le nouveau SDK est plus pratique. Les appels de base prennent chacun une journée. »
Chapeau : « Qu’en est-il des données historiques qu’ils conservent pour nous ? »
SRE : « Est-ce que nous exploitons les deux fournisseurs en parallèle, ou est-ce que nous procédons à 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 parfaitement, ou faut-il les adapter ?
- Période de fonctionnement en parallèle : quelle durée, et à partir de quand peut-on considérer que la situation est « suffisamment stable » pour procéder à la bascule ?
- Limites de débit et modèle tarifaire du 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 plus d’un cas de figure — séparez-les et évaluez la vérification indépendamment de l’implémentation.
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 aura été esquissé.