La dette technique que vous voyez n’est presque jamais celle qui coûte cher.

Une métaphore lue à l’envers

Ward Cunningham, qui a introduit la comparaison avec la dette, ne parlait pas de code bâclé. Il décrivait une situation précise : on livre une première version avec la compréhension du domaine qu’on avait à ce moment-là, en sachant que cette compréhension va évoluer. L’intérêt de la dette, c’est le temps perdu à travailler avec un logiciel qui reflète encore l’ancienne compréhension.

La différence n’est pas théorique. Dans la lecture courante, la dette est une faute de qualité qu’un développeur aurait pu éviter en travaillant mieux. Dans la lecture d’origine, elle est la conséquence normale d’avoir livré tôt et appris ensuite. La première invite à blâmer ; la seconde invite à rembourser.

Martin Fowler a proposé une grille utile pour distinguer les cas, en croisant deux axes : la dette était-elle délibérée ou involontaire, et le raisonnement était-il prudent ou téméraire. Un raccourci assumé pour tenir une date est une dette délibérée et prudente. Ignorer les conventions par manque de rigueur est une dette téméraire. Et la catégorie la plus intéressante est ailleurs.

La dette que les outils ne détectent pas

La dette involontaire et prudente est celle qui apparaît quand une équipe compétente, après dix-huit mois de travail sérieux, comprend enfin comment le domaine aurait dû être modélisé. Personne n’a mal travaillé. Le logiciel est simplement construit sur une définition du métier qui n’est plus la bonne.

Elle ne se voit pas dans un rapport d’analyse statique. Elle se manifeste autrement : une demande d’apparence anodine touche onze endroits, une règle change de sens selon le module qui l’applique, personne ne sait dire où une notion métier est réellement définie. Ce sont ces symptômes, et non le nombre d’avertissements de l’outil de qualité, qui prédisent le coût des prochains mois.

Le coût d’une dette ne se mesure pas à son volume, mais à la fréquence avec laquelle on doit traverser la zone concernée.

Pourquoi un budget de dette isolé se fait couper

La réponse organisationnelle habituelle consiste à demander une enveloppe : un trimestre de refactorisation, un pourcentage de capacité réservé, un chantier de modernisation. Ces demandes échouent souvent, et pas par manque de bonne volonté.

Elles échouent parce qu’elles sont invérifiables de l’extérieur. Une direction qui approuve une enveloppe de dette technique achète une promesse d’amélioration sans livraison observable, en concurrence avec des initiatives qui promettent un résultat daté. Au premier arbitrage difficile, c’est cette ligne qui disparaît.

L’approche qui tient est différente : on ne rembourse pas la dette en général, on rembourse la portion qui se trouve sur le chemin d’un changement demandé. Le travail de remodelage devient une partie du coût d’une fonctionnalité, défendable parce qu’il est rattaché à un résultat attendu. C’est moins spectaculaire qu’un grand chantier, et cela survit aux comités.

Mesurer le coût du prochain changement

Si la quantité de dette est un mauvais indicateur, que regarder ? La question utile porte sur le coût marginal : dans quelle zone du système un changement de taille comparable coûte-t-il systématiquement plus cher qu’ailleurs ?

• Le délai entre une demande comprise et sa mise en production, par domaine fonctionnel.
• Le nombre de composants à modifier pour un changement typique, et leur dispersion entre équipes.
• La proportion d’incidents qui se concentrent sur quelques zones toujours identiques.
• Le temps qu’une nouvelle personne met à devenir autonome sur chaque partie du système.

Ces mesures désignent des endroits, pas des quantités. Elles permettent une conversation que la métaphore financière rend difficile : il ne s’agit pas de savoir combien l’organisation doit, mais où elle paie, et si elle continuera de passer par là.

Une zone coûteuse que plus personne ne modifie n’est pas un problème, quel que soit son état. Une zone propre selon les outils mais traversée par chaque nouvelle fonctionnalité mérite, elle, une attention immédiate. C’est cette inversion qui rend la discussion sur la dette technique exploitable par une direction.