Dans les couloirs, elle circule comme une rumeur. “On a de la dette.” Parfois c’est un soupir, parfois une excuse, parfois une menace. La dette technique est devenue ce mot-valise qui permet de tout expliquer — un délai, un incident, une équipe qui n’ose plus toucher au code. Mais derrière le jargon, il y a une réalité très simple : la dette technique, c’est du business différé. Une entreprise a emprunté du temps et de la qualité à son futur pour livrer plus vite, survivre à une urgence, répondre à un client, ou simplement tenir une date. Tant que le prêt est piloté, tout va bien. Quand il ne l’est plus, les intérêts s’emballent — et c’est l’organisation entière qui ralentit.
Le problème, c’est que la dette technique est souvent traitée comme un sujet technique. Comme si elle ne concernait que “les devs”, le cloud, un framework ou un refactoring. Or la dette technique est d’abord un phénomène économique : elle se manifeste par une perte de vitesse, une hausse des incidents, une incapacité à faire évoluer le produit. Et à ce stade, ce n’est plus un sujet IT : c’est un sujet de direction.
Un impôt invisible sur chaque nouvelle fonctionnalité
Le signe le plus clair n’est pas un diagramme d’architecture. C’est la friction. Chaque changement devient un parcours du combattant. Une fonctionnalité “simple” finit en sprint complet. Une correction “rapide” déclenche deux régressions. Les déploiements deviennent des cérémonies. Les équipes vivent avec une phrase qui revient comme un refrain : “Attention, ce module est sensible.”
Cette sensation d’un système qui “vibre” au moindre toucher a un coût très concret : le time-to-market se dégrade, la roadmap se décale, la qualité perçue baisse, la confiance des métiers s’érode. Et plus le système ralentit, plus la tentation est forte d’accélérer… en reprenant de la dette. C’est la spirale classique : on compense le ralentissement par de nouveaux raccourcis qui aggravent le ralentissement.
Le grand malentendu : la dette n’est pas “du code moche”
On a tendance à associer dette technique et code. C’est réducteur. La dette se loge partout où l’entreprise a “fait tenir” au lieu de construire durablement :
- des dépendances non mises à jour, des composants en fin de support, des CVE qui s’accumulent ;
- des déploiements manuels, des environnements non reproductibles, des procédures au lieu de pipelines ;
- une architecture trop couplée, impossible à faire évoluer sans effet domino ;
- une base de données devenue un goulot d’étranglement, des migrations repoussées, de la donnée incohérente ;
- un monitoring incomplet, des alertes qui crient pour rien, des incidents sans RCA ;
- et, plus insidieux encore, une dette de gouvernance : pas de backlog de dette, pas de règle, pas de budget, donc pas de pilotage.
La dette technique, ce n’est pas ce qu’on n’aime pas. C’est ce qui réduit la capacité future à livrer.
Mesurer : la dette doit passer du ressenti au tableau de bord
Si la dette reste une impression — “on en a beaucoup”, “le legacy est horrible” — elle ne sera jamais priorisée. Le produit priorise ce qu’il peut expliquer, chiffrer, défendre. La dette doit donc se traduire en indicateurs lisibles par une direction : impact client, impact delivery, risque, coût.
La méthode la plus efficace n’est pas une grille sophistiquée. C’est un scoring simple, qui oblige à nommer ce qui fait mal.
Imaginez un inventaire par périmètre (un service, un domaine, un module critique) et, pour chacun, une note de 0 à 5 sur quatre axes d’“intérêts” :
- Expérience client : bugs visibles, lenteurs, indisponibilités, irritants.
- Vitesse de delivery : lead time, retours arrière, rework, difficulté à livrer.
- Opérations : incidents récurrents, astreintes, MTTR, fragilité des déploiements.
- Sécurité & conformité : versions EOL, vulnérabilités, traçabilité, exigences réglementaires.
Puis, en face, un cinquième axe qui change tout : le coût de remédiation (effort, complexité, dépendances, risques de migration).
On obtient alors deux scores distincts : le coût mensuel (les intérêts) et le coût de remboursement (le principal). C’est trivial, mais puissant : la discussion sort de “c’est sale” pour entrer dans “ça coûte tant” et “ça rapportera tant”.
La crédibilité se gagne avec des preuves, pas avec des opinions
Pour que ce scoring ne devienne pas un débat d’ego, on l’ancre sur des faits :
- fréquence des incidents et temps de rétablissement ;
- taux de rollback, de hotfix, de régressions ;
- temps moyen pour livrer un changement sur ce périmètre ;
- volume d’alertes sécurité et dépendances en fin de support ;
- ratio “run” vs “change” : combien d’énergie dépensée à maintenir vs construire.
L’objectif n’est pas la perfection métrologique : c’est la lisibilité. Quand un directeur produit voit noir sur blanc que tel composant “mange” 30% du temps d’une équipe en correctifs et retarde les features, la dette devient un sujet de pilotage.
Prioriser : la dette se gère comme un portefeuille
Le grand piège est connu : transformer la dette en croisade. Tout devient dette, tout devient urgent, et l’organisation s’épuise. La priorisation doit être implacablement business : on traite d’abord ce qui fait monter les intérêts.
Une lecture simple permet d’éviter les guerres de religion :
- Dette bloquante : elle empêche le produit d’évoluer (architecture qui interdit une fonctionnalité clé, pipeline absent, base EOL).
- Dette toxique : elle alimente incidents et stress, sans toujours bloquer, mais elle empoisonne.
- Dette cosmétique : elle gêne, elle irrite, mais son coût réel est faible. Celle-ci se documente, se surveille, mais ne dicte pas la roadmap.
Les organisations qui réussissent ne sont pas celles qui “nettoient” le plus, mais celles qui réduisent les intérêts le plus vite.
Rembourser sans arrêter : la stratégie du “continuity-first”
La question qui obsède les directions est légitime : “Si on rembourse, est-ce qu’on doit stopper le produit ?” La réponse est non, à condition d’abandonner le fantasme de la refonte totale.
On ne rembourse pas la dette technique comme un chantier qu’on fermerait derrière soi. On la rembourse comme une stratégie en flux continu.
Réduire d’abord les intérêts
Avant de viser la cathédrale, on s’attaque à ce qui rend chaque journée plus facile :
- automatiser une partie du build/test/deploy ;
- améliorer l’observabilité (logs structurés, métriques, traces) ;
- traiter les incidents récurrents avec des actions structurelles ;
- mettre des garde-fous (feature flags, canary, rollback) ;
- sécuriser les composants les plus exposés (EOL, CVE critiques).
Ces gestes ne “refont” pas le système, mais ils le rendent respirable. Et un système qui respire permet de rembourser sans se suicider.
Rénover par tranches : remplacer sans big bang
La refonte big bang est séduisante parce qu’elle promet une libération. En pratique, elle ressemble souvent à un arrêt masqué : on gèle, on réécrit, on dérive, et on revient au point de départ… avec deux systèmes à maintenir.
L’alternative est plus sobre : isoler, encapsuler, migrer progressivement, jusqu’à ce que l’ancien périmètre s’éteigne. Une façade, une extraction de domaine, un basculement du trafic, puis un décommissionnement. C’est moins spectaculaire, mais c’est ce qui protège la continuité business.
Fixer un budget de dette : la discipline qui change tout
Sans budget, la dette est toujours repoussée “après”. Et “après”, c’est jamais.
Les entreprises qui progressent fixent un budget stable : une part de capacité par équipe, ou une équipe plateforme qui industrialise, plus un quota de dette dans chaque sprint. Le chiffre varie, mais la règle est la même : la dette doit avoir une place contractuelle dans la planification.
Le pacte produit : transformer la dette en engagement commun
C’est ici que tout se joue. Tant que la dette est “un sujet technique”, elle est structurellement perdante face aux features. Le vrai levier est un pacte produit, un accord explicite entre Produit, Tech et Direction.
Un pacte solide contient cinq éléments :
- Une définition commune : la dette est ce qui crée de la friction et du risque mesurable.
- Un backlog dette gouverné : items décrits, scorés, priorisés, visibles.
- Des règles de traitement : incident récurrent = RCA + action structurelle planifiée ; dépendance EOL = plan sous un délai donné.
- Un indicateur d’intérêts mensuel : charge de correctifs, incidents, lead time ; si ça baisse, on gagne.
- Un arbitrage trimestriel explicite : quelle part pour la croissance, la stabilité, la dette.
Ce pacte évite les procès d’intention. Il retire aux équipes la nécessité de “cacher” du refactoring dans des user stories. Il donne au produit un langage pour accepter la dette quand elle est utile, et la rembourser quand elle devient dangereuse.
La conclusion qui dérange : vous n’aurez jamais zéro dette, et c’est très bien
Chercher “zéro dette” est un objectif naïf. Une entreprise qui innove prend forcément des raccourcis. La question n’est pas d’éliminer la dette, mais de la rendre soutenable : des intérêts sous contrôle, une capacité de changement préservée, une architecture qui ne punit pas chaque évolution.
La dette technique n’est pas un problème de développeurs. C’est un indicateur de maturité de pilotage. Les organisations qui gagnent ne sont pas celles qui prétendent ne pas en avoir. Ce sont celles qui savent la mesurer, la prioriser, et la rembourser — sans arrêter de faire tourner la boutique.
En savoir plus sur GDL T&C
Subscribe to get the latest posts sent to your email.