Chiffrer sa dette technique : la méthode qui transforme un sentiment en budget

Pourquoi la dette technique est un problème de comptabilité, pas de code

On a longtemps présenté la dette technique comme une question de code laid, de tests manquants ou de vieille architecture. C'est une erreur de cadrage. La dette technique est avant tout un problème de temps : c'est du temps d'ingénierie qui part en réparation, en compréhension, en contournements, au lieu de créer de la valeur neuve. Et le temps, lui, se convertit très bien en euros. Dès qu'on raisonne ainsi, le sujet cesse d'être un différend d'opinion entre ingénieurs pour devenir une ligne d'un budget que l'on peut défendre devant un fonds, un acquéreur ou un comité de direction.

Les chiffres qui plantent le décor sont nets. Dans l'enquête Stripe Developer Coefficient (2018, plus de 1 000 développeurs et 1 000 dirigeants dans cinq pays), les développeurs déclarent passer en moyenne 13,5 heures par semaine — soit un tiers de leur temps de travail — à la dette technique stricte, et 17,3 heures si l'on ajoute la maintenance de code de mauvaise qualité (donnée tierce : Stripe, 2018). Une étude longitudinale publiée à la conférence ICSE et relayée par l'ACM suit 43 développeurs deux fois par semaine pendant sept semaines : 23 % du temps de travail y est qualifié de gaspillé à cause de la dette, et l'estimation perçue par les praticiens atteint 36 % (donnée tierce : ACM, 2018). Ce n'est pas un ressenti isolé : c'est la réalité mesurée d'équipes qui tiennent leur temps.

J'insiste sur ce point parce qu'il change la posture. Si vous approchez un fonds en disant « notre code est perfectible », vous ouvrez la porte à toutes les appréhensions. Si vous arrivez avec « voici le coût annuel de notre dette, voici les quatre indices qui le soutiennent, et voici le plan pour la réduire », vous transformez un motif d'inquiétude en un élément de discussion chiffré — exactement le registre dans lequel se négocie une valorisation.

Quatre indices concrets pour chiffrer sa dette, sans logiciel magique

Inutile d'acheter un outil onéreux pour débuter : quatre indicateurs accessibles depuis vos outils habituels suffisent à construire une première estimation défendable. Je les mesure sur douze mois glissants, ni plus ni moins, pour lisser les saisonnalités.

Le premier, le plus parlant, est la part des tickets de maintenance : prenez l'ensemble des tickets fermés par l'équipe technique sur la période, et classez ce qui relève de corrections, de bugs, d'aléas techniques et de contournements contre ce qui relève de fonctionnalités neuves. Un ratio de maintenance largement au-dessus de 30 % est, dans mon expérience, un signal clair de dette qui plombe la capacité à livrer (ordre de grandeur, à comparer à vos données). Le second est le délai de livraison lui-même : si un même type de fonctionnalité met deux fois plus de temps qu'il y a deux ans, la dette de complexité en est presque toujours la cause. Le troisième est l'effort d'intégration : combien de temps un nouvel arrivant met-il à produire son premier élément utile ? Un onboarding qui se compte en semaines révèle une documentation insuffisante et une lisibilité du code dégradée. Le quatrième, plus subjectif mais utile, est la stabilité perçue : le nombre d'incidents, de régressions et de corrections d'urgence.

Ces quatre indices ont un avantage décisif : ils sont lisibles par un non-technique. Un fonds n'a pas besoin de comprendre la valeur d'un refactor de telle couche ; il comprend immédiatement « 40 % de l'effort part en maintenance » ou « le temps d'onboarding a triplé ». C'est exactement ce que je cherche lorsque j'audite un code avant investissement : non pas une note esthétique, mais les données qui transformeront le technologique en financier. Si vous voulez anticiper les questions d'un fonds, préparer une due diligence technique vous donne les angles qu'il vérifiera en priorité.

Les trois erreurs qui faussent tout le chiffrage

La première erreur est de n'estimer que le coût de réparation. Or le coût de vivre avec la dette — les contournements, la lenteur, le débuggage — dépasse presque toujours le coût de corriger le code. Une estimation qui n'inclut que les heures de refactor sous-estime massivement la situation. La seconde est d'oublier l'opportunité : chaque heure passée en dette est une heure qui ne produit pas de fonctionnalité vendable. C'est ce que pointent les travaux de Gartner quand ils prédisent que la dette consommera plus de 40 % des budgets IT courants d'ici 2025 (donnée tierce : Gartner, 2025) : ce n'est pas seulement un budget brûlé, c'est une capacité d'innovation plafonnée.

La troisième erreur est la plus délicate, car elle est humaine : la sous-estimation défensive. Une équipe qui a peur que le chiffre serve contre elle aura tendance à minimiser. Je le comprends, mais c'est contre-productif : un chiffrage trop bas découvert en due diligence est bien plus dommageable qu'un chiffrage réaliste annoncé en amont, parce qu'il signale soit une méconnaissance de son propre patrimoine, soit une volonté de cacher. La seule posture qui protège, chez soi comme chez un fonds, est la transparence chiffrée accompagnée d'un plan de réduction.

Au passage, la question de l'IA mérite d'être traitée honnêtement, car elle divise : une enquête récente de Sonar (2026) montre que 88 % des développeurs déclarent au moins un impact négatif de l'IA sur la dette technique, et 93 % au moins un impact positif — il n'y a pas de verdict univoque (donnée tierce : Sonar, 2026). L'IA génère du code plus vite, ce qui peut produire du code « qui semble juste mais ne l'est pas » ; elle peut aussi accélérer le remboursement. Ce n'est donc pas un argument pour arrêter de mesurer : c'est au contraire une raison de mesurer plus souvent, car le volume de code généré automatiquement augmente et donc le stock de dette potentielle aussi.