Niveau : Expert – DSI, CTO, Tech Leads, Architectes

La dette technique est l’un des concepts les plus utilisés et les moins bien compris dans les organisations IT. Elle est souvent invoquée pour justifier des refontes complètes coûteuses, ou au contraire ignorée jusqu’à ce qu’elle provoque une crise. Entre ces deux extrêmes, il existe une approche structurée qui permet de la gérer sans interrompre la création de valeur.

Cet article propose un cadre opérationnel pour mesurer la dette technique de manière objective, la prioriser selon son impact réel, et la résorber progressivement dans le rythme normal de développement.

Définition de travail : la dette technique est le coût futur généré par des décisions de conception ou d’implémentation prises pour gagner du temps à court terme. Comme une dette financière, elle génère des intérêts – le surcoût de travailler sur un code de mauvaise qualité.

1. Taxonomie de la dette technique

Toutes les dettes techniques ne se ressemblent pas. La classification de Martin Fowler (Technical Debt Quadrant) reste la plus utile en pratique :

La dette Reckless/Deliberate est la plus toxique et la plus urgente à traiter. La dette Prudent/Inadvertent est inévitable et normale – tout code écrit contient une part de décisions qui se révèleront sous-optimales à mesure que la compréhension du domaine évolue.

2. Mesurer la dette technique de manière objective

La dette technique est souvent qualifiée de manière subjective (« le code est sale », « le système est vieux »). Pour arbitrer des décisions d’investissement, elle doit être quantifiée. Quatre dimensions méritent d’être mesurées :

2.1 Métriques de code

Les outils d’analyse statique fournissent des métriques objectives sur la qualité du code :

• Complexité cyclomatique : nombre de chemins d’exécution indépendants. Au-delà de 10 par fonction, la testabilité et la maintenabilité chutent. Au-delà de 20 : refactoring urgent.
• Couplage afférent/efférent : nombre de modules qui dépendent d’un module (Ca) et nombre de modules dont dépend ce module (Ce). Un module avec Ca élevé est difficile à modifier sans effets de bord.
• Duplication de code : taux de code dupliqué. SonarQube exprime cela en pourcentage. Au-delà de 5%, la maintenabilité est significativement impactée.
• Couverture de tests : indicateur indirect de la capacité à refactorer en toute sécurité. Un code sans tests est une dette structurelle – tout refactoring est risqué.

2.2 Métriques de vélocité

Les métriques d’ingénierie révèlent l’impact de la dette sur la productivité :

• Lead time : temps entre le commit et la mise en production. Une augmentation progressive sur 6 mois sans changement d’organisation est souvent le signe d’une dette croissante.
• Change failure rate : taux de déploiements causant un incident. Un taux élevé indique une base de code fragile.
• MTTR (Mean Time To Restore) : temps moyen pour rétablir le service après un incident. Un MTTR élevé indique souvent un manque d’observabilité et une architecture difficile à déboguer.

2.3 Le coût en temps développeur

La méthode la plus parlante pour les décideurs : estimer le surcoût généré par la dette sur chaque ticket de développement. Si vos développeurs estiment que 30% de leur temps sur chaque fonctionnalité est consacré à « travailler autour » du code existant plutôt qu’à développer, votre dette consomme 30% de votre capacité d’ingénierie.

Formule simple : Coût annuel de la dette = (% de temps consommé par la dette) x (coût annuel de l’équipe). Si votre équipe coûte 500k€/an et que 25% du temps est consommé par la dette : 125k€/an perdus en « intérêts ».

3. Prioriser la dette : la matrice Impact / Effort

Toute la dette ne mérite pas d’être remboursée immédiatement. La priorisation doit se faire selon deux axes :

3.1 Impact sur le business

• Impact sur la vélocité de l’équipe : quel pourcentage de la capacité est consommé par cette dette ?
• Impact sur la fiabilité : cette dette génère-t-elle des incidents en production ?
• Impact sur la sécurité : expose-t-elle des vulnérabilités ?
• Impact sur le recrutement : est-elle un frein à l’onboarding de nouveaux développeurs ?

3.2 Effort de remboursement

• Complexité technique du refactoring
• Risque de régression (couverture de tests disponible)
• Dépendances avec d’autres modules

Les dettes à traiter en priorité : fort impact business + effort faible ou modéré. Les dettes à planifier sur le moyen terme : fort impact + effort élevé. Les dettes à accepter et documenter : faible impact, quelle que soit la complexité.

4. Stratégies de résorption sans interrompre le business

La grande erreur des organisations qui prennent conscience de leur dette technique est de vouloir la résorber en une « grande refonte ». Ces projets durent en moyenne 2 à 3 fois plus longtemps que prévu, gèlent les nouvelles fonctionnalités, et se terminent souvent par un abandon ou un résultat décevant.

Voici les stratégies qui fonctionnent réellement :

4.1 La règle du boy scout

« Laissez le code plus propre que vous ne l’avez trouvé. » Chaque fois qu’un développeur touche à un module pour une fonctionnalité ou un bug, il y consacre 10 à 20% de son temps supplémentaire à améliorer la qualité locale (renommer des variables, extraire des fonctions, ajouter des tests). Appliqué systématiquement, ce principe crée une amélioration continue sans projet dédié.

4.2 Le budget dette (20% rule)

Allouer formellement 20% de la capacité de chaque sprint au remboursement de dette technique. Cette allocation doit être visible dans le planning, protégée contre la pression des fonctionnalités, et rapportée dans les rétrospectives. Les équipes qui ne protègent pas explicitement ce budget le perdent systématiquement.

4.3 Refactoring par opportunité (Opportunistic Refactoring)

Identifier les modules les plus douloureux (hotspots) en croisant les métriques de complexité cyclomatique avec la fréquence de modification (git log). Les modules complexes ET fréquemment modifiés sont vos hotspots prioritaires. Chaque passage dans ces modules est une opportunité de refactoring ciblé.

4.4 Strangler Fig pour les composants majeurs

Pour les composants architecturaux majeurs (une API legacy, un module monolithique), le pattern Strangler Fig permet de remplacer progressivement le code existant sans arrêt de service : construire le nouveau système en parallèle, basculer le trafic fonctionnalité par fonctionnalité, décommissionner l’ancien une fois la migration complète.

5. Gouvernance de la dette technique

La dette technique ne peut pas être gérée uniquement au niveau des équipes de développement. Elle nécessite une gouvernance qui implique la direction IT :

• Dashboard de dette mensuel : métriques SonarQube, vélocité, incidents liés à la dette – présenté au COMEX IT
• Architecture Decision Records (ADR) : documenter les décisions techniques et leurs compromis – crée une traçabilité de la dette intentionnelle
• Definition of Done enrichie : un ticket n’est terminé que si la couverture de tests est maintenue et si aucune nouvelle dette critique n’est introduite (quality gate SonarQube)
• Revues d’architecture trimestrielles : evaluation de la trajectoire architecturale et de l’evolution de la dette

Conclusion

La dette technique est inévitable dans tout système logiciel vivant. L’objectif n’est pas de l’éliminer, mais de la maintenir à un niveau acceptable et de s’assurer qu’elle ne croît pas plus vite qu’elle n’est remboursée.

Les organisations qui gèrent leur dette technique comme un actif financier – en la mesurant, la priorisant et lui allouant un budget explicite – maintiennent une vélocité d’ingénierie durable et évitent les crises coûteuses des grandes refontes d’urgence.

OryStack réalise des audits de dette technique et accompagne les équipes dans la mise en place de pratiques d’ingénierie durables. Pour un diagnostic de votre SI : contact@orystack.com