Chaque VP Engineering a déjà vécu cette réunion. La revue de feuille de route se déroule bien jusqu’à ce que quelqu’un demande pourquoi une fonctionnalité simple a pris trois sprints au lieu d’un. L’ingénieur évoque le code legacy, un couplage trop fort et un schéma de base de données que personne ne veut toucher. Le CFO hoche la tête, passe au point suivant, et le moment est passé. Rien dans cette réponse n’était chiffré, et les équipes financières n’accordent pas de budget à une impression, aussi forte soit-elle.
C’est le mode d’échec central de toute discussion sur la dette technique menée en langage d’ingénieur plutôt qu’en langage financier. Les ingénieurs décrivent la dette comme un problème de qualité. Les équipes financières financent les problèmes de qualité à contrecœur, quand elles les financent. En revanche, elles financent sans hésiter ce qui freine la croissance, érode la marge et pèse sur le bilan, parce que ce sont les catégories qu’un CFO est payé pour piloter.
Cet article vous donne donc le chiffre : un modèle à deux couches pour calculer le coût de la dette technique en dollars. D’abord, les heures d’ingénierie que votre équipe perd à chaque sprint. Ensuite, quatre coûts que la finance comprend déjà : revenus décalés, clients perdus, factures de recrutement plus élevées et prix de sortie plus bas. Vous n’avez besoin d’aucun nouvel outil pour le faire tourner, car les données d’entrée viennent de vos rétrospectives de sprint, de votre journal d’incidents et de votre dernière revue de code.
Ce que la recherche indépendante dit du coût de la dette technique
Avant de modéliser votre propre chiffre, il est utile de savoir ce que d’autres ont mesuré. Trois études méritent d’être citées en réunion avec la finance.
L’analyse 2026 de Deloitte situe la dette technique entre 21 % et 40 % des dépenses informatiques d’une organisation, en retenant 30 % comme point médian de travail. Sur un budget informatique annuel de 10 millions de dollars, cela représente de 2,1 à 4 millions de dollars par an consacrés au travail de dette plutôt qu’à de nouvelles capacités.
McKinsey a interrogé 50 DSI d’entreprises de services financiers et de technologie réalisant plus de 1 milliard de dollars de chiffre d’affaires. Ces DSI estimaient la dette technique à 20 à 40 pour cent de la valeur de l’ensemble de leur parc technologique avant amortissement. En clair : additionnez la valeur de tous leurs systèmes, et un cinquième à deux cinquièmes de ce montant correspond à du travail encore dû, c’est-à-dire aux correctifs et aux mises à niveau qui doivent avoir lieu avant que ces systèmes soient dans l’état dont l’entreprise a réellement besoin. Ces mêmes DSI indiquaient que 10 à 20 pour cent du budget réservé aux nouveaux produits est détourné vers du travail de dette avant même qu’une seule fonctionnalité soit livrée, et 60 pour cent déclaraient que le problème s’était nettement aggravé au cours des trois années précédentes.
À l’échelle nationale, le Consortium for Information and Software Quality a estimé la dette technique accumulée dans l’économie logicielle américaine à environ 1,52 billion de dollars, sur un coût total de la mauvaise qualité logicielle de 2,41 billions de dollars.
Utilisez ces chiffres comme test de cohérence de votre propre modèle, pas comme substitut. Si votre résultat tombe très en dessous de 20 pour cent des dépenses d’ingénierie, vos hypothèses sont probablement trop optimistes, et votre CFO le remarquera avant vous. Les métriques qui alimentent ces hypothèses sont détaillées dans notre guide pour mesurer la dette technique.
Le modèle de coût prêt pour le CFO
Le modèle comporte deux couches. La première est un coût direct que vous pouvez calculer à partir de données dont vous disposez déjà. La seconde regroupe des coûts indirects qui exigent quelques estimations raisonnables, ce qui ne pose aucun problème : les CFO sont à l’aise avec des fourchettes estimées dès lors que la méthodologie est transparente. C’est déjà ainsi qu’ils traitent les amortissements, les provisions pour créances douteuses et la plupart des autres postes du bilan.
Couche 1 : le coût direct que vous pouvez calculer dès aujourd'hui
Coût direct = heures perdues par sprint à cause de la dette × coût complet horaire d’un ingénieur × nombre de sprints par an
- Heures perdues par sprint. Tirez ce chiffre de vos rétrospectives de sprint, de votre suivi du temps ou d’une enquête de deux semaines demandant quelle part des story points est partie en reprises liées à la dette plutôt qu’en travail réellement nouveau. Si vous n’avez encore aucune donnée interne, partez du bas de la fourchette de la recherche, 20 pour cent, et remplacez-la par votre propre chiffre en un ou deux sprints. Un chiffre issu de vos propres rétrospectives résistera toujours mieux à l’examen qu’une moyenne sectorielle.
- Coût complet horaire d’un ingénieur. Le coût complet, c’est tout ce qu’un ingénieur coûte à l’entreprise sur une année, pas seulement ce qui arrive sur son compte en banque : salaire de base, plus avantages sociaux, charges patronales, matériel, licences logicielles, recrutement et une part des frais de locaux et d’administration. La finance calcule déjà ce montant pour chaque poste, alors demandez-lui son chiffre plutôt que de l’estimer vous-même.
- Nombre de sprints par an. En général 24 à 26 sur une cadence de deux semaines.
Voici le calcul étape par étape, pour une équipe de dix ingénieurs :
- Capacité de l’équipe par sprint. Dix ingénieurs sur un sprint de deux semaines représentent 800 heures au total, soit 10 personnes × 80 heures chacune.
- Coût horaire. Admettons un coût complet de 145 000 dollars par ingénieur et par an. Divisez-le par 2 080 heures travaillées, soit l’année standard à temps plein de 40 heures par semaine × 52 semaines, et vous obtenez environ 70 dollars de l’heure.
- Heures perdues à cause de la dette. À 35 pour cent, 280 de ces 800 heures partent en travail de dette à chaque sprint.
- Coût d’un sprint. 280 heures × 70 dollars = 19 600 dollars.
- Coût de l’année. 19 600 dollars × 26 sprints = environ 510 000 dollars.
Ces 510 000 dollars sont du temps d’ingénierie consacré au service de la dette au lieu de la construction du produit, et ils n’ont jamais figuré sur une seule ligne budgétaire. Cela suffit généralement à faire se redresser un CFO sceptique, parce qu’il s’agit d’une charge d’exploitation bien réelle que personne ne suivait. Pour rendre la donnée d’entrée des heures plus difficile à contester avant la réunion, resserrez la façon dont votre équipe définit et suit la qualité du code.
Couche 2 : les coûts indirects qui font réagir la finance
Les coûts indirects, c’est ce que la dette technique fait au reste de l’entreprise : des revenus qui arrivent en retard, des clients qui partent après une panne de trop, des salaires que vous surpayez pour armer un système vieillissant.
Fonctionnalités retardées
Valeur de la fonctionnalité par semaine × semaines de retard causées par la dette
Projections de feuille de route, historique de livraison
Attrition due aux incidents
Clients perdus par incident majeur × valeur vie client moyenne
Tickets de support, journal d’incidents, rapports d’attrition
Surcoût de recrutement
Délai de recrutement supplémentaire et taux de refus d’offre sur les postes legacy face aux postes modernes
Données de l’entonnoir de recrutement
Décote de valorisation
Coût de remise à niveau probable chiffré par l’équipe de due diligence d’un acquéreur
Conclusions de due diligences antérieures, rapports d’audit
Fonctionnalités retardées. Prenez le revenu ou l’économie projetés de la fonctionnalité, divisez par son calendrier prévu pour obtenir une valeur par semaine, puis multipliez par le retard imputable aux reprises liées à la dette. Une fonctionnalité qui vaut 40 000 dollars par mois et qui sort huit semaines en retard à cause de contraintes legacy, cela fait environ 80 000 dollars de valeur différée, totalement distincts des heures d’ingénierie brûlées pour y arriver.
Attrition due aux incidents. Utilisez votre taux d’échec des changements, la part des déploiements qui déclenchent un incident, un rollback ou un correctif à chaud, avec vos données de support et d’attrition pour estimer combien de clients vous perdez par incident majeur, puis multipliez par la valeur vie client. La plupart des équipes trouvent ce chiffre plus élevé que prévu, parce que les incidents sont rarement rattachés à la dette qui les a causés.
Surcoût de recrutement. Si votre système exige une version ancienne d’un framework, un outil interne sur mesure ou un langage abandonné, comparez le délai de recrutement et le taux d’acceptation des offres sur ces postes à ceux de votre stack moderne. La pénalité est réelle pour deux raisons : le vivier d’ingénieurs qui maîtrisent encore une technologie obsolète se réduit chaque année, et ceux qui la maîtrisent refusent souvent le poste parce que l’accepter restreint leur prochain mouvement de carrière. Vous payez cela deux fois, par une vacance plus longue et par une offre plus élevée.
Décote de valorisation. Si une sortie, une acquisition ou une levée de fonds se profile à l’horizon, modélisez une décote prudente à partir du coût de remise à niveau que chiffrerait l’équipe de due diligence technique d’un acquéreur. C’est le plus difficile des quatre à cerner, mais même une fourchette approximative fait passer la dette du statut de plainte d’ingénieurs à celui d’enjeu de valeur pour l’actionnaire. Notre checklist de due diligence technique en M&A montre ce que ces équipes recherchent réellement, ce qui rend l’estimation beaucoup moins spéculative.
Ajoutez les quatre estimations indirectes au coût direct et vous obtenez un seul chiffre annualisé : le coût de la dette technique pour votre organisation, en dollars plutôt qu’en story points. Ce que vous en faites est la décision suivante, et c’est le fait d’avoir le chiffre qui rend cette décision possible. Basculer l’entretien courant, comme les mises à jour de dépendances, la couverture de régression et les correctifs de sécurité, sur un contrat de maintenance logicielle est une voie fréquente, car cela convertit un coût imprévisible en une ligne budgétaire fixe que la finance peut prévoir.
Là où le code assisté par IA change le calcul
Si votre équipe a livré nettement plus de code cette année à effectif constant, votre chiffre d’heures de dette de l’an dernier est déjà périmé. Le développement assisté par IA déplace le goulot d’étranglement de l’écriture du code vers sa relecture, et le code qui passe la revue trop facilement a l’habitude de revenir en reprises un trimestre plus tard. Nous avons expliqué comment cette dette s’accumule dans notre article sur la dette technique dans le code généré par IA.
Deux changements maintiennent votre modèle de coût juste. Mesurez de nouveau le chiffre d’heures de dette de la couche 1 chaque trimestre plutôt qu’une fois par an, et suivez-le en parallèle de la part de code fusionné qui a été produite avec l’IA. Si ces deux chiffres montent ensemble, vous avez trouvé votre source de dette à la croissance la plus rapide alors qu’elle est encore peu coûteuse à traiter. Les équipes qui utilisent déjà des outils de revue par IA devraient aussi vérifier ce que ces outils détectent vraiment, ce que nous avons testé dans notre évaluation de Claude Code pour la revue de code.
Lorsqu’un code source a déjà accumulé un arriéré de code généré par IA que personne ne prend pleinement en charge, une mission ciblée de nettoyage de vibe code revient généralement moins cher que d’absorber ce travail dans la capacité de sprint normale, car le périmètre est borné et peut être chiffré face au nombre que vous venez de calculer.
Pourquoi les équipes font entrer Redwerk dans cette conversation
Redwerk développe des logiciels depuis 2005, nous avons donc vu beaucoup de dette s’accumuler et nous avons été engagés pour en nettoyer une bonne part. Nous construisons des produits complexes de zéro, nous auditons des systèmes que personne n’a documentés depuis des années et nous refactorisons des projets legacy que d’autres équipes ont abandonnés. Plus récemment, nous avons ajouté à ce travail des solutions dopées à l’IA ainsi que du développement et des tests assistés par IA. Les fondamentaux d’ingénierie et les pratiques de sécurité qui les sous-tendent sont ceux que nous appliquons pour des clients en Amérique du Nord et en Europe, dont des entreprises du Fortune 500 comme Siemens, J.B. Hunt et Universal Music Group. Ils couvrent désormais aussi les sources de dette les plus récentes.
Les économies commencent souvent plus petites et plus tôt qu’on ne l’imagine. Quand Adoorabelle, une place de marché immobilière d’Atlanta, nous a fait appel, le fondateur n’était pas technique, il était enfermé chez un prestataire précédent et n’avait aucune documentation à montrer à un investisseur. Notre audit de leur application immobilière a mis au jour 80 problèmes, du secret codé en dur aux failles structurelles critiques, a supprimé 300 dollars par mois d’abonnements API inutiles, soit 3 600 dollars par an récupérés sur le budget de fonctionnement à eux seuls, a rapproché leur infrastructure AWS de leurs utilisateurs et a ajouté une observabilité 24/7 avec Sentry, Prometheus et Grafana. Ils ont terminé avec une spécification fonctionnelle complète, une indépendance totale vis-à-vis des prestataires et quelque chose à montrer aux investisseurs.
Voilà le schéma à copier : découvrir ce que la dette coûte réellement, en dollars, avant de décider combien y consacrer. Si vous voulez ce chiffre produit par des gens qui vous diront aussi franchement quelles parties ne valent pas la peine d’être corrigées, commencez par un audit de développement logiciel.
FAQ
Combien coûte la dette technique ?
Il n’existe pas de chiffre sectoriel unique, car cela dépend de la taille de l’équipe, du coût d’ingénierie et du niveau d’endettement du code. La recherche indépendante donne des repères utiles : Deloitte situe la dette technique entre 21 % et 40 % des dépenses informatiques, et McKinsey a constaté que les DSI l’estimaient à 20 à 40 pour cent de la valeur totale de leur parc technologique. Appliquer votre propre coût complet d’ingénierie aux heures de dette par sprint de votre équipe est le seul moyen d’obtenir un chiffre propre à votre entreprise plutôt qu’une moyenne sectorielle.
Comment estimer le coût à long terme de la dette technique ?
Combinez un coût direct, c’est-à-dire les heures perdues par sprint à cause de la dette multipliées par le coût complet d’ingénierie et le nombre de sprints par an, avec quatre coûts indirects : le coût d’opportunité des fonctionnalités retardées, l’attrition liée à la fréquence des incidents, les surcoûts de recrutement pour les compétences sur stack legacy et toute décote de valorisation qui apparaîtrait en due diligence technique. Comme la dette est cumulative, modélisez le total sur une base annuelle et revoyez les données d’entrée chaque trimestre plutôt que de traiter l’exercice comme un calcul unique.
Comment les entreprises calculent-elles le coût de la dette technique ?
La plupart des organisations d’ingénierie mûres suivent un chiffre d’heures de dette par sprint issu des rétrospectives ou du suivi du temps, appliquent le coût complet par ingénieur fourni par leur équipe financière et y ajoutent des métriques de livraison comme le taux d’échec des changements et le temps de rétablissement pour relier la dette aux coûts d’incidents et d’attrition. Le résultat est généralement exprimé en montant annualisé en dollars, à côté d’un pourcentage de la capacité totale d’ingénierie.
Pourquoi les CFO rejettent-ils les demandes de budget pour la dette technique ?
La plupart des demandes sont formulées en termes d’ingénierie, comme la qualité du code, le refactoring et l’architecture, plutôt qu’en termes financiers comme les dollars, le coût d’opportunité et l’exposition au risque. Une demande formulée ainsi, « 510 000 dollars de temps d’ingénierie par an, plus 600 000 dollars d’attrition et de revenus décalés projetés », concourt pour le budget de la même façon que n’importe quelle autre décision d’allocation de capital. Une demande formulée comme « le code a besoin d’un nettoyage » ne le fait généralement pas.
Découvrez comment Redwerk a repris une application fitness en difficulté auprès d'un autre prestataire, nettoyé la dette technique héritée, et aidé Pridefit à augmenter ses abonnements de 45 %
