Chiffrer et financer une dette technique

Dans presque toutes les entreprises où j’interviens, l’équipe technique parle de dette technique depuis longtemps, et la direction l’entend comme une plainte. « Le code est vieux », « il faudrait tout refaire », « on n’a jamais le temps de nettoyer ». Ces phrases sont souvent vraies, mais elles ne permettent pas de décider. Un comité de direction arbitre entre des investissements : il lui faut un montant, un délai, un risque évité et un gain attendu. Tant que la dette n’est pas exprimée dans ces termes, elle perd systématiquement face à la prochaine fonctionnalité demandée par un client.

Voici la méthode que j’applique pour passer du constat diffus à une décision de financement. Je l’utilise lors des audits, des reprises de projet et des due diligences, et elle fonctionne aussi bien pour une petite application métier que pour un produit SaaS. Les commandes sont des exemples génériques, à adapter à votre outillage.

1. Ce qu’on appelle dette, et ce qu’on n’appelle pas dette

Le mot couvre trop de choses, et c’est la première cause de dialogue de sourds. Je sépare d’emblée trois catégories, parce qu’elles ne se financent pas de la même manière :

• La dette de maintenance : versions du langage, du framework, de la base ou des dépendances en fin de support. Elle n’est pas un choix de conception, elle arrive avec le temps, et elle a souvent une date butoir externe.
• La dette de conception : un module que tout le monde a peur de toucher, un modèle de données qui ne correspond plus au métier, des règles copiées à plusieurs endroits. Elle ralentit chaque évolution.
• La dette d’outillage et de pratique : absence de tests, déploiement manuel, absence de supervision, documentation inexistante, savoir concentré sur une personne. Elle augmente le risque de chaque mise en production.

Ce qui n’est pas de la dette : une fonctionnalité manquante, un choix technologique qui ne plaît pas à un nouveau développeur, un code qui marche bien mais qu’on écrirait autrement aujourd’hui. Si on ne peut pas dire ce que le problème coûte ou fait risquer, ce n’est pas une dette, c’est une préférence. Retirer ces sujets de la liste dès le départ rend le reste beaucoup plus crédible.

2. Repérer la dette à partir de mesures, pas d’opinions

Je commence toujours par les outils, avant les entretiens. Les mesures ne disent pas tout, mais elles orientent les questions et évitent que la liste reflète seulement les agacements de la personne la plus bavarde de l’équipe.

L’historique du code. Les fichiers modifiés le plus souvent, croisés avec leur taille, désignent les zones où la dette coûte réellement, parce qu’on y travaille sans cesse. Un fichier énorme que personne ne touche est un problème bien moins urgent qu’un fichier moyen modifié chaque semaine.

# Fichiers les plus modifiés sur les douze derniers mois
$ git log --since="12 months ago" --name-only --pretty=format: \
    | grep -v '^$' | sort | uniq -c | sort -rn | head -20

# Qui connaît ces fichiers
$ git shortlog -sn --since="12 months ago" -- src/Facturation/

Les dépendances et leur fin de support. Un audit des vulnérabilités connues et un relevé des versions, croisé avec les dates de fin de support publiées par les éditeurs (le site endoflife.date les centralise) :

$ composer outdated --direct
$ composer audit
$ npm outdated
$ npm audit --omit=dev

Les tests. Pas le pourcentage de couverture global, qui ne dit presque rien, mais la question : les parcours qui font le chiffre d’affaires (commande, facturation, paiement, calculs réglementaires) sont‑ils couverts par des tests qui tournent automatiquement à chaque modification ? Et la CI peut‑elle échouer, ou les erreurs sont‑elles ignorées ?

Les incidents. L’outil de tickets et la supervision donnent la liste des incidents de production sur les derniers mois. Je les regroupe par module. Quand une même zone revient dans les incidents et dans les fichiers les plus modifiés, on tient presque toujours la dette la plus chère du système.

Le temps de livraison. Le délai entre une demande validée et sa mise en production, et sa variation selon les modules. Si une petite évolution sur la facturation prend trois fois plus de temps qu’une évolution comparable ailleurs, l’écart est une mesure directe du coût de la dette dans cette zone.

Viennent ensuite les entretiens avec les développeurs, avec une question très simple : « sur vos trois dernières demandes, qu’est-ce qui vous a fait perdre du temps ? ». Les réponses concrètes valent mieux que la question générale « où est la dette ? », qui produit des listes de souhaits.

