Dette technique : ce qu’elle est, ce qu’elle vous coûte et comment la rembourser

Toute entreprise qui fait tourner un logiciel depuis quelques années porte de la dette technique. Ce guide s’adresse à ceux qui la paient, souvent sans la voir : le directeur dont la feuille de route glisse, la direction financière qui valide un nouveau budget de maintenance, le DSI à qui l’on demande pourquoi une petite évolution prend un mois. Les chiffres cités viennent des sources listées en fin de page, toutes consultées le 1er octobre 2026.

Dette technique : les intérêts payés sur chaque évolution

La dette technique, c’est le temps supplémentaire que coûte chaque modification parce que le logiciel est plus difficile à faire évoluer qu’il ne devrait l’être. La métaphore vient de Ward Cunningham, dans un retour d’expérience de 1992 : livrer un premier code, écrit-il, revient à s’endetter ; un peu de dette accélère le développement tant qu’elle est remboursée rapidement par une réécriture. Il ajoute l’avertissement qui compte : chaque minute passée sur du code « pas tout à fait juste » est un intérêt payé sur cette dette.

Martin Fowler en fait un calcul concret. Une fonctionnalité qui prendrait quatre jours dans un module clair en prend six dans un module confus : les deux jours d’écart sont les intérêts. Nettoyer le module prendrait cinq jours, ce qui ne se rentabilise pas sur une seule fonctionnalité, mais très vite si deux autres suivent. Il pointe aussi la limite de la métaphore : un code désordonné que personne ne touche ne coûte rien, puisqu’on ne paie les intérêts qu’en le modifiant. La dette à traiter d’abord est donc celle des parties du logiciel qui changent chaque semaine.

Quand les intérêts sont devenus si lourds que le logiciel ne suit plus l’activité, la réponse passe en général par une modernisation applicative : remplacer, morceau par morceau, ce qui freine chaque évolution.

Les quatre sortes de dette technique

Une dette peut être un choix raisonnable ; tout dépend de savoir si elle a été prise en connaissance de cause, et si c’était prudent. Le quadrant de Martin Fowler, publié en 2009, croise ces deux questions.

Ce quadrant change la discussion avec la direction. La dette délibérée et prudente est une décision de financement, comme un emprunt. La dette imprudente est un problème de qualité, et en reprendre ne fait pas gagner de temps longtemps : dans son article sur la dette technique, Fowler décrit des équipes qui épuisent toutes leurs cartes de crédit et livrent quand même plus tard que si elles avaient soigné la qualité.

Où se cache la dette technique

La dette loge dans le code, mais aussi dans la plateforme, la documentation et la façon de mettre en production. Les outils d’analyse de code ne voient que la première.

La dette de plateforme a des dates, ce qui en fait la plus simple à planifier. PHP assure deux ans de support actif pour chaque branche, puis deux ans de correctifs de sécurité critiques seulement, après quoi la branche est en fin de vie ; au 1er octobre 2026, la plus ancienne branche encore maintenue, la 8.2, reçoit des correctifs de sécurité jusqu’au 31 décembre 2026. Microsoft a mis fin au support de Windows 10 le 14 octobre 2025 : les postes fonctionnent encore, mais ne reçoivent plus de mises à jour de sécurité en dehors du programme de mises à jour de sécurité étendues (ESU) de Microsoft. Toute application liée à ces plateformes porte une dette dont l’échéance est publique.

La dette de connaissance est la plus souvent oubliée. La rattraper commence par écrire où se trouve chaque règle. Un assistant qui répond à partir de votre documentation interne, comme notre démonstration d’assistant documentaire, aide ensuite un nouveau développeur à la retrouver sans solliciter la seule personne qui sait.

Ce que coûte la dette technique

Les estimations publiées diffèrent par leur méthode, mais elles s’accordent sur l’ordre de grandeur : la dette absorbe une part importante du temps et de l’argent consacrés au logiciel. Trois sources, chacune avec ses limites :

