Attention, opinion brûlante. Accrochez-vous.

J’ai passé pas mal de temps à écrire sur la dette technique, à prêcher les bonnes pratiques de code propre et à défendre les architectures solides. J’ai expliqué aux développeurs comment l’éviter, comment la rembourser, comment la négocier avec leurs managers.

Voilà le truc : j’avais partiellement tort.

Pas sur les pratiques, elles restent bonnes. Pas même sur toutes les utilisations du terme. Mais sur le fait d’accepter ce cadre conceptuel sans esprit critique.

La dette technique n’est pas juste mal comprise ; c’est une métaphore fondamentalement cassée qui déforme notre façon de penser le développement logiciel. Et le pire ? On continue à l’utiliser parce que c’est la seule métaphore financière que les dirigeants comprennent, ce qui veut dire qu’on est coincés à expliquer des problèmes d’ingénierie dans des termes qui obscurcissent activement ce qui se passe réellement.

Laissez-moi vous expliquer.

Le Problème avec la Métaphore

Ward Cunningham a créé le terme “dette technique” en 1992 pour décrire un scénario précis : choisir délibérément une implémentation rapide en sachant qu’on la refactorisera plus tard. Comme une dette financière, vous empruntez du temps maintenant avec la promesse de le rembourser avec intérêts.

Mais voilà ce qui se passe réellement dans la plupart des organisations :

Manager : “Pourquoi cette fonctionnalité prend autant de temps ? Je croyais que tu avais dit deux semaines ?”

Ingénieur : “Ben, on a beaucoup de dette technique à contourner…”

Manager : “Pff, pourquoi vous n’avez pas écrit du meilleur code dès le départ ?”

Et comme ça, les ingénieurs deviennent les méchants. Ceux qui ont “accumulé de la dette”. Ceux qui ont pris des “raccourcis”. Ceux qui freinent maintenant l’entreprise.

Sauf que c’est complètement n’importe quoi.

La Dette Implique Que Vous Aviez le Choix

La vraie dette fonctionne comme ça : vous allez voir un prêteur, vous négociez les termes, vous signez des papiers, et vous acceptez de rembourser le capital plus les intérêts. Vous comprenez le deal. Vous y consentez.

La dette technique ? Voilà comment ça se passe vraiment :

Manager : “Il faut que ça soit livré vendredi pour la démo investisseurs.”

Ingénieur : “Ce n’est pas assez de temps pour le faire correctement. On aurait besoin d’au moins trois semaines pour bien le construire.”

Manager : “Fais en sorte que ça marche. Je m’en fous comment.”

[Trois mois plus tard]

Manager : “Cette base de code est un bordel.”

Vous voyez le problème ? L’ingénieur n’a rien “emprunté”. Il n’a pas choisi la dette. On lui a donné des contraintes impossibles et il a fait de son mieux. Et maintenant on le blâme pour les “intérêts”.

Ce n’est pas de la dette technique. Ce sont les conséquences techniques des décisions du management.

Tout Code Vieillit (Ce N’est Pas de la Dette, C’est de l’Entropie)

Voilà un autre truc qui me rend fou : appeler n’importe quel vieux code “dette technique”.

Votre base de code de 4 ans qui utilise React 16 au lieu de la dernière version n’est pas de la “dette”. Votre API qui retourne du XML au lieu de GraphQL n’est pas de la “dette”. Votre monolithe que tout le monde voudrait maintenant transformer en microservices n’est pas de la “dette”.

C’est juste du code qui existe dans le temps.

Les exigences changent. Les plateformes évoluent. Les bonnes pratiques changent. De nouveaux frameworks émergent. Le contexte dans lequel votre code a été écrit n’est pas le contexte dans lequel il vit aujourd’hui.

Appeler ça de la “dette” implique que quelqu’un a fait une erreur. Ça implique de la négligence. Ça implique que si seulement les ingénieurs avaient été plus intelligents, plus visionnaires, plus compétents, ce ne serait pas un problème.

