La dette technique est une décision, pas un accident

En réunion, un responsable produit a dit que l’équipe avait « laissé s’accumuler beaucoup de dette technique ». Personne n’a relevé. Pourtant, chaque raccourci de ce code avait été validé, arbitré, parfois imposé, dans des réunions dont j’avais encore les comptes rendus. Le mot « laissé » faisait à lui seul tout le travail politique de la phrase.

L’image d’origine parlait d’emprunt volontaire

Ward Cunningham, qui a introduit la métaphore, décrivait quelque chose de précis : livrer vite avec une compréhension imparfaite du problème, en acceptant de payer des intérêts sous forme de ralentissement futur, à condition de rembourser une fois qu’on comprend mieux. C’est un choix de financement, pas une négligence.

Martin Fowler a ensuite classé ces situations selon deux axes : la dette peut être délibérée ou involontaire, prudente ou imprudente. Ces catégories sont utiles parce qu’elles rendent visible ce que l’usage courant efface. Un code médiocre écrit par méconnaissance et un code simplifié pour tenir une date de sortie sont deux objets différents, avec deux responsables différents.

Dans l’usage d’entreprise, tout cela s’est aplati en un seul sens : la dette technique désigne le code sale, le code sale vient des développeurs, et les développeurs devraient être plus rigoureux. La métaphore financière a perdu exactement la partie qui parlait du créancier.

Suivre qui décide et qui paye

Regardons une trajectoire ordinaire. Une date est fixée avant que le périmètre soit connu, parce qu’elle a été annoncée à un client ou à un conseil d’administration. L’équipe signale que la fonctionnalité propre demande six semaines et que la version rapide en demande deux. On prend la version rapide, avec la promesse de revenir dessus. La démonstration se passe bien, l’objectif trimestriel est atteint, la prime aussi.

Personne ne revient dessus. Six mois plus tard, chaque évolution coûte trois fois plus cher, les correctifs se multiplient, et on parle de qualité de code. Les personnes qui ont bénéficié du gain de court terme ne sont plus les mêmes que celles qui paient les intérêts, et parfois elles ne sont plus dans l’entreprise.

Le même mécanisme joue au moment du recrutement. Une équipe réduite pour tenir un budget produit mécaniquement plus de raccourcis, et cette réduction n’apparaît jamais dans le bilan de qualité du code. On mesure la vélocité de l’équipe, jamais la contrainte qu’on lui a posée.

Ce décalage n’a rien d’exceptionnel, c’est la structure normale du système d’incitations. Un objectif trimestriel est mesuré et récompensé. La maintenabilité à dix-huit mois n’apparaît dans aucun tableau de bord tant qu’elle n’a pas déjà coûté cher. Tant que le raccourci est rentable pour celui qui le décide, il sera décidé, et il ne sert à rien de le déplorer en rétrospective d’équipe.

Je le dis sans surplomb : j’ai livré des choses que je savais fragiles, et j’ai laissé passer des dates plutôt que d’ouvrir le conflit. C’est confortable de traiter ces épisodes comme des accidents techniques.

Ce qui change quand on nomme la décision

La seule chose qui a fonctionné, dans mon expérience, est d’obliger l’arbitrage à s’écrire. Pas un ticket vague intitulé « refactoriser le module », mais une ligne dans la décision : on choisit la version rapide, elle nous fait gagner tel délai, elle nous coûtera tel travail, et voici la date à laquelle on décide de rembourser ou d’assumer.

L’effet n’est pas magique, la dette existe toujours. Mais elle cesse d’être un défaut moral flottant attribué à l’équipe. Elle redevient ce qu’elle est : un emprunt contracté par une organisation, avec un bénéficiaire identifiable et une échéance.

Depuis, quand j’entends « on a beaucoup de dette technique », je demande qui l’a empruntée. La réunion devient plus courte.