Dette technique : définition, signes et plan pour la réduire

Chaque évolution prend plus de temps que la précédente, une correction en casse une autre, et l’équipe hésite à toucher certaines parties de l’application : c’est souvent la dette technique qui se fait sentir. Ce guide explique ce que le mot recouvre, comment la repérer depuis la direction et comment la réduire sans arrêter le reste.

Il s’adresse aux dirigeants, aux DSI et aux fondateurs qui entendent parler de dette technique par leurs équipes ou leur prestataire, et qui veulent savoir si c’est grave, ce que cela coûte et quoi décider.

Dette technique : définition

L’expression vient de Ward Cunningham, l’un des pionniers du développement agile. En 1992, dans un retour d’expérience présenté à la conférence OOPSLA, il compare la livraison d’un premier code à un emprunt : un peu de dette accélère le développement, à condition d’être remboursée vite, par une réécriture. Le danger vient de la dette que l’on ne rembourse pas : chaque minute passée sur un code imparfait en est l’intérêt.

Pour une entreprise, la définition utile est simple : la dette technique, c’est l’écart entre l’application telle qu’elle est et ce qu’elle devrait être pour évoluer sans effort inutile. Le capital, c’est le travail reporté. Les intérêts, c’est le temps perdu chaque fois que l’on travaille dans une partie concernée.

Ce n’est donc pas un synonyme de « bug » ni de « mauvais code ». Une application peut fonctionner parfaitement pour ses utilisateurs et porter une dette lourde : elle se paie au moment de la faire évoluer, pas au moment de s’en servir.

Les quatre formes de dette technique

En 2009, Martin Fowler a proposé une grille devenue classique : la dette est délibérée ou involontaire, et prudente ou imprudente. Pour lui, la question utile n’est pas de savoir s’il y a de la dette, mais de quelle sorte.

D’après le « Technical Debt Quadrant » de Martin Fowler (2009).

Seule la case prudente et délibérée est un choix de gestion : la dette y est connue, notée et datée. La case imprudente et involontaire est la plus coûteuse, parce que personne ne sait où elle est ni combien elle pèse. C’est souvent ce que l’on trouve en reprenant une application développée vite, par des intervenants successifs (voir notre méthode de reprise d’application web).

Où elle se loge dans une application

• Le code. Des fonctions trop longues, de la logique copiée en plusieurs endroits, des noms qui ne disent pas ce qu’ils font.
• L’architecture. Des parties si liées entre elles qu’on ne peut en changer une sans toucher aux autres.
• Les dépendances. Un langage, un framework ou une bibliothèque dont la version ne reçoit plus de correctifs. PHP 8.2, par exemple, ne reçoit plus que des correctifs de sécurité, jusqu’au 31 décembre 2026 (voir notre article sur la fin du support de PHP 8.2).
• Les tests. Peu ou pas de tests automatisés : chaque modification se vérifie à la main, ou pas du tout.
• Le déploiement. Une mise en production manuelle, longue, que seule une personne sait faire.
• La documentation et la connaissance. Des règles métier qui ne sont écrites nulle part, sinon dans la mémoire d’un développeur.

Les signes visibles depuis la direction

Un dirigeant ne lit pas le code. Il voit en revanche les symptômes, qui reviennent presque toujours.

• Les délais s’allongent à demande égale, et les estimations deviennent imprévisibles.
• Une correction en provoque une autre, ailleurs : les régressions se multiplient.
• L’équipe évite certaines parties de l’application, ou dit qu’« il faudrait tout refaire ».
• Les mises en production sont rares, regroupées et redoutées.
• Une seule personne sait faire certaines choses, et son absence bloque le reste.
• Une version de langage ou de framework n’est plus maintenue, et la mise à jour est sans cesse repoussée.
• Un nouveau développeur met des semaines à devenir autonome.