Mais ce n’est pas comme ça que le logiciel fonctionne. Ce n’est pas comme ça que quoi que ce soit fonctionne. On ne peut pas prédire l’avenir. On ne peut pas construire pour des exigences qui n’existent pas encore. Et même si on le pouvait, on ferait du sur-ingénierie et on perdrait du temps à construire une flexibilité qu’on n’utilisera jamais.

La “Dette” Était Généralement la Bonne Décision

Parlons de ce MVP que vous avez construit il y a deux ans. Celui qui est maintenant “legacy”. Celui qui “doit être réécrit”. Celui qui “vous freine”.

Vous savez ce que ce MVP a aussi fait ? Il a validé votre modèle économique. Il a acquis vos mille premiers utilisateurs. Il a généré le revenu qui vous permet d’avoir cette conversation.

Sans ce “mauvais code”, vous n’auriez rien. Vous auriez fait faillite en attendant “l’architecture parfaite”.

Mais maintenant qu’il a du succès, maintenant qu’il scale, maintenant que vous voulez aller plus vite… soudainement c’est de la “dette technique”. Soudainement les ingénieurs qui ont construit la chose qui a rendu votre entreprise viable sont blâmés pour ne pas l’avoir construite “correctement”.

C’est du biais du survivant et du biais rétrospectif roulés en un seul burrito toxique.

Ce Que les Managers Appellent “Dette”, les Ingénieurs l’Appellent “Compromis”

Chaque décision d’ingénierie est un compromis. Pas quelques-unes. Pas la plupart. Toutes.

• Vitesse vs flexibilité
• Simplicité vs fonctionnalités
• Technologie éprouvée vs innovation
• Construire vs acheter
• Monolithe vs microservices
• SQL vs NoSQL
• Couverture des tests vs vitesse de livraison

Il n’y a pas de “bonne” réponse à ces questions. Il y a seulement “bon pour notre contexte actuel, nos contraintes et nos priorités”.

Les bons managers comprennent ça. Ils participent à ces décisions. Ils disent des choses comme :

“On optimise pour la vitesse maintenant parce qu’on doit valider le marché. On revisera l’architecture une fois qu’on aura trouvé notre product-market fit.”

Les mauvais managers disent :

“Fais juste en sorte que ça marche. Démerde-toi.”

Et puis plus tard :

“Pourquoi il y a autant de dette technique ?”

Le Vrai Problème : L’Ignorance Qui S’Accumule

Voilà ce qui se passe vraiment quand les managers ne comprennent pas la nature cumulative des coûts de maintenance :

Année 1 : “Livrez vite ! Ne vous inquiétez pas du code parfait !”

Année 2 : “Pourquoi les nouvelles fonctionnalités prennent plus de temps ? On livrait si vite avant !”

Année 3 : “On doit arrêter tout le travail sur les fonctionnalités et faire une réécriture.”

Ce n’est pas de la dette technique. C’est le management qui ne comprend pas que la maintenance logicielle n’est pas gratuite. Que chaque fonctionnalité ajoute de la surface. Que chaque dépendance doit être mise à jour. Que chaque API nécessite du versioning.

Les ingénieurs le savaient. Ils vous l’ont dit. Vous n’avez pas écouté parce que vous étiez concentré sur le prochain trimestre.

OK, Mais Et Les Vrais Raccourcis ?

D’accord. Oui. Parfois les ingénieurs coupent vraiment les coins. On saute l’écriture des tests. On code en dur des valeurs. On ne gère pas les erreurs correctement. On fait du copier-coller au lieu d’abstraire.

Mais vous savez quoi ? Ça arrive presque toujours à cause de pression externe.

“On a besoin de ça pour la démo de demain.”

“Le client menace de partir si on ne livre pas cette semaine.”

“On perd de l’argent et on a besoin de revenus maintenant.”

Même les vraiment mauvaises décisions d’ingénierie sont généralement prises sous contrainte, avec un temps limité, des informations incomplètes et une pression immense de… attendez… le management.

La Vérité Inconfortable : Parfois C’est Vraiment de la Mauvaise Ingénierie

Bon, soyons honnêtes. Je ne peux pas écrire tout un article pour défendre les ingénieurs sans reconnaître l’éléphant dans la pièce : parfois le code est vraiment juste mauvais, et ce n’est pas la faute du management.

