10 février 2026
N'oublie jamais de te demander "pourquoi ?"
La frustration face au code legacy nous fait parfois oublier d'étudier son histoire. La dette d'hier peut-elle nous aider à mieux comprendre la dette de demain ?« Tiens tiens tiens, mais qui à encore écrit ça... git blame !»
Cette phrase, on l’a tous prononcée – parfois avec ironie, parfois sans – quand une implémentation nous bloque. Le code legacy a ce curieux pouvoir de nous faire grincer des dents. Code smells, pratiques anciennes, utilitaires dépréciés... Tant de choses qui limitent une évolution simple et rapide. On se surprend à penser : « Si seulement ils avaient fait les choses "correctement", on n’en paierait pas le prix maintenant. »
Comprendre le contexte
Pourtant, se demander « pourquoi ? », plutôt que de juger à l’aune des contraintes actuelles, est salvateur :
- Y avait-il une limitation technique à l’époque ?
- La deadline était-elle serrée ?
- Quelles étaient les spécifications techniques initiales ?
- La dette technique était-elle anticipée ou est-elle apparue ultérieurement ?
Cela nous rappelle que la dette n’est pas le fruit d’un manque de compétence – même si parfois... PEBKAC –, mais d’une réflexion résultant de problèmes que nous n’avons plus aujourd’hui.
C’est cette compréhension qui nous pousse à écrire aujourd’hui le code legacy de demain avec plus de rigueur.
Vers une gestion éclairée de la dette technique
« Everything we’re writing right now… maybe the code you’re building literally today, if things go really well, that is the legacy code of tomorrow. » — Shawna Martell, Building Tomorrow’s Legacy Code, Today
Adopter cette démarche transforme notre rapport à la dette future. Documenter le contexte, clarifier les choix et les compromis devient une évidence. La dette assumée se distingue alors de la négligence, et chaque ligne de code reflète une décision éclairée. Reste à déterminer le moment opportun pour la rembourser. Réussir à ne jamais crée de dette sans ruinner son élan est une arcane à étudier.
La dette technique n'est donc pas un héritage maudit - même si voué à se répéter si oublié - mais une opportunité d'apprentissage qui nous guide vers une meilleure maîtrise de notre métier.
« Il n’y a pas de mal à fonder des espoirs sur ce qu’on ignore. »
- Gandalf, La Communauté de l’Anneau
Merci à Seb, qui au cours d’une session de pair programming, m'a rappelé que « l'important, c'est bien de se demander "pourquoi ?" » (citation approximative).