Accueil/Ressources/Coût de la dette technique

Note

Ce que coûte vraiment la dette technique

Dire « La dette technique est importante » n'aide personne à décider de quoi que ce soit. Une phrase utile dans une négociation doit contenir un nombre de jours, un horizon, et ce qu'on obtient en échange.

Mis à jour le 4 septembre 2026

I. Trois choses derrière un seul mot

On appelle « dette technique » trois réalités très différentes, et les confondre est la première cause de chiffrages fantaisistes.

• La dette choisie. Un raccourci assumé pour tenir une date. C'est un emprunt au sens propre : l'équipe a acheté du temps contre un remboursement futur. Bien gérée, c'est un signe de maturité, pas de négligence.
• La dette d'érosion. Le système n'a pas bougé, le monde autour si. Les dépendances vieillissent, les hypothèses de départ ne tiennent plus, les volumes ont changé d'ordre de grandeur. Personne ne l'a contractée : elle s'accumule toute seule.
• Le code qui n'aurait pas dû être écrit comme ça. C'est le seul cas où le mot « dette » induit en erreur. Il n'y a pas eu d'emprunt, donc rien n'a été obtenu en échange.

La première se rembourse, la deuxième se refinance en continu, la troisième se réécrit. Trois traitements, trois coûts, trois poids différents dans une valo.

II. Pourquoi les outils ne répondent pas

Les plateformes d'analyse statique affichent un chiffre, en jours ou en euros. Je ne m'en sers jamais tel quel, parce qu'elles mesurent l'écart à une norme abstraite et pas la gêne réelle. Un module qui viole trois cents règles de style mais que personne n'a ouvert depuis quatre ans ne coûte rien. Un fichier de quatre cents lignes bien noté, que six personnes modifient chaque semaine, coûte cher tous les mois.

La dette ne se paie que là où on passe. Dans du code gelé, ce n'est pas une dette, c'est de l'archéologie.

Ces outils gardent une utilité, mais comme carte de chaleur à croiser avec l'historique du dépôt. Ce qui compte, c'est l'intersection entre le code de mauvaise qualité et le code souvent modifié. Cette intersection représente en général quelques pour cent de la base ... et la quasi-totalité du coût.

III. Ce que je mesure à la place

Je pars de l'écart entre ce que l'équipe produit et ce qu'une équipe comparable produirait sur le même périmètre fonctionnel.

Concrètement : je prends trois à cinq évolutions récentes, réellement livrées, et je reconstitue leur coût complet — conception, développement, correction des régressions qu'elles ont provoquées, mise en production. Puis je compare à ce que la même évolution coûterait sur une base saine. Le rapport obtenu est rarement flatteur, et rarement absurde.

Trois indicateurs, tous lisibles dans les outils que l'équipe utilise déjà, viennent étayer ce rapport : le délai entre un commit et sa mise en production, la part du temps de développement passée à réparer ce qui a été livré le mois précédent, et le délai avant la première livraison d'un nouvel arrivant.

IV. Passer aux jours-homme

L'erreur classique consiste à chiffrer la remise à niveau totale. Ce nombre est énorme et sans objet, puisque personne ne remet jamais un système à neuf.

Ce que je chiffre, c'est un scénario, défini par ce que vous voulez faire de l'entreprise. On pose l'objectif — tenir la croissance du business plan pendant vingt-quatre mois, ouvrir la plateforme à des clients grands comptes, permettre à l'équipe de doubler — puis je ne chiffre que les chantiers sans lesquels cet objectif est hors d'atteinte. Chacun en jours-homme, avec une fourchette assumée et le risque encouru si on ne le fait pas.

V. Passer aux euros

La conversion est arithmétique, mais deux termes sont presque toujours oubliés.

• Le coût complet, pas le salaire. Un jour d'ingénieur coûte à l'entreprise bien plus que la fraction de salaire correspondante. Il faut prendre le coût chargé, outils et encadrement compris. C'est aussi du temps que la personne ne passera pas sur autre chose et le membre d'une équipe technique ne passe pas que son temps à développer, c'est parfois un maillon essentiel à un process fluide dans une autre équipe car compréhension plus fine d'un process, documentation non partagée entre les équipes etc. C'est un élément qu'il est important de pouvoir identifier car c'est du temps qui se paie ailleurs.
• Le coût d'opportunité. C'est le terme qui domine, et le seul qui intéresse vraiment un investisseur. Deux ingénieurs mobilisés six mois sur une remise à niveau, ce sont deux ingénieurs qui ne construisent pas le produit. Dans une équipe de huit, cela fait un trimestre de roadmap.

En face, il faut décompter ce que la dette coûte déjà chaque année, en développements ralentis et en incidents. C'est ce qui transforme la remise à niveau en investissement avec retour plutôt qu'en charge sèche. La question posée au board devient « en combien de trimestres est-ce remboursé ? » — et à celle-là, un board sait répondre.

VI. Ce qu'il ne faut pas rembourser

Une partie de la dette d'une entreprise en croissance est parfaitement rationnelle, et doit le rester. Le code d'un produit dont on ne sait pas encore s'il trouvera son marché n'a aucune raison d'être exemplaire. Le rendre exemplaire trop tôt est une erreur d'allocation, pas une preuve de rigueur (attention, je ne dis pas qu'il faut livrer des fonctionnalités avec des failles de sécurité ou des bonnes pratiques de développement jetées à la poubelle !).

Quand un audit recommande de tout reprendre, c'est en général que son auteur n'a pas fait le tri. La recommandation la plus utile est souvent celle qui désigne ce qu'il faut laisser en l'état, et explique pourquoi c'est sans danger.

VII. Ce que ça change dans un deal

Un chiffrage qui tient se traduit de trois façons : un ajustement du prix, un complément de prix conditionné à des jalons techniques, ou une clause de garantie. Les trois supposent un montant et un calendrier, c'est-à-dire exactement ce qu'une formulation qualitative ne donne pas.

Côté vendeur, la logique s'inverse et l'exigence reste la même. Une dette que vous annoncez, chiffrée, avec un plan, se négocie. La même dette découverte par l'acquéreur trois semaines avant le closing se paie au prix fort — parce qu'elle jette un doute rétroactif sur tout ce que vous avez affirmé par ailleurs.

VIII. Questions fréquentes

← Toutes les ressources