Une philosophie de gestion de dette technique (partie 2) : le coût de la dette

Nicolas Nallet
YounitedTech
Published in
6 min readJul 31, 2020

Ecrire notre définition de la dette technique était la première étape du voyage et cela nous a permis de voir les étapes suivantes.

  • Quelle est notre cible technique ?
  • Où se cache la dette ?
  • Quel est son coût ?

S’il vous plaît… Dessine-moi une cible technique !

Un humain à la recherche de sa cible technique

Comme expliqué dans notre article précédent, la dette technique est l’écart entre le système actuel et le système cible. Nous nous sommes donc remonté les manches et avons commencé à coucher sur le papier un certain nombre de principes (architecturaux, liés au code, à l’infrastructure, etc.) dont certains étaient déjà largement partagées au sein de la tech depuis plusieurs années. Nous en avons extrait des grands principes qui ont constitué la première version de notre cible technique.

Nous avons ensuite affiné cette première version en nous assurant qu’elle était en phase avec la stratégie d’entreprise et permettait d’atteindre nos ambitions business à 2/3 ans de manière efficace.

Une passe de validation a été faite avec les équipes pour mettre un dernier coup de polish, s’assurer de la compréhension et l’adhésion autour de ses grands principes.

Voici l’un des axes retenus pour l’exemple :

  • Ambition business : nous avons l’ambition de lancer de nouveaux pays, des nouveaux produits et de nouvelles fonctionnalités sur tout ça rapidement pour entretenir notre hyper croissance.
  • Problématique : notre plateforme est en partie ségréguée par pays (France, Italie, Espagne, Portugal, Allemagne) ce qui ralentit notre capacité à délivrer de la valeur.
  • Cible technique : nous avons besoin d’une plateforme unifiée (multi-tenant) qui gère l’activité de l’ensemble de nos pays et nos produits.

Estimer les travaux

Une fois les grands principes de la cible technique définis et partagés, chaque équipe les a déclinés sur son périmètre. Ce travail a permis de faire ressortir les poches de dettes. Puis, avec l’aide des équipes, nous avons passé les applications en revue pour déterminer :

  • Son niveau de conformité par rapport à la cible technique : une note sur 10
  • Son poids relatif dans le périmètre de l’équipe qui en est propriétaire

On a ensuite rassemblé tout ça dans un beau fichier Excel pour calculer un score par application, résultat de la multiplication du poids de l’application par le niveau de conformité par rapport au score max que pourrait avoir l’application : le poids * 10 qui correspond au niveau de conformité maximum.

Score de dette par application

Une fois l’ensemble des applications auditées et scorées, nous avons pu calculer un score au niveau des équipes et faire une photo à l’instant T du niveau global de la dette.

Le score de dette par équipe

Être dans les bons coûts

Avec une vision de la dette par équipe on a pu se pencher sur sa traduction sur les différents types de coûts.

Le coût de la stabilisation

Il matérialise l’entretien quotidien du patrimoine logiciel (certains font référence à la règle du boyscout). Cela permet de se maintenir au niveau de dette technique courant dans un contexte technique et business stable (pas de grande réorientation business ou pas de nouvelle cible technique). On a constaté empiriquement que son coût était stable dans le temps et mobilisait entre 1 et 2 mois/équipe par an et par équipe. C’est un coût fixe, que l’on doit payer quoi qu’il arrive, sous peine de voir la dette se creuser.

Le coût de la remédiation

Il représente le prix du remboursement de la dette technique. On a travaillé pour élaborer une échelle permettant une correspondance entre le score de dette d’équipe et le prix de la remédiation.

Le premier et le dernier échelon de cette échelle étaient assez évidents :

  • Niveau de dette optimal : le système est conforme a la cible technique. Il n’y a aucun coût de remédiation à ce niveau. La capacité dédiée à la stabilisation de la dette est suffisante pour faire les adaptations pour rester à ce niveau.
  • Niveau de dette hors contrôle : cet échelon matérialise simplement l’absence de contrôle de la dette. On ne sait pas combien on va devoir payer. Par contre on sait que ça ne sera pas bon marché du tout. En général c’est le moment où les plus chanceux (ou malchanceux ça dépend du point de vue) dégainent un projet de refonte from scratch sur plusieurs années.

Les autres échelons ont été un peu plus compliqués à trouver. Nous voulions calibrer l’échelle pour monter un échelon (pour s’approcher du niveau optimal) par an. Pour ça on a dû :

  • Étudier le prix et l’impact d’une dizaine de projets de remédiation effectués ces trois dernières années et estimer le niveau de dette avant et après les projets.
  • Faire une estimation du niveau de dette par équipe 1 an et 2 ans en arrière.

Après quelques itérations, nous avons déterminé qu’une équipe chez Younited remboursait sa dette jusqu’à 3 mois/équipe par an et modélisé une échelle à 7 échelons. Les valeurs peuvent évidemment différer selon les organisations.

Bon et combien ça nous coûte en vrai ?!

En synthèse, voici la table de correspondance entre les scores et le coût. Le score influe surtout sur le coût de remédiation.

Attention à toi lecteur, si tu souhaites utiliser cette échelle, on te conseille fortement d’investir du temps dans la calibration des échelons et le coût correspondant à chacun, car ces valeurs sont très dépendantes du contexte et du système étudié.

Les limites de l’exercice

Comme tu dois t’en douter certainement, cher lecteur, la récolte et l’analyse de toutes ces données a été très manuelle, subjective et reposait sur un certain nombre d’hypothèses. Ce qui rend les différentes valeurs approximatives.

Néamnoins le temps passé à réaliser l’étude n’était pas une perte de temps pour autant. Même si une des échelles a été mal calibrée ou une applications mal scorée, c’est un travail collectif qui s’est affiné au gré des nombreux retours des différentes équipes (tech, produit et même membre du Comex). Et ce travail nous a permis de faire des avancées importantes :

  • Formaliser notre cible technique.
  • Effectuer une cartographie complète de notre plateforme actuelle et cible au niveau global et au niveau des équipes.
  • Factualiser que les équipes prenaient soin de leur périmètre régulièrement depuis 3 ans. On le savait mais sans avoir plus de chiffre que cela.
  • Définir une trajectoire, un rythme de remboursement de notre dette technique pour les prochaines années.

Dans le prochain article on présentera la suite du voyage : comment on a construit cette trajectoire et comment on a déterminé la date de débranchement de notre Legacy !

Notre Legacy attendant sa décommission

--

--