Qu'est-ce que la dette technique ?
La dette technique est le travail de correction qu'un logiciel « doit » à cause des raccourcis pris pendant son développement ou de son vieillissement, et qui ralentit chaque évolution tant qu'il n'est pas fait.
La métaphore financière sépare deux coûts qu'un dirigeant peut arbitrer :
- Le capital : le travail nécessaire pour corriger le compromis (réorganiser un module, écrire les tests manquants, monter de version).
- Les intérêts : le temps perdu à chaque intervention parce que le compromis est toujours là, par exemple une modification qui prend trois jours au lieu d'un.
Tant que le capital n'est pas remboursé, les intérêts tombent à chaque demande.
D'où vient l'expression dette technique ?
L'expression vient de Ward Cunningham, qui a introduit la métaphore de la dette en 1992, dans un retour d'expérience sur le logiciel financier WyCash présenté à la conférence OOPSLA.
Il y écrit que livrer un premier code revient à s'endetter, et qu'un peu de dette accélère le développement à condition d'être remboursée rapidement par une réécriture. Non remboursée, elle fait payer des intérêts qui peuvent immobiliser toute une équipe.
En 2009, Martin Fowler a précisé l'idée par un quadrant : la dette est-elle volontaire, et prudente ?
| Délibérée | Involontaire | |
|---|---|---|
| Imprudente | L'équipe sait qu'elle bâcle, faute de temps pour concevoir | L'équipe ignore les bonnes pratiques et produit du code confus sans s'en rendre compte |
| Prudente | L'équipe choisit de livrer vite et de corriger ensuite, en connaissance de cause | L'équipe comprend après coup comment il aurait fallu faire, ce qui arrive aussi aux équipes expérimentées |
Seule la case « délibérée et prudente » relève d'une vraie décision de gestion : c'est celle d'un MVP livré vite pour tester une hypothèse, avec un remboursement prévu.
Exemples de dette technique dans une PME
La dette technique se voit rarement à l'écran, mais elle se manifeste par des situations très concrètes.
- Un langage en fin de vie. Selon le site officiel de PHP, en octobre 2026, les versions 8.1 et antérieures ne reçoivent plus aucun correctif, et la version 8.2 cesse d'en recevoir le 31 décembre 2026. Une boutique en ligne restée sur PHP 7 tourne donc sans correctif de sécurité.
- Une règle copiée à plusieurs endroits. Le calcul de la remise client existe dans le devis, la commande et la facture. On le modifie dans deux écrans sur trois, et les factures ne correspondent plus aux devis.
- Aucun test automatisé. Chaque mise en production fait peur, donc on les espace, et chaque livraison regroupe trop de changements pour savoir lequel a causé l'anomalie.
- Un savoir dans une seule tête. Seul le développeur d'origine comprend le module de facturation, et rien n'est documenté.
Comment repérer une dette technique trop lourde ?
Un dirigeant n'a pas besoin de lire le code pour repérer une dette technique trop lourde : les symptômes se voient dans le quotidien du projet.
- Des demandes simples, comme ajouter un champ, sont estimées en jours.
- Chaque livraison corrige une chose et en casse une autre.
- L'équipe hésite à toucher certaines parties du logiciel.
- Le langage et les bibliothèques n'ont pas été mis à jour depuis des années.
- Personne ne sait réinstaller le logiciel sur un nouveau serveur sans l'auteur d'origine.
Trois symptômes ou plus justifient un audit du code avant de commander de nouvelles fonctions. Si l'auteur n'est plus joignable, la page reprendre un logiciel abandonné décrit la marche à suivre.
Comment rembourser la dette technique ?
On rembourse la dette technique progressivement, en commençant par les parties du logiciel que l'on modifie le plus souvent, car ce sont elles qui coûtent le plus d'intérêts.
- Inventorier les dettes connues et les classer selon leur coût et leur risque.
- Poser un filet : des tests automatisés sur les parcours critiques, rejoués à chaque livraison par une chaîne d'intégration et de déploiement continus.
- Réserver une part de chaque cycle au remboursement, au lieu d'attendre un grand chantier.
- Monter de version par petites marches, plutôt que de sauter plusieurs versions d'un coup.
- Réécrire en dernier recours, module par module, quand les intérêts dépassent durablement le coût d'une reconstruction.
Pour un logiciel ancien, la démarche complète est décrite sur la page moderniser un logiciel ancien.
Les idées reçues sur la dette technique
- « C'est la faute des développeurs. » La dette naît souvent d'un arbitrage commercial : une date de salon, une démonstration promise. L'important est de le savoir et de planifier le remboursement.
- « Un logiciel neuf n'a pas de dette. » Toute première version en contient, ne serait-ce que parce que l'équipe comprend mieux le métier en le construisant.
- « Il faut tout réécrire. » Une réécriture complète gèle les évolutions pendant des mois et reproduit souvent une partie des défauts ; le remboursement progressif est en général plus sûr.
Termes voisins de la dette technique
- Refactoring (remaniement du code) : réorganisation du code sans changer ce qu'il fait pour l'utilisateur, principal moyen de rembourser la dette.
- Régression : anomalie qui apparaît dans une fonction qui marchait, après une modification ailleurs.
- MVP : première version volontairement réduite, qui crée une dette assumée (voir la définition du MVP).
- TMA : maintenance confiée à un prestataire, qui sert aussi à contenir la dette au fil du temps (voir la définition de la TMA).
Questions fréquentes
- Qu'est-ce que la dette technique en termes simples ?
- En termes simples, la dette technique est ce qu'un logiciel « doit » parce qu'on a pris des raccourcis en le construisant ou qu'on l'a laissé vieillir. Comme une dette d'argent, elle a un capital, le travail pour corriger ces raccourcis, et des intérêts, le temps perdu à chaque modification tant qu'ils ne sont pas corrigés. Plus on attend, plus les intérêts s'accumulent.
- Qui a inventé l'expression dette technique ?
- L'expression dette technique vient de Ward Cunningham, qui a introduit la métaphore de la dette en 1992 dans un retour d'expérience présenté à la conférence OOPSLA. Il y comparait la livraison d'un premier code à un emprunt : utile pour aller vite s'il est remboursé rapidement, dangereux s'il ne l'est jamais. Martin Fowler a proposé en 2009 un quadrant pour en distinguer les types.
- La dette technique est-elle toujours une mauvaise chose ?
- Non, la dette technique n'est pas toujours une mauvaise chose. Contracter volontairement une dette pour livrer vite un MVP ou tenir une échéance commerciale peut être une bonne décision, à condition de la noter et de planifier son remboursement. La dette devient un problème quand elle est involontaire, ignorée ou jamais remboursée : chaque évolution coûte alors de plus en plus cher.
- Comment réduire la dette technique sans tout réécrire ?
- Pour réduire la dette technique sans tout réécrire, on commence par écrire des tests automatisés sur les parcours critiques, puis on corrige d'abord les parties du logiciel les plus souvent modifiées, car ce sont elles qui coûtent le plus cher. On réserve une part de chaque cycle de développement à ce remboursement et l'on monte de version régulièrement, par petites étapes.