Pourquoi tes métriques QA ne changent aucune décision

Imagine un rapport qualité de fin de sprint : 94 % de taux d'exécution des tests, 847 cas exécutés, 23 bugs corrigés. Chaque chiffre est exact. Le management hoche la tête, la réunion passe à autre chose, et personne n'a décidé quoi que ce soit. Cet exemple est fictif, mais tu en as probablement lu un qui lui ressemble.

Un rapport peut être juste sans servir à rien. Dans cet article, je regarde pourquoi des métriques correctes finissent par ne changer aucune décision, et ce que tu peux faire dans ton contexte pour que les tiennes comptent.

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 premier. Les cinq articles se lisent idéalement dans l'ordre, mais chacun reste utile pris isolément.

Deux problèmes se cachent sous le même symptôme

Quand un rapport ne change rien, le réflexe est d'accuser ceux qui le lisent. Dans la pratique, deux causes différentes se mélangent, et elles ne se corrigent pas de la même façon.

Premier cas : la métrique ne répond à aucune décision. Taux d'exécution, nombre de cas, nombre de bugs corrigés : ces chiffres mesurent l'activité de test, pas la qualité du produit. Ils sont faciles à produire, faciles à communiquer et faciles à optimiser sans rien améliorer. On peut fermer des bugs sans les résoudre, exécuter des tests qui ne couvrent aucun risque important, ou afficher 100 % d'exécution sur une suite qui ne détecte plus rien.

Second cas : la métrique est utile, mais pas à celui qui la lit. Le taux de tests instables est précieux pour l'équipe. Présenté tel quel à un directeur, il reste du bruit, tant que personne ne lui dit ce que cela change pour la date de livraison.

Pour trier, pose quatre questions à chaque chiffre de ton rapport :

Quelle décision ce chiffre aide-t-il à prendre (livrer ou non, où investir, quel risque traiter cette semaine) ?
Quel risque couvre-t-il ?
Que fait-on s'il se dégrade (porte de qualité, gel des fonctionnalités, stabilisation de la CI) ?
Qui le lit, et que doit cette personne en faire ?

Reprends le rapport du début. Les 94 % d'exécution n'aident à décider de rien : les 6 % restants peuvent contenir le parcours de paiement, ou des cas sans importance, et le chiffre ne le dit pas. Il ne passe aucune des trois premières questions. Un chiffre dans ce cas ne sert pas à piloter la qualité, il rassure.

Une même donnée, trois lecteurs, trois versions

Prends une situation fictive. Sur la branche prévue en livraison jeudi, la suite de tests du paiement donne ce résultat : 41 tests exécutés, 38 réussis, 3 échoués. C'est exact, et c'est la version brute que beaucoup d'équipes envoient à tout le monde.

Voici ce que deviennent ces mêmes faits quand tu tiens compte de qui lit :

Lecteur	Sa question	Ce que tu lui écris
Direction ou sponsor de la date	Peut-on livrer jeudi ?	Le paiement est le parcours qui rapporte. Un défaut réel touche les cartes refusées. Livrer jeudi expose ces cas, la correction est en cours.
Product owner	Quels comportements utilisateur sont touchés ?	Un client dont la carte est refusée ne peut plus modifier sa commande. Les paiements acceptés ne sont pas concernés.
Équipe de développement	Qu'est-ce que je corrige ?	Un test révèle le défaut sur le refus de carte, trace jointe. Les deux autres échecs viennent d'un environnement de test indisponible : à relancer, pas à corriger.

Les trois lignes disent la même chose. Seuls changent le niveau de détail, le vocabulaire et la question à laquelle chaque version répond. Remarque aussi ce que la version brute cachait : sur les trois échecs, un seul est un défaut produit. Un compteur qui additionne les trois mélange un risque réel et un problème d'environnement.

Ton rôle est d'apporter les faits et le risque, sous une forme que chaque lecteur peut utiliser. La décision, elle, appartient à ceux qui la portent : livrer, corriger d'abord ou reporter se joue avec le product owner et le sponsor de la date, pas dans un tableau de bord.

Pourquoi les mauvaises métriques survivent

Si ces chiffres sont si peu utiles, pourquoi les retrouve-t-on partout ? Trois raisons reviennent.

Elles coûtent peu. Un taux d'exécution sort d'un outil de gestion de tests en quelques clics. Un taux d'échappement demande de relier des bugs apparus en production aux tests qui auraient dû les voir, ce qui prend du temps et suppose que d'autres équipes jouent le jeu.

Elles rassurent quelqu'un. Les chiffres actuels ont souvent été demandés par une personne, pour une bonne raison à l'époque. Les remplacer revient à dire que les précédents ne suffisaient pas, et personne n'aime l'entendre. Le sujet est donc autant politique que technique.

Elles deviennent des objectifs. Fixe un objectif de 100 % d'exécution et les équipes exécuteront d'abord les tests faciles. Fixe zéro bug ouvert et certains bugs seront fermés sans être résolus. DORA, la référence sur les métriques de livraison logicielle, met en garde contre ce travers : transformer une métrique en but pousse les équipes à la manipuler (page DORA sur les métriques). La page cite la loi de Goodhart, qui dit qu'une mesure cesse d'être bonne dès qu'elle devient une cible.

La troisième raison est la plus utile à retenir : un bon indicateur le reste seulement tant qu'il sert à décider, pas à être atteint.

Changer sans tout casser

Supprimer d'un coup les anciens chiffres est le moyen le plus sûr de crisper tout le monde. Voici une progression plus douce, en trois temps.

Ajoute avant de retirer. Garde le taux d'exécution dans le rapport et place à côté un indicateur qui parle d'un risque. La phrase à dire reste simple : « On continue à suivre le taux d'exécution, et on ajoute le taux d'échappement pour avoir une vision complète. » Les deux cohabitent un moment. Si le premier ne sert plus à personne, il disparaîtra de lui-même.

Pars d'un incident récent. Choisis un bug passé en production que tes rapports n'avaient pas annoncé, puis demande-toi quel chiffre l'aurait fait voir. C'est l'argument le plus fort pour montrer qu'un indicateur actuel a un angle mort, parce qu'il ne repose sur rien d'abstrait et que personne n'est mis en cause : on parle d'un symptôme que tout le monde a vu.

Présente chaque indicateur par la décision qu'il permet. Ne dis pas « on va suivre le taux d'échappement ». Dis plutôt « cet indicateur nous aide à décider si on peut livrer en production avec confiance ». Le lecteur n'a pas à apprendre ta métrique, il a seulement à comprendre ce qu'elle lui permet de trancher.

Une dernière précaution : n'en ajoute pas trop. Mon repère personnel est de partir de trois décisions récurrentes, de cinq risques majeurs et d'au plus huit indicateurs. C'est un point de départ, pas une norme. Si un rapport n'a que trois chiffres et que chacun déclenche une action, il vaut mieux qu'un tableau de bord de trente graphiques.

À retenir

Un rapport exact peut ne servir à rien : vérifie pour chaque chiffre la décision qu'il aide à prendre, le risque qu'il couvre et l'action qu'il déclenche.
Distingue deux problèmes : une métrique qui ne répond à aucune décision, et une métrique utile présentée à quelqu'un pour qui elle ne l'est pas.
Écris le même fait différemment pour la direction, le product owner et l'équipe : seul le détail change, pas la vérité.
Ne transforme pas un indicateur en objectif, il perd alors sa valeur.
Change par ajout, à partir d'un incident réel, et présente chaque nouveau chiffre par la décision qu'il permet.

FAQ

Faut-il supprimer le taux d'exécution ?

Pas tout de suite. Garde-le comme information de suivi, mais n'en fais plus ton argument de qualité. Quand plus personne ne l'utilise pour décider, tu pourras le retirer sans débat.

Combien d'indicateurs faut-il dans un rapport ?

Il n'y a pas de nombre universel. Mon repère de départ est de trois décisions, cinq risques et huit indicateurs au maximum. Si un indicateur ne déclenche aucune action, enlève-le.

Mon management exige ces chiffres. Que faire ?

Garde-les et ajoute à côté un indicateur lié à un risque, en expliquant la décision qu'il permet. Tu complètes le rapport au lieu de contredire ce qui existe.

Comment montrer l'angle mort d'un indicateur sans accuser personne ?

Pars d'un incident que tout le monde a vu et demande quel chiffre l'aurait annoncé. Tu parles d'un symptôme, pas d'une personne ni d'une décision passée.

Faut-il un seuil pour chaque indicateur ?

Oui, idéalement : une valeur cible, une valeur d'alerte et quelqu'un qui décide quoi faire quand elle est franchie. Sans cela, l'indicateur reste un commentaire. En revanche, ne recopie pas les seuils d'une autre équipe : observe quelques livraisons dans ton contexte avant de les fixer.

La suite de la série

Cet article pose le cadre. Les suivants prennent les métriques par couche : la qualité telle que la vit l'utilisateur, la fluidité de la livraison, la dette de test et la dette qualité, puis la construction d'un tableau de bord qui déclenche des décisions.

Pour aller plus loin

Si tu montes en responsabilité sans avoir vraiment été accompagné pour ça, c'est précisément pour cette situation que j'ai créé le Bootcamp Leader QA : découvrir le Bootcamp Leader QA.