Estimation du coût du remplacement d'une API tierce

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 c’est en réalité une date dans leur format », « ceci renvoie null alors que cela signifie zéro », « ceci limite le débit sans le signaler ». Un remplacement en bonne et due forme 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 double exploitation : quelle durée, et à partir de quand peut-on considérer que la situation est « suffisamment bonne » pour procéder à la transition ?
• 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 plus d’un cas de figure : séparez-les et évaluez 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 pour l’estimation d’une migration de base de données, le code est rapide à écrire, mais c’est la mise en œuvre qui demande du travail. Consultez les autres exemples d’estimation déjà réalisés, ou lancez une session gratuite de « planning poker » une fois que le plan de double exécution aura été esquissé.