Définition courte
Faiblesse de conception ou d'architecture d'un logiciel dont l'entreprise a décidé qu'elle serait traitée, et qui porte à ce titre un coût de remboursement et une place dans les priorités. Tant que cette décision n'est pas prise, la faiblesse reste un inconfort ou un risque latent.
Définition détaillée
Dans l'usage courant, le mot recouvre tout ce qu'un développeur regrette dans un code existant : un raccourci ancien, une architecture faible, une complexité accumulée, une bibliothèque obsolète. L'analogie financière y est purement descriptive — on parle de dette pour dire que quelque chose coûtera plus tard, sans qu'aucun créancier, aucune échéance ni aucun montant ne soient nommés.
Dans les articles de ce blog, le mot est réservé à ce qui a franchi une décision. Une faiblesse connue depuis des années, que personne n'a inscrite au programme, n'est pas une dette : elle n'a ni date, ni coût arbitré, ni responsable du remboursement. Elle le devient quand l'entreprise juge que son coût de portage dépasse son coût de traitement — parce qu'elle bloque une stratégie, ralentit fortement l'équipe, expose à un risque, dégrade la qualité perçue par le client, ou empêche un changement produit important.
L'usage terrain diverge nettement du sens retenu ici : sur le terrain, « on a de la dette » désigne un état permanent du système, et ne déclenche rien. Le sens retenu ici fait du mot un statut qui s'acquiert, pas un constat qui se répète.
Usage dans le domaine
Revue de priorisation entre un sujet produit et un sujet technique, argumentation d'un développeur devant un comité, décision d'entrée d'un sujet technique dans la roadmap, définition d'une stratégie de traitement distincte de la gestion quotidienne des bugs.
Synonymes et variantes
« la dette » en abrégé · « dette d'architecture » quand la faiblesse est structurelle · « inconfort technique » et « risque latent » pour l'état antérieur à la décision.
À ne pas confondre avec
- Défaut — écart entre le comportement attendu d'un logiciel et son comportement réel ; la dette n'a pas de comportement fautif visible, elle coûte à l'évolution.
- Politique zéro bug — régime qui interdit de conserver un défaut connu sans décision ; il porte sur les écarts de comportement, jamais sur les faiblesses de conception.
- Roadmap — vue des grands sujets engagés, préparés et possibles ; la dette technique n'y figure qu'après la décision de traitement.
- Dette de compréhension — écart entre ce qu'une équipe a produit et ce qu'elle sait de ce qu'elle a produit ; elle se paie en incapacité à décider quoi refondre, là où la dette technique se paie en travail de refonte.
- Refactoring — geste d'amélioration interne du code sans changement de comportement ; c'est un moyen de remboursement, pas la dette elle-même.
- Complexité essentielle — difficulté inhérente au problème traité, qu'aucun travail d'architecture ne supprime.
- Reconstructibilité — propriété d'un système qu'une équipe saurait refaire ailleurs à partir de ses contrats, de ses règles métier et de ses tests ; elle qualifie ce qu'on sait dire du système, pas la qualité de sa conception.
- Dette de compréhension — écart entre ce qu'un système fait et ce que l'équipe qui en répond sait expliquer ; elle porte sur la tête de ceux qui maintiennent, quand la dette technique porte sur l'état du code, et elle n'attend aucune décision pour exister.
Exemples
Une architecture faible, connue depuis longtemps, qui n'empêche personne de livrer : inconfort, pas dette.
La même architecture, le jour où elle bloque un chantier stratégique et que l'entreprise décide de la reprendre : dette, avec une place à trouver dans les priorités.
Ambiguïtés / débats
L'analogie financière est contestée : la dette suppose un emprunt volontaire, alors qu'une grande part de ce que le mot recouvre a été accumulée sans choix, par ignorance ou par contrainte de délai. Certains proposent d'en réserver l'emploi aux raccourcis délibérés.
Second flottement, plus opératoire : faut-il compter la dette technique dans la capacité de l'équipe ou dans les sujets de la roadmap. Les deux réponses circulent, et elles n'engagent pas le même arbitre.