Dette technique
La dette technique désigne les choix techniques pris pour livrer plus vite (code dupliqué, absence de tests, architecture non adaptée à l'échelle actuelle) qui, comme une dette financière, génèrent des « intérêts » : chaque nouvelle fonctionnalité devient plus longue et plus risquée à développer.
Une startup qui sort un MVP en trois mois accumule presque toujours de la dette technique, et c'est souvent le bon choix pour valider un marché rapidement. Le problème arrive un ou deux ans plus tard, quand l'équipe passe plus de temps à corriger des régressions et à contourner du code fragile qu'à livrer de nouvelles fonctionnalités. C'est à ce moment qu'un audit de code devient utile : il chiffre la dette et distingue ce qui bloque réellement la feuille de route de ce qui peut attendre.
L'erreur la plus fréquente est de laisser la dette s'accumuler sans jamais la mesurer ni la rendre visible aux décideurs non techniques : elle finit par ralentir toute la roadmap sans qu'on comprenne pourquoi les délais s'allongent. Le bon réflexe est de la documenter au fur et à mesure et de réserver une part fixe de chaque sprint à son remboursement, plutôt que d'attendre une crise pour agir.