Parfois vous embauchez un développeur qui :

• Ne comprend pas le langage ou le framework qu’il utilise
• Copie des réponses Stack Overflow sans les comprendre
• Écrit des conditionnelles imbriquées sur douze niveaux parce qu’il n’a jamais appris les retours anticipés
• Crée des classes Dieu de 5 000 lignes parce que “c’est plus facile de tout garder au même endroit”
• Refuse d’apprendre ou de progresser parce que “c’est comme ça que j’ai toujours fait”

Et parfois, votre processus de revue de code est tellement cassé que ce truc arrive en production quand même.

La Revue de Code Qui Approuve Tout

Vous connaissez ce pattern. Quelqu’un ouvre une PR à 16h45 un vendredi. C’est 847 lignes de changements sur 23 fichiers. Le reviewer y jette un œil pendant 90 secondes, ne voit pas d’erreurs de syntaxe évidentes, et clique sur “Approve” pour pouvoir commencer son week-end.

Ou pire, vous avez un ingénieur “senior” qui est territorial et sur la défensive, et tout le monde a peur de donner un vrai feedback parce que la dernière fois que quelqu’un a suggéré un refactoring, il a reçu un essai de 2 000 mots expliquant pourquoi il a tort suivi de trois semaines de messages Slack passifs-agressifs.

Quand l’Équipe N’a Aucun Standard

Certaines équipes n’ont vraiment aucun standard de code. Pas de guide de style. Pas de principes architecturaux. Pas de patterns convenus. Tout le monde fait juste ce qui lui semble bon sur le moment.

Une personne écrit du code fonctionnel avec des structures de données immuables. Une autre écrit de l’OOP avec beaucoup d’héritage. Une troisième a découvert l’injection de dépendances la semaine dernière et injecte maintenant tout y compris l’évier de cuisine. La quatrième veut juste livrer et se fout de tout ça.

Le résultat ? Une base de code Frankenstein où chaque module a l’air d’avoir été écrit par une entreprise différente.

Le Développeur Junior Laissé Sans Supervision

Voilà un scénario plus commun qu’on voudrait l’admettre : vous embauchez un développeur junior, vous lui donnez un ticket, et… personne ne vérifie son travail. Il galère pendant deux semaines, finit par faire marcher quelque chose par essai-erreur, et le livre. Ça marche (plus ou moins), donc ça part en production.

Six mois plus tard, quelqu’un doit modifier ce code et découvre que ça tient avec du scotch et des prières. Pas de tests. Pas de gestion d’erreurs. Des variables nommées temp1, temp2, finalFinal, finalFinalActuel. La logique métier mélangée avec le code UI mélangé avec les requêtes de base de données.

Est-ce de la dette technique ? Est-ce la faute du management ? En quelque sorte oui, en quelque sorte non.

Le management a échoué à fournir du mentorat et de la supervision. Mais aussi, l’ingénieur aurait pu demander de l’aide. Aurait pu regarder le code existant pour les patterns. Aurait pu… vous savez, essayer.

La Nuance Dont Personne Ne Veut Parler

Donc voilà où ça devient compliqué. Parce que même quand le code est vraiment mauvais à cause d’échecs d’ingénierie, le cadre de “dette technique” est toujours faux.

Pourquoi ? Parce qu’appeler ça “dette” :

• Le cadre comme un compromis intentionnel (ce n’en était pas un)
• Implique qu’elle devrait être “remboursée” (elle devrait être corrigée)
• Obscurcit la cause racine (problèmes d’embauche, de formation, de revue de code, ou de standards)

Si vous avez embauché quelqu’un qui n’est pas assez bon, c’est un problème d’embauche. Si vos revues de code n’attrapent pas les problèmes, c’est un problème de processus. Si votre équipe n’a pas de standards, c’est un problème de leadership. Si les juniors livrent du code impossible à maintenir, c’est un problème de mentorat.

Rien de tout ça n’est de la “dette”. Ce sont des échecs organisationnels qui se manifestent par des problèmes de qualité de code.

Et voilà le truc : même ces échecs remontent souvent aux décisions du management. Qui a décidé de :

