Dette technique : comment la prioriser et la gérer au quotidien
Dette technique : comment l’inventorier, la prioriser avec une matrice impact/coût, lui réserver de la capacité et convaincre vos parties prenantes business.
Par l’équipe RoadmapHero · Mis à jour le · 9 min de lecture
L’essentiel
- La dette technique est le coût futur des raccourcis pris dans le code, l’architecture, les tests ou l’infrastructure ; ses intérêts se paient en lenteur, en incidents et en risque.
- Pour la prioriser, classez chaque dette selon deux axes : son impact sur la livraison ou le risque, et son coût de correction. Corrigez d’abord l’impact fort à coût faible.
- Une règle empirique courante consiste à réserver une part fixe de chaque sprint à la dette, souvent de 15 à 20 %, plutôt que d’attendre un hypothétique sprint de nettoyage.
- Face aux parties prenantes business, parlez de coût du retard : jours perdus par sprint, incidents évités, délais de mise sur le marché, jamais de « code sale ».
Prioriser la dette technique, c’est la traiter comme n’importe quel autre investissement produit : l’inventorier dans le backlog, estimer ce qu’elle coûte chaque sprint, la classer selon son impact et son coût de correction, puis lui réserver une part explicite de la capacité. La dette qui ralentit la livraison ou fait peser un risque passe en premier ; celle qui dort dans un module que personne ne touche peut attendre, parfois indéfiniment.
Le problème n’est presque jamais l’existence de la dette. Toute équipe qui livre en accumule. Le problème est qu’elle reste invisible jusqu’au jour où une fonctionnalité simple prend trois sprints, ou où un incident révèle qu’un composant critique n’a aucun test. Ce guide propose une méthode pour sortir de ce cycle.
Qu’est-ce que la dette technique ?
La dette technique est l’écart entre l’état actuel d’un système et l’état qui permettrait de le faire évoluer facilement et sans risque. L’expression a été proposée par Ward Cunningham au début des années 1990 sous forme de métaphore financière : un raccourci permet de livrer plus vite aujourd’hui (le capital emprunté), mais chaque modification future coûte un peu plus cher (les intérêts), jusqu’à ce que la dette soit remboursée.
Cette métaphore est utile parce qu’elle rappelle deux choses. D’abord, s’endetter n’est pas une faute en soi : une startup qui valide son marché a raison de prendre des raccourcis. Ensuite, ce qui compte n’est pas le montant de la dette mais le montant des intérêts : une dette dans un code que personne ne modifie ne coûte presque rien.
Dette délibérée ou accidentelle
On distingue classiquement deux origines, que Martin Fowler a formalisées dans son quadrant de la dette technique :
La dette délibérée : l’équipe choisit consciemment un raccourci pour tenir une échéance, en sachant qu’il faudra y revenir. Elle est saine si elle est tracée et remboursée.
La dette accidentelle : elle apparaît sans décision explicite, par manque de connaissance, par évolution du besoin ou simplement parce que le système a grandi. Elle est la plus fréquente et la plus sournoise.
Les quatre grandes familles
Dette de code : duplication, fonctions trop longues, nommage obscur, logique métier dispersée.
Dette d’architecture : couplage fort entre modules, monolithe qui empêche de déployer séparément, choix de base de données inadaptés à la charge actuelle.
Dette de tests : couverture faible sur les parcours critiques, tests instables, absence de tests de bout en bout.
Dette d’infrastructure : dépendances obsolètes, versions de framework en fin de support, déploiements manuels, observabilité insuffisante.
Les chantiers les plus lourds, comme une migration de framework ou un découpage d’architecture, relèvent souvent d’une roadmap technologique à part entière. Ce guide se concentre sur la dette courante, celle qui se gère au fil des sprints.
Comment rendre la dette technique visible ?
Une dette qui n’est pas dans le backlog n’existe pas pour la priorisation. La première étape consiste donc à l’inventorier au même endroit que le reste du travail, avec un format commun. Pour chaque élément, notez au minimum :
le symptôme observé, en langage compréhensible par un non-développeur ;
la zone concernée (module, service, parcours utilisateur) ;
les intérêts payés aujourd’hui : temps perdu, incidents, contournements ;
le risque si rien n’est fait : sécurité, conformité, panne, perte de données ;
l’estimation du coût de correction, même grossière (taille de t-shirt ou story points).
Le champ le plus important est celui des intérêts. C’est lui qui transforme une plainte d’équipe en argument de priorisation. Formulez-le en coût du retard : « chaque évolution du module de facturation prend environ deux jours de plus que nécessaire, et nous en faisons une par sprint », ou « ce composant a causé trois incidents ce trimestre ». La notion de coût du retard est au cœur de la méthode WSJF et s’applique très bien ici.
Le moment naturel pour alimenter et mettre à jour cet inventaire est la réunion de backlog refinement : les développeurs y signalent la dette rencontrée pendant le sprint, et le product manager aide à qualifier son impact.
Prioriser avec la matrice impact × coût
Une fois la dette inventoriée, une grille simple suffit dans la plupart des cas. Elle croise deux axes : l’impact de la dette sur la vitesse de livraison ou le niveau de risque (axe vertical), et le coût de correction (axe horizontal). C’est une déclinaison de la matrice valeur/effort, adaptée à la dette.
Quadrant | Impact | Coût | Décision |
|---|---|---|---|
À corriger maintenant | Fort | Faible | Prochain sprint, sans débat |
À planifier | Fort | Élevé | Initiative dédiée, découpée et datée |
Opportuniste | Faible | Faible | Règle du boy-scout, au fil de l’eau |
Accepter / surveiller | Faible | Élevé | Documenter, réévaluer chaque trimestre |
Quelques précisions pour bien utiliser la grille :
Évaluez l’impact au regard de la roadmap. Une dette dans un module que la roadmap va fortement solliciter au prochain trimestre voit son impact grimper, même si elle est gênante aujourd’hui seulement de temps en temps.
Le quadrant « À planifier » demande un découpage. Un chantier de six semaines doit être fractionné en étapes livrables, chacune apportant un gain mesurable, sinon il ne sera jamais arbitré en sa faveur.
La règle du boy-scout consiste à laisser le code un peu plus propre qu’on l’a trouvé. Elle suffit pour la dette opportuniste, à condition de rester dans le périmètre de la tâche en cours.
Accepter une dette est une décision légitime. L’important est qu’elle soit consciente, écrite, et revue périodiquement.
Pour intégrer la dette dans un classement unique avec les fonctionnalités, rattachez-la à un objectif (vitesse de livraison, fiabilité, sécurité) et scorez-la avec la même méthode que le reste. Le guide pour bien prioriser son backlog compare les méthodes possibles.
Combien de capacité consacrer à la dette technique ?
Il n’existe pas de chiffre universel, mais quelques règles empiriques reviennent souvent dans les équipes produit. Elles sont à ajuster selon l’âge du produit et l’état du code.
Réserver une part fixe de chaque sprint. Une fourchette de 15 à 20 % de la capacité est un point de départ courant. Elle est protégée : on ne la sacrifie pas au premier imprévu commercial.
Moduler selon l’état du système. Un produit récent peut descendre vers 10 % ; un produit ancien avec des incidents fréquents peut monter temporairement à 30 % ou plus, le temps de revenir à un niveau soutenable.
Financer les gros chantiers comme des initiatives. La dette du quadrant « À planifier » ne tient pas dans une réserve de 20 % : elle doit apparaître dans la roadmap, avec un objectif et une date.
Éviter le « sprint de nettoyage » ponctuel. Il donne bonne conscience mais ne change pas le rythme d’accumulation, et il est le premier annulé quand une échéance approche.
Cette réserve doit figurer dans votre calcul de capacité dès le départ, comme le détaille le guide de planification de capacité. Une équipe qui planifie 100 % de sa capacité sur des fonctionnalités a, de fait, décidé de ne jamais rembourser sa dette.
Ne créez pas de « voie spéciale » opaque où la dette est traitée à l’écart de la priorisation. Elle finit toujours par être désinvestie au premier arbitrage difficile. La dette doit être visible dans le même backlog et défendue avec les mêmes arguments que le reste.
Comment convaincre les parties prenantes business ?
Les directions commerciales ou générales ne sont pas hostiles à la dette technique ; elles ne comprennent simplement pas ce qu’elles achètent. « Refactoriser le module de paiement » ne dit rien. Traduisez chaque sujet en conséquences qui les concernent :
Délai de mise sur le marché : « les évolutions de la facturation prennent deux fois plus de temps que les autres ; les trois demandes clients en attente sortiront plus vite après ce chantier. »
Risque : « cette librairie n’est plus maintenue ; une faille découverte demain nous laisserait sans correctif. »
Coût récurrent : « l’équipe perd environ deux jours par sprint sur des contournements, soit l’équivalent d’une fonctionnalité par trimestre. »
Qualité perçue : « ce composant est à l’origine de la majorité des tickets de support sur l’export. »
Présentez ensuite un choix, pas une demande : « voici ce que nous livrons avec 20 % de capacité sur la dette, voici ce que nous livrons sans, et voici ce que cela coûtera dans six mois ». Les arbitrages explicites sont beaucoup mieux acceptés que les ralentissements inexpliqués.
Quels indicateurs suivre ?
Mesurer la dette elle-même est difficile ; mesurer ses effets l’est beaucoup moins. Choisissez trois ou quatre indicateurs, suivis dans la durée, plutôt qu’un tableau de bord exhaustif. Les KPI produit classiques peuvent être complétés par :
le lead time : le délai entre le début du travail sur un ticket et sa mise en production ;
la fréquence de déploiement et le taux d’échec des changements, deux des indicateurs popularisés par le programme de recherche DORA ;
le nombre d’incidents en production par mois, et leur temps de résolution ;
la part de capacité consommée par le travail non planifié (bugs, urgences, contournements) ;
l’ancienneté moyenne des éléments de dette dans le backlog ;
la part réelle de chaque sprint consacrée à la dette, comparée à la part prévue.
Si le lead time baisse et que le travail non planifié recule alors que vous investissez régulièrement dans la dette, vous avez vos arguments pour le prochain arbitrage.
Gérer la dette technique dans RoadmapHero
Dans RoadmapHero, la dette peut vivre dans le même backlog que les fonctionnalités, avec un type de ticket et un workflow dédiés. Le HeroScore permet de la scorer avec les mêmes critères pondérés (objectifs, effort, confiance) que le reste du backlog, et le pilotage de la capacité des sprints aide à protéger la part réservée. Le tableau de bord de santé du backlog signale aussi l’ancienneté des tickets, utile pour repérer la dette oubliée. Vous pouvez créer un compte gratuitement pour tester cette organisation.
Questions fréquentes
Qu’est-ce que la dette technique en termes simples ?
La dette technique est le coût futur des raccourcis pris lors du développement d’un logiciel. Comme une dette financière, elle permet d’aller plus vite au départ, mais elle génère des intérêts : chaque modification ultérieure devient plus lente, plus risquée ou plus coûteuse. Elle peut concerner le code, l’architecture, les tests ou l’infrastructure, et elle n’est pas forcément une erreur si elle est choisie et suivie.
Comment prioriser la dette technique face aux nouvelles fonctionnalités ?
Inscrivez la dette dans le même backlog que les fonctionnalités, estimez son coût du retard (temps perdu, incidents, risque) et scorez-la avec la même méthode. Classez-la ensuite avec une matrice impact sur la livraison ou le risque contre coût de correction. En complément, réservez une part fixe de chaque sprint à la dette pour qu’elle ne soit pas toujours repoussée.
Quel pourcentage d’un sprint consacrer à la dette technique ?
Il n’y a pas de norme, mais une règle empirique fréquente consiste à réserver entre 15 et 20 % de la capacité de chaque sprint. Un produit jeune peut se contenter d’environ 10 %, alors qu’un produit ancien avec beaucoup d’incidents peut monter temporairement à 30 %. Les chantiers lourds doivent être financés à part, comme des initiatives de la roadmap.
Comment expliquer la dette technique à un dirigeant ?
Parlez de conséquences business, pas de qualité de code : délai de mise sur le marché, risque de sécurité ou de panne, temps perdu chaque sprint, tickets de support générés. Chiffrez les intérêts, même approximativement, puis présentez un choix explicite entre plusieurs scénarios de capacité. Un dirigeant accepte plus facilement un arbitrage clair qu’un ralentissement inexpliqué des livraisons.
Qui est responsable de la dette technique, le PM ou l’équipe tech ?
Les deux. L’équipe technique identifie la dette, estime son coût de correction et alerte sur les risques. Le product manager intègre ces éléments à la priorisation, arbitre avec les fonctionnalités et défend la capacité réservée auprès des parties prenantes. Une dette gérée par la seule équipe technique, sans visibilité produit, finit généralement par être sacrifiée.