D'où elle vient, et pourquoi elle n'est pas une faute
Toute application en production porte de la dette. Elle se crée à chaque fois qu'on choisit la solution du moment plutôt que la solution durable : une date de salon à tenir, un client à débloquer, une fonctionnalité à sortir avant un concurrent. Ces arbitrages sont souvent les bons. Le problème n'est pas de contracter la dette, c'est de ne jamais la rembourser et surtout de ne pas savoir combien on en porte.
Elle s'accumule aussi toute seule, sans que personne ne décide quoi que ce soit. Une dépendance qu'on ne met plus à jour, un framework qui sort une version majeure, un membre de l'équipe qui part avec la connaissance d'un module dans la tête : la dette monte pendant que le code, lui, ne bouge pas.
Les signaux qui ne trompent pas
La dette technique se voit rarement dans le code, elle se voit dans le calendrier. Une estimation qui triple entre l'annonce et la livraison. Une correction qui casse autre chose ailleurs. Une mise en production repoussée au vendredi soir parce que personne n'ose la faire en pleine journée. Un développeur qui répond « il faudrait tout reprendre » à une demande qui paraissait simple.
Le signal le plus coûteux est celui qu'on entend en comité : « on ne peut pas faire ça sur l'application actuelle ». À ce stade, la dette ne ralentit plus la technique, elle bloque des décisions business.
La mesurer avant de la traiter
On ne rembourse pas une dette qu'on n'a pas chiffrée. Le travail utile commence par un état des lieux : quelles zones du code concentrent les incidents, quelles dépendances sont hors support, quelles parties n'ont aucun test, quel module ne peut être modifié que par une seule personne. C'est exactement ce que produit une phase d'audit et étude de cadrage, avec un plan de remboursement priorisé plutôt qu'une liste de reproches.
Ensuite, on traite par zone et par valeur. La dette qui touche un module stable, que personne ne modifie jamais, peut rester en l'état pendant des années. Celle qui touche le parcours d'inscription, modifié tous les mois, se paie chaque semaine. Cette hiérarchisation évite le réflexe coûteux de la refonte totale, qui remet le compteur à zéro mais fait repartir de zéro aussi la connaissance métier accumulée.
Quand la dette s'est transformée en code legacy, c'est-à-dire quand plus personne ne maîtrise vraiment ce qui tourne, le sujet change de nature : il ne s'agit plus d'entretenir, mais de reprendre la main.
