Dette technique & Entropie logicielle
1. Qu’est-ce que la dette technique ?
La dette technique est une métaphore introduite par Ward Cunningham :
Lorsque l’on prend un raccourci technique pour aller plus vite, on contracte une dette. Si elle n’est pas remboursée, elle s’accumule avec des intérêts.
Exemples de dette technique
- Code dupliqué ou non testé
- Fonctionnalité livrée sans design clair
- Architecture improvisée sous pression
- Documentation absente ou obsolète
2. Le coût réel de la dette
- Une étude de 745 applications (365M lignes de code) montre :
- Des défauts critiques omniprésents
- Un coût moyen de 3,61 $ par ligne pour les corriger
- Certains projets deviennent économiquement non viables avant leur mise en production
La dette technique impacte directement la maintenabilité, la sécurité, et la capacité d’évolution d’un système.
3. Complexité accidentelle & entropie
Complexité essentielle vs accidentelle
- Complexité essentielle : liée au métier, au besoin réel
- Complexité obligatoire : introduite par le besoin fonctionnel de l'applicatif (ex : serveur http)
- Complexité accidentelle : la mauvaise conception ou les pratiques mal maîtrisées
L’entropie logicielle augmente naturellement : sans soin, un système “pourrit”.
Sources d’entropie
- Stack technique mal choisie
- Outils non compris
- Documentation absente
- Couplage fort entre modules
- Architecture figée
4. Le développement pas ou peu piloté
Quand les retards s’accumulent, les équipes :
- Priorisent les livraisons à court terme
- Multiplient les rustines
- Perdent la vision long terme
Cela crée un cycle d’endettement permanent, où l’on code pour survivre, plus pour durer.
5. L’illusion des outils
"No tool will save you from bad processes."
- NoSQL ≠ magie (ex : pas de jointures)
- CI/CD ≠ DevOps sans culture
- Framework ≠ architecture
Les outils doivent s’adapter au métier, pas l’inverse.
6. Aliénation technique
Quand on utilise des outils sans les comprendre :
- On subit plus qu’on ne conçoit
- On duplique les erreurs des autres
- On renforce l’entropie
Le rôle du dev est de choisir ses outils en conscience, pas de les empiler.
7. L’architecture et le découplage
Une mauvaise architecture est une dette silencieuse.
- Une base de données centrale mal découpée peut rendre toute évolution risquée.
- Un manque de séparation des responsabilités complique chaque changement.
Découpler, c’est concevoir pour le changement, pas pour le confort immédiat.
8. Responsabilités partagées
La dette technique :
- N’est pas qu’un problème de dev
- Engage aussi les PO / OPS, les achats, le management
- Se combat par une culture partagée de la qualité
À retenir
- La dette technique est inévitable, mais doit être maîtrisée
- L’entropie vient surtout de la complexité inutile
- Le bon outil, au bon moment, dans le bon contexte
- L’architecture est un investissement, pas un luxe
- L’amélioration continue est la seule réponse durable