Réponse Brève
La dette technique ne se mesure pas à la qualité du code, mais au coût qu'elle impose à chaque modification future. Par conséquent, la priorité n'est pas ce qui est "le plus laid", mais plutôt ce qui rend la prochaine tâche la plus coûteuse.
La règle rapide de tri : un élément qui implique qu'une modification dans sa zone nécessite une vérification de régression étendue est prioritaire. Il multiplie le coût de toute autre activité du programme.
Score sur Quatre Dimensions
| Dimension | Question | Poids |
|---|---|---|
| Exposition Commerciale | Que se passe-t-il en cas de défaillance en période de forte charge ? | Élevé |
| Fréquence | Combien de fois par jour cet élément est-il sollicité ? | Élevé |
| Dépendance | Combien d'autres domaines sont bloqués à cause de cela ? | Moyen |
| Effort | Combien coûte la correction dans un environnement contrôlé ? | Inverse |
Le score n'est pas une science exacte. Sa véritable valeur réside dans le fait qu'il force une discussion explicite entre celui qui connaît le risque technique et celui qui connaît la douleur commerciale, et qu'il produit un ordre qui peut être défendu face aux dirigeants.
Trois Types de Dettes Qui Passent Avant les Autres
Indépendamment du score, trois types montent en première ligne :
- Dette qui bloque les tests - L'absence d'un environnement Sandbox fonctionnel ou de données de test. Toute autre correction effectuée sans cela se fait à l'aveugle.
- Dette liée aux autorisations - Un modèle de visibilité qui a perdu sa logique est une exposition réglementaire active, pas un simple inconvénient.
- Dette concentrée sur une seule personne - Quand une seule personne comprend un composant, le risque n'est pas technique mais organisationnel.
Comment Présenter une Dette pour Obtenir un Budget
La direction ne finance pas le "nettoyage des automatisations". Elle finance la réduction du temps et des coûts. La traduction se fait en trois lignes pour chaque élément : combien d'heures de support il consomme par trimestre, combien de jours il ajoute à chaque modification dans sa zone, et quelle est l'exposition en cas de défaillance.
Celui qui présente "trois demandes de changement par trimestre, chacune prolongée de deux semaines à cause du même composant" obtient l'approbation. Celui qui présente un diagramme de dépendances, non.
Une Allocation Fixe, pas une Opération Ponctuelle
Le modèle qui échoue : un grand projet de nettoyage tous les deux ans. Le modèle qui fonctionne : une allocation fixe de 15 à 20 % de chaque vague de développement dédiée à la dette, définie à l'avance et non négociable à chaque sprint.
Parallèlement à cette allocation, au moins une règle préventive est nécessaire – par exemple, l'interdiction d'ajouter une nouvelle automatisation à un objet qui en contient déjà plusieurs, avant de les unifier. Sans prévention, le rythme de création de la dette dépasse le rythme de nettoyage. Le lien avec l'infrastructure de développement est détaillé dans la Stratégie de Sandboxes et de DevOps.
Résumé
La priorisation de la dette technique est un exercice économique et non esthétique : on corrige ce qui renchérit la prochaine modification, on anticipe ce qui bloque les tests et ce qui crée une exposition, et on fixe une allocation pour éviter les récidives. Une liste de dix éléments classés vaut plus que cent éléments cartographiés.