Le problème de la dette technique

J'écoutais dernièrement un épisode du podcast A la French avec Mehdi Medjaoui, Jean-Baptiste Kempf et Steeve Morin.

Ces derniers font un constat intéressant, le traitement de la dette technique sur un projet.

Ils ont commencé par définir les termes, et j'apprécie l'analogie:

La dette technique est un emprunt où on accepte de concéder de la qualité technique pour obtenir un gain de temps en contrepartie.

Et cette métaphore est totalement exacte car comme une dette financière, plus on la rembourse tard, plus les intérêts sont élevés.

Donc, traîner de la complexité et un risque de bugs.

Ensuite, ils embrayent sur l'utilité de réécrire le code et j'ai vécu énormément de choses énoncées:

• les nouveaux sur un projet ont souvent un biais de validation. Ils pensent que l'existant est médiocre et qu'il faut réécrire pour faire mieux et aller plus vite etc...
• il faut accepter certaines concessions parfois et se dire qu'une partie du code est endettée mais que ça ne vaut pas forcément le coup de le réécrire

Jean Baptiste dit une chose intéressante :

Bien souvent quand quelqu'un arrive au constat qu'il faut réécrire le code, c'est qu'il ne faut absolument pas réécrire.

Son principal argument, c'est que:

au bout de 3 mois quand le gros du projet est fait (le plus simple). On réalise que les petits cas en marges sont tellement complexes à gérer qu'on en revient au même niveau de vélocité.

Et c'est souvent à ce moment qu'on comprend que l'architecture d'avant faisait peut être sens.

Je suis entièrement aligné avec ça et d'ailleurs j'ai un principe:

Quand la principale raison pour réécrire du code, c'est "je peux mieux faire" ou "je ne comprends pas". C'est bien souvent que le problème c'est soi même et rarement le code existant.

Et je parle dans un cas précis:

• l'application tourne déjà
• l'application implémente déjà beaucoup de features
• pas ou peu de bugs remontés

Ici, le but de réécrire du code c'est soit disant le gain de temps à la clé ou encore l'égo.

Vous savez que vous êtes dans le faux, encore plus quand vous prenez cette décision sans être aligné avec tous les autres devs du projet.

Et une métriques intéressante pour démontrer ce que je dis:

Comparez le taux de bugs avant/après pour vous en rendre compte.

Il y a rapidement une tendance qui se dessine: plus le temps passe, plus vous perdez le contrôle.

De toute façon, on a beau annoncer la vague qui arrive, il n'y a que quand les gens commencent à se noyer qu'ils comprennent.

De plus, je trouve qu'aujourd'hui, en 2026, on doit vraiment se poser la question du refactor à tout prix, du moins à grande échelle. Le fait est qu'on est bien souvent capable d'aller chercher la vélocité via des LLMs. Arbitrer au mieux devient le vrai challenge technique d'aujourd'hui.