Dette technique : définition, types et comment la gérer

La dette technique, ou technical debt, désigne le coût futur d’un choix de conception retenu pour livrer plus vite, au lieu de la solution qui aurait été la plus durable. Ce coût se paie ensuite en temps supplémentaire, à chaque modification du code concerné.

La métaphore financière est le plus souvent réduite à un bulletin de mauvaise conduite : la dette serait du code sale, produit par des équipes peu rigoureuses. Cette lecture explique pourquoi le sujet reste bloqué dans tant d’organisations. Une dette est d’abord un mode de financement : elle achète du temps, à un prix. Reste à savoir lequel, qui l’a contractée, et comment la faire apparaître dans un backlog produit — c’est là que se situe le travail d’un product manager.

Qu’est-ce que la dette technique ? Définition

Une dette technique se constitue dès qu’une équipe retient une solution moins solide que celle qu’elle sait possible : un contournement plutôt qu’une refonte, une duplication plutôt qu’une abstraction, une vérification manuelle plutôt qu’un test automatisé. Le produit fonctionne, l’utilisateur ne voit rien, la date est tenue. Le coût est reporté, pas annulé.

L’analogie avec un emprunt tient sur trois éléments. Le principal, c’est le travail de remise en état qu’il faudra bien faire un jour. L’intérêt, c’est le surcoût payé entre-temps sur chaque évolution touchant la zone. Et l’échéance n’existe pas : personne n’envoie de rappel. C’est cette absence d’échéance, bien plus que la nature technique du sujet, qui rend la dette dangereuse : rien ne force jamais la décision.

L’origine de la métaphore : Ward Cunningham

L’expression vient de Ward Cunningham, qui l’emploie en 1992 dans un rapport d’expérience sur le système WyCash. Sa formulation d’origine reste la plus juste :

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.

Ward Cunningham, 1992

Livrer du code du premier jet revient donc à s’endetter, et un peu de dette accélère le développement — à condition d’être remboursée rapidement. Deux idées y figurent, et la vulgarisation en a perdu une : la dette est utile, et elle ne l’est qu’aussi longtemps qu’elle est remboursée.

Ce que la dette technique n’est pas

• Ce n’est pas un bug — un bug est un comportement incorrect à corriger ; une dette est un comportement correct, obtenu par un moyen coûteux à faire évoluer.
• Ce n’est pas une faute — une dette contractée pour tenir une date de mise sur le marché peut être la meilleure décision disponible. Le problème naît de l’oubli, pas de l’emprunt.
• Ce n’est pas réservé au code — une base de données mal modélisée, une chaîne de déploiement manuelle ou une configuration que personne ne comprend produisent le même effet, côté backend comme côté frontend.

L’intérêt : ce que la dette coûte à chaque livraison

C’est le point que la métaphore rend le mieux, et celui qu’on oublie le plus vite. Une dette ne coûte rien tant que personne ne retourne dans la zone concernée, et devient chère dès qu’on y revient — ce qui arrive sans arrêt, puisque les zones les plus endettées sont celles où le produit évolue le plus.

La dette technique ne se paie pas en fin de mois. Elle se paie à chaque fois qu’on touche au code concerné.

L’intérêt ne se présente jamais sous forme de facture. Il apparaît dans des symptômes que les équipes attribuent le plus souvent à autre chose :

• Des estimations qui gonflent — une évolution simple sur le papier demande plusieurs fois plus de temps qu’ailleurs dans le produit.
• Des régressions à répétition — chaque correction en casse une autre, faute de tests automatisés.
• Un délai de mise en production qui s’allonge — vérifications manuelles, déploiements risqués, fenêtres de livraison rares.
• Une dépendance à une personne — une seule sait intervenir dans la zone, et son absence suffit à bloquer le sujet.
• Des renoncements silencieux — le coût le plus élevé et le moins visible : l’équipe cesse de proposer des évolutions sur la zone qu’elle sait trop risquée à toucher.

Ce dernier symptôme ne se mesure pas, et c’est ce qui le rend redoutable : une dette installée finit par déformer la roadmap, les options qui traversent la zone n’étant simplement plus proposées. À l’inverse, tout ce qui abaisse le coût d’une intervention réduit le taux d’intérêt sans rembourser le principal — c’est le rôle des tests automatisés et de l’intégration continue portés par les pratiques DevOps.

Dette délibérée ou subie : le quadrant de Martin Fowler

