Dette technique : ce qu'il faut rembourser et ce qu'il faut ignorer
Toute dette technique ne mérite pas d'être remboursée. L'art consiste à distinguer celle qui porte intérêt de celle qui n'est que du vieux code qui marche.
Les développeurs demandent du temps pour assainir ; l'entreprise entend un coût sans bénéfice visible et le reporte. Les deux camps ont partiellement raison, et le débat revient chaque trimestre parce qu'aucun ne dispose d'un langage commun pour dire quelle dette compte vraiment.
La dette qui porte intérêt
- Tout ce qui ralentit chaque modification future : un modèle de données emmêlé, une logique dupliquée à cinq endroits, aucune couverture de tests sur ce qui casse.
- Les dépendances qui ne reçoivent plus de correctifs de sécurité. Ce n'est pas une préférence : c'est un passif non corrigé avec une liste publique de failles connues.
- La connaissance concentrée dans une seule personne, ce qui est une dette même quand le code est bon.
- Les étapes manuelles de déploiement ou de restauration, sans problème jusqu'au jour où celui qui les connaît est indisponible pendant un incident.
La dette qui n'en porte pas
Du code démodé qui fonctionne, rarement touché et aux frontières nettes, n'est pas un problème à financer. Une version de framework en retard non plus, en l'absence d'implication de sécurité. Une dette ne vous coûte que lorsque vous devez travailler à proximité — un code que vous ne touchez jamais ne porte aucun intérêt, aussi démodé paraisse-t-il en revue. C'est aussi notre propre définition du fini, détaillée dans ce que bien construit veut dire.
La financer sans réécriture
- Allouez un pourcentage permanent de capacité — couramment dix à vingt pour cent — plutôt que de demander un projet dédié qui perdra toujours face à une fonctionnalité.
- Remboursez la dette là où vous travaillez déjà. Nettoyer du code que vous vous apprêtez à modifier est presque gratuit ; nettoyer du code que personne ne touche est un loisir.
- Chiffrez-la en termes de livraison : « cette modification a pris trois jours au lieu d'un à cause de X ». Répété trois fois, cela devient un argument sur lequel un non-technicien peut agir.
- Ne proposez jamais une réécriture complète. Les réécritures prennent plus de temps que prévu, n'apportent aucune valeur nouvelle pendant le processus, et reproduisent fréquemment les problèmes d'origine avec des outils plus récents.
- 10-20% de capacité en allocation permanente
- 0 réécriture complète proposée
- 1 question : est-ce que cela nous ralentit
Questions fréquentes
Comment expliquer la dette technique à un décideur non technique ?
En délais de livraison, pas en qualité de code. « Les évolutions dans cette zone prennent trois fois plus de temps, et voici trois exemples du trimestre dernier » porte là où « l'architecture est mauvaise » échoue.
Une réécriture est-elle parfois justifiée ?
Rarement, et généralement quand la plateforme elle-même n'est plus maintenue ou quand le modèle économique a changé au point que le modèle de données ne décrit plus la réalité. Le remplacement progressif — du nouveau code à côté de l'ancien, migré morceau par morceau — reste presque toujours la voie la moins risquée.
Sur le même thème: Web & Produit.
À lire ensuite
Vous voulez la même chose pour votre entreprise ? Voir ce que nous faisons.