La dette technique est l’ensemble des raccourcis, défauts de conception et composants vieillissants qui rendent une application plus lente, plus coûteuse et plus risquée à faire évoluer qu’elle ne devrait l’être. Comme une dette financière, elle a un principal (le travail nécessaire pour remettre le code en ordre) et des intérêts (le temps supplémentaire payé à chaque nouvelle évolution). Pour un dirigeant, l’enjeu n’est pas de l’éliminer, mais de la rendre visible, de décider consciemment quand on en contracte et de la rembourser là où elle coûte le plus.
Le sujet est souvent laissé aux équipes techniques. C’est une erreur : la dette technique est une décision d’investissement, avec un effet direct sur votre capacité à livrer, sur la sécurité et sur la valeur de vos outils. Voici comment la comprendre sans lire une ligne de code.
D’où vient la métaphore de la dette ?
L’expression vient de Ward Cunningham, l’un des pionniers des méthodes agiles. En 1992, dans un retour d’expérience présenté à la conférence OOPSLA, il écrit : « Shipping first time code is like going into debt », autrement dit livrer du code de premier jet revient à s’endetter. Un peu de dette accélère le développement, à condition d’être remboursée rapidement par une réécriture. Le danger survient quand elle ne l’est jamais : chaque minute passée sur un code imparfait compte comme un intérêt, et des organisations entières peuvent se retrouver paralysées.
Martin Fowler a précisé la mécanique. Dans son article de référence, il prend l’exemple d’une fonctionnalité qui demanderait quatre jours dans un code bien structuré et six jours dans un code encombré : les deux jours d’écart sont les intérêts. Remettre la structure en ordre coûterait cinq jours. Pour une seule fonctionnalité, ce n’est pas rentable ; si deux autres évolutions similaires sont prévues dans la même zone, ça l’est.
Cette arithmétique simple résume toute la gestion de la dette : on rembourse quand les intérêts futurs dépassent le coût du remboursement.
Toutes les dettes ne se valent pas : le quadrant de Fowler
En 2009, Martin Fowler propose de classer la dette selon deux axes : est-elle délibérée ou involontaire ? Est-elle prudente ou imprudente ? Son quadrant de la dette technique est devenu l’outil le plus utile pour en parler en comité de direction.
| Délibérée | Involontaire | |
|---|---|---|
| Prudente | « Nous livrons maintenant et nous assumons le compromis » : choix conscient pour tenir une échéance, avec un plan de remboursement | « Maintenant, nous savons comment nous aurions dû faire » : l’équipe apprend en construisant, c’est inévitable même pour les meilleures |
| Imprudente | « Nous n’avons pas le temps de bien faire » : le raccourci est pris en sous-estimant son coût | « C’est quoi, une architecture ? » : l’équipe ignore les bonnes pratiques |
Ce tableau change la conversation. La dette prudente et délibérée est un outil de gestion légitime : sortir un MVP avant un salon professionnel, en sachant qu’il faudra consolider ensuite. La dette prudente et involontaire est le prix normal de l’apprentissage. Les deux cases imprudentes, en revanche, signalent un problème de méthode ou de compétence.
Combien coûte réellement la dette technique ?
Les chiffres publiés sont rares et doivent être lus avec prudence. L’étude la plus citée reste The Developer Coefficient, publiée par Stripe en 2018 à partir d’une enquête auprès de développeurs et de dirigeants. Les répondants estimaient qu’un développeur consacre en moyenne 13,5 heures par semaine à la dette technique, sur une semaine moyenne de 41,1 heures. La France ressortait comme le pays où le temps estimé passé en maintenance (bugs, débogage, refonte) était le plus élevé : 20,9 heures par semaine, contre 17,3 en moyenne.
Il s’agit d’estimations déclaratives, pas de mesures. Mais l’ordre de grandeur suffit à comprendre l’enjeu : une part importante de la capacité de développement que vous financez peut servir à contourner des problèmes plutôt qu’à créer de la valeur.
Les coûts cachés s’ajoutent aux heures :
- des délais qui s’allongent pour des demandes qui paraissent simples ;
- des régressions : une correction ici casse une fonctionnalité là ;
- des failles de sécurité dans des composants obsolètes, que l’OWASP classe parmi les risques majeurs des applications web avec les composants vulnérables et obsolètes ;
- une dépendance aux personnes : seul un développeur ose encore toucher au module de facturation ;
- une valeur d’actif dégradée, visible lors d’un audit préalable à une levée de fonds ou à une cession d’entreprise.
Comment la mesurer sans être développeur ?
Il n’existe pas de compteur unique de la dette technique. En revanche, plusieurs signaux, suivis dans le temps, en donnent une image fiable. Les uns se lisent dans le pilotage, les autres demandent un regard technique ponctuel.
Les signaux de pilotage
| Signal | Ce qu’il révèle | Comment le suivre |
|---|---|---|
| Délai entre une demande et sa mise en production | Les intérêts de la dette : tout prend plus de temps | Tendance sur six à douze mois, à périmètre comparable |
| Taux de régressions après livraison | Un code fragile, peu couvert par des tests | Nombre de bugs réintroduits par version |
| Part du temps consacrée aux corrections | La capacité absorbée par la maintenance | Répartition des tickets traités par catégorie |
| Zones « intouchables » | Une concentration de dette et de risque humain | Question directe à l’équipe : où n’osez-vous pas aller ? |
| Écart des estimations | Une complexité mal maîtrisée | Comparaison estimé / réalisé par type de demande |
Les signaux techniques
Un audit de code, réalisé par l’équipe en place ou par un tiers, examine notamment :
- L’âge des dépendances : frameworks et bibliothèques encore maintenus ou non, versions en retard. Le programme de recherche DORA recommande de suivre la part des applications qui ne sont pas sur la dernière version stable de leurs bibliothèques et le nombre de versions de plus d’un an en production.
- La couverture de tests automatisés sur les règles de gestion critiques.
- La duplication : la même règle codée à plusieurs endroits, qui finit par diverger.
- La complexité de certains fichiers ou fonctions, que des outils d’analyse statique mesurent automatiquement.
- La documentation : peut-on installer et déployer l’application sans l’aide de la personne qui l’a écrite ?
Comment rembourser la dette sans arrêter les évolutions ?
La tentation, face à une dette lourde, est le « grand nettoyage » : six mois sans nouvelle fonctionnalité pour tout remettre à plat. C’est presque toujours une mauvaise idée, pour deux raisons. Les métiers ne peuvent pas attendre, et le nettoyage lui-même produit de la nouvelle dette s’il n’est pas guidé par des besoins réels.
Les équipes qui gèrent bien la dette appliquent quelques règles simples :
- Rembourser là où le code change. Fowler le souligne : les intérêts ne se paient que lorsqu’on travaille dans une zone. Un module stable et rarement modifié peut rester imparfait. Une zone très active, comme la tarification ou le planning, mérite une tolérance zéro.
- Réserver une part fixe de chaque sprint. Plutôt qu’un chantier à part, une fraction visible de la capacité est consacrée à la qualité, ajustée selon les indicateurs.
- Appliquer la règle du campeur : chaque intervention laisse le code un peu plus propre qu’elle ne l’a trouvé.
- Tenir un registre de la dette, au même titre que le backlog fonctionnel : chaque compromis délibéré y est noté avec sa raison et son plan de remboursement.
- Mettre à jour les dépendances en continu, par petites marches, plutôt que de laisser s’accumuler des années de retard.
- Écrire des tests avant de toucher à une zone fragile, pour sécuriser le remboursement lui-même.
Quand la dette est concentrée dans une application ancienne et que la technologie elle-même n’est plus maintenue, la question devient celle de la modernisation. Nous l’abordons dans notre guide pour moderniser une application historique sans arrêter l’activité.
Les questions à poser à votre équipe ou à votre prestataire
Vous n’avez pas besoin de compétences techniques pour piloter la dette. Il suffit de poser régulièrement les bonnes questions :
- Quels compromis avons-nous faits pour tenir les dernières échéances, et quand les rembourserons-nous ?
- Quelles sont les trois zones de l’application les plus coûteuses à faire évoluer ?
- Quelle part de la capacité du dernier trimestre est allée aux corrections ?
- Quelles dépendances ne sont plus maintenues, ou le seront bientôt ?
- Si vous partiez demain, combien de temps faudrait-il à une autre équipe pour reprendre le code ?
La cinquième question est la plus révélatrice. Elle rejoint les sujets de propriété du code et de réversibilité : une dette documentée et maîtrisée reste un actif transmissible ; une dette cachée est un passif.
Intégrer la dette dans vos décisions d’investissement
La dette technique a un coût, mais ne pas en contracter du tout en a un aussi : livrer trop tard, surconcevoir des fonctionnalités dont personne n’aura besoin. Le bon réflexe est de l’intégrer explicitement dans le coût total d’une application et dans le budget de maintenance après mise en production, au lieu de la découvrir sous forme de dérapages.
C’est aussi pour cela que notre méthode repose sur des livraisons courtes, des tests automatisés et une revue de code systématique : la dette ne disparaît pas, mais elle reste petite, visible et choisie. Vous voulez un regard extérieur sur l’état d’une application existante ? Décrivez-la dans notre diagnostic de projet : nous vous dirons quels signaux examiner en priorité.
