Redonner du sens à nos compromis pour mieux construire ensemble.
Le terme “dette technique” est partout… et il ne veut plus rien dire.
Il recouvre aussi bien un hack mal ficelé qu'un choix technologique assumé, ou un modèle métier encore instable.
Ce flou sémantique nuit à la qualité comme à la collaboration. Il empêche les équipes de faire des arbitrages clairs, et rend toute discussion avec le métier confuse ou impossible.
Cet article tente de proposer une distinction simple et structurante afin de mieux comprendre ce que nous faisons, ce que nous décidons… et ce que nous laissons s'accumuler.
La métaphore de la dette
Le concept de la “dette” a été introduit en 1992 par Ward Cunningham, pour expliquer une réalité simple : parfois, on doit livrer du code alors qu'on n'a pas encore bien compris le domaine. Ce code fonctionnera, mais il sera partiellement mal conçu — et devra être corrigé plus tard. C'est comme une dette : on gagne du temps maintenant, mais on devra “payer des intérêts” jusqu'à ce qu'on refactore.
“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, OOPSLA 1992
Et surtout, Ward insiste sur un point que beaucoup ont oublié :
“I'm never in favor of writing code poorly. I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.”
— Ward Explains the Debt Metaphor (2009)
En d'autres termes, la “dette” chez Ward n'a jamais été une excuse pour écrire du mauvais code. Et celle-ci n'a pas été présentée comme technique !
De plus, il s’agissait d’une dette “négociée” : un compromis conscient, explicite, pris pour livrer plus vite en assumant de revenir corriger plus tard.
Dette d'alignement conceptuel
J'écris cet article en m'appuyant sur mon approche orientée Domain-Driven Design (DDD). Dans ce cadre, la modélisation se fait directement avec le métier, via l'Ubiquitous Language (UL).
Si l'on peut concevoir en collaboration avec le métier, alors la dette est parfaitement visible du métier lui-même, qui comprend très bien qu'un modèle encore partiel devra évoluer. Livrer tôt revient donc à assumer ensemble un compromis :
- on met en production une version simplifiée,
- on sait qu'il faudra y revenir,
- et le métier comprend naturellement pourquoi.
C'est ce que Ward Cunningham appelait la dette et que j'appellerais ici la dette d'alignement conceptuel : un écart assumé et négocié entre la compréhension actuelle du domaine et le modèle qui en découle.
Tant qu’elle est visible et traitée rapidement, la dette d’alignement conceptuel ne pose aucun problème : elle fait même partie intégrante des approches agiles, qui assument de livrer tôt puis d’ajuster. Mais si on laisse s’accumuler les décalages sans jamais revenir sur les choix initiaux, le modèle se dégrade peu à peu, et ces écarts non corrigés finissent par produire les architectures confuses et rigides qu’on retrouve dans les systèmes legacy.
Autrement dit : la dette d’alignement est une force, à condition que le refactoring suive effectivement l’apprentissage.
Note : Même si l'on ne peut pas appliquer une approche DDD stricte — faute de pouvoir modéliser directement avec le métier, ou simplement parce qu'on ne connaît pas le DDD — cet article et les distinctions qu'il introduit peut déjà constituer une piste intéressante de réflexion et permettre de mieux qualifier nos compromis, de distinguer ce qui est choisi de ce qui est subi, et de rendre nos arbitrages plus clairs.
Dette technique
Il existe un autre type de compromis, différent de la dette d'alignement conceptuel : celui qui concerne nos outils et nos choix technologiques.
Rester sur une version ancienne d'un framework, repousser une migration, différer la mise à jour d'une dépendance critique : ce sont des décisions assumées, prises pour livrer plus vite ou réduire un coût immédiat.
Ces compromis techniques sont souvent les plus faciles à expliquer à un PO ou à un client. On peut expliquer le besoin, les contraintes, en négocier les échéances, et planifier leur résolution.
C'est pourquoi je propose de réserver ici le terme dette technique à ce sens strict: un compromis technologique conscient, lié à l'outillage, ou aux dépendances — pris temporairement, avec l'intention explicite de corriger plus tard.
Exemple typique :
- Rester sur React 17 le temps de finaliser la refonte du design system, en prévoyant la migration ensuite.
- Reporter la mise à jour d'un framework côté serveur pour respecter un calendrier produit, tout en planifiant la migration dans le trimestre suivant.
La dette technique (stricte) est donc un arbitrage technique négociable.
Dette de qualité de code
J'en ai déjà parlé en début d'article: la métaphore de la dette n'a jamais été une excuse pour écrire du mauvais code. Et pourtant il arrive que l'on écrive du code fragile, illisible ou non testé.
Que ce soit par un choix conscient, mais aussi sous la pression du delivery ou encore par manque de maturité professionnelle.
C'est ce que j'appelle ici la dette de qualité de code. Une dette qui ne devrait tout simplement pas exister car elle relève du strict minimum professionnel attendu. Une dette non négociable avec métier.
Prenons une analogie concrète. Si vous faîtes venir chez vous un plombier pour réparer une fuite, vous n'attendez pas de discuter avec lui du fait qu'il doive souder correctement, utiliser des joints adaptés, et vérifier que ça ne fuit plus ! Ce n'est pas négociable: c'est le métier. De la même manière, un développeur n'a pas à négocier la lisibilité de son code ou l'existence de tests.
La dette de qualité, c'est donc tout ce qui n'aurait jamais dû exister et surtout tout ce qui ne peut être négocié avec le client ou le PO:
- du code fragile, illisible
- de la vraie duplication de code
- du code mort
- des bricolages techniques temporaires devenus permanents
- l'absence de tests
Note — Sur la responsabilité de la dette de qualité
En théorie, la dette de qualité ne devrait jamais exister : produire du code lisible, testé et cohérent fait partie du métier. En pratique, elle apparaît sous la pression du délai ou par manque de maturité, quand les développeurs renoncent progressivement à ce minimum professionnel.
La responsabilité est donc partagée : elle est individuelle, car chaque développeur a le devoir de ne pas céder à la facilité, et elle est collective, car l’organisation doit créer un cadre qui permette de tenir cette ligne.
Passif
En comptabilité, le passif désigne l'ensemble de ce que l'entreprise doit. Il inclut toutes les dettes, quelles qu'elles soient. Je propose donc d'adopter la même logique ici.
Le passif, c’est donc l’ensemble des dettes que porte un système :
- la dette d'alignement conceptuel,
- la dette technique,
- la dette de qualité de code
Chacune de ces dettes a une nature différente, mais elles s'additionnent toutes dans le passif global du logiciel et, comme en comptabilité, ce passif n'a rien de théorique: il pèse concrètement sur la capacité à faire évoluer le système.
Jeu de vocabulaire ?
On pourrait se dire que tout cela n’est qu’un jeu de vocabulaire. Mais la distinction entre dette d’alignement, dette technique, dette de qualité et passif change profondément la manière dont nous pouvons travailler ensemble.
Elle clarifie les discussions.
Quand tout est appelé “dette technique”, chacun comprend ce qu'il veut : un développeur pense à du code fragile, un architecte à une migration, un PO à une refonte métier. En posant des mots précis, on évite les malentendus et on rend les arbitrages possibles.
Elle trace une frontière nette entre ce qui est négociable et ce qui ne l’est pas.
Un modèle métier simplifié ou une migration différée peuvent être discutés avec le client et planifiés dans le temps. Mais un code lisible et testé ne se négocie pas : c’est la base de notre métier, comme un plombier ne négocie pas l’étanchéité de ses raccords.
Elle permet de rendre les dettes visibles.
Une dette assumée peut être consignée et suivie, comme une dette financière dans un bilan. Une dette non assumée tombe dans le passif, et s’accumule en silence. En distinguant les deux, on se donne la possibilité de cartographier notre passif, d’en évaluer le poids et d’orienter nos efforts de refactoring là où ils auront le plus d’impact.
Elle clarifie les responsabilités.
L’alignement conceptuel est une responsabilité partagée avec le métier. La dette technique relève d’arbitrages organisationnels. La dette de qualité engage directement les développeurs et leur professionnalisme.
En résumé.
Ce découpage permet de transformer une plainte floue — “il y a trop de dette technique” — en un constat précis, compréhensible et actionnable. Et c’est là que le langage change la pratique : parce que derrière les mots, il y a la capacité à mieux décider ensemble.
Un exemple concret
Dans une équipe agile proche de son métier, les choses se passent ainsi:
- Sur le modèle métier : tout le monde sait que l’implémentation des “contrats” est encore partielle. Quand une nouvelle fonctionnalité arrive pour laquelle on s'est rendu compte que la modélisation précédente n'était pas correcte, le métier comprend immédiatement pourquoi le développement de cette nouvelle fonctionnalité prendra un peu plus de temps : il n’y a rien à “expliquer”, puisque le décalage est déjà visible et partagé.
- Sur la migration de framework : le PO sait qu’il existe une mise à jour importante à prévoir. Il choisit consciemment de la repousser, en attendant une fenêtre plus propice dans la roadmap. Ce n’est pas un non-dit, c’est un arbitrage planifié.
- Sur la qualité du code : un module est instable car fragile et non testé. Ici, pas de négociation possible : l’équipe assume le temps nécessaire pour remettre d’aplomb cette partie du code. Ce correctif reste limité à ce périmètre précis, il n’est pas noyé dans le reste du passif.
Le vrai risque
Dans beaucoup d’organisations, la réalité est brutale : le code est tellement fragile, les versions tellement en retard, la façon de travailler tellement dégradée… que tout est déjà noyé dans un immense passif. Dans ce contexte, il impossible de distinguer clairement dette d’alignement, dette technique et dette de qualité : tout s’est accumulé sans être assumé, jusqu’à former un enchevêtrement indémêlable.
Face à cette situation, les équipes se concentrent généralement sur ce que les outils de qualité de code (Sonar, PMD, linters, ...) savent mesurer :
- le code fragile,
- la duplication,
- la couverture de tests,
- les fonctions trop complexes,
- les dépendances pas à jour, ou vulnérables...
Et c’est bien là le problème : ces outils ne voient pas le modèle métier, ni l’alignement avec la réalité du domaine.
Attention : cela ne veut pas dire que cette correction est inutile! Au contraire : il s’agit de dette de qualité de code, et cette dette n’aurait jamais dû exister. Elle doit être traitée, car elle fragilise le système et ralentit tout le reste.
Mais il faut être lucide : dans la plupart des systèmes legacy, une grande partie du “plat de spaghetti” vient déjà d’un désalignement conceptuel accumulé au fil des ans. Et corriger seulement la dette de qualité ou quelques migrations techniques ne suffira pas à éliminer cette racine du problème.
En pratique, les équipes font ce qu’elles peuvent :
- elles surveillent la nouvelle dette de qualité,
- elles corrigent partiellement l’ancienne,
- mais la dette d’alignement conceptuel reste largement présente, parce qu’aucun outil ne sait l’indiquer.
Tant que nous appelons tout cela “dette technique”, nous risquons de rester focalisés sur ce que les outils savent mesurer, sans jamais adresser la dette la plus importante : celle qui touche au modèle lui-même, et qui était au cœur de la métaphore de Ward Cunningham.
Et si les développeurs ne comprennent pas ce sens originel, cette dette-là reviendra toujours, projet après projet, quelle que soit la technologie utilisée ou la rigueur des outils de contrôle.
Conclusion
En repartant de la définition originelle de Cunningham, j’ai cherché à déconstruire l’usage fourre-tout du terme “dette technique”, qui s’est peu à peu éloigné de la métaphore.
En distinguant dette d’alignement conceptuel, dette technique, dette de qualité et passif, on redonne à la métaphore sa force explicative.
De plus, cela permet de la faire réapparaître clairement alors qu'elle était noyée dans le passif des systèmes legacy alors qu'elle est pourtant la plus déterminante pour l'avenir du logiciel.
