Idée principale

Tout ce qu'on appelle dette technique n'en est pas. Un code mal structuré, une architecture faible, une complexité connue depuis des années, un risque latent : ce sont des inconforts. Ils existent, ils pèsent, ils ne portent aucune échéance et personne ne les paie à une date.

La dette apparaît au moment où l'entreprise décide de régler. C'est cette décision qui crée l'objet : elle fixe un montant — le coût de traitement —, un bénéficiaire et un moment. Avant elle, il n'y a rien à inscrire ; après elle, il y a un sujet produit comme un autre, comparable aux fonctionnalités et arbitrable avec elles.

Le déclencheur habituel de cette décision est un basculement de coût : l'inconfort devient plus cher à supporter qu'à traiter — parce qu'il bloque une stratégie, ralentit fortement l'équipe, expose à un risque, dégrade la qualité perçue par le client, ou empêche un changement produit important.

Pourquoi c'est important

Cela désamorce une conversation qui tourne en rond entre développeurs et produit. Tant que la dette est présentée comme un état du code, elle se discute en termes de propreté, et le produit n'a aucune prise. Requalifiée en décision de règlement, elle se discute en termes de coût et devient arbitrable.

Cela explique aussi pourquoi les inventaires de dette ne produisent presque jamais de travail : ils recensent des inconforts, et un inconfort ne demande rien à personne.

Nuances et limites

La requalification a un revers : elle donne au produit le droit de ne jamais décider, et donc de laisser un risque s'accumuler jusqu'à ce qu'il devienne un incident. L'inconfort non traité n'est pas gratuit, il est simplement non compté.

Et le basculement de coût est difficile à établir avant qu'il ne se manifeste — le ralentissement de l'équipe se constate mieux après coup qu'au moment où il faudrait décider.

Questions ouvertes

• Quels signaux annoncent le basculement de coût assez tôt pour que la décision de régler précède l'incident ?