La dette technique n'existe pas. Ce qui existe, c'est la dette de décision.

La question qui m'a réduit au silence

CTO d'une boîte e-commerce de 80 personnes. Mission de 3 jours pour faire un audit de leur stack. À la fin du jour 2, je lui présente mes constats :

"Votre back-end est en monolithe Symfony 4 (EOL). 40 % des controllers n'ont aucun test. Le pipeline déploie en 47 minutes au lieu de 5. Vous avez 12 librairies désynchronisées entre projets. C'est de la dette technique sérieuse."

Il me regarde 5 secondes en silence. Puis :

"OK. Combien ça coûte ? Genre, en euros, sur les 12 prochains mois ?"

Je n'ai pas su répondre.

J'ai dit "ça vous ralentit". Il a répondu "Oui mais de combien ?". J'ai dit "vous prenez des risques". Il a répondu "Quels risques ? Statistiquement, ils arrivent quand ?".

J'ai bredouillé. J'avais raison sur le diagnostic. Je n'avais pas la moindre justification chiffrée.

C'est ce jour-là que j'ai compris que "dette technique" est un mot que les développeurs utilisent pour ne pas avoir à argumenter.

La vraie nature du problème

Quand on dit "on a de la dette technique", on dit en fait 3 choses distinctes :

1. Du code qu'on n'aime pas

Souvent du code qu'on a écrit nous-même, il y a 2 ans, et qui nous fait honte aujourd'hui. La honte est légitime — on a appris. Mais elle n'a aucune valeur business.

Réécrire du code dont on a honte n'apporte rien au client. C'est de la satisfaction personnelle déguisée en travail.

2. Du code qui ralentit objectivement

Là on commence à parler. "Cette feature nous prend 5 jours au lieu de 1 parce que le module X est mal conçu" est mesurable :

• 5 features par an touchent ce module
• Coût supplémentaire : 4 × 5 = 20 jours/an
• Tarif dev : 600 €/jour
• Coût annuel : 12 000 €

Refactor coûte 15 jours = 9 000 €. ROI atteint en 9 mois.

C'est ça, une vraie justification de refactor.

3. Du risque non-couvert

C'est le pire — invisible jusqu'à l'incident. "Notre Symfony est EOL" devient critique le jour où une CVE est publiée et qu'on n'a plus de patch. La probabilité × le coût d'occurence = le risque attendu.

Là encore, chiffrable. "EOL depuis 18 mois, 2 CVE/an en moyenne, coût d'un incident similaire dans le secteur : 80 000 € de remédiation". Risque annuel ≈ 16 000 €. Coût d'une migration prévue : 30 jours = 18 000 €.

Le refactor est rentable en 14 mois si on regarde le risque, pas le code.

Le piège des devs : le "code propre" comme valeur en soi

J'ai été ce dev pendant 5 ans. Je voyais du code que je trouvais moche et je voulais immédiatement le réécrire. "Single Responsibility violé." "Pas de DI." "Couplage fort." "Anti-pattern XYZ."

Et je ne comprenais pas pourquoi mon manager me disait "non, on garde".

Aujourd'hui je le comprends. Mon manager pesait le coût opérationnel d'un refactor (risque de bug régression, mois de prod stable foutu) contre la valeur réelle apportée (zéro pour le client).

Et zéro pour le client, ça veut dire non.

Le dev senior pose une question différente. Pas "ce code est-il propre ?", mais "combien ça coûte de garder ce code dans 12 mois ?"

Si la réponse est 50 000 €, on refactore. Si la réponse est "ça nous embête nous, mais ça marche", on garde.

Comment je chiffre la dette technique aujourd'hui

J'utilise une grille simple. Pour chaque "problème de dette" qu'un client me mentionne, je pose 5 questions :

Question 1 : "Combien de fois par mois ce code est-il modifié ?"

Si la réponse est "jamais", la dette est virtuelle. Du code mort n'a pas de dette. Tu peux le hair, ça n'a pas d'impact opérationnel.

Question 2 : "Quand vous le modifiez, combien de temps ça vous prend de

plus qu'attendu ?"

Ça donne le coût marginal en heures. Multiplié par la fréquence de modif et le TJM = coût annuel.

Question 3 : "Quelles features avez-vous renoncé à faire à cause de ce

code ?"

C'est la dette d'opportunité. Souvent invisible. Toujours la plus chère. "On voulait ajouter X mais c'était trop dur sur l'archi actuelle" = X de CA perdu chaque année.

Question 4 : "Quand est la dernière fois que ce code a causé un incident

en prod ?"

Donne le coût des incidents. Statistiquement, un incident à 80 000 € de remédiation tous les 18 mois = 53 000 €/an d'espérance.

Question 5 : "Si vous embauchez un nouveau dev sénior, combien de temps lui

faut-il pour être autonome sur cette zone du code ?"

Donne le coût de croissance bloquée. Si c'est 3 mois au lieu de 3 semaines, c'est 9 semaines de salaire investies sans output direct.

Avec ces 5 chiffres, j'arrive à un coût annuel total de la dette de cette zone. C'est ça que je présente au CTO. Pas "c'est moche".

Ce que ça change en mission

Sur le client e-commerce dont je parlais au début, voici la grille appliquée sur leur module commandes (la pire zone) :

Coût annuel total identifié : 190 000 €, dont 120 K€ de CA perdu sur multi-currency.

Refactor estimé : 4 mois × 2 devs = 100 000 €. ROI : ~5 mois.

Le CTO m'a écouté en silence. Puis il a dit :

"OK. Vous commencez quand ?"

Cette grille m'a vendu une mission de 4 mois à 100 K€. Le "c'est de la dette technique sérieuse" du début ne valait rien.

La leçon

La dette technique n'est pas du code. C'est une équation business non explicitée.

Tant que tu n'expliques pas en euros pourquoi un refactor est rentable, ton CTO a raison de te dire non. Pas par méchanceté. Par responsabilité fiduciaire. Son job n'est pas de payer ton refactor parce que tu trouves le code moche. Son job est d'optimiser le ROI du capital.

Le tien — si tu es dev senior — est de lui donner les chiffres. Pas le diagnostic vague.

Le jour où tu changes de vocabulaire — de "dette technique" à "190 000 € de coût annuel" — tu cesses d'être un dev qui se plaint. Tu deviens un dev que le CTO écoute.

C'est, en pratique, la différence entre un dev senior et un dev qui se croit senior.

Le pattern à appliquer demain

1. Pour chaque morceau de code que tu veux refactorer, chiffre les 5 questions au-dessus. Demande à ton manager s'il manque des données.

2. Compare au coût du refactor. Si le refactor est rentable, présente le chiffre, pas l'opinion.

3. Si tu ne peux pas chiffrer, c'est que tu n'as pas vraiment de cas business. Reviens-y dans 6 mois quand le pattern d'usage du code aura évolué.

C'est moins satisfaisant que "j'ai écrit un superbe refactor". C'est ce qui fait que ton CTO te promeut en lead.