3. Traduire chaque point en jours, avec ses hypothèses

Chaque élément de dette retenu devient un chantier, et chaque chantier une fourchette en jours de travail. Je chiffre en jours et non en euros, parce que le même chantier ne coûte pas la même chose selon l’équipe qui le réalise : c’est à la direction de valoriser ces jours au coût réel de son équipe interne ou de son prestataire.

Deux règles rendent ces chiffres défendables devant un comité :

• Une fourchette, jamais un chiffre unique. Un écart étroit signifie que j’ai lu le code concerné. Un écart large signale une incertitude, et je dis laquelle : « de 15 à 30 jours, selon le nombre de requêtes SQL écrites à la main dans les templates, que je n’ai pas encore comptées ».
• Une hypothèse écrite à côté de chaque estimation. « Migration par étapes, avec des tests ajoutés sur les parcours touchés », « l’hébergement actuel est conservé », « le développeur historique reste disponible pendant la transmission ». Si l’hypothèse tombe, le chiffre change, et tout le monde le sait à l’avance.

Pour estimer, je découpe le chantier en étapes livrables de quelques jours au plus. Une estimation de quarante jours d’un seul bloc est presque toujours fausse ; la même somme découpée en dix étapes de trois à cinq jours se vérifie, se discute et se suit.

4. Traduire chaque point en risque et en coût de non-action

Les jours de travail disent combien coûte le remboursement. Le comité a besoin de l’autre moitié : ce que coûte de ne rien faire. C’est cette moitié qui manque presque toujours, et c’est pour cela que la dette perd les arbitrages.

Je la formule selon trois types de coût, en restant prudent et en distinguant ce qui est mesuré de ce qui est estimé :

• Le surcoût récurrent : le temps perdu sur chaque évolution dans la zone concernée. Si l’historique montre que l’équipe passe régulièrement du temps à contourner un module, on peut l’exprimer en jours par mois, avec la méthode de calcul visible.
• Le risque d’incident : ce qui peut arriver, avec quel impact métier (facturation bloquée, données perdues, site indisponible), et un niveau de probabilité qualitatif (faible, moyen, élevé) justifié par des faits, par exemple les incidents passés ou l’absence de restauration testée.
• L’échéance subie : une fin de support de sécurité, une obligation réglementaire, une exigence d’un client ou d’un investisseur. Elle ne dépend pas de vous, et passée cette date, le chantier coûte plus cher parce qu’il se fait dans l’urgence.

Je n’invente jamais un montant de perte en euros sur un incident hypothétique : un chiffre fragile décrédibilise tout le reste. Il vaut mieux écrire « la facturation mensuelle repose sur un script sans test, exécuté à la main par une seule personne » et laisser la direction juger de l’impact, qu’elle connaît mieux que moi.

5. Classer : une matrice simple, trois horizons

Une liste de vingt chantiers ne se décide pas. Je classe chaque point selon deux axes, le coût de non-action et le coût de remboursement, puis je les répartis sur trois horizons :

La troisième ligne est aussi importante que les deux autres. Dire explicitement qu’une partie de la dette ne sera pas remboursée, parce qu’elle ne coûte rien de mesurable, rend le reste plus crédible et protège l’équipe du sentiment d’une liste infinie. Une dette sur un module que personne ne modifie peut rester en place des années sans dommage.

6. Présenter la dette à un comité de direction

Un comité n’a ni le temps ni l’envie de lire un rapport d’audit complet. Je prépare une page de synthèse, et je garde le détail technique en annexe pour l’équipe. Cette page répond à cinq questions, dans cet ordre :

1. Où en sommes-nous ? L’état en quelques lignes, avec une note par domaine (code, sécurité, tests et déploiement, savoir, documentation) et une phrase de justification pour chacune.
2. Qu’est-ce qui peut mal tourner, et quand ? Les deux ou trois risques de l’horizon « maintenant », en langage métier.
3. Combien cela coûte-t‑il de corriger ? Le total en jours par horizon, en fourchette, avec les hypothèses principales.
4. Que gagne-t‑on ? Le risque évité et le surcoût récurrent supprimé, formulés prudemment.
5. Que demande-t‑on ? Une décision précise : un budget en jours, une part de capacité, une date de revue.

La structure de l’exemple de rapport publié sur ce site suit cette logique (synthèse, notes par domaine, risques, plan à 30, 60 et 90 jours), sur des données fictives. Elle peut servir de gabarit pour votre propre présentation.