• Embaucher les développeurs les moins chers au lieu des meilleurs ?
• Sauter la partie technique de l’entretien parce que le candidat “avait l’air intelligent” ?
• Ne pas allouer du temps d’ingénieur senior pour les revues de code et le mentorat ?
• Ne jamais investir dans l’établissement de standards d’équipe ou de directives architecturales ?
• Prioriser les story points sur la qualité du code ?

Vous voyez comment on revient toujours au management ?

Quand les Ingénieurs Doivent Assumer

Mais ne nous laissons pas complètement décrocher. En tant qu’ingénieurs, on doit assumer notre métier. On doit :

• Vraiment reviewer le code, pas juste l’approuver automatiquement
• Donner et recevoir du feedback comme des professionnels
• Investir dans l’apprentissage et la croissance
• Demander de l’aide quand on est bloqué
• Repousser le code terrible dans les PRs, même si c’est inconfortable
• Établir et maintenir des standards en équipe

Si vous avez approuvé une PR sans la lire, vous partagez la responsabilité de ce code. Si vous avez écrit du code bâclé parce que vous n’aviez pas envie de faire attention, c’est sur vous. Si vous écrivez les mêmes mauvais patterns depuis cinq ans et refusez d’apprendre, vous êtes le problème.

La différence ? Quand on assume ces échecs, on peut vraiment les corriger. On peut améliorer notre culture de revue de code. On peut monter en compétences. On peut établir de meilleures pratiques.

Mais quand on se cache derrière “dette technique” comme fourre-tout vague, on ne peut rien corriger parce qu’on n’identifie même pas le vrai problème.

Alors Comment Devrait-On Appeler Ça ?

Au lieu de “dette technique”, essayez :

“Conséquences techniques des décisions business passées” – Verbeux, mais précis. Garde la responsabilité là où elle appartient.

“Coût de maintenance” – Chaque base de code en a un. Il grandit avec le temps. Budgétez pour ça.

“Changement de contexte” – Ce qui avait du sens il y a deux ans n’en a plus maintenant. C’est OK.

“Refactoring nécessaire” – Le logiciel évolue. Le refactoring est normal. Arrêtez de le traiter comme une punition.

“Le coût d’apprendre” – Vous ne saviez pas que ce que vous construisiez aurait du succès. Maintenant vous le savez. Il est temps d’optimiser.

Conclusion

La dette technique n’est pas un mythe parce que les raccourcis n’existent pas. C’est un mythe parce que la métaphore a été corrompue au-delà de toute reconnaissance.

Elle est devenue un moyen pour les managers de :

• Blâmer les ingénieurs pour des décisions business
• Éviter la responsabilité pour l’allocation des ressources
• Traiter l’évolution normale du logiciel comme de la négligence
• Échapper à la responsabilité des deadlines impossibles

Les bons managers assument les compromis. Ils disent “On a choisi la vitesse plutôt que la flexibilité et maintenant on doit ré-optimiser. Ça prendra du temps et des ressources. J’alloue les deux.”

Les mauvais managers weaponisent le recul. Ils disent “Vous auriez dû bien le construire dès le début. Pourquoi il y a autant de dette technique ?”

Si vous êtes un manager qui lit ceci et que vous vous êtes déjà plaint de dette technique, demandez-vous : avez-vous donné à votre équipe le temps et les ressources pour le construire “correctement” ? Saviez-vous même ce que “correctement” voulait dire ? Ou vouliez-vous juste que ce soit livré ?

Si vous êtes un ingénieur qui lit ceci, arrêtez d’accepter le blâme pour des décisions qui n’étaient pas les vôtres. La prochaine fois que quelqu’un mentionne la dette technique dans une rétro, essayez ça :

“Parlons des contraintes sous lesquelles on travaillait quand on a pris ces décisions. Parce que je suis à peu près sûr qu’on a fait le meilleur choix possible avec l’information et le temps qu’on avait.”

Et s’ils insistent ? S’ils persistent à dire que c’est de la “dette” que vous avez “empruntée” ?

Commencez à passer des entretiens. Parce que vous travaillez pour quelqu’un qui ne comprend pas le développement logiciel et qui vous blâmera toujours quand les choses deviennent difficiles.