Architecture & delivery / Dette technique
La dette technique n’est pas le vrai problème.
Le vrai problème, c’est de faire comme si elle n’existait pas…
ou de vouloir l’éliminer à tout prix.
Le combat intérieur de tout développeur
Pour beaucoup de développeurs, accepter la dette technique est un combat.
Accepter de dire :
“Stop. Là, je livre quelque chose de fonctionnel,
même si ce n’est pas parfait.”
Ce n’est pas naturel.
Parce qu’on a tous cette envie : finir proprement, factoriser, optimiser, réécrire “comme il faut”.
Je développe des solutions depuis plus de 15 ans, et je lutte encore aujourd’hui contre cette pulsion.
Celle de vouloir toujours améliorer, toujours réinventer, toujours “faire mieux”.
La claque YAGNI (et pourquoi ça fait mal)
Je me souviens très bien d’une discussion avec un manager qui me disait :
“Mon paradigme, c’est YAGNI.”
YAGNI signifie
You Aren’t Gonna Need It : ne développe pas ce dont tu n’as pas besoin maintenant.
À l’époque, je me suis dit : “En fait, ce mec est juste un sagouin. Il code sale, il ne veut pas faire les choses bien.”
Et puis, avec le recul, j’ai compris qu’il avait raison.
Pas parce qu’il fallait mal faire son travail. Mais parce que, dans un projet, ce qui compte avant tout, c’est de sortir sur le marché.
Le vrai enjeu : le go-to-market, pas la perfection
Un logiciel n’existe vraiment que lorsqu’il est utilisé.
Tant qu’il est dans un dépôt Git, aussi élégant soit-il, il ne crée aucune valeur.
Le go-to-market est donc prioritaire :
Livrer vite
Tester le marché
Générer du business
Et c’est là que la dette technique devient acceptable.
Parce que coder “aux petits oignons” une fonctionnalité que le client jettera dans trois mois est une perte de temps et d’argent.
Quand la dette devient réellement dangereuse
Le problème n’est pas la dette en soi. Le problème, c’est la dette non pilotée.
J’ai vu des sociétés incapables de pivoter après plusieurs années de développement.
Pourquoi ?
dépendances dans tous les sens
code figé
architecture impossible à faire évoluer
À ce stade, ajouter une fonctionnalité ou faire une migration devient un cauchemar.
Là, oui, la dette technique devient un vrai problème business.
Première règle : rendre la dette visible
Une dette invisible est une dette dangereuse.
Et là, je vais dire un truc que beaucoup de développeurs sous-estiment :
les TODO dans le code sont importants
Un TODO ne veut pas dire “j’ai mal travaillé”.
Ça veut dire : “je sais qu’il y a un compromis ici, et je veux pouvoir y revenir”.
Aujourd’hui, en plus, ces annotations peuvent être relues par des outils, par des LLM, et servir de points d’entrée pour de futurs refactorings.
Deuxième règle : consigner la dette dans un backlog
La dette ne doit pas rester dans la tête des développeurs.
Elle doit être :
discutée avec les tech leads
partagée avec le chef de projet
consignée dans un backlog
Refactoring envisagé, amélioration possible, dette acceptée temporairement: tout doit être écrit.
Et surtout : ne jamais céder aux pulsions.
Relire un backlog avec un peu de recul permet souvent de se rendre compte que certaines refontes n’étaient finalement pas si utiles.
La dette comme levier business
La dette technique, quand elle est maîtrisée, est un levier.
Elle permet :
d’aller plus vite
de tester des hypothèses
de financer la suite grâce au business
Parce que, soyons honnêtes : vous devez rentrer de l’argent.
Votre client doit faire du business avec le logiciel que vous livrez.
Et ce sont ces revenus qui permettront plus tard de nettoyer, refactorer, consolider.
L’architecture comme filet de sécurité
Toutes les dettes ne se valent pas.
Une architecture bien pensée permet de vivre beaucoup plus sereinement avec la dette.
Des approches comme :
DDD
SOA / macro-services
architecture hexagonale
permettent d’isoler les compromis, de faire évoluer certaines parties sans tout casser.
C’est exactement ce qu’on a fait sur plusieurs plateformes chez Winzana : accepter des dettes locales, sans mettre en danger l’ensemble.
Conclusion
La dette technique n’est pas un échec.
Elle devient un problème uniquement quand elle est ignorée, subie, ou niée.
Acceptez-la,
rendez-la visible,
consignez-la,
pilotez-la.
Et surtout : ne sacrifiez jamais votre go-to-market pour une perfection que personne ne vous a demandée.
La maturité technique, ce n’est pas l’absence de dette.
C’est la capacité à vivre avec, intelligemment.