Deux pièges à éviter devant un comité. Le premier est de présenter la dette comme une faute de l’équipe ou du prestataire : une partie de la dette vient de décisions raisonnables prises sous contrainte de délai, et chercher un coupable bloque la discussion. Le second est de demander tout d’un coup : un comité qui voit un chantier de six mois sans livraison intermédiaire refuse, et il a souvent raison.

7. Rembourser au fil de l’eau ou ouvrir un chantier dédié

C’est la décision centrale, et elle ne se tranche pas par principe. Les deux modes ont leur place, souvent dans le même plan :

Pour le remboursement au fil de l’eau, je recommande une part de capacité réservée et visible, plutôt qu’une promesse vague de « nettoyer quand on aura le temps ». Un repère usuel se situe autour de 15 à 20 % de la capacité de l’équipe, mais le bon niveau dépend de l’état de départ et doit être revu après quelques mois. La règle qui l’accompagne : toute évolution dans une zone endettée laisse cette zone un peu meilleure (un test ajouté, une duplication supprimée), et ce travail est inclus dans l’estimation, pas facturé à part.

Pour un chantier dédié, je pose trois conditions avant de le lancer : un filet de tests sur les parcours critiques touchés, un découpage en étapes livrables qui laisse l’application en service pendant toute la durée des travaux, et un critère de fin vérifiable (« l’application tourne en production sur la version maintenue du framework », et non « le code est propre »). Je me méfie par défaut des réécritures complètes : elles demandent de redécouvrir toutes les règles métier enfouies dans l’ancien code, et c’est presque toujours là que les délais explosent.

8. Suivre la réduction dans le temps

Une dette financée qu’on ne suit pas revient en six mois, et la direction perd confiance dans le prochain chiffrage. Je tiens un tableau de dette vivant, dans le dépôt ou dans l’outil de tickets, avec pour chaque ligne le constat, l’horizon, la fourchette initiale, le consommé et l’état. Il est revu chaque mois, et présenté au comité chaque trimestre.

Je suis aussi quelques indicateurs de tendance, qui montrent si le remboursement produit l’effet promis :

• Le temps de livraison sur les zones traitées, comparé à sa valeur avant les travaux.
• Le nombre d’incidents de production par module, sur une période glissante.
• Le nombre de vulnérabilités connues remontées par l’audit automatique des dépendances.
• La couverture des parcours critiques, exprimée en liste de parcours testés plutôt qu’en pourcentage.
• Le nombre de personnes capables d’intervenir sur chaque module critique.
• L’écart entre estimé et consommé sur les chantiers de dette, pour améliorer les chiffrages suivants.

Le dernier indicateur est souvent négligé, et il compte beaucoup. Si les chantiers de dette consomment régulièrement le double de leur estimation, il faut le dire et corriger la méthode, pas le cacher : c’est ce qui permet de garder la crédibilité de l’équipe pour les arbitrages suivants.

Le même tableau sert lors d’une levée de fonds ou d’une cession. Une entreprise qui présente une dette chiffrée, classée et en cours de réduction aborde une due diligence technique dans une position bien plus solide qu’une entreprise dont l’acheteur découvre la dette lui-même : dans le premier cas, la dette est un plan ; dans le second, elle devient un argument de négociation contre le vendeur. J’ai vécu ce processus côté entreprise examinée, et la différence se joue largement là.

Une dette qu’on ne chiffre pas se rembourse quand même : en retard, en incidents, puis en urgence.

Les leçons

• Trier avant de chiffrer. Maintenance, conception, outillage, et ce qui n’est qu’une préférence sort de la liste.
• Les mesures avant les opinions. Historique du code, dépendances, tests, incidents et temps de livraison désignent la dette qui coûte vraiment.
• Des jours en fourchette, avec hypothèses. Jamais un chiffre unique, jamais d’euros à la place de la direction.
• Toujours le coût de non-action. Surcoût récurrent, risque d’incident, échéance subie : c’est ce qui fait gagner l’arbitrage.
• Trois horizons, dont un « jamais ». Renoncer explicitement à une partie de la dette rend le reste crédible.
• Une page pour le comité, une décision précise demandée. Le détail technique reste en annexe.
• Les deux modes de remboursement se combinent. Une part de capacité visible au quotidien, un chantier dédié pour ce qui est structurel ou daté.
• Un tableau vivant et des tendances. Ce qui n’est pas suivi revient.