Une direction générale ne refuse pas de financer la dette technique parce qu’elle la juge secondaire. Elle refuse parce que personne ne lui a jamais présenté un montant en face. Tant que la demande se formule en termes de refactoring, de couverture de tests ou de modernisation, elle se compare à des projets qui, eux, portent un chiffre d’affaires attendu. La comparaison est perdue d’avance, et elle est perdue pour de bonnes raisons.
Voxalia a un peu plus d’un an, et c’est la conversation la plus fréquente que j’ai avec des responsables techniques : ils ont raison sur le fond et ils perdent l’arbitrage.
Ce que la dette coûte, à l’échelle où c’est mesuré
Commençons par l’ordre de grandeur, parce qu’il surprend même les convaincus.
Le Consortium for Information and Software Quality, dans son rapport publié le 6 décembre 2022, évalue le coût de la mauvaise qualité logicielle aux États-Unis à 2 410 milliards de dollars, dont 1 520 milliards de dette technique accumulée.
Ce chiffre est macroéconomique et il faut le manier avec précaution : il agrège des réalités hétérogènes et repose sur des hypothèses discutables. Ce qui est instructif, c’est sa structure. La part la plus lourde n’est ni celle des incidents, ni celle des projets échoués : c’est la dette elle-même, c’est-à-dire le coût permanent de travailler dans un système qu’on a dégradé.
Autrement dit, l’essentiel du coût n’est pas un événement, c’est un frottement. Il ne produit pas de crise identifiable, il produit une lenteur générale que chacun finit par considérer comme normale.
Pourquoi les arguments techniques échouent
Trois formulations reviennent systématiquement, et toutes les trois échouent pour la même raison : elles décrivent l’état du système et non l’effet sur l’entreprise.
« Le code est illisible. » C’est probablement vrai, et cela ne concerne personne d’autre que l’équipe. Une direction n’achète pas de la lisibilité.
« Nous avons X % de couverture de tests. » Le taux de couverture ne mesure pas le risque, il mesure la proportion de code exécutée par les tests. On peut couvrir 90 % d’un code sans vérifier une seule règle métier importante. Cet indicateur n’a jamais convaincu personne qui ne l’était pas déjà.
« Il faut moderniser la stack. » Cette formulation transforme une demande de remboursement en demande d’investissement, et place le sujet en concurrence directe avec les projets métier, où il perdra toujours.
La formulation qui fonctionne dit l’inverse : elle part de ce que l’entreprise constate déjà, en général sans le relier à la technique. Les livraisons sont plus lentes qu’il y a deux ans. Les incidents prennent plus longtemps à résoudre. Les estimations sont systématiquement dépassées. Ces trois faits sont visibles depuis la direction, et ils sont mesurables.
Trois mesures produisibles en un mois
Aucune ne demande d’outillage particulier. Toutes se calculent à partir de ce que l’entreprise enregistre déjà, tickets et historique de livraison.
Le taux de retravail, introduit par DORA dans son rapport 2024 sur l’état du DevOps : la part du travail consacrée à refaire ce qui a déjà été livré. C’est la mesure la plus directe de la dette, parce qu’elle capture précisément le travail qui ne produit rien de nouveau. Convertie en jours-homme sur douze mois puis en coût salarial chargé, elle donne un montant que personne ne peut contester sans contester les tickets.
Le délai de rétablissement, c’est-à-dire le temps entre la détection d’un incident et son retour à la normale. Sa progression sur deux ans raconte l’histoire mieux que n’importe quel discours : un système qu’on ne comprend plus se répare de plus en plus lentement.
L’écart entre estimation et réalisation, mesuré sur les demandes métier. Il ne mesure pas la mauvaise foi des équipes, il mesure l’imprévisibilité du système. Et l’imprévisibilité a un coût direct pour le métier, qui ne peut plus s’engager sur des dates.
Ces trois mesures ont une propriété commune, et c’est ce qui fait leur force en comité : elles ne parlent pas de code. Elles parlent de délai, de coût et de fiabilité, c’est-à-dire des trois choses sur lesquelles une direction arbitre déjà.
Quatre dettes, qui ne se remboursent pas de la même façon
Parler de « la » dette technique au singulier est la deuxième raison pour laquelle ces demandes échouent : on présente un montant global à financer, alors que les quatre formes qui le composent n’ont ni le même coût, ni la même urgence, ni le même mode de remboursement.
La dette de code est la plus visible et la moins coûteuse. Duplication, nommage, complexité inutile. Elle ralentit la lecture, elle se rembourse au fil de l’eau, et c’est généralement celle qu’on met en avant parce qu’elle est facile à montrer.
La dette d’architecture est la plus chère. Un couplage qui oblige à modifier trois composants pour un changement fonctionnel, une base de données partagée par des systèmes qui n’auraient pas dû l’être. Elle ne se rembourse pas au fil de l’eau : elle demande une décision, un budget et une bascule, et son coût croît avec le temps parce que chaque nouveau développement s’appuie dessus.
La dette de test est la plus insidieuse, parce qu’elle ne se voit qu’au moment où l’on veut changer quelque chose. Une base sans filet de sécurité n’est pas seulement risquée, elle est immobile : toute modification devient un pari, donc on modifie moins, donc le système vieillit plus vite.
La dette de connaissance est celle que personne ne classe dans la dette technique, et elle est souvent la plus déterminante. Les décisions qui expliquent le système ne sont écrites nulle part, et les personnes qui les ont prises sont parties. C’est le même mécanisme que la connaissance qu’aucune clause de réversibilité ne restitue, appliqué à l’intérieur de l’entreprise. Elle se rembourse par de la documentation vivante et par du temps passé à deux sur les zones sensibles, ce qui est précisément ce qu’on coupe en premier.
Présenter ces quatre postes séparément, avec un montant et une urgence pour chacun, transforme une demande d’enveloppe en arbitrage. Et un arbitrage, une direction sait le rendre.
La dette n’est pas une faute, et le dire change la conversation
Un point de posture, qui compte davantage que la méthode.
La dette technique est presque toujours présentée, y compris par les équipes techniques elles-mêmes, comme la conséquence de mauvaises décisions passées. C’est parfois vrai. C’est surtout inutile, parce que cela transforme la demande de financement en procès, et qu’un comité qui se sent mis en cause ne finance rien.
La formulation honnête est différente : une part de la dette a été contractée sciemment, et c’était le bon choix. Livrer vite en acceptant un contournement pour tenir une échéance commerciale est une décision rationnelle. Le problème n’est pas d’avoir emprunté, c’est de n’avoir jamais inscrit le remboursement au budget.
Cette manière de poser le sujet a un effet pratique immédiat : elle permet de proposer une règle pour l’avenir, du type consacrer une part fixe de la capacité de chaque cycle au remboursement, plutôt que de demander une enveloppe exceptionnelle. Une part fixe se négocie une fois ; une enveloppe exceptionnelle se renégocie à chaque exercice, et se perd.
Ce que l’IA change à ce calcul
Il faut intégrer un facteur nouveau, parce qu’il modifie la trajectoire.
Nous l’écrivions le mois dernier à propos de l’effet de l’IA sur la qualité logicielle : le rapport DORA publié en septembre 2025, auprès de près de 5 000 professionnels, mesure que l’adoption de l’IA améliore désormais le débit de livraison mais reste associée négativement à la stabilité, en l’absence de systèmes de contrôle robustes. Sa conclusion centrale est que l’IA agit comme un amplificateur : elle magnifie les forces des organisations performantes et les dysfonctionnements des autres.
Appliquée à une base de code endettée, cette conclusion est sans ambiguïté. Produire davantage de code plus vite dans un système qu’on comprend mal n’allège pas la dette, cela l’accroît plus rapidement. Le remboursement devient donc plus urgent au moment précis où l’on croit pouvoir s’en dispenser.
C’est aussi, accessoirement, le meilleur argument disponible aujourd’hui devant une direction générale, parce qu’il relie un sujet qu’elle finance volontiers à un sujet qu’elle finance rarement.
Ce que nous en tirons
Nous refusons les missions de remboursement de dette technique formulées comme des missions de refactoring, et c’est une position qui nous coûte des affaires.
La raison est simple. Une équipe extérieure qui refactorise pendant six mois produit un code plus propre et ne change rien à la mécanique qui a produit la dette : les mêmes arbitrages, sous la même pression, la reconstitueront en dix-huit mois. Ce que nous proposons à la place commence par la mesure décrite plus haut, se poursuit par une règle d’allocation inscrite dans le fonctionnement des équipes, et ne concerne le code qu’ensuite.
Cela suppose d’ailleurs que quelqu’un, chez le client, ait le pouvoir de tenir cette règle quand la pression commerciale arrive. C’est exactement la question de gouvernance qui décide de tout le reste, et nous la posons avant de signer.
Vous pouvez lire qui nous sommes et d’où nous venons et ce que nous faisons en qualité logicielle avant de nous accorder le moindre crédit.
Questions fréquentes
Comment chiffrer la dette technique ?
Trois mesures suffisent, et elles se calculent à partir des tickets et de l’historique de livraison sans outillage particulier. Le taux de retravail, introduit par DORA dans son rapport 2024, mesure la part du travail consacrée à refaire ce qui a déjà été livré ; converti en jours-homme sur douze mois puis en coût salarial chargé, il donne un montant opposable. Le délai de rétablissement des incidents, suivi sur deux ans, montre la dégradation de la capacité à réparer. L’écart entre estimation et réalisation mesure l’imprévisibilité du système, dont le coût est supporté par le métier qui ne peut plus s’engager sur des dates.
Pourquoi les directions refusent-elles de financer la dette technique ?
Parce que la demande leur est presque toujours présentée en termes techniques, code illisible, taux de couverture, modernisation de la stack, qui décrivent l’état du système et non l’effet sur l’entreprise. Une telle demande entre en concurrence avec des projets métier porteurs d’un chiffre d’affaires attendu, et elle perd. La demande fonctionne lorsqu’elle part de faits que la direction constate déjà, à savoir des livraisons plus lentes qu’il y a deux ans, des incidents plus longs à résoudre et des estimations systématiquement dépassées, et qu’elle les convertit en montant.
L’IA aggrave-t-elle la dette technique ?
Elle l’accélère dans les organisations qui en ont déjà. Le rapport DORA publié en septembre 2025, auprès de près de 5 000 professionnels, montre que l’adoption de l’IA améliore le débit de livraison mais reste associée négativement à la stabilité en l’absence de systèmes de contrôle robustes, et conclut que l’IA agit comme un amplificateur des forces et des dysfonctionnements existants. Produire plus de code, plus vite, dans un système qu’on comprend mal accroît la dette au lieu de l’alléger, ce qui rend le remboursement plus urgent au moment même où l’on croit pouvoir s’en dispenser.
Sources
- Consortium for Information and Software Quality, The Cost of Poor Software Quality in the US: A 2022 Report, 6 décembre 2022, auteur Herb Krasner (2 410 milliards de dollars de coût total, dont 1 520 milliards de dette technique accumulée).
- DORA, Accelerate State of DevOps Report 2024, octobre 2024 (introduction du taux de retravail parmi les indicateurs de performance, délai de rétablissement, taux d’échec des changements).
- DORA, State of AI-assisted Software Development 2025, 23 septembre 2025, près de 5 000 professionnels (relation devenue positive avec le débit de livraison, relation toujours négative avec la stabilité en l’absence de systèmes de contrôle robustes, conclusion sur l’IA amplificateur).
