Dette technique : ce qu’elle est, ce qu’elle n’est pas

Le test opérationnel

La mauvaise question à propos de la dette technique est « depuis combien de temps ce code est-il là ? » La bonne question est différente : « est-ce que cela ralentit votre capacité à modifier le système dans le contexte où vous êtes aujourd’hui ? » Si la réponse est non, il ne s’agit pas de dette technique au sens opérationnel du terme. Si la réponse est oui, c’en est, peu importe la date d’écriture, l’auteur ou l’intention d’origine.

Ce test change la perspective en profondeur. La dette technique mesure la résistance au changement dans le présent, bien plus qu’elle ne juge moralement du code écrit par le passé. Un système vieux de dix ans, construit avec des technologies que plus personne n’utilise, peut très bien ne pas être de la dette si l’équipe le connaît bien et peut le modifier sans friction. À l’inverse, un système écrit six mois plus tôt par des développeurs compétents peut porter une dette lourde si ses modules sont si couplés que chaque changement a des conséquences imprévisibles.

Le spectre : du micro au systémique

La dette technique se manifeste à différents niveaux, avec des impacts différents, et les confondre conduit à intervenir au mauvais endroit.

Au niveau le plus fin, il y a la dette mesurable : chaque petite modification prend plus de temps que prévu parce que les fonctions portent trop de responsabilités, l’imbrication est profonde, les comportements se chevauchent. En langage technique, on parle de complexité cyclomatique élevée ; en langage opérationnel, cela veut dire que le même changement, qui prendrait une heure ailleurs, en prend ici une journée, parce qu’il est difficile de savoir où toucher sans casser autre chose. Des outils comme SonarQube la suivent en continu. L’avantage de cette forme de dette, c’est qu’elle est visible et quantifiable : on peut en mesurer la tendance dans le temps et agir avant qu’elle ne s’installe.

Un cran au-dessus, il y a la dette liée à la violation systématique des standards de code, à ne pas confondre avec le style personnel d’un développeur, qui reste affaire de préférence. Le problème, ici, c’est l’absence de conventions partagées, installée avec le temps : chaque développeur qui arrive sur la zone doit reconstruire le contexte depuis zéro, parce que les règles implicites changent d’un fichier à l’autre. Le coût est surtout cognitif, il allonge le temps de lecture, affaiblit le raisonnement collectif et ralentit la revue de code.

Au niveau des modules apparaît la dette due au couplage excessif : un composant qui dépend de trop d’autres, ou que trop de parties du système appellent, devient un goulot d’étranglement architectural. En pratique, chaque modification sur ce module oblige à retracer à la main toutes les dépendances concernées. Quel est l’impact ? Qu’est-ce qui risque de casser ailleurs ? C’est pour cette raison que certaines zones du système, personne ne veut y toucher, que les mises en production doivent être synchronisées et que les tests d’intégration deviennent fragiles à mesure que les surfaces de contact se multiplient.

Au sommet se trouve la dette architecturale : les abstractions fondamentales du système ne reflètent plus la façon dont fonctionne l’entreprise. Les bounded contexts ont été dessinés quand l’entreprise ne gérait qu’un tiers de ses processus actuels, et la structure des données modélise des flux qui n’existent plus. C’est la dette la plus coûteuse et la plus difficile à voir. Elle se traduit en une résistance diffuse à tout changement stratégique, sans qu’aucune erreur du code ne la trahisse.

Ce qui n’est pas de la dette technique

Employer le terme à la légère produit des discussions techniques qui ne mènent nulle part. Quatre catégories sont régulièrement confondues avec la dette, classées par type de contrainte :

• Un bug : c’est une erreur de comportement, le système fait quelque chose de travers. La dette technique, elle, est une contrainte structurelle : le système fonctionne, mais il est difficile à modifier. La distinction a des conséquences concrètes, car elle appelle des approches différentes, des priorités différentes, et souvent des équipes différentes. Un système très endetté génère davantage de bugs, parce que les dépendances cachées multiplient les effets de bord, mais bug et dette restent deux phénomènes distincts.
• Une fonctionnalité manquante : ne pas construire une fonctionnalité relève d’un choix produit. La dette technique concerne la structure du système existant ; ce qu’il faut construire relève d’une autre décision.
• Une technologie « ancienne » : l’âge d’une technologie n’a aucune importance en soi. PostgreSQL sur un serveur de 2012 reste sans dette tant que le système est modifiable et stable. Java sur un service critique reste sans dette tant que l’équipe en a la pleine maîtrise et livre à un rythme correct. La dette apparaît quand cette technologie bloque l’évolution : elle empêche l’intégration avec de nouveaux systèmes, exige des compétences de plus en plus rares, ou introduit des contraintes qui renchérissent chaque changement.
• Le style personnel : qu’un collègue nomme ses variables autrement que le reste de l’équipe relève de la préférence individuelle. Cela devient de la dette uniquement quand cela viole systématiquement les standards partagés par l’équipe, car le coût cognitif collectif grimpe alors de façon mesurable et réelle.