• Le temps des développeurs. Dans une enquête menée en 2018 avec Harris Poll auprès de plus de 1 000 développeurs et plus de 1 000 dirigeants aux États-Unis, au Royaume-Uni, en France, en Allemagne et à Singapour, Stripe relève que les développeurs estiment consacrer 13,5 heures d’une semaine de 41,1 heures à la dette technique, et 17,3 heures à la maintenance au sens large (débogage, refactorisation). Les développeurs français déclaraient la semaine la plus courte de l’enquête (39,6 heures) et le temps de maintenance le plus élevé (20,9 heures). L’enquête est ancienne et déclarative : à lire comme un ordre de grandeur.
• La part des systèmes. La revue de l’état du numérique public publiée par le gouvernement britannique en janvier 2025 estime que les technologies anciennes représentaient 28 % des systèmes des ministères en 2024, contre 26 % en 2023.
• Le coût d’exploitation. La même revue indique que la maintenance des systèmes anciens coûte souvent trois à quatre fois plus que celle d’alternatives modernes, en citant les contrats de maintenance de systèmes COBOL de l’administration fiscale britannique.

Aucun de ces chiffres ne donne le coût de votre propre dette. Le chiffre utile est local : combien de jours prend aujourd’hui une évolution type, comparé à ce qu’elle prendrait dans un code sain, multiplié par le nombre d’évolutions de votre feuille de route. Les quatre jours contre six de Fowler, appliqués à votre carnet de demandes.

Comment mesurer la dette technique

Une mesure crédible combine l’estimation d’un outil sur le code et les signaux que l’activité voit déjà. L’analyse statique donne la première partie. SonarQube, un outil d’analyse de code, définit la dette technique comme la somme des efforts nécessaires pour corriger tous les défauts de maintenabilité, et le ratio de dette comme cet effort divisé par le coût estimé de développement du code, avec par défaut 30 minutes par ligne. Sa note de maintenabilité par défaut va de A, pour un ratio de 5 % ou moins, à E, à partir de 50 %.

L’outil ne voit pas ce qui n’est pas dans le code. Ajoutez quatre questions :

1. Combien de temps prend une évolution type, de la demande à la mise en production, et ce délai s’allonge-t-il ?
2. À quelle fréquence une livraison casse-t-elle quelque chose qui marchait ?
3. Quels composants sont hors support ou proches de l’être, et à quelle date ?
4. Quelles parties ne sont comprises que par une seule personne ?

Un audit de code répond à ces questions sur votre logiciel, preuves à l’appui : les mesures de l’outil, la liste des dépendances et leurs dates de fin de support, les parties du code où chaque évolution traîne. Il se termine par les risques classés et une recommandation pour chaque partie du logiciel, sous accord de confidentialité.

Rembourser : refactoriser, remplacer ou réécrire

La plupart des dettes se remboursent mieux progressivement, dans les parties du logiciel que l’on modifie de toute façon. Fowler recommande de traiter la dette technique comme une dette financière : rembourser le capital petit à petit, en nettoyant davantage là où le code change le plus. Les options, de la plus légère à la plus lourde :

La refonte complète est souvent l’option la plus tentante, et la plus risquée. Notre travail de modernisation part de l’hypothèse inverse : le logiciel continue de tourner, on remplace d’abord ce qui vous freine, et vous voyez l’avancement chaque semaine.

Garder la dette sous contrôle une fois remboursée

La dette revient si personne n’en est chargé : un plan de maintenance qui lui réserve du temps est ce qui garde un logiciel bon marché à faire évoluer. Les consignes d’achat du gouvernement britannique le disent aux acheteurs publics : pour éviter de créer de la dette technique et des systèmes obsolètes, prévoir une amélioration continue, par exemple en automatisant les déploiements et en testant le produit régulièrement.

Concrètement, quatre habitudes : des tests automatisés sur les parties critiques, des dépendances mises à jour selon un calendrier, un registre de la dette revu avec la feuille de route, une part de chaque budget gardée pour le nettoyage. Un contrat de tierce maintenance applicative peut porter les quatre, avec un code, des comptes et des droits qui restent à votre nom. Si vous préparez la suite, notre guide du prix d’un logiciel sur mesure donne les fourchettes du marché pour la maintenance comme pour le développement.

Vous ne savez pas combien de dette porte votre logiciel ? Pendant l’audit gratuit de 30 minutes, on regarde votre système avec vous, on pose les quatre questions ci-dessus et on vous dit où les intérêts sont les plus lourds. Le périmètre et le prix d’un audit ou d’une modernisation sont ensuite fixés par écrit avant de commencer. Réservez votre audit gratuit de 30 minutes : on vous répond sous un jour ouvré.