Deux ou trois de ces signes suffisent à justifier un état des lieux. Aucun ne dit, seul, combien pèse la dette : c’est le rôle de l’inventaire.

Ce qu’elle coûte vraiment

Les chiffres qui circulent sur le coût de la dette technique viennent le plus souvent d’éditeurs ou de cabinets qui vendent la solution : nous n’en citons aucun. Le coût réel se mesure dans votre propre application, et il prend quatre formes.

• Du temps. Les intérêts : chaque évolution dans une partie endettée coûte plus de jours qu’elle ne devrait. C’est le coût le plus visible, et il grossit avec le temps.
• Du risque. Un composant qui ne reçoit plus de correctifs reste exposé aux failles découvertes après sa fin de support. Pour un éditeur de logiciel, le Cyber Resilience Act renforce les obligations sur ce point.
• De la dépendance. Quand la connaissance tient à une personne ou à un prestataire, en changer devient long et coûteux.
• Des occasions manquées. Le temps passé à contourner la dette n’est pas passé sur les évolutions qui comptent pour le métier.

Réduire la dette technique en cinq étapes

1. Faire l’inventaire. Lister ce qui pèse, partie par partie : les dépendances et leur date de fin de support, la couverture de tests, la manière de déployer, les zones que l’équipe redoute, ce qui n’est pas documenté. Un regard extérieur aide, parce que l’équipe en place s’est habituée à ses contournements : c’est l’objet d’un audit de l’existant.

2. Estimer et classer. Pour chaque point, une estimation en jours du remboursement, et deux questions : quel risque fait-il courir, et à quelle fréquence travaille-t-on dans cette partie ? Une dette lourde dans un module que personne ne touche peut attendre. Une dette légère dans le module modifié chaque semaine coûte des intérêts tous les jours.

3. Réserver du temps, de façon régulière. Une part fixe de la capacité de l’équipe, à chaque cycle, va au remboursement. Cette part se décide avec la direction, au même titre que les évolutions : c’est elle qui protège la vitesse de demain. Dans un contrat de maintenance, elle s’écrit noir sur blanc (voir notre guide de la maintenance évolutive).

4. Rembourser là où l’on travaille. Le plus rentable est de nettoyer une partie au moment où une évolution la touche : on la comprend déjà, on la teste déjà. Les mises à jour de sécurité, elles, ne se reportent pas.

5. Arrêter d’en créer. Des tests automatisés sur ce qui change, une relecture de chaque modification par un second développeur, des dépendances tenues à jour, et une définition partagée de « terminé » qui inclut la documentation. Quand l’équipe choisit de prendre un raccourci, elle le note, avec la date à laquelle elle le reprendra.

Rembourser peu à peu ou tout refaire

« Il faudrait tout refaire » est souvent la première réaction devant une application endettée. Une refonte complète arrête pourtant les évolutions pendant des mois, recrée des défauts déjà corrigés dans l’ancienne version et porte son propre risque de dette. Le remboursement progressif est la voie par défaut ; la refonte se justifie dans quelques cas :

• la technologie de base n’est plus maintenue et aucune migration raisonnable n’existe ;
• le métier a tellement changé que l’application ne correspond plus au besoin ;
• l’inventaire montre que presque chaque partie serait à reprendre.

Même dans ces cas, une refonte par morceaux, partie par partie, en gardant l’ancienne application en service, limite le risque. La décision se prend sur l’inventaire, pas sur une impression.

Questions fréquentes

Une dette se pilote

La dette technique n’est ni une faute à chercher ni une fatalité. C’est un passif, qui se recense, se chiffre et se rembourse à un rythme décidé, comme n’importe quel autre. Ce qui la rend dangereuse, c’est de l’ignorer.

L’équipe nearshore et francophone d’iones, basée à Tunis, reprend des applications existantes en maintenance applicative, avec un temps réservé au remboursement de la dette, et peut commencer par un audit de l’existant. Vous pouvez aussi nous écrire pour un premier échange.