Article Craft #1 : La dette technique

Pourquoi cet article ?

« Nous avons trop de dette technique. » C’est le diagnostic que nous posent 90 % des DSI et CTO que nous rencontrons. Ils y voient la cause de tous leurs maux : lenteur, bugs, incapacité à innover.

Pourtant, en intervenant en "renfort", nous avons fait un constat constant : le véritable verrou est rarement dans le code. Derrière une "dette insurmontable" se cachent souvent des problèmes organisationnels : une culture de l’urgence qui interdit de dire « non », des décisions métier prises sans comprendre leurs impacts techniques, ou des équipes qui ont perdu le sens de leur mission. Cet article vise à réconcilier le business et la technique : la dette n’est pas un bug, c’est un outil de pilotage.

Abstract

La dette technique est souvent le bouc émissaire de l’immobilisme. Mais vouloir l’éradiquer est une illusion. Le vrai danger n'est pas son existence, mais son absence de pilotage. Lorsqu'elle devient invisible ou subie, elle ne paralyse pas seulement le système, elle paralyse la prise de décision. Cet article explore comment passer d'une dette "fatale" à un levier stratégique consciemment arbitré.

Introduction

La dette technique est devenue l’excuse universelle : « On ne peut pas livrer, c’est à cause de la dette. » Cette explication est confortable car elle dédouane tout le monde. Elle est aussi largement fausse.

La dette technique n'est pas une fatalité matérielle comme l'usure d'une machine. C'est le reflet de nos choix. Le véritable problème n’est pas la dette en soi, mais l’irresponsabilité dans la manière dont elle est contractée, ignorée et transmise.

1. La dette technique est un outil économique, pas un défaut moral

La métaphore de la dette, introduite par Ward Cunningham, sert à expliquer un arbitrage volontaire : livrer plus vite aujourd’hui, au prix d’un effort supplémentaire demain. Comme le rappelle Arnaud Lemaire, la dette technique est indissociable du flow de livraison.

L'analogie : Lancer un logiciel sans dette reviendrait à refuser tout emprunt pour créer une entreprise : possible en théorie, paralysant en pratique.

La dette devient un problème uniquement quand elle n’est plus visible, plus intentionnelle, ou plus remboursable.

2. La vraie fracture : dette consciente vs dette inconsciente

La ligne de fracture ne passe pas entre bonne et mauvaise dette, mais entre ce qui est maîtrisé et ce qui est subi.

• Dette consciente : Compromis explicite, coût futur estimé, seuil de remboursement identifié.
• Dette inconsciente : On ne sait plus pourquoi le code est ainsi, les auteurs sont partis, le métier ignore les risques. Chaque évolution devient une épreuve de force.

Nous sommes plusieurs à penser que ce n’est pas la dette en elle-même qui tue les systèmes, mais l’absence de mécanisme de pilotage pour la rendre visible et arbitrable.

3. Un problème organisationnel avant d’être technique

Dans beaucoup d’organisations, la dette est invisible pour le métier et internalisée comme une souffrance par les équipes.

Le vrai verrou : Nous avons vu des entreprises convaincues que leur code était "mort", alors que le blocage venait d'un processus de décision si lent que plus personne n'osait proposer de changement. Le problème n'était pas la complexité du logiciel, mais une culture de la peur.

C’est à cause de la peur, que certains éditeurs laissent passer des ruptures technologiques et décident très tard d’y aller, suite à un changement d’organisation par exemple. C’est aussi la peur qui freine les organisations qui veulent gommer leur dette d’un seul coup. Une approche itérative et progressive de modernisation est souvent possible et obligera à se concentrer sur l’essentiel.

Une dette qui ne peut pas être renégociée avec le métier n’est plus une dette : c’est un passif toxique.

4. Le rôle clé du Craft : rendre les compromis explicites

Le Software Craftsmanship n'élimine pas la dette, il impose une exigence : la rendre visible. Un développeur responsable ne dit pas : « On n’a pas le temps de faire propre ». Il dit : « Voici ce que nous simplifions aujourd'hui, et voici ce que cela coûtera de le stabiliser plus tard. »

5. Toutes les dettes ne se ressemblent pas

Le quadrant de Martin Fowler reste la référence :

1. Prudente & Délibérée : Saine, stratégique.
2. Prudente & Involontaire : Apprentissage inévitable.
3. Imprudente & Délibérée : Dette politique souvent risquée.
4. Imprudente & Involontaire : Négligence pure.

Ce dernier quadrant jaune n'est pas de la "dette", c'est un défaut de compétence.

6. Une équipe mature ne supprime pas la dette, elle la pilote

Les équipes performantes intègrent la qualité comme une variable de décision produit. Elles mesurent le coût réel (retards, bugs, friction) et arbitrent en continu. Maîtriser sa dette, ce n’est pas juste faire du "refactoring", c’est gouverner son patrimoine technologique.

Conclusion

La dette technique n’est pas un échec. L’ignorer, la masquer ou la transmettre sans explication en est un. Un système logiciel est un patrimoine vivant. Le professionnalisme consiste à choisir comment et pourquoi il se dégrade.

La prochaine fois que quelqu’un dira : « On a trop de dette technique », la seule question utile est : « Laquelle ? Pourquoi ? Et qu’est-ce qu’on fait concrètement ? » Si personne ne peut répondre, le problème n’est pas la technique. C’est l’irresponsabilité.