Mesurer la qualité produit : métriques utilisateur et business
Tes tests passent, ton rapport est propre, la livraison part. Deux semaines plus tard, le support voit arriver une vague de tickets sur les paiements refusés. Ton rapport avait raison sur ce qu'il mesurait. Il ne mesurait simplement rien de ce que vivent les utilisateurs.
Dans le premier article, on a vu qu'un chiffre utile répond à une décision. Ici, on prend la première couche d'un tableau de bord qualité : celle de l'utilisateur et du business. Je regarde quels indicateurs la composent, d'où viennent les données, qui les détient et comment les obtenir quand elles ne sont pas chez toi.
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 deuxième. Les cinq articles se lisent idéalement dans l'ordre, mais chacun reste utile pris isolément.
Ce que tu peux lire seul, et ce que tu dois demander
La plupart des données qui disent ce que vit l'utilisateur ne sont pas produites par la QA. Les incidents de production sont dans les outils d'exploitation, les plaintes dans l'outil de support, l'abandon d'un parcours dans les statistiques du produit. Ton rapport de tests habituel n'y touche pas. C'est la raison pour laquelle cette couche est souvent absente des tableaux de bord qualité : personne ne l'a demandée.
Un indicateur, en revanche, est à ta portée dès maintenant : le taux d'échappement. Dans ce texte, j'appelle ainsi la part des bugs découverts en production par rapport à tous les bugs découverts sur la même période, avant et après la mise en production. C'est une définition simple, il en existe d'autres. Elle suppose une seule chose : que chaque bug de ton outil de suivi dise où il a été trouvé.
Le reste, tu le demandes. Cela change ton rôle : tu ne produis plus seulement des résultats de tests, tu relies ce que tu sais du produit à ce que d'autres savent de ses utilisateurs.
Cinq indicateurs pour la couche utilisateur et business
Voici cinq indicateurs, avec l'endroit où chercher la donnée et la décision qu'ils éclairent. Tu n'as pas besoin de tous : mon repère pour cette couche est d'en suivre un à trois.
Indicateur | Ce qu'il dit | Où trouver la donnée | Décision qu'il éclaire |
Incidents de production qui touchent des utilisateurs, par gravité et par parcours | Ce qui a vraiment cassé pour eux | Outil d'incident, exploitation ou équipe de développement | Geler une livraison, renforcer les tests sur un parcours |
Taux d'échappement | La part des bugs que tes tests n'ont pas vus | Ton outil de suivi de bugs, à condition d'étiqueter l'origine | Où renforcer la détection |
Disponibilité, latence ou taux d'erreur sur les parcours critiques | Si le service tient sa promesse | Outils de supervision, équipe d'exploitation | Alerter, ralentir les livraisons |
Tickets de support par cause | Ce dont les utilisateurs se plaignent, dans leurs mots | Outil de support, équipe support | Prioriser les corrections et les tests |
Abandon sur un parcours clé, comme le paiement | Ce que le défaut coûte à l'activité | Statistiques du produit, équipe produit ou data | Mesurer l'impact business d'un défaut |
Le troisième indicateur vient d'un vocabulaire que les équipes d'exploitation connaissent bien. Le livre sur le métier de SRE publié par Google définit un indicateur de niveau de service (SLI) comme une mesure quantitative d'un aspect du service, et un objectif de niveau de service (SLO) comme la valeur cible de cet indicateur (chapitre sur les SLO). Il donne aussi un conseil qui s'applique à la QA : partir de ce qui compte pour les utilisateurs, pas de ce qu'on sait mesurer, et se limiter à une poignée d'indicateurs représentatifs.
Comment les obtenir sans bloquer personne
Le réflexe est de demander un accès à tous les outils. C'est la meilleure façon de recevoir un refus poli. Pose plutôt une question précise à une personne, sur un problème qu'elle a déjà.
Voici trois ouvertures possibles, pour la boutique fictive de cette série :
- À l'équipe support : « Quels sont les trois motifs qui reviennent le plus dans vos tickets depuis un mois, et sur quels parcours ? »
- À l'exploitation : « Quel incident de production vous a pris le plus de temps ce trimestre, et qu'est-ce qui l'a déclenché ? »
- Au produit : « Où les clients abandonnent-ils le plus dans le parcours d'achat ? »
Chaque question a deux qualités. Elle part de ce que l'autre connaît déjà, donc elle ne demande aucun travail supplémentaire. Et elle te donne un fait que tu peux relier à un test : le motif de ticket devient un risque à couvrir, l'incident devient un cas qui manquait.
Ensuite, propose à ton tour quelque chose. Par exemple, tu peux envoyer avant chaque livraison la liste des risques que tu connais, pour que le support sache quoi surveiller. L'échange devient réciproque, et on te donnera plus facilement un extrait régulier.
Commence petit : un indicateur, une personne, un mois d'observation. Si tu ne sais pas par où démarrer, prends le taux d'échappement. Il ne dépend de personne d'autre que de toi et de l'équipe de développement.
Lire ces chiffres sans te tromper
Reprenons le cas du début. La livraison de jeudi est partie avec le défaut connu sur les cartes refusées. Une semaine plus tard, le support compte 12 tickets sur le paiement alors qu'il en recevait 2 d'habitude (chiffres inventés pour l'exemple). Trois pièges guettent ta lecture.
Confondre corrélation et cause. Le pic suit la livraison, mais une campagne commerciale ou une panne du prestataire de paiement peut produire le même effet. Avant de conclure, vérifie la date, le parcours et le motif des tickets.
Lire l'absence de signal comme une bonne nouvelle. Peu de tickets ne veut pas dire peu de problèmes : beaucoup d'utilisateurs abandonnent sans rien signaler. C'est pourquoi un indicateur de support se croise avec un indicateur d'abandon ou d'erreur.
Se contenter d'une moyenne. Une latence moyenne correcte peut cacher une minorité d'utilisateurs très mal servis. Demande, quand c'est possible, comment se comportent les cas les plus lents.
Un dernier réflexe : change le moins possible la définition d'un indicateur en cours de route. Si le taux d'échappement se calcule autrement d'un mois à l'autre, personne ne saura plus s'il progresse. Quand tu dois en changer, écris la date et la raison.
Enfin, ces indicateurs ne mesurent pas ton travail seul. Un incident de production est un signal partagé par l'équipe. Le présenter comme un reproche fait fuir les données, le présenter comme une information fait venir les questions.
À retenir
- La couche utilisateur et business vit surtout hors de la QA : ton travail est de relier ce que tu sais du produit à ce que d'autres savent de ses utilisateurs.
- Le taux d'échappement est le point de départ le plus accessible, à condition d'étiqueter où chaque bug a été trouvé.
- Un à trois indicateurs suffisent : incidents de production, tickets de support par cause, abandon sur un parcours clé, ou un SLI sur un parcours critique.
- Obtiens les données par une question précise sur un problème que l'autre connaît déjà, pas par une demande d'accès.
- Ne conclus pas à partir d'un pic ou d'un silence : croise les sources et garde la même définition d'un mois à l'autre.
FAQ
La QA est-elle responsable des incidents de production ?
Elle n'en est pas la seule responsable. Un incident est un signal partagé avec le développement, l'exploitation et le produit. Il t'aide à voir où ta détection est faible, il ne te donne pas la décision de livrer ou non, qui appartient à ceux qui la portent.
Que faire si je n'ai accès à aucune donnée de production ?
Commence par ton outil de suivi de bugs : ajoute un champ qui indique si le bug a été trouvé avant ou après la mise en production. Puis pose une question à une personne du support ou de l'exploitation.
Combien d'indicateurs faut-il dans cette couche ?
Mon repère est d'un à trois. Plus, et personne ne sait lequel regarder en premier.
Quelle différence entre SLI, SLO et SLA ?
Dans le vocabulaire de Google, un SLI est la mesure d'un aspect du service, comme la latence ou le taux d'erreur. Un SLO est la valeur cible fixée pour cet indicateur. Un SLA est un accord avec les utilisateurs qui prévoit des conséquences si les objectifs ne sont pas tenus (chapitre sur les SLO). En tant que QA, tu n'as pas besoin de les définir seul : demande ceux qui existent déjà.
Mes bugs ne sont pas étiquetés. Comment calculer le taux d'échappement ?
N'essaie pas de reconstituer tout l'historique. Étiquette les nouveaux bugs dès maintenant, et calcule le taux sur une période récente que tu peux vérifier à la main.
La suite de la série
L'article suivant passe à la deuxième couche : la fluidité de la livraison, avec le vocabulaire actuel de DORA et ce que le QA peut y lire ou influencer. Pour ne pas le rater, abonne-toi à la newsletter La Guilde : laguilde.substack.com.