La dette technique : comment on la mesure, et comment on la finance

« La dette technique » est un des rares termes d’ingénierie qui a réussi à traverser jusqu’aux comités de direction. C’est une bonne nouvelle, avec un effet secondaire : le mot sert maintenant à justifier à peu près n’importe quelle réécriture.

Je propose ici une façon de la rendre mesurable — donc discutable — et un mode de financement qui fonctionne, parce que les autres ne fonctionnent pas.

Le problème du mot

La métaphore de la dette est excellente : on emprunte du temps aujourd’hui, on rembourse avec intérêts plus tard. Elle est aussi devenue un fourre-tout où l’on range trois choses très différentes.

La dette délibérée. « Nous prenons ce raccourci pour tenir la date, nous corrigerons au trimestre prochain. » C’est une décision d’ingénierie légitime, à condition qu’elle soit tracée.

La dette d’usure. Les dépendances vieillissent, les versions changent, les pratiques évoluent. Elle apparaît même sans erreur de personne, simplement parce que le temps passe. C’est la plus prévisible, et la plus souvent ignorée.

La dette d’incompétence. Du code mal conçu, sans intention. Celle-là n’est pas une dette : c’est un défaut. La nommer « dette » la rend acceptable, et c’est exactement ce qu’il ne faut pas faire.

Ces trois catégories appellent des traitements différents. Les confondre est la première raison pour laquelle les discussions sur la dette tournent en rond.

Photo : rawpixel — licence CC0.

Mesurer par les effets, pas par le code

Les métriques de qualité de code — complexité, duplication, couverture — sont utiles aux développeurs et inaudibles en comité. Elles décrivent une cause, pas une conséquence.

Nous suivons quatre indicateurs qui parlent à tout le monde, parce qu’ils se traduisent directement en délais et en risque.

Le délai d’une correction simple

De la demande à la mise en production, pour un changement trivial. C’est l’indicateur le plus révélateur, parce qu’il agrège tout : lisibilité du code, qualité des tests, automatisation du déploiement, lourdeur des validations.

Une journée est sain. Cinq jours signalent un problème structurel — presque toujours dans la chaîne de déploiement plutôt que dans le code.

Le taux de régression

Sur les modifications livrées, quelle proportion a cassé quelque chose d’autre ? Au-delà de 15 %, l’équipe ne peut plus s’engager sur des délais : chaque intervention comporte une part d’aléa.

Le temps de reconstruction et de déploiement

Depuis un poste vierge, sans aide. Nous testons cela systématiquement lors des audits de reprise, et la réponse « on ne sait pas » est fréquente. C’est le pire des cas : la dette est maximale et invisible.

Les dépendances non maintenues

Le nombre de bibliothèques sans mise à jour depuis deux ans, en distinguant celles qui portent des vulnérabilités connues. Cet indicateur s’automatise et se surveille en continu.

Financer : ce qui ne marche pas

Le chantier exceptionnel. « On fera un sprint de refonte technique au premier trimestre. » Il est reporté au deuxième, puis annulé au troisième parce qu’une urgence commerciale est arrivée. Elle arrive toujours.

Attendre la crise. La dette se traite alors dans l’urgence, au pire moment, sous pression — donc mal, en créant de la dette nouvelle.

La réécriture complète. Séduisante et presque toujours mauvaise. Elle suppose de reconstruire des années de règles métier non documentées, pendant que l’ancienne application continue d’évoluer. Le taux d’échec de ces projets est élevé, et l’échec est spectaculaire.

Photo : domaine public (CC0).

Financer : ce qui marche

Une allocation permanente. Nous réservons 15 à 20 % de la capacité de chaque itération à la dette. Ce n’est pas négociable au cas par cas — c’est une ligne budgétaire structurelle, au même titre que les tests.

L’avantage est double. La dette est traitée en continu, avant d’atteindre un seuil critique. Et surtout, le sujet cesse d’être une négociation permanente entre l’équipe technique et le métier, ce qui est épuisant pour les deux.

Réparer ce qu’on touche. Chaque intervention dans une zone laisse cette zone un peu plus propre qu’on ne l’a trouvée. Cela concentre naturellement l’effort là où il sert : le code qu’on ne modifie jamais n’a pas besoin d’être beau.

Rendre la dette visible dans le suivi. Nous affichons les quatre indicateurs à côté des indicateurs fonctionnels. Quand le délai de correction passe de un à quatre jours, la discussion budgétaire devient concrète et se tient avant la crise.

Photo : Dmitri Popov — licence CC0.

La dette qu’il ne faut pas rembourser

Toute dette technique ne mérite pas d’être traitée, et c’est ce qui distingue une démarche sérieuse d’une croisade.

Le code d’un module stable qu’on ne modifie jamais. Il est laid, il n’est pas testé, et il fonctionne depuis six ans sans incident. Le refactorer ne rapporte rien : le coût d’un code médiocre ne se paye qu’au moment où on le modifie. S’il ne bouge pas, il ne coûte rien.

Le code d’une fonctionnalité en sursis. Si le métier envisage de la retirer, tout investissement dessus est perdu d’avance. La bonne question n’est pas « ce code est-il bon ? » mais « ce code sera-t-il encore là dans deux ans ? ».

Une technologie ancienne mais toujours supportée. L’ancienneté n’est pas une dette. Ce qui en est une, c’est l’absence de correctifs de sécurité ou l’impossibilité de recruter. Tant que ces deux conditions sont réunies, laisser en place est un choix légitime.

Ce filtre élimine généralement la moitié de ce qu’une équipe considère spontanément comme de la dette — et rend le reste finançable, parce que la liste devient crédible.

Comment j’évite qu’elle revienne

Rembourser sans changer ce qui la produit revient à vider une baignoire dont le robinet coule.

Deux pratiques suffisent, et elles ne coûtent presque rien.

Traiter la dette au moment où l’on touche au code, pas dans un chantier séparé. Quand une évolution amène à modifier un module, on y laisse un peu de propreté au passage — un test qui manquait, un nom qui ment. Ce qui est modifié souvent finit ainsi par être en bon état ; ce qui ne l’est jamais reste tel quel, et c’est très bien.

Rendre visible ce qu’on décide d’assumer. Une dette prise consciemment, écrite quelque part avec sa raison et sa date, reste gérable. Une dette prise en silence devient un piège pour la personne qui héritera du code. La différence n’est pas technique — elle est de traçabilité.

Ce que je dis aux directions

La dette technique n’est pas un problème d’ingénieurs perfectionnistes. C’est une charge financière différée, et elle se comporte exactement comme telle : elle croît toute seule, et elle rend chaque décision future plus chère.

Une application dont le délai de correction est passé de un à cinq jours a perdu 80 % de sa réactivité. Ce n’est pas une question de confort pour l’équipe : c’est une perte de capacité à répondre au marché, et elle se mesure en euros.

C’est le seul argument que j’aie vu fonctionner de façon fiable — parce qu’il est vrai.