Le principe qui unifie ces distinctions est déjà présent dans le test initial : la dette est toujours relationnelle. Elle existe dans le rapport entre le code et le changement que le système doit absorber aujourd’hui ; le code pris isolément ne suffit jamais à la définir. C’est pour cela que le même module peut être de la dette pour une équipe et un atout pour une autre, ou de la dette à trente personnes sans l’être à six.

Les quatre types de Fowler

Martin Fowler a décrit la dette à travers une matrice qui croise deux axes : délibéré/accidentel et imprudent/prudent. Le détail se trouve dans son Technical Debt Quadrant ; ce qui nous intéresse ici, c’est la distinction opérationnelle que cette matrice rend possible.

La dette délibérée et prudente, c’est « on fait comme ça pour l’instant, on sait qu’il faudra réécrire ». C’est un outil légitime : on choisit consciemment un raccourci à un moment précis, avec l’intention de le rembourser quand le contexte le permettra. La dette accidentelle et prudente fonctionne à l’inverse : on découvre après coup qu’une décision prise de bonne foi était la mauvaise. Cela arrive dans tout système qui grandit ; c’est la dette d’une connaissance qui mûrit avec le temps.

En pratique, la distinction entre délibéré et accidentel compte moins qu’on ne le pense. Le vrai problème, c’est la dette imprudente : celle qui s’accumule sans qu’on en ait conscience, qui se superpose en couches jusqu’à ce que plus personne ne sache estimer le coût d’un changement. C’est cette forme-là, plus que les autres, qui paralyse les équipes.

Pourquoi elle est difficile à voir

La dette technique n’apparaît dans aucun rapport, n’a pas de ligne au bilan, ne déclenche aucune alerte. Elle se manifeste comme un bruit de fond : des estimations qui dérapent sans cesse, des bugs qui reviennent après avoir été corrigés, des développeurs qui disent « mieux vaut ne pas toucher à cette partie-là ». Le temps que ces signaux deviennent lisibles, la dette est déjà installée depuis des mois.

Un mécanisme organisationnel aggrave la situation. Ceux qui accumulent la dette ne sont souvent pas ceux qui la paient : l’équipe qui prend le raccourci pour tenir le délai de mars n’est pas celle qui assurera la maintenance deux ans plus tard. Ce décalage structurel vient de la façon dont les responsabilités et les incitations se répartissent dans le temps. Les organisations optimisent pour le court terme parce que les coûts de la dette sont différés et difficiles à attribuer.

Le mécanisme psychologique est tout aussi concret. La dette s’accumule par petites touches, des incréments qui paraissent toujours gérables sur le moment. Chaque décision qui la crée semble raisonnable dans son contexte : on est pressé, le contexte n’est pas totalement clair, la solution simple fonctionne pour l’instant. Le problème, c’est l’absence d’un moment dédié à mesurer l’effet cumulé de toutes les décisions prises dans des conditions semblables. Les raccourcis restent inévitables ; ce qui distingue les organisations qui gèrent bien leur dette, c’est qu’elles s’arrêtent périodiquement pour faire le point sur le chemin parcouru.

Une fois la dette à l’œuvre, les signaux se répartissent sur trois niveaux :

• Dans le flux quotidien : les estimations sont systématiquement fausses et l’écart grandit sprint après sprint, le CI/CD exige une intervention manuelle, un nouveau développeur met des mois avant de travailler en autonomie. Personne ne connaît vraiment le système dans son ensemble : chaque zone appartient implicitement à quelqu’un, et quand cette personne n’est plus là, le travail s’arrête.
• Dans la livraison : les mises en production deviennent des événements à risque, concentrées sur certains jours et certains horaires, la roadmap devient si instable que le métier a arrêté de demander des dates, et recruter des développeurs n’accélère rien. Chaque fonctionnalité est plus lente à livrer que la précédente : elle doit interagir avec une surface de code de plus en plus vaste et fragile, un phénomène étranger à la productivité de l’équipe.
• Dans les chiffres que voit le métier : l’équipe corrige plus qu’elle ne construit, le taux de bugs grimpe pendant que les fonctionnalités ralentissent, les développeurs seniors partent en invoquant leur frustration. Deux signaux qu’un CEO ou un CFO peuvent lire directement : la facture cloud grimpe sans lien avec le trafic, et le coût de chaque nouvelle fonctionnalité dépasse celui de la précédente sans raison produit.

Ce qu’elle coûte

Les données agrégées convergent : selon McKinsey, des DSI de grandes entreprises (plus d’un milliard de chiffre d’affaires, dans la finance et la tech) estiment que la dette technique représente entre 20 et 40 % de la valeur de leur patrimoine technologique, avec un impact direct de 10 à 20 % sur le budget consacré aux nouveaux produits. Des études sectorielles estiment qu’une part importante du temps des développeurs part dans la gestion de la complexité accumulée, au détriment de la création de valeur nouvelle : une proportion difficile à chiffrer précisément, mais que les équipes de terrain jugent systématiquement significative. Ce sont des estimations sur de larges échantillons ; dans la pratique, l’écart varie fortement selon la zone du système et la phase de croissance.

