Dette technique : le coût caché
Partager
Dette technique :
Le coût caché du « On corrigera ça plus tard »
Dans chaque base de code, chaque architecture système et chaque processus de production se trouve une décision prise sous pression et jamais remise en question. Un contournement devenu permanent. Une solution temporaire qui a survécu au chef de projet qui l'a approuvée. Un commentaire qui dit // TODO : corriger correctement — daté d'il y a trois ans.
C'est la dette technique. Et contrairement à la dette financière, elle n'apparaît sur aucun bilan comptable avant que le paiement des intérêts ne soit exigé.
## 01. CE QU'EST VRAIMENT LA DETTE TECHNIQUE
Le terme a été inventé par l'ingénieur logiciel Ward Cunningham en 1992, mais le concept s'applique bien au-delà du code. La dette technique est le coût cumulé du choix d'une solution plus rapide ou plus simple aujourd'hui au lieu de la meilleure solution, qui prendrait plus de temps.
Comme la dette financière, elle comprend un capital et des intérêts. Le capital correspond au travail de refonte nécessaire pour mettre en œuvre la bonne solution. Les intérêts sont le coût continu du contournement de la solution de facilité — développement plus lent, maintenance plus difficile, systèmes plus fragiles, taux de défauts plus élevés.
La différence cruciale avec la dette financière : la dette technique s'accumule silencieusement. Vous ne recevez pas de relevé mensuel. Les intérêts s'accumulent de manière invisible sous forme de vélocité ralentie, d'augmentation du nombre de bugs, de temps d'intégration plus longs pour les nouveaux ingénieurs et de systèmes de plus en plus difficiles à modifier.
## 02. COMMENT LA DETTE TECHNIQUE S'ACUMULE
La dette technique ne résulte généralement pas de la paresse ou de l'incompétence. Elle résulte de décisions rationnelles prises dans des contraintes réelles. L'échéance était réelle. Le budget était fixe. Le MVP devait être livré. Le contournement était la bonne décision — à l'époque. Le problème est ce qui se passe ensuite : l'échéance passe, la pression se déplace vers la fonctionnalité suivante, et personne ne revient corriger la solution de facilité.
## 03. LES QUATRE TYPES DE DETTE TECHNIQUE
Toutes les dettes techniques ne se valent pas. Le quadrant de la dette technique de Martin Fowler identifie quatre types basés sur deux axes : délibéré vs involontaire, et imprudent vs prudent.
« Nous savons que ce n'est pas correct — nous le corrigerons après le lancement »
La forme la plus gérable. Un compromis conscient, pris en pleine connaissance de cause du coût et avec un plan pour le rembourser. Acceptable lorsque le remboursement a réellement lieu. Dangereux lorsque « après le lancement » devient « jamais ».
« Nous n'avons pas le temps de le concevoir correctement »
Des raccourcis pris sans reconnaître ni planifier les conséquences. Souvent déguisés en pragmatisme. S'accumule le plus rapidement car il n'y a aucune intention de rembourser — la dette n'est même pas reconnue comme telle.
« Maintenant, nous savons comment nous aurions dû le faire »
Une dette contractée par un véritable manque de connaissances au moment de la décision. L'équipe a fait de son mieux avec ce qu'elle savait — la meilleure approche n'est devenue claire qu'avec l'expérience. Courant dans les domaines techniques en évolution rapide.
« Que voulez-vous dire par architecture en couches ? »
Une dette due à l'ignorance de ce à quoi ressemble une bonne pratique. L'équipe n'a pas réalisé qu'elle créait de la dette. La plus coûteuse à découvrir car elle est souvent profondément ancrée avant que quelqu'un ne l'identifie.
## 04. LES SYMPTÔMES — À QUOI RESSEMBLE LA DETTE TECHNIQUE EN PRATIQUE
La dette technique se fait rarement remarquer. Elle apparaît indirectement, à travers des symptômes que les équipes attribuent souvent à d'autres causes :
| Symptôme | Ce qu'il signale vraiment |
|---|---|
| Les changements « simples » prennent des semaines | Couplage élevé — tout dépend de tout le reste |
| Les nouveaux ingénieurs mettent des mois à être productifs | Aucune documentation, modèles incohérents, système trop complexe à apprendre rapidement |
| Les corrections de bugs introduisent de nouveaux bugs | Architecture fragile, absence de tests, contournements construits sur des contournements |
| Personne ne veut toucher au Module X | Zone à forte dette — tout le monde le sait, mais personne n'a le temps de la corriger |
| La vélocité chute chaque trimestre | Les paiements d'intérêts augmentent — on passe plus de temps à combattre le système qu'à développer des fonctionnalités |
| « Nous avons besoin d'une réécriture complète » | Le capital de la dette a dépassé la valeur d'un remboursement progressif — les intérêts composés ont gagné |
## 05. GÉRER LA DETTE TECHNIQUE — L'APPROCHE PRATIQUE
L'objectif n'est pas d'avoir zéro dette technique. Une partie de la dette est rationnelle — le type délibéré et prudent qui accélère la livraison lorsqu'il est remboursé dans les temps. L'objectif est une dette gérée : visible, suivie et remboursée avant que les intérêts ne dépassent le gain initial.
La rendre visible
La dette technique qui n'est pas suivie n'est pas remboursée. Créez un registre de la dette — une simple liste des raccourcis connus, de leur coût de remboursement estimé et de leur taux d'intérêt actuel (à quel point ils vous ralentissent). Ce qui est mesuré est géré.
Allouer une capacité de remboursement
Une règle générale courante consiste à réserver environ 20 % de la capacité d'ingénierie au remboursement de la dette — refactorisation, documentation, améliorations de l'architecture. Les équipes qui sautent cette étape constatent que le pourcentage augmente involontairement à mesure que les coûts de service de la dette consomment de plus en plus la capacité des sprints.
Arrêter d'accumuler avant de rembourser
Rembourser la dette tout en continuant à l'accumuler au même rythme revient à courir sur place. Avant qu'un remboursement agressif ne soit pertinent, les conditions qui ont créé la dette — échéances irréalistes, absence de revues de conception, absence de définition du « fini » — doivent changer.
Prioriser par taux d'intérêt, et non par capital
Remboursez d'abord la dette qui vous coûte le plus par sprint, et non celle qui a le plus gros capital. Un petit raccourci architectural dans une zone à fort taux de changement coûte plus cher en intérêts quotidiens qu'un gros module hérité que personne ne touche.
## 06. CE QU'IL FAUT RETENIR
La dette technique n'est pas un échec de l'ingénierie. C'est une caractéristique de l'ingénierie dans des contraintes réelles. L'échec consiste à prétendre qu'elle n'existe pas — à traiter « on corrigera ça plus tard » comme une phrase complète plutôt que comme le début d'un plan.
Les meilleures équipes d'ingénierie n'ont pas zéro dette. Elles ont une dette qu'elles peuvent voir, un taux qu'elles peuvent se permettre et un calendrier de remboursement qu'elles suivent réellement. Elles savent que l'échéance et le budget n'existent pas en vase clos — ils se chevauchent dans la dette technique, et ce qui se trouve à cette intersection déterminera finalement si le système est un atout ou un passif.
Les ingénieurs qui comprennent cela ne se contentent pas de livrer plus vite. Ils livrent des systèmes qui restent livrables.
// grabnade.com · vêtements
Échéance. Budget. Dette technique.
Lois de la physique.
Le diagramme de Venn que vos parties prenantesdoivent voir avant la prochaine planification de sprint.
Portez-le à la réunion.