Dette technique : 3 signaux qui coûtent avant de se voir

La dette technique ne se présente jamais comme telle. Personne n’écrit « ceci est de la dette » dans un commit. Elle se voit d’abord dans le quotidien : des tâches simples qui prennent trois jours, des mises en production qui font peur, des « on ne touche pas à ce fichier ».

1. Le coût des petites modifications augmente

Le signal le plus fiable : comparez ce que coûte aujourd’hui un changement trivial — un libellé, un champ de formulaire — avec ce qu’il coûtait il y a six mois. Si la tendance monte alors que le produit n’a pas changé d’échelle, la structure du code résiste au changement. C’est la définition opérationnelle de la dette.

2. Les mêmes bugs reviennent sous d’autres formes

Un bug corrigé qui réapparaît ailleurs n’est pas un hasard : c’est une logique dupliquée ou une responsabilité mal placée. Chaque correction locale ajoute une variante de plus à maintenir. Le vrai correctif n’est presque jamais là où le bug se manifeste.

3. Le savoir est dans des têtes, pas dans le système

Si le déploiement, la configuration ou « pourquoi ce module marche comme ça » dépendent d’une personne précise, le système n’est pas transférable. Ce n’est pas un problème de documentation d’abord — c’est un signe que le système est trop complexe pour être expliqué simplement.

Par où commencer

Pas par un « grand refactoring ». Mesurez une chose : le temps réel des petites modifications. Puis retirez — une duplication, une dépendance, une étape manuelle — à chaque passage. La sobriété n’est pas un chantier, c’est une pratique.