Le chiffre le plus utile reste le chiffre opérationnel : combien de temps faut-il pour faire une petite modification dans une zone que vous connaissez bien ? Si la réponse normale devrait être « quelques heures » et que la réponse réelle est « une semaine, le temps de comprendre comment les effets se propagent », cet écart se multiplie à chaque changement futur dans cette zone. C’est ce coût concret, mesuré sur le prochain changement, qui doit guider la décision. Pour la définition opérationnelle du coût du changement et la méthode de calcul, voir notre article sur comment mesurer la dette technique.

Le ralentissement s’aggrave avec le temps parce que la relation entre complexité et vitesse n’est pas linéaire : au-delà d’un certain seuil, chaque modification demande un effort disproportionné par rapport à sa valeur. Ajouter de la complexité à un système déjà complexe coûte bien plus que le double, parce que chaque nouvel élément interagit avec tout ce qui existe déjà. Ajouter des développeurs à un système dans cet état augmente d’abord la coordination nécessaire, avant même d’augmenter la capacité de production. Quand le coût d’ajouter une fonctionnalité dépasse sa valeur business, la dette cesse d’être un problème technique pour devenir une contrainte stratégique.

Ce qu’il faut faire concrètement

Trois actions concrètes pour arrêter d’estimer et commencer à mesurer.

1. Mesurez le cycle time et le bug rate sur les 4 à 8 dernières semaines, avec des données concrètes en main. Le bug rate, c’est le nombre d’incidents ou de régressions par sprint. Pour la définition opérationnelle du cycle time et la différence avec le Lead Time for Changes de DORA, voir l’article sur comment mesurer la dette technique. Si vous n’avez pas ces données, demandez à l’équipe combien de temps a pris le dernier changement non trivial dans chaque zone critique du système. Les chiffres qui en sortent sont déjà un indicateur fiable.
2. Identifiez la zone où l’écart entre effort prévu et effort réel est le plus grand : c’est presque toujours là que se trouve le goulot d’étranglement, là où les estimations se trompent le plus, où les pull requests restent ouvertes le plus longtemps, où chaque mise en production fait monter l’angoisse. Ni la taille du module ni son ancienneté n’entrent en compte. Dans cette zone, la dette prélève déjà un loyer élevé chaque semaine.
3. Apportez un chiffre concret à votre prochaine conversation avec la direction : « cette intégration coûte X semaines contre Y prévues, parce qu’elle traverse ces 3 modules couplés ». Le coût du prochain changement concret convainc toujours davantage qu’une estimation globale de la dette totale. Le Consistency Impact Calculator aide à structurer cette mesure et à la traduire en argument que la direction sait lire.

Le regard de QMates

Notre point de départ, c’est de mesurer les effets : le cycle time et le bug rate. Un cycle time qui grimpe trimestre après trimestre sans hausse correspondante de la complexité des fonctionnalités, c’est presque toujours de la dette au travail. Un bug rate qui monte pendant que la vitesse de développement ralentit indique que le système résiste au changement. Quand les deux indicateurs se dégradent ensemble, la dette devient un fait opérationnel, confirmé par les deux mesures. Pour démarrer tout de suite, le Consistency Impact Calculator permet de structurer cette première mesure.

Les indicateurs seuls ne disent pas où agir. Notre méthode procède par zoom progressif : on part de l’effet agrégé pour descendre vers le goulot d’étranglement précis. Dans certaines organisations, le blocage se niche dans le micro : des fonctions à la complexité cognitive hors de contrôle, des modules sans tests que personne ne touche. Dans d’autres, il se loge dans le macro : des frontières d’équipes qui ne reflètent plus les flux métier, des architectures pensées pour une organisation qui n’existe plus. Le niveau où se situe le goulot d’étranglement ne se devine pas à l’avance ; il dépend de l’histoire propre à chaque organisation, et de la manière dont architecture, équipes et métier ont cessé d’évoluer ensemble.

Ce que nous trouvons presque toujours, ce sont des architectures dessinées à un moment précis de la croissance, qui ne reflètent plus le fonctionnement actuel de l’entreprise : des frontières de modules tracées quand l’équipe comptait six personnes et qui en compte vingt aujourd’hui, des structures de données qui modélisent des processus qui ont changé trois fois depuis, des abstractions qui avaient leur place et qui ne produisent plus que des contournements. Les développeurs sont compétents ; c’est le système qui a cessé d’être cohérent avec l’organisation qui le produit.

C’est pour cela que nous n’arrivons jamais avec une liste de refactorings à faire. Nous cartographions d’abord où la dette bloque le flux de valeur, puis nous agissons à cet endroit précis. Un effort bien exécuté sur le mauvais module ne change rien à la vitesse de livraison. C’est le principe qui guide notre approche du refactoring stratégique, et qui rejoint le Consistency Model : la bonne question est « le système est-il encore cohérent avec l’organisation qui le produit ? ».

La mauvaise question reste celle du début : depuis combien de temps ce code est-il là. La question opérationnelle, celle qui compte vraiment, est tout autre : combien coûtera le prochain changement que vous devez faire ? Si vous n’avez pas de réponse, vous venez de trouver votre point de départ.