Toutes les dettes ne se traitent pas de la même manière, et confondre leurs origines conduit à des réponses inadaptées. Martin Fowler propose pour cela un quadrant de la dette technique qui croise deux axes : la dette était-elle délibérée ou involontaire, et le choix était-il prudent ou imprudent ? Quatre cases, illustrées par la phrase que l’on entend dans chacune.

	Délibérée	Involontaire (subie)
Prudente	« On doit livrer maintenant, on assumera les conséquences » — un compromis conscient, motivé par une échéance réelle.	« Maintenant, on sait comment il aurait fallu le faire » — la bonne conception n’apparaît qu’après avoir compris le domaine.
Imprudente	« On n’a pas le temps de faire de la conception » — les bonnes pratiques sont connues, elles sont écartées sous pression.	« C’est quoi, un découpage en couches ? » — le problème n’est même pas identifié comme un problème.

Ce que la distinction change concrètement

Une dette délibérée et prudente est une décision de gestion : elle a un auteur et une raison. C’est la seule des quatre qui puisse être pilotée comme un investissement — à condition d’avoir été consignée au moment où elle a été contractée, et non reconstituée deux ans plus tard.

Une dette involontaire et prudente est le produit normal de l’apprentissage : au bout d’un an sur un domaine, une bonne équipe sait ce qu’elle aurait dû faire autrement. Elle ne se prévient pas, elle se rembourse — et constitue l’essentiel du volume dans un produit qui dure.

Les deux cases imprudentes, en revanche, appellent autre chose qu’un élément de backlog : l’imprudence délibérée signale une pression de livraison mal arbitrée, et ce sont le cadre de travail et les artefacts de l’équipe qu’il faut revoir ; l’imprudence involontaire relève de la compétence. Aucun plan de remboursement ne tiendra tant que la même dette continue d’être produite.

Rendre la dette technique visible dans le backlog produit

C’est ici que se situe le vrai problème d’un product manager, et il n’est pas technique. Une dette n’a ni utilisateur, ni demandeur, ni démonstration à montrer en revue de sprint. Face à une fonctionnalité qui a un client et un porteur, elle perd tous les arbitrages — non parce qu’elle est moins importante, mais parce qu’elle est moins racontable.

La première tentation consiste à lui créer un espace à part : un « backlog technique » tenu par l’équipe de développement. C’est une erreur mécanique plus que philosophique : deux listes séparées ne se comparent jamais, et une liste qui n’entre pas en concurrence avec les fonctionnalités n’est pas priorisée, elle est mise de côté. Il n’existe qu’un backlog produit, et la dette y figure comme le reste.

Formuler un élément de dette pour qu’il soit priorisable

Un élément de dette écrit en langage technique est ininterprétable pour ceux qui décident : « refactoriser le module de paiement » ne dit ni ce que la situation coûte aujourd’hui, ni ce qu’elle empêche demain. La reformulation suit la même logique qu’une user story : partir de l’effet observable, pas de la solution.

• Nommer la zone et l’intérêt observé — « chaque ajout d’un moyen de paiement demande plusieurs jours de vérifications manuelles ».
• Dire ce qui redevient possible — quelle évolution, aujourd’hui écartée d’office, entre à nouveau dans le champ des options.
• Donner la fréquence de passage — une dette dans une zone touchée à chaque sprint ne pèse pas comme une dette dans une zone gelée.
• Dimensionner l’effort comme le reste — même unité d’estimation que les autres éléments, sans barème à part.
• Écrire le déclencheur plutôt qu’une date — « à traiter avant d’ajouter un troisième moyen de paiement » vaut mieux qu’une échéance qui glissera.

Formulée ainsi, la dette entre dans les mêmes grilles que le reste du backlog. Un scoring ICE l’accepte sans adaptation : l’impact devient le temps de développement récupéré et le risque évité. Une priorisation MoSCoW fonctionne aussi, à condition d’accepter qu’un élément de dette puisse être classé « must have ». Le moment naturel de l’exercice reste l’affinage du backlog.

Trois façons de lui faire de la place

1. Au contact — toute intervention laisse la zone un peu plus propre qu’on ne l’a trouvée. Cette règle ne se planifie pas et suffit pour la dette diffuse, celle qui ne mérite pas un élément dédié.
2. Une part de capacité réservée — l’équipe consacre une fraction connue de chaque itération au remboursement, actée en sprint planning. L’avantage est la régularité ; la limite est connue, cette part sert de variable d’ajustement dès que la pression monte.
3. Un chantier assumé — un objectif de sprint entièrement consacré à une dette identifiée, avec un résultat attendu formulé comme n’importe quel autre. À réserver aux dettes dont l’intérêt annuel dépasse le coût du remboursement.

Comment gérer la dette technique : refactoring et arbitrages

Le principe directeur tient en une phrase : on ne rembourse pas toute sa dette, on rembourse celle dont on paie effectivement les intérêts. Un audit exhaustif produit un inventaire long et sans hiérarchie ; le point de départ utile est l’endroit où l’équipe souffre.

1. Repérer où l’intérêt est payé — les zones où les estimations gonflent, où les régressions reviennent, où l’équipe hésite avant d’intervenir. Ceux qui écrivent le code les nomment en quelques minutes.
2. Traduire en langage produit — temps de développement immobilisé, évolutions écartées, incidents récurrents. C’est cette traduction qui rend l’arbitrage possible avec les parties prenantes et la direction des systèmes d’information.
3. Prioriser par intérêt payé, pas par gravité technique — une dette grave dans une zone qu’on ne touche plus peut attendre ; une dette modérée sur le chemin de la roadmap passe devant.
4. Rembourser par refactoring — modifier la structure interne du code sans changer son comportement observable. Par petites étapes, au contact des évolutions en cours, l’opération est peu risquée. Une réécriture complète est un autre arbitrage, avec son coût propre.
5. Arrêter d’en produire — une définition de fini exigeante, des tests automatisés et une intégration continue coupent le robinet. Sans cela, le remboursement court derrière une dette qui se reconstitue à chaque sprint.
6. Assumer les dettes qu’on garde — décider de ne pas rembourser est légitime ; cela ne devient un problème que lorsque la décision n’est écrite nulle part.

La cinquième étape est celle qu’on saute le plus souvent, et la seule qui change la pente. La définition de fini — ou Definition of Done, telle que la décrit le Guide Scrum — fixe ce qu’une équipe considère comme réellement terminé : tout ce qu’elle n’exige pas devient de la dette par défaut, sans que personne n’ait le sentiment d’avoir mal travaillé.

En vidéo : la dette technique vue du côté des équipes de développement (Scrum Life).

S’il ne fallait retenir qu’une chose : je n’ai jamais vu une dette technique se régler par un plaidoyer sur la qualité du code. Elle se règle le jour où son intérêt est exprimé en jours de développement perdus et posé dans le backlog, à côté des fonctionnalités et dans la même unité d’estimation.

FAQ — Tout savoir sur la dette technique

Comment dit-on « dette technique » en anglais ?

On dit technical debt, souvent abrégé en « tech debt ». On rencontre aussi « design debt », employé par Ward Cunningham lui-même, et « code debt » pour la part strictement logicielle. Les trois renvoient à la même idée de coût futur contracté aujourd’hui.

Quel est un exemple concret de dette technique ?

Un tunnel de commande dont la logique de calcul du prix a été dupliquée à trois endroits pour livrer plus vite. Chaque changement de règle tarifaire exige désormais trois modifications coordonnées, et l’oubli de l’une provoque un écart en production. La fonctionnalité marche, son évolution coûte trois fois trop cher.

Comment gérer la dette technique en Scrum ?

En la plaçant dans le backlog produit unique, jamais dans une liste technique séparée, et en la formulant avec un effet observable et une estimation comparable aux autres éléments. Le remboursement se fait ensuite au contact des évolutions, sur une part de capacité réservée, ou sur un objectif de sprint dédié.

Quelle différence entre dette technique et refactoring ?

La dette technique est l’état : un écart de conception qui coûte du temps à chaque intervention. Le refactoring est l’action de remboursement, c’est-à-dire modifier la structure interne du code sans changer son comportement observable. On contracte une dette ; on fait du refactoring pour la réduire.

Faut-il rembourser toute sa dette technique ?

Non, et viser le zéro dette est le meilleur moyen de ne rien traiter. Une dette située dans une zone stable que personne ne modifie plus ne coûte rien : la rembourser serait une dépense sans contrepartie. La bonne cible est celle qui se trouve sur le chemin des prochaines évolutions.

Comment mesurer la dette technique ?

Les outils d’analyse statique situent les zones à risque, mais aucun ne mesure ce qui compte pour décider : le temps réellement perdu. Les signaux les plus exploitables restent l’écart d’estimation entre zones comparables, le taux de régression et le délai de mise en production.