La dette technique désigne le coût futur des compromis faits lors de la conception ou de l'évolution d'un système informatique : raccourcis de code, architecture provisoire, tests absents, documentation manquante, composants devenus obsolètes. Comme une dette financière, elle produit des intérêts : chaque évolution devient plus lente, plus risquée et plus chère tant qu'elle n'est pas remboursée.
L'expression a été proposée par le développeur Ward Cunningham en 1992. Sa métaphore a fait fortune parce qu'elle dit une chose juste : la dette n'est pas une faute. Emprunter peut être rationnel. Ce qui ne l'est pas, c'est d'oublier qu'on a emprunté.
Une dette n'est pas une erreur
Toute équipe contracte de la dette. Livrer vite une première version, reporter un refactoring, choisir une solution simple en attendant d'en savoir plus : ces décisions sont souvent légitimes. Martin Fowler a proposé de croiser deux axes — dette délibérée ou involontaire, prudente ou imprudente — pour séparer les arbitrages assumés des négligences.
Le problème commence quand la dette devient invisible. Personne ne l'a inscrite nulle part, personne n'en mesure le coût, et elle s'accumule jusqu'à ce que le système ne puisse plus évoluer.
Les formes de la dette
La dette technique ne se limite pas au code. Elle prend plusieurs formes :
- le code difficile à lire ou à modifier ;
- l'architecture devenue inadaptée aux usages actuels ;
- l'absence de tests, qui rend chaque changement risqué ;
- la documentation manquante, qui fait dépendre le système de quelques personnes ;
- les dépendances obsolètes — langages, frameworks, logiciels arrivés en fin de support ;
- la dette de données : doublons, formats hétérogènes, règles implicites.
Ce que coûte la dette
Son coût est rarement visible dans un budget, parce qu'il se paie en temps. Chaque nouvelle fonctionnalité prend plus longtemps qu'elle ne devrait. Les incidents se multiplient. Les meilleurs ingénieurs passent leurs journées à contourner l'existant plutôt qu'à le faire progresser.
À l'échelle d'une organisation, l'effet est considérable. Dans une enquête publiée par McKinsey en 2020, des directeurs des systèmes d'information estimaient leur dette technique à 20 à 40 % de la valeur de leur patrimoine technologique.
La dette a aussi un coût stratégique. Un système endetté ralentit tout ce qui vient après lui — y compris l'IA. Un agent ne peut pas s'appuyer sur des données inaccessibles, ni sur des processus que personne ne sait plus décrire.
Mesurer la dette
On ne réduit pas ce qu'on ne mesure pas. Plusieurs indicateurs aident à objectiver la dette : les outils d'analyse statique, qui estiment un temps de remédiation ; la couverture de tests ; l'âge des dépendances et leur statut de support ; les indicateurs de livraison, comme le délai entre une demande et sa mise en production.
Aucun ne suffit seul. Leur évolution dans le temps en dit plus que leur valeur à un instant donné.
Rembourser la dette
Une dette technique se rembourse rarement en une fois, et presque jamais par une réécriture complète, qui reste le pari le plus risqué. Quatre principes donnent de meilleurs résultats.
Inventorier et prioriser, en commençant par la dette qui coûte le plus d'intérêts : celle qui ralentit les évolutions les plus fréquentes. Réserver une capacité régulière au remboursement, plutôt que d'attendre un grand projet qui ne viendra pas. Sécuriser par les tests avant de modifier, pour que chaque changement reste réversible. Et moderniser progressivement, en remplaçant un système morceau par morceau.
Ce que l'IA change
Le remboursement de la dette bute toujours sur le même obstacle : comprendre ce que fait l'existant. Les outils d'IA permettent désormais de lire et de documenter de grandes bases de code, d'identifier le code mort, de proposer des refactorings et de générer les tests qui manquent.
Ils ne remplacent pas le jugement des ingénieurs. Ils abaissent le coût de la compréhension, qui était le principal frein. C'est le principe de la modernisation augmentée par l'IA.
FAQ
Qu'est-ce que la dette technique ?
Le coût futur des compromis faits dans un système informatique — code, architecture, tests, documentation, dépendances. Elle se manifeste par des évolutions de plus en plus lentes et risquées.
Quelles sont les causes de la dette technique ?
Les délais serrés, les solutions provisoires devenues définitives, l'absence de tests, le manque de documentation, le renouvellement des équipes et l'obsolescence des technologies utilisées.
Comment réduire la dette technique ?
En l'inventoriant, en priorisant la dette la plus coûteuse, en lui consacrant une capacité régulière, en sécurisant les changements par des tests et en modernisant progressivement plutôt qu'en réécrivant tout d'un coup.
Origin 137 aide les ETI et les grands groupes à réduire leur dette technique et à moderniser leurs systèmes avec des ingénieurs augmentés à l'IA. Échanger avec nos équipes.
Pour aller plus loin :
- Moderniser son legacy avec l'IA
- TMA vs modernisation augmentée
- Brownfield vs greenfield
- Modernisation Java et applications legacy