Quatre signes de dette technique, visibles sans lire une ligne de code

La dette technique est une métaphore comptable : livrer vite en s’autorisant un raccourci revient à emprunter. L’emprunt est parfois rationnel. Ce qui pose problème, ce sont les intérêts, payés en lenteur croissante, et rarement identifiés comme tels.

Le diagnostic ne demande pas de lire le code.

Signal 1 — l’estimation qui gonfle à périmètre constant

Une demande comparable à celle de l’an dernier est chiffrée deux fois plus cher, sans que le besoin ait changé. Ce n’est généralement pas une dérive commerciale : c’est le coût réel de la modification qui a augmenté, parce que chaque changement doit désormais tenir compte de davantage d’exceptions.

Suivi utile : le coût moyen d’une demande d’évolution de taille comparable, année après année.

Signal 2 — la peur de toucher

Une zone du produit que personne ne veut modifier avant une échéance importante. Une fonctionnalité contournée plutôt que corrigée. Une phrase qui revient : « personne ne sait ce que ça casse ».

Ce signal indique moins un code compliqué qu’une absence de filet : sans tests automatisés, la seule façon de savoir si une modification casse quelque chose est de le découvrir en production.

Signal 3 — les dépendances figées

Une bibliothèque bloquée sur une version de 2019 parce que la mise à jour « demande trop de travail ». Le problème n’est pas l’ancienneté en soi, c’est que les correctifs de sécurité ne sont plus publiés pour cette version.

Ce signal est le plus facile à objectiver : la liste des dépendances, leur version, la date de la dernière version disponible, et le statut de maintenance de chacune. Un tableau d’une page, qui se demande et se relit sans compétence technique.

Signal 4 — le savoir concentré sur une personne

Une seule personne sait déployer, ou comprend un module. Les congés de cette personne deviennent un sujet de planification.

Ce n’est pas de la dette de code, c’est de la dette de documentation, et elle se rembourse vite : faire exécuter la procédure de déploiement par quelqu’un d’autre, à partir de la seule documentation, révèle les manques en une demi-journée.

Rembourser, et jusqu’où

Rembourser intégralement n’a pas de sens : une partie de la dette porte sur du code stable que personne ne modifie, et dont le coût d’intérêt est nul.

L’effort se concentre sur ce qui est modifié souvent. Le croisement entre fréquence de modification et difficulté de modification donne une liste courte, et cette liste est le plan de remboursement.

Le reste peut vieillir tranquillement. Un module écrit en 2018, jamais retouché depuis et qui fonctionne, n’est pas une dette : c’est du code amorti.