Dette de test et dette qualité : ce que tu peux mesurer sans être développeur
Brouillon du blog Shift Op, article 4 sur 5 de la série « Piloter la qualité » · @October 12, 2026 · @Jeff
Chaque sprint, l'équipe ajoute des tests automatisés. Personne ne sait combien sont instables, combien ont été désactivés « temporairement » il y a six mois, ni combien ne protègent plus aucun risque réel. La suite grossit, le rapport reste vert, et la dette s'accumule sans apparaître nulle part.
Cet article porte sur la troisième couche d'un tableau de bord qualité : celle qui explique les deux premières. Tu n'as pas besoin d'être développeur pour y lire des signaux utiles. Je distingue d'abord de quelle dette on parle, puis je liste ce que tu peux compter toi-même et ce que tu peux en décider.
Cet article fait partie d'une série de cinq articles sur le pilotage de la qualité : métriques, reporting et décisions. C'est le quatrième. Les cinq articles se lisent idéalement dans l'ordre, mais chacun reste utile pris isolément.
De quelle dette parle-t-on ?
Le mot « dette » recouvre trois choses qu'il vaut mieux séparer.
- La dette technique concerne le code de l'application : modules fragiles, couplage, raccourcis pris pour livrer.
- La dette de test concerne la suite de tests : tests instables, désactivés, obsolètes, lents ou redondants.
- La dette qualité concerne les défauts connus qu'on a laissés ouverts, et les risques acceptés sans que personne en garde la trace.
Pour la première, méfie-toi des chiffres trop précis. Les outils d'analyse statique en affichent, mais il s'agit d'estimations. SonarQube, par exemple, définit la dette technique comme la somme des coûts de correction des problèmes de maintenabilité, chaque coût étant un effort en minutes évalué pour corriger le problème. Son ratio de dette compare cette somme à un coût de développement fixé par défaut à 30 minutes par ligne de code (documentation SonarQube sur les métriques). C'est un modèle utile pour repérer des zones, pas une mesure exacte de ce que coûterait un chantier.
Je ne te propose donc pas de mesurer la dette technique elle-même. Je te propose de suivre ses symptômes, ceux que tu observes dans les tests et dans les bugs. Ils sont plus simples à compter, et plus faciles à relier à une décision.
Six signaux que tu peux mesurer
Signal | Ce qu'il montre | Comment le compter | Décision qu'il éclaire |
Part de tests instables | Des tests dont le résultat change sans changement de code | Tests réussis seulement à la relance, dans l'historique de ton outil d'intégration continue | Stabiliser avant d'ajouter de nouveaux tests |
Tests désactivés ou mis de côté | Des risques qui ne sont plus protégés | Nombre et ancienneté, depuis le code ou le rapport de tests | Réparer, supprimer, ou assumer l'abandon |
Âge des bugs ouverts par gravité | Des défauts connus qui traînent | Date de création dans l'outil de suivi | Traiter ou accepter explicitement |
Part de capacité absorbée par la correction de bugs | Le poids du passé sur le futur | Temps passé en correction contre temps passé sur les nouvelles fonctionnalités, dans le planning | Arbitrer entre livrer et assainir |
Modules à défauts récurrents | Des zones fragiles | Un champ composant dans les bugs, compté par module | Où investir en tests ou en refonte |
Défauts acceptés sans décision tracée | Une dette qualité que personne ne porte | Bugs fermés sans correction ni propriétaire identifié | Documenter qui a accepté quoi, et jusqu'à quand |
Les mesurer sans outil coûteux
Aucun de ces signaux n'exige un outil spécialisé. Il faut surtout de la discipline sur trois habitudes.
Repérer les tests instables dans l'historique. Certains outils les classent déjà. Playwright, par exemple, appelle « flaky » un test qui échoue puis réussit à la relance, et distingue ce résultat de « passed » et de « failed » (documentation des relances). Si tu relances les tests en CI, ne laisse pas le rapport redevenir vert sans compter ces cas.
Garder une trace des tests mis de côté. Quand quelqu'un désactive un test, il y associe une raison, une personne et une date. Sans cela, « temporaire » devient une dette permanente.
Ajouter un champ composant dans les bugs. C'est le geste le plus rentable pour détecter les zones fragiles : un simple comptage par module révèle où les défauts reviennent.
Voici ce que cela donne sur la boutique fictive, avec des valeurs inventées pour l'exemple. La suite compte 200 tests automatisés, dont 14 instables : 7 %. Neuf tests sont désactivés, dont quatre depuis plus de six mois. Le module de paiement concentre la moitié des bugs rouverts du trimestre.
Le chiffre isolé ne dit rien. Rapproché des deux autres, il raconte une histoire : la partie la plus sensible de la boutique est aussi celle qui s'effrite, et on a laissé des tests dormir sur des risques que le rapport de cette semaine présente comme couverts.
Pour situer l'ordre de grandeur de l'instabilité, un article de Google sur ses propres tests indique qu'environ 16 % d'entre eux présentent un certain niveau d'instabilité et qu'environ 1,5 % des exécutions donnent un résultat instable (Flaky Tests at Google). C'est le contexte d'une très grande organisation, pas une norme à viser.
Que faire quand un signal passe au rouge
Un signal sans règle de décision reste un commentaire. Voici des règles d'exemple, à régler selon ton contexte. Ce ne sont pas des normes.
- Les tests instables dépassent un seuil que vous avez fixé ensemble : on suspend l'ajout de nouveaux tests automatisés et on stabilise. Décide le responsable de l'automatisation avec le lead de l'équipe.
- Un test est désactivé depuis plus de trois mois : on le répare ou on le supprime en notant le risque qu'on accepte. Décide le porteur du risque, pas la personne qui l'a mis de côté.
- Des bugs critiques restent ouverts au-delà d'un délai convenu : on remet le sujet au product owner, avec l'impact attendu. C'est une décision d'arbitrage, pas un sujet de test.
- Un module concentre les défauts récurrents : on ouvre une analyse des causes avec les développeurs avant d'ajouter d'autres tests dessus.
Trois précautions. La première : ne vise pas zéro. Une dette que l'équipe a choisie en connaissance de cause, avec un responsable et une date de revue, est un arbitrage. La deuxième : n'utilise pas ces chiffres pour classer des personnes, sinon ils disparaissent des rapports. La troisième : reviens sur les seuils après chaque incident, comme on l'a vu dans le premier article, pour qu'ils restent liés à un risque réel.
À retenir
- Distingue dette technique, dette de test et dette qualité. Le QA mesure surtout les deux dernières, à travers leurs symptômes.
- Les chiffres de dette technique des outils d'analyse sont des estimations : utilise-les pour repérer des zones, pas pour chiffrer un chantier.
- Six signaux suffisent à démarrer : tests instables, tests désactivés, âge des bugs, capacité absorbée par la correction, modules à défauts récurrents, défauts acceptés sans trace.
- Chaque signal appelle une règle de décision et un décideur identifiés, pas seulement un seuil.
- Une dette choisie, documentée et révisée est un arbitrage. Une dette ignorée est un risque.
FAQ
Faut-il utiliser un outil d'analyse statique ?
Ce n'est pas indispensable pour suivre les signaux de cet article. Si les développeurs en ont un, demande-leur ses résultats pour repérer des zones à surveiller, en gardant en tête que sa dette est une estimation.
Quel taux de tests instables est acceptable ?
Il n'existe pas de seuil universel. Les chiffres de Google donnent un ordre de grandeur pour une très grande organisation, pas un objectif. Fixe le tien en observant ton équipe, puis regarde si la tendance monte ou baisse.
Faut-il supprimer les tests désactivés ?
Si le risque qu'ils protégeaient n'existe plus, oui. S'il existe encore, répare-les. Dans les deux cas, décide avec une date plutôt que de laisser le test dormir.
La dette de test se résume-t-elle aux tests instables ?
Non. Un test lent, redondant ou obsolète coûte aussi du temps et de la confiance. Les tests instables sont simplement les plus faciles à repérer.
Comment obtenir du temps pour traiter la dette ?
Parle en décisions, comme dans le premier article. Montre un incident récent lié à un module fragile, la part de capacité déjà absorbée par la correction, et ce que coûte de ne rien faire. Laisse l'équipe choisir le niveau de risque qu'elle accepte.
La suite de la série
Le dernier article réunit les trois couches dans un tableau de bord qui déclenche des décisions, avec le rituel qui le fait vivre. Retrouve-le sur la newsletter La Guilde : laguilde.substack.com.