Dette technique : comment la mesurer avant de la traiter

Quand on parle de dette technique, la première réaction est souvent de vouloir agir : refactorer, réécrire, migrer. C’est une erreur. Avant de traiter, il faut mesurer. Et mesurer sérieusement, pas à l’intuition.

Cette étape est celle que la plupart des équipes sautent, par impatience ou par manque d’outillage. C’est pourtant elle qui conditionne la pertinence de tout ce qui suit.

Ce que “dette technique” recouvre vraiment

Le terme est galvaudé. On l’utilise pour désigner des choses très différentes :

• Du code mal structuré ou non documenté
• Des dépendances obsolètes ou non maintenues
• Une architecture couplée qui rend les évolutions coûteuses
• Des tests absents ou insuffisants
• Des processus de déploiement manuels et fragiles
• Des règles métier enfouies dans du code sans traçabilité

Ces catégories n’ont pas le même impact, ni le même coût de remédiation. Les traiter avec le même poids est une erreur de pilotage.

Les quatre dimensions à évaluer

1. La complexité cyclomatique

La complexité cyclomatique mesure le nombre de chemins logiques indépendants dans une fonction ou un module. Une complexité > 10 sur une fonction est un signal d’alerte. > 20, c’est un problème avéré.

Les outils comme SonarQube, CodeClimate ou Lizard calculent cette métrique automatiquement sur l’ensemble du codebase. L’objectif n’est pas d’atteindre 1 partout, mais d’identifier les hotspots, les modules à haute complexité qui sont aussi fréquemment modifiés.

C’est le croisement complexité × fréquence de modification qui indique la priorité réelle.

2. L’analyse des dépendances

Un système vieillissant accumule des dépendances dont certaines :

• Ne sont plus maintenues (CVE non corrigées)
• Bloquent les mises à jour du framework principal
• Créent des conflits de version impossibles à résoudre sans refonte

Comment l’évaluer :

• npm audit / pip audit / mvn dependency:analyze selon l’écosystème
• Vérification des dates de dernier commit sur les dépendances critiques
• Analyse des licences (risque juridique souvent sous-estimé)

Un tableau de bord simple avec : dépendance / version actuelle / version stable / CVE ouvertes / date de fin de support.

3. La couverture de tests

La couverture n’est pas une métrique de qualité en soi : un test mal écrit ne prouve rien. Mais l’absence de tests sur des modules critiques est un indicateur fiable de risque de régression.

Ce qui compte :

• La couverture des chemins critiques (paiement, authentification, calcul métier)
• L’existence de tests d’intégration, pas seulement unitaires
• La stabilité des tests dans le temps (un test qui “flake” est pire que pas de test)

4. Le couplage et la cohésion

Un système bien architecturé a des modules faiblement couplés (peu de dépendances inter-modules) et fortement cohésifs (chaque module fait une chose et la fait bien).

Les outils d’analyse statique mesurent :

• Le nombre de dépendances entrantes/sortantes par module (fan-in/fan-out)
• Les cycles de dépendances (A dépend de B qui dépend de A)
• La taille des modules (un module de 10 000 lignes est presque toujours un problème)

La méthode des hotspots : croiser complexité et changement

Développée par Adam Tornhill (CodeScene), la méthode des hotspots est la plus opérationnelle pour prioriser.

Principe : un code complexe qui ne change jamais n’est pas urgent. Un code complexe qui change souvent est un risque quotidien.

Protocole :

1. Extraire l’historique Git des 12 derniers mois : git log --format=format: --name-only | sort | uniq -c | sort -rg
2. Croiser avec les scores de complexité par fichier
3. Les fichiers en haut des deux classements sont vos hotspots prioritaires

C’est une analyse qui prend une demi-journée et qui change radicalement la conversation sur les priorités.

Ce que l’audit doit produire

Un bon audit de dette technique produit trois livrables :

Une cartographie visuelle

Un graphe de dépendances entre modules, avec code couleur selon la complexité. Pas pour être joli, pour permettre à des non-développeurs (direction, métier) de comprendre où sont les zones de risque.

Un score de criticité par module

Une grille simple : complexité × couplage × fréquence de modification × criticité métier. Chaque module reçoit un score. Le score oriente les décisions de refonte.

Une estimation du coût de la dette

Souvent ignorée, cette estimation est pourtant ce qui permet de défendre un budget de modernisation. Les méthodes varient, mais une approximation raisonnable :

• Temps de développement supplémentaire induit par la complexité (mesuré sur les derniers sprints)
• Coût des incidents liés aux zones fragiles (temps de résolution × fréquence)
• Coût d’opportunité : fonctionnalités non livrées à cause de la dette

Les pièges à éviter

Mesurer sans contexte métier. Un module à haute complexité qui gère des règles fiscales héritées peut être volontairement complexe. L’audit technique doit toujours être croisé avec la connaissance fonctionnelle.

Vouloir tout mesurer. Un audit exhaustif de 3 mois sur 500 modules produit un rapport que personne ne lit. Mieux vaut une analyse ciblée sur les 20% de modules qui concentrent 80% du risque.

Confondre couverture de code et qualité. 90% de couverture avec des tests qui ne testent rien de réel est pire que 40% de couverture sur les vrais chemins critiques.

Oublier la dette organisationnelle. La dette technique a souvent une cause organisationnelle : équipes trop petites, pression sur les délais, absence de revue de code. Traiter le symptôme sans adresser la cause, c’est recreer de la dette.

Conclusion

Mesurer la dette technique n’est pas une fin en soi. C’est ce qui permet de défendre un budget et de prioriser les chantiers sur des faits, pas sur des intuitions.

Sans mesure, la modernisation est une décision de foi. Avec une mesure rigoureuse, c’est une décision d’ingénierie.

Vous souhaitez cadrer un audit de dette technique sur votre SI ? Parlons-en.