Pourquoi un mauvais indicateur est pire que l’absence d’indicateur
La tentation la plus courante quand on veut mesurer la dette technique, c’est d’installer un outil d’analyse statique, d’obtenir un score de qualité de code, et d’utiliser ce chiffre comme indicateur de la dette. Le problème, c’est que ce chiffre mesure la complexité du code, et le coût que cette complexité fait peser sur l’évolution du système lui échappe.
Un module à forte complexité cyclomatique dans une zone qui ne change jamais n’est pas un problème opérationnel. Un module à complexité moyenne dans une zone qui change à chaque sprint, que traverse chaque nouvelle fonctionnalité et dont dépendent dix autres modules, est un vrai blocage. La différence tient à la fréquence de modification et au poids des dépendances, que le chiffre produit par l’outil ignore.
Mesurer la dette technique, c’est répondre à une question claire : combien coûte le fait de modifier ce système, et où coûte-t-il plus cher qu’il ne devrait ? Les indicateurs qui répondent à cette question diffèrent de ceux qui mesurent la qualité statique du code. Ce guide se concentre sur les premiers.
Les trois indicateurs opérationnels
Pour mesurer la dette, trois indicateurs suffisent ; lus ensemble, ils donnent une vision assez précise pour décider.
Le cycle time, c’est le temps entre la prise en charge d’une tâche et son arrivée en production : le temps de traversée du flux de travail actif. Il compte le temps réel passé en implémentation, revue, tests et mise en production ; le temps d’analyse et d’estimation, qui relève d’un autre problème de processus, reste hors de ce calcul. Il se distingue du Lead Time for Changes de DORA (du premier commit au déploiement en production), qui inclut aussi le temps qu’un commit passe en attente avant même que le travail ne débute. Dans cet article, nous utilisons le cycle time au sens Lean : la mesure du temps de traversée du flux actif, l’indicateur le plus sensible pour détecter une résistance interne du système. Un cycle time qui grimpe trimestre après trimestre sans hausse correspondante de la complexité des fonctionnalités est le signal le plus fiable d’une dette à l’œuvre. C’est exactement là que la dette technique se manifeste : chaque changement prend plus de temps parce que les dépendances cachées multiplient le travail nécessaire, les tests échouent de façon imprévisible, et la revue oblige à tracer l’impact sur des parties du système qui ne devraient pas être concernées.
Le bug rate normalisé, c’est le nombre d’incidents et de régressions par fonctionnalité livrée, bien plus parlant que le chiffre absolu. Une équipe qui livre deux fois plus de fonctionnalités peut avoir deux fois plus de bugs sans que cela ne signale de dette. Le signal apparaît quand le bug rate par fonctionnalité augmente : chaque nouvelle fonctionnalité génère plus de problèmes que la précédente, parce que le système devient toujours moins prévisible dans ses réactions au changement. Cet indicateur est particulièrement utile pour localiser la dette : le bug rate le plus élevé pointe presque toujours vers la zone du système au couplage le plus caché.
Le coût du changement, c’est le coût réel d’une modification précise, calculé non seulement sur le temps de développement, mais sur tout le cycle : analyse d’impact, coordination inter-équipes, revue approfondie, tests manuels compensatoires, coordination du déploiement, vérification post-mise en production. Cet indicateur ne s’automatise pas : il se construit sur des cas concrets. Mais c’est celui qui se traduit le plus directement en argument compréhensible pour la direction. « Ce changement, qui aurait dû prendre trois jours, en a pris quinze parce qu’il traversait ces quatre modules dépendants » est un chiffre concret sur un cas réel. Il convainc toujours plus qu’une estimation globale.
Le Consistency Model : la dimension que les indicateurs locaux ne voient pas
Les trois indicateurs opérationnels mesurent le coût de la dette dans le présent. Ils ne mesurent pas la cause structurelle qui la génère. D’où le besoin d’un autre outil d’analyse : le Consistency Model.
Le Consistency Model mesure le degré de cohérence entre trois dimensions qui, dans un système sain, évoluent ensemble : l’architecture logicielle, la structure des équipes qui la développent, et les processus métier qu’elle doit prendre en charge. Quand ces trois dimensions restent cohérentes, le système se modifie facilement : chaque équipe a une responsabilité claire sur sa zone, les frontières architecturales reflètent les frontières de responsabilité, les processus métier trouvent une traduction directe dans les modules logiciels.
Quand ces trois dimensions se désalignent, et elles se désalignent toujours au fil de la croissance, la dette devient systémique. Le signal propre au désalignement, c’est que les changements demandés par le métier traversent systématiquement des frontières architecturales qu’ils ne devraient pas traverser.
En pratique : une organisation qui a restructuré ses équipes sans toucher à l’architecture se retrouve avec des équipes qui doivent se coordonner sur chaque changement, parce que le code ne reflète pas la nouvelle structure. Une organisation qui a changé ses processus métier sans toucher aux modules logiciels se retrouve avec des bounded contexts qui modélisent des flux disparus, et des contournements partout pour gérer les nouveaux. La dette vit dans l’écart entre la structure du système et le fonctionnement actuel de l’organisation : les composants pris isolément comptent moins.
Comment mesurer le désalignement
Le Consistency Model ne demande aucun outil sophistiqué pour être appliqué. Il demande des réponses à un ensemble de questions structurées sur trois niveaux.
Au niveau architecture-équipe : chaque changement demandé par le métier est-il géré par une seule équipe en autonomie, ou exige-t-il une coordination entre plusieurs équipes ? Si la réponse est « souvent plusieurs équipes », où se situent ces frontières ? Les équipes qui doivent le plus se coordonner sur chaque fonctionnalité sont presque toujours celles dont les frontières architecturales ne reflètent pas les frontières de responsabilité. Des équipes qui se bloquent mutuellement cachent le plus souvent un problème d’architecture derrière un problème de communication.
Au niveau architecture-processus : les bounded contexts du système reflètent-ils les flux métier actuels ? Ou existe-t-il des zones où chaque nouveau processus oblige à toucher trois ou quatre modules différents, parce que les abstractions ont été pensées pour une organisation qui n’existe plus ? Voici un test : prenez un processus métier qui a changé dans les douze derniers mois. Combien de modules logiciels ont dû être modifiés pour le prendre en charge ? Si la réponse dépasse deux ou trois, le système ne reflète plus la structure du métier.
Au niveau équipe-processus : les frontières de responsabilité des équipes reflètent-elles les flux de valeur vers le client ? Ou les équipes sont-elles organisées autour de technologies ou de composants, ou bien autour de produits ou de services ? Une équipe qui possède la base de données mais pas l’API qui l’expose crée des dépendances structurelles qui ralentissent toute modification de la donnée.
Du chiffre à la décision
Mesurer la dette sert à décider où et comment intervenir. Les indicateurs opérationnels et le Consistency Model répondent à deux questions différentes mais complémentaires.
Les indicateurs opérationnels répondent à : combien de dette payons-nous actuellement, et où ? Le cycle time montre à quel point le système ralentit la livraison. Le bug rate montre où le système est le moins prévisible. Le coût du changement chiffre le coût réel sur des cas concrets. Ensemble, ils indiquent où la pression est la plus forte et où l’intervention aurait le meilleur retour.
Le Consistency Model répond à : pourquoi la dette s’accumule-t-elle précisément dans ces zones ? Comprendre le désalignement structurel est nécessaire pour traiter la cause. Un refactoring qui réduit la complexité cyclomatique sans toucher aux frontières architecturales soulage un symptôme : la dette reviendra, car les conditions qui l’ont générée restent en place.
Le Consistency Impact Calculator est l’outil que nous utilisons pour structurer cette analyse et produire un résultat compréhensible par la direction, du type « le coût du prochain changement dans cette zone est X, parce qu’il traverse Y modules désalignés, et pourrait être ramené à Z avec une intervention précise ».
Les indicateurs qui distraient
Tous les indicateurs disponibles ne sont pas utiles pour mesurer la dette. Certains sont plus faciles à collecter mais moins informatifs ; les utiliser conduit à optimiser le chiffre, au détriment du problème sous-jacent.
La couverture de tests est le plus fréquent de ces indicateurs. Une couverture élevée n’implique pas une dette faible : on peut avoir des tests sur chaque fonction et une architecture si couplée que chaque changement devient un risque. La couverture est surtout un préalable pour pouvoir refactorer en sécurité, sans constituer une mesure directe de la dette à éliminer.
La complexité cyclomatique absolue est un autre indicateur trompeur, utilisé sans contexte. Comme on l’a vu, la complexité qui compte est la complexité opérationnelle : ce que coûte la modification de cette partie du système, rapportée à la fréquence à laquelle elle doit changer. Un module très complexe qui ne change jamais n’est pas un problème urgent.
Le nombre de tickets ouverts fonctionne comme un indicateur de charge. Un backlog long peut simplement refléter des choix de priorisation. Un backlog qui grossit dans des zones précises du système à chaque sprint, en revanche, est un signal indirect de dette : cette zone se pilote moins bien que le reste.
Ce qu’il faut faire concrètement
- Instrumentez le cycle time par zone du système, plus utile que le cycle time moyen global, trop agrégé pour révéler quoi que ce soit à lui seul. Segmentez par zone du codebase ou par type de changement. La comparaison entre zones révèle presque toujours des schémas que l’analyse agrégée dissimule : une zone quatre fois plus lente que les autres est presque certainement un goulot d’étranglement architectural.
- Calculez le coût du changement sur trois modifications complexes récentes : choisissez trois changements que l’équipe a trouvés plus difficiles que prévu. Reconstituez le coût réel : temps d’analyse d’impact, coordination inter-équipes, revue, tests supplémentaires, coordination du déploiement. La somme de ces coûts, comparée à l’estimation initiale, donne l’écart qui mesure le coût de la dette sur ces exemples concrets.
- Cartographiez le Consistency Model en une heure : réunissez le tech lead et les responsables de deux ou trois équipes. Répondez à cette question pour chaque changement stratégique des six derniers mois : combien d’équipes ont dû se coordonner ? Combien de modules du système ont nécessité des changements ? Où les frontières architecturales ne reflètent-elles pas les frontières de responsabilité ? Le résultat restera partiel, mais il suffira à repérer les zones où le désalignement est le plus marqué.
Le regard de QMates
Notre analyse part toujours du flux : nous suivons comment les changements se propagent dans le système, où ils se bloquent, combien de temps ils prennent à aboutir. Les indicateurs que nous collectons mesurent la friction dynamique du système, qui est directement corrélée au coût de livraison.
Ce que nous constatons presque à chaque fois, c’est que la dette la plus coûteuse se loge là où l’architecture et l’organisation des équipes ont cessé d’évoluer ensemble. Cela peut être un bounded context qui servait trois clients et doit aujourd’hui en servir cent, avec des processus complètement différents. Cela peut être une équipe dont la composition et les responsabilités ont changé, mais qui travaille encore sur une architecture pensée pour l’ancienne configuration. La mesure de la dette qui compte reste toujours relationnelle : ce que coûte sa modification dans le contexte de l’organisation qui doit la porter, bien plus que la complexité du code en lui-même.
Pour obtenir cette mesure sur votre code, l’audit de la dette technique la produit en environ quatre semaines : une cartographie des zones critiques classées par fréquence de changement et impact business, avec un plan d’action à 90 et 180 jours.
Le cinquième article de cette série aborde l’étape suivante : comment réduire la dette technique avec des stratégies qui fonctionnent vraiment, sans bloquer la livraison pendant l’intervention.