Évaluer la dette technique : maîtriser les risques DSI

23.10.2025

En bref

L’essentiel en bref

La dette technique coûte aux entreprises entre 25 et 40 % de leur capacité de développement informatique en moyenne – et cette tendance est à la hausse.
Le plus grand danger ne réside pas dans le code lui-même, mais dans l’érosion de la capacité à évoluer : les nouvelles fonctionnalités prennent de plus en plus de temps à développer.
La dette technique peut être quantifiée en euros – et ainsi figurer à l’ordre du jour des conseils d’administration.
Trois types de dette technique nécessitent des stratégies différentes : délibérée, accidentelle et « bit rot » (obsolescence logicielle).
Les DSI performants réservent en permanence 20 % de leur capacité de développement au remboursement de cette dette.

Tout DSI connaît le problème, mais rares sont ceux qui peuvent le chiffrer : la dette technique – ces solutions de contournement, systèmes obsolètes, tests manquants ou code non documenté – grignote la capacité de développement sans que la direction générale n’en perçoive le véritable coût.

La raison est structurelle : la dette technique n’apparaît dans aucun bilan. Elle rallonge chaque projet de plusieurs semaines, rend chaque mise en production plus risquée et pousse les meilleurs développeurs à rejoindre la concurrence. Qui ne quantifie pas sa dette technique ne peut la gérer – et qui ne la gère pas perd progressivement sa capacité à innover.

Rendre visibles les coûts cachés

McKinsey estime que la dette technique représente 20 à 40 % des actifs informatiques totaux dans les grandes entreprises. Autrement dit : sur chaque euro investi dans l’IT, jusqu’à 40 centimes sont consacrés à la gestion de problèmes anciens, au lieu de créer de la valeur nouvelle.

Ces coûts se matérialisent sur quatre niveaux : ralentissement (les fonctionnalités prennent plus de temps à développer), fragilité (les modifications entraînent des erreurs imprévues), concentration des connaissances (seuls quelques développeurs comprennent le code) et coût d’opportunité (des projets qui ne voient jamais le jour, faute de capacités disponibles).

Le dernier point est le plus coûteux – et le plus invisible. Aucun DAF ne s’interroge sur les produits qui n’ont pas été développés. Pourtant, c’est là que réside le véritable préjudice stratégique.

Les trois types de dette technique

Dette délibérée : Des compromis assumés sous la pression des délais. La solution de contournement rapide, promise à être « nettoyée au prochain sprint » – mais qui ne l’est jamais. Ce type de dette reste gérable, à condition d’être documenté et priorisé.

Dette accidentelle : Elle naît d’un manque de connaissances ou de décisions de conception obsolètes. Un système qui était à la pointe il y a cinq ans devient aujourd’hui un frein. Cette dette exige un refactoring stratégique.

Érosion logicielle (Bit Rot) : Une dégradation insidieuse causée par des changements externes – bibliothèques non maintenues, API dépréciées, normes de sécurité évolutives. L’érosion est la forme la plus dangereuse, car elle survient même avec un code parfait et ne se révèle souvent qu’à l’occasion d’un incident de sécurité.

La dette technique expliquée au comité de direction

Pour capter l’attention du conseil d’administration, rien ne vaut une traduction en métriques business :

Coût du retard (Cost of Delay) : Quel manque à gagner mensuel représente le report d’une fonctionnalité ? Si la dette technique retarde chaque livraison de deux semaines et que le chiffre d’affaires mensuel attendu d’une nouvelle fonction s’élève à 200 000 euros, ces retards coûtent 100 000 euros – par fonctionnalité.

Exposition aux risques (Risk Exposure) : Quel est le risque financier lié aux systèmes obsolètes ? Les dépendances non corrigées, l’absence de tests et les architectures monolithiques augmentent la probabilité de pannes et d’incidents de sécurité. Ces risques se quantifient via le Expected Loss (perte attendue).

Taxe sur la capacité (Capacity Tax) : Quelle part des ressources de développement est absorbée par la maintenance plutôt que par l’innovation ? Ce chiffre – généralement compris entre 25 et 40 % – constitue l’argument le plus convaincant pour le directeur financier.

La règle des 20 % et autres stratégies

La stratégie la plus efficace est aussi la plus simple : réserver en permanence 20 % de la capacité de développement au remboursement de la dette technique. Pas comme une option facultative, mais comme une planification fixe des capacités, qui ne doit pas être sacrifiée au profit du développement de nouvelles fonctionnalités.

Trois approches tactiques ont également fait leurs preuves :

Règle du scout : Chaque demande de fusion (pull request) doit laisser le code dans un meilleur état qu’à son arrivée. De petites améliorations continues empêchent la dette de croître plus vite qu’elle ne peut être résorbée.

Sprints dédiés à la dette technique : Des sprints trimestriels entièrement consacrés au remboursement de la dette. Particulièrement efficaces pour les projets de refactoring plus importants, qui ne peuvent pas être réalisés en parallèle des tâches courantes.

Fonctions de fitness : Des tests automatisés qui imposent des standards de qualité architecturale. Si une modification réduit la couverture des tests, augmente le couplage ou allonge le temps de construction, le pipeline déclenche une alerte – avant même que de nouvelles dettes ne soient contractées.

Questions fréquentes

La dette technique est-elle toujours néfaste ?

Non. Contracter une dette technique de manière consciente peut s’avérer stratégiquement judicieux – par exemple, lorsque la rapidité de mise sur le marché justifie les efforts de remédiation ultérieurs. Le problème survient lorsque cette dette s’accumule à l’insu des équipes, sans documentation, ou qu’elle n’est jamais remboursée.

Comment mesurer la dette technique de façon objective ?

Quatre indicateurs se révèlent particulièrement pertinents : la fréquence de déploiement, le délai de livraison des modifications (Lead Time for Changes), le taux d’échec des changements (Change Failure Rate) et le temps moyen de rétablissement (Mean Time to Recovery) – soit les métriques DORA. Des outils d’analyse statique de code comme SonarQube complètent cette approche en quantifiant la dette technique en unités de temps.

Faut-il tout refactoriser ou repartir de zéro ?

Dans la majorité des cas, une refactorisation incrémentale s’impose plutôt qu’une réécriture complète. Les réécritures dépassent souvent les délais prévus, imposent un gel des fonctionnalités et comportent le risque de remplacer d’anciennes erreurs par de nouvelles. L’exception ? Lorsqu’un système devient si fragile que toute modification entraîne des effets de bord incontrôlables.

Comment convaincre le DAF d’investir dans la dette technique ?

Avec des chiffres concrets. Calculez la « taxe de capacité » (part du temps de développement consacrée à la maintenance), le coût du retard (pertes de revenus liées aux livraisons ralenties) et l’exposition aux risques (coûts potentiels des pannes). Lorsque le directeur administratif et financier constate que la dette technique représente un coût annuel de plusieurs millions d’euros, l’allocation d’un budget devient une décision rationnelle.

Contexte DACH : En Allemagne, en Autriche et en Suisse (région DACH), les DAF (Directeurs Administratifs et Financiers) jouent un rôle clé dans les décisions d’investissement technologique, souvent avec une approche plus conservatrice qu’en France. Leur adhésion repose sur des arguments financiers tangibles.

Comment éviter que de nouvelles dettes techniques ne s’accumulent ?

Trois leviers d’action : une « Definition of Done » intégrant explicitement la qualité du code, des garde-fous automatisés dans la chaîne CI/CD, et une culture où les développeurs sont récompensés pour la qualité – et pas seulement pour la rapidité. La « règle des 20 % » garantit que la réduction de la dette technique ne reste pas un projet ponctuel, mais s’inscrive dans la durée.

Contexte réglementaire : La « règle des 20 % » fait référence à une pratique courante dans les entreprises allemandes, où 20 % du temps de développement est systématiquement alloué à l’amélioration continue du code, conformément aux principes d’excellence opérationnelle (Operational Excellence) prônés par des normes comme ISO 9001 ou ITIL.

Source de l’image d’en-tête : Unsplash / Emile Perron