Un bon rapport de bug finit corrigé. Un mauvais reçoit l'étiquette « impossible à reproduire », une demande de précisions à laquelle son auteur ne répond jamais, puis meurt lentement au fond du backlog. La différence tient rarement à l'effort fourni. Elle tient à ce que l'auteur sait des besoins de la personne qui va corriger le bug.
Voici la structure d'un rapport qui survit au tri, que vous le rédigiez vous-même ou que vous appreniez à vos utilisateurs et à votre équipe à en écrire de meilleurs.
Anatomie d'un rapport utile
Un titre qui décrit le problème, pas le ressenti
« Le paiement est cassé » n'apprend rien au développeur. « Paiement : après un code promo, cliquer sur Payer affiche un spinner qui tourne sans fin » lui dit où chercher, quoi essayer, et le met sur la piste du déclencheur. Un bon titre donne l'endroit, l'action et le résultat observé.
Étapes de reproduction
Écrivez la séquence la plus courte qui déclenche le bug, en partant d'un état connu :
Se connecter en tant que client avec un article dans le panier
Appliquer le code promo SAVE10
Cliquer sur Payer
La numérotation compte, parce que la personne qui corrige suivra les étapes à la lettre. Si l'étape 2 est indispensable et que vous l'omettez, le bug se reproduit chez vous mais pas chez elle, et vous voilà bloqués tous les deux.
Comportement attendu et comportement observé
Deux lignes courtes : ce qui aurait dû se passer, et ce qui s'est passé à la place. Ça paraît bureaucratique, jusqu'au jour où l'auteur du rapport et le développeur ne s'entendent pas sur ce qui est « correct ». « Attendu : page de confirmation de commande. Observé : spinner sans fin, aucune activité réseau après le clic » lève l'ambiguïté.
L'environnement
Navigateur et version, système d'exploitation, appareil, taille d'écran et URL exacte de la page. Un nombre énorme de bugs front-end dépendent de l'environnement : une date mal parsée uniquement dans Safari, une mise en page qui ne casse qu'en largeur tablette. Sans ces données, le développeur teste dans son propre navigateur, ne voit rien et ferme le rapport.
Les preuves
C'est ce qui sépare un rapport diagnostiqué en cinq minutes d'un rapport qui demande une journée :
La sortie de la console : le vrai message d'erreur et la stack trace, pas une paraphrase.
L'activité réseau : quelle requête a échoué, avec quel code de statut.
Une capture d'écran ou un enregistrement : surtout pour les bugs visuels et de mise en page, où mille mots valent vraiment moins qu'une image.
Le moment : quand c'est arrivé, pour recouper avec les logs serveur et les déploiements.
Pourquoi les utilisateurs ne feront rien de tout ça
Ce qui coince, c'est que cette checklist est raisonnable pour un ingénieur QA et absurde pour un utilisateur. Les utilisateurs ne savent pas ce qu'est une console, ne vont pas chercher la version de leur navigateur et n'écriront pas d'étapes de reproduction. De bonne foi, le mieux qu'ils puissent écrire, c'est « ça ne marche pas ». Et chaque champ ajouté à un formulaire de bug vous fait perdre encore des rapports.
Il reste deux options. Accepter des rapports vagues et en payer le prix au moment du tri. Ou collecter automatiquement la moitié technique du rapport et laisser l'utilisateur apporter ce que lui seul sait : ce qu'il essayait de faire.
C'est sur ce modèle que reposent les widgets de signalement de bugs. Avec un outil comme BugDump, l'utilisateur clique sur un bouton et tape une phrase ; le widget joint de lui-même les logs de la console, les requêtes réseau, la relecture de session, les détails de l'environnement et l'URL de la page. L'utilisateur écrit « j'ai cliqué sur payer, rien ne s'est passé », et ça suffit : l'exception non interceptée et la requête en échec sont là, dans le rapport.
La checklist
Pour les rapports qu'une personne rédige de bout en bout (QA interne, rapports de collègues, issues GitHub) :
Le titre donne l'endroit + l'action + le résultat observé
Étapes de reproduction numérotées, à partir d'un état de départ connu
Comportement attendu, en une ligne
Comportement observé, en une ligne
Environnement : navigateur + version, OS, appareil, viewport, URL
Erreurs de la console, copiées telles quelles
Requête réseau en échec et code de statut, s'il y en a
Capture d'écran ou enregistrement pour tout ce qui est visuel
Gravité et impact : qui tombe dessus, et à quelle fréquence ?
Pour les rapports venus des utilisateurs, la checklist change de forme. La plupart des cases devraient être cochées par l'outil, pas par une personne :
Une description dans les mots de l'utilisateur (le seul champ obligatoire)
Tout le reste (environnement, console, réseau, relecture) capturé automatiquement
L'identité de l'auteur jointe automatiquement pour les utilisateurs connectés, pour pouvoir revenir vers lui
Un rapport, un bug
Résistez à l'envie de tout regrouper. « Le tableau de bord est lent, le bouton d'export ne marche pas non plus, et le mode sombre s'affiche mal », ce sont trois bugs sous l'identifiant d'un seul rapport. Un rapport groupé ne se priorise pas (les gravités diffèrent), ne se ferme pas (corriger un bug laisse le rapport ouvert aux deux tiers) et ne s'assigne pas proprement. Créez trois rapports. Si votre outil range les rapports dans des tâches (BugDump transforme les rapports en cartes sur un tableau kanban), cette discipline paie tout de suite, car chaque carte avance de son côté.
Une gravité honnête
Notez la gravité selon l'impact, pas selon votre agacement. Une coquille qui vous gêne personnellement est de faible gravité ; un paiement qui échoue dans un seul navigateur est de gravité élevée, même si vous n'arrivez pas à le reproduire. Des rapports toujours marqués « critique » apprennent à l'équipe à ignorer complètement ce champ, ce qui est pire que de ne pas l'avoir.
Ce que ça rapporte
Les bons rapports de bug font boule de neige. Chaque rapport accompagné de vraies preuves est corrigé plus vite, ce qui garde le backlog court, donc le tri rapide, et laisse plus de temps pour les rapports vraiment difficiles. Et l'habitude est contagieuse : les développeurs qui reçoivent de bons rapports se mettent à en écrire.
Écrivez le rapport que vous aimeriez recevoir un vendredi à 17 h, et automatisez tout ce que son auteur ne devrait pas avoir à savoir fournir.
Pour aller plus loin
Un modèle de rapport de bug qui marche vraiment (et comment l'automatiser) — un modèle à copier, le rôle de chaque champ, et pourquoi retirer du formulaire tout ce qu'une machine peut remplir.
Que faire d'un rapport de bug impossible à reproduire — les causes habituelles, le contexte qui les éclaire et la façon d'éviter qu'elles reviennent.
Anatomie d'un rapport de bug – ce que BugDump capture et pourquoi — chaque signal que collecte le widget (console, réseau, relecture, actions, métadonnées) et ce qu'il apporte au débogage.