Kraft.gg - Formations

Appearance

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