- Description
- Chantier de construction enserré dans d'énormes échafaudages, avec grues et conteneurs de matériaux.
- Source
- Fons Heijnsbroek · page d’origine
- Licence
- CC0 Domaine public
Dette technique et maintenabilité
Ce thème mesure la capacité à garder le logiciel modifiable dans la durée : la dette technique est connue, chiffrée, arbitrée et remboursée à un rythme choisi, plutôt que subie. La promesse…
En bref
Ce thème mesure la capacité à garder le logiciel modifiable dans la durée : la dette technique est connue, chiffrée, arbitrée et remboursée à un rythme choisi, plutôt que subie. La promesse n'est pas « zéro dette » (une dette consciente est un outil) mais « la dette ne ralentit pas l'équipe sans qu'elle le sache ».
Niveau : 🟢→🔴 · Code thème : DTT (matrice DL)
Pourquoi ce thème#
La métaphore de la dette vient de Ward Cunningham : prendre un raccourci pour livrer plus tôt, c'est emprunter ; tant qu'on ne rembourse pas, on paie des intérêts (chaque évolution est plus lente). Martin Fowler a distingué la dette délibérée de l'inconsciente, l'imprudente de la prudente. Le danger majeur est la dette invisible : personne ne la mesure, donc le coût apparaît comme une « vélocité qui baisse » sans explication, ou comme une incapacité à recruter (personne ne veut toucher ce code).
La dette ne se limite pas au code : dépendances et plateformes en fin de support, schémas de base devenus incompréhensibles, documentation fausse, pipelines fragiles, scripts à un seul auteur, tests lents. Dans un produit qui maintient plusieurs versions en parallèle, chaque version supportée est une dette : elle multiplie les correctifs. Voir 04.
Ce que mesure le thème#
- Axe : de « on subit » à « la dette est un portefeuille géré, avec un budget de remboursement ».
- Indicateurs clés : part de capacité consacrée au remboursement (%) ; délai d'un changement type (tendance) ; part de composants en fin de support ; ancienneté de la dette reconnue.
- Unité : % de capacité ; jours ; nombre d'éléments, âge.
Tableau des cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Subie | On ne sait pas pourquoi les évolutions ralentissent. | Aucune liste ; remboursement ≈ 0 % |
| 2 | Reconnue | La dette connue est notée, et chacun peut en citer les principaux éléments. | Registre de dette ; remboursement opportuniste |
| 3 | Arbitrée | Chaque élément de dette a un coût estimé, et une décision (rembourser, accepter, retirer) datée. | Registre priorisé ; 10-20 % de capacité réservée |
| 4 | Mesurée | La tendance du coût de changement est suivie ; le remboursement est piloté par l'effet observé. | Délai d'un changement type suivi ; dette qui décroît à périmètre constant |
| 5 | Soutenable | La dette prise est volontaire, bornée et remboursée avant échéance ; le produit reste facile à changer après dix ans. | Aucun composant hors support ; délai de changement stable depuis 3 ans |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| DL-DTT-1.1 | L'équipe sait désigner les 3 zones les plus risquées à modifier | Réponses convergentes de trois personnes |
| DL-DTT-1.2 | Les raccourcis pris sont signalés au moment où ils sont pris (commentaire, ticket) | Au moins 5 éléments signalés |
| DL-DTT-1.3 | Les composants et versions utilisés sont connus | Inventaire |
| DL-DTT-2.1 | Un registre de dette existe (élément, nature, origine, conséquence) | Registre accessible, daté |
| DL-DTT-2.2 | Les composants arrivant en fin de support sont recensés avec leur date | Colonne « fin de support » |
| DL-DTT-2.3 | Les éléments de dette sont rattachés à des composants et des responsables | Responsable nommé par élément |
| DL-DTT-2.4 | La dette de documentation et de tests est distinguée de celle du code | Catégories dans le registre |
| DL-DTT-3.1 | Chaque élément est estimé en coût d'intérêt (jours perdus par mois) et en coût de remboursement | Estimations, même grossières |
| DL-DTT-3.2 | Une part fixe de capacité (par exemple 10 à 20 %) est réservée au remboursement | Planification sur 3 itérations |
| DL-DTT-3.3 | Toute dette nouvelle délibérée reçoit une échéance et un propriétaire | Revue de 10 raccourcis récents |
| DL-DTT-3.4 | Le registre est révisé à intervalle régulier (au moins trimestriel) | Comptes rendus de revue |
| DL-DTT-3.5 | Les décisions « accepter la dette » sont explicites et justifiées | Mention dans le registre |
| DL-DTT-4.1 | Le délai d'un changement type (par composant) est mesuré et sa tendance suivie | Courbe sur 12 mois |
| DL-DTT-4.2 | Les zones à forte évolution et forte dette (« points chauds ») sont repérées par l'historique de changements | Analyse historique + complexité |
| DL-DTT-4.3 | Les remboursements sont évalués après coup (le délai de changement a-t-il baissé ?) | Revue d'effet sur 5 remboursements |
| DL-DTT-4.4 | La dette de dépendances est suivie (âge des versions, écart avec la dernière stable) | Tableau d'âge des dépendances |
| DL-DTT-4.5 | Les versions supportées et la politique de fin de vie sont définies et publiées | Politique datée |
| DL-DTT-5.1 | Aucun composant ne reste en fin de support sans plan chiffré | Plan de migration pour chaque cas |
| DL-DTT-5.2 | La dette est plafonnée par politique : au-delà d'un seuil, la livraison de nouveautés ralentit | Décision de gel déjà appliquée |
| DL-DTT-5.3 | Les remplacements majeurs sont incrémentaux et financés en continu, pas en « grand soir » | Historique des 3 dernières migrations |
| DL-DTT-5.4 | Un nouvel arrivant modifie les zones les plus anciennes sans accompagnement lourd | Intégration mesurée sur les zones anciennes |
Lecture détaillée par niveau#
🟢 Niveau 1 — Subie#
- Signes : « on n'a pas le temps de ranger » ; des zones taboues ; les estimations gonflent.
- Gain : livraison rapide à court terme.
- Ne garantit pas : la soutenabilité ; les intérêts s'accumulent silencieusement.
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Reconnue#
- Signes : un registre, une liste de fins de support, quelques responsables.
- Gain : la dette cesse d'être taboue.
- Ne garantit pas : qu'on la rembourse : un registre peut devenir un cimetière de bonnes intentions.
- Difficulté : 2/5 · Effort : 1/5.
🟡 Niveau 3 — Arbitrée#
- Signes : une part de capacité réservée ; chaque raccourci délibéré a une échéance. La discussion avec le métier passe par le coût d'intérêt (« cette zone nous coûte 4 jours par mois ») et non par l'esthétique du code.
- Gain : des arbitrages explicites et défendables.
- Ne garantit pas : que les estimations soient justes — elles sont des ordres de grandeur.
- Difficulté : 3/5 · Effort : 3/5.
🔴 Niveau 4 — Mesurée#
- Signes : on suit le délai d'un changement type, on repère les points chauds (fichiers qui changent souvent et sont complexes), et l'on vérifie, après remboursement, que le coût a baissé.
- Gain : on investit où cela rapporte.
- Ne garantit pas : la prévention des nouvelles dettes ; il faut aussi une discipline en amont (02).
- Difficulté : 4/5 · Effort : 4/5.
🔴 Niveau 5 — Soutenable#
- Signes : la dette est plafonnée, financée en continu, et les migrations majeures se font par incréments. Le produit vieillit sans se figer.
- Gain : durabilité, attractivité du code pour les recrutements.
- Ne garantit pas : l'absence de choix difficiles — une version supportée de trop reste une charge.
- Difficulté : 5/5 · Effort : 5/5.
Atteinte partielle et notation#
Appliquez la règle de notation.
- 0,5 sur DL-DTT-3.2 : une capacité est réservée, mais seulement quand « il n'y a pas d'urgence ».
- 0,5 sur DL-DTT-4.1 : le délai de changement est mesuré sur un composant seulement.
- Un 5 partiel : plafond de dette décidé, jamais encore déclenché ; migrations incrémentales sur un seul chantier.
Registre cimetière. Symptôme : 400 éléments, aucun traité. Cause : pas d'estimation de coût ni de seuil. Remède : n'inscrire que ce qui a un coût d'intérêt, fermer ce qui n'a pas d'avenir.
Grand soir. Symptôme : « on réécrit tout, 18 mois ». Cause : dette perçue comme insoutenable. Remède : étranglement progressif (01), livraison de valeur à chaque étape.
Croisez fréquence de changement et complexité : une zone complexe stable coûte peu, une zone simple très changeante coûte peu, c'est le croisement qui fait mal. Remboursez là.
Datamart : une procédure de 1 200 lignes, modifiée 14 fois en un an, chaque modification durant 3 jours. Coût d'intérêt ≈ 42 jours/an. Un refactoring de 8 jours ramène chaque modification à 1 jour : l'investissement (8 jours) est rentabilisé en moins de quatre mois (28 jours gagnés par an).
Si l'on pilote sur le « nombre d'éléments de dette », on les fusionne ou on les découpe pour faire baisser le chiffre. Pilotez sur le délai de changement.
Passer au niveau suivant#
Moyens possibles (facultatifs)
- 1 → 2 : un atelier d'une heure pour dresser la liste des zones craintes ; un registre simple.
- 2 → 3 : estimation de l'intérêt, réservation de capacité, échéance sur les raccourcis.
- 3 → 4 : mesure du délai de changement, analyse des points chauds, revue d'effet après remboursement.
- 4 → 5 : plafond de dette, plan de fin de support, migrations incrémentales.
Voir aussi#
- Voisins : 01 Architecture · 02 Qualité du code · 03 Tests · 10 Documentation · 12 Expérience développeur.
- Autres matrices : Projet — gestion des risques · Projet — amélioration continue · BI — modèle sémantique.
- Pratique : pièges et bonnes pratiques · comparatif des méthodes · stratégies de branches.
- Glossaire · Notation.
✻ Rédigé par Claude Sonnet 5.5
