La dette technique n'est pas un problème — c'est un outil de gestion. Bien comprise et bien gérée, elle permet de livrer vite sans hypothéquer l'avenir. Mal gérée, elle paralyse les équipes.
La métaphore de la dette technique, inventée par Ward Cunningham, est souvent mal comprise. La dette n'est pas forcément le résultat de mauvaises pratiques — c'est parfois un choix délibéré et rationnel. Livrer rapidement une solution imparfaite pour valider un marché, puis rembourser la dette quand la valeur est confirmée, c'est une stratégie parfaitement valide. Le problème, c'est la dette non intentionnelle et non tracée.
Pour mesurer la dette, des outils comme SonarQube fournissent des métriques objectives : code smells, duplications, complexité cyclomatique, couverture de tests. Ces métriques donnent une image partielle mais utile. La méthode SQALE (Software Quality Assessment based on Lifecycle Expectations) va plus loin en estimant le coût de remédiation en jours-homme. Ce chiffre, mis en regard du coût de maintenance actuel, aide à prioriser les remboursements.
La gestion de la dette doit être outillée et visible. Un Tech Debt Backlog maintenu par l'équipe technique, discuté régulièrement avec le Product Owner, est la pratique la plus efficace. Allouer 20% de la capacité de chaque sprint au remboursement de dette est une règle empirique qui fonctionne bien. L'important est que la dette ne soit pas invisible — une dette documentée et priorisée est gérable, une dette cachée est une bombe à retardement.
→ À lire aussi : Les principes SOLID · Clean Architecture