Un mauvais rapport de bug se fait rejeter, réassigner ou ignorer. Un bon se fait corriger dès la première tentative. La différence ne tient pas à la chance. Elle repose sur un ensemble prévisible d'éléments que tout rapport efficace contient.

Pourquoi les rapports de bugs échouent

Le résultat le plus courant d'un rapport mal rédigé : le développeur l'ouvre, ne peut pas reproduire le problème, le marque "Impossible à reproduire" et passe à autre chose. Le bug existe toujours. Vous avez perdu du temps. Le développeur est légèrement agacé. Personne n'y gagne.

Le deuxième résultat le plus courant : le développeur le reproduit mais ne comprend pas l'impact, le déprioritise, et il passe en production.

Ces deux échecs sont évitables.

L'anatomie d'un rapport de bug qui se fait corriger

Titre : une phrase, sans termes vagues

Le titre est ce qui apparaît dans Jira ou quel que soit l'outil de votre équipe. Il doit dire à un développeur qui parcourt une liste de tickets exactement quel est le bug, sans l'ouvrir.

Mauvais titres :

  • "Bug de connexion"
  • "Quelque chose est cassé sur le tableau de bord"
  • "Problème de message d'erreur"
  • "Tableau qui ne fonctionne pas correctement"

Bons titres :

  • "Le formulaire de connexion se soumet avec un champ mot de passe vide : aucune erreur de validation affichée"
  • "Le tableau du tableau de bord perd l'ordre de tri après un filtrage par statut"
  • "L'upload de fichier affiche un toast 'Succès' même quand l'upload échoue avec une erreur 413"
  • "Le nombre de lignes du tableau des éléments diffère de la réponse API quand la page est chargée avec un filtre actif"

Le pattern : [composant/fonctionnalité] [ce qui se passe] [quand/dans quelle condition]. Tout ce qu'un développeur a besoin pour comprendre le périmètre du problème, avant même de cliquer pour l'ouvrir.

Environnement : exactement où ça se produit

Vague : "Chrome sur Windows"

Utile :

Navigateur : Chrome 124.0.6367.78 (Windows 11)
OS : Windows 11 22H2
Version / build de l'app : v2.4.1 (commit : abc123)
Environnement de test : staging (https://staging.lab.becomeqa.com)
Utilisateur de test : admin@becomeqa.com

Les détails d'environnement semblent fastidieux jusqu'au moment où vous essayez de reproduire un bug qui n'apparaît que dans Firefox sur macOS. Quand vous avez passé 20 minutes sous Chrome sur Windows à vous demander pourquoi ça ne plante pas, vous comprenez.

Étapes de reproduction : exactes, numérotées, autonomes

Chaque étape doit être suffisamment précise pour que quelqu'un qui n'a jamais vu ce bug puisse le reproduire à la première tentative.

Mauvais :

1. Se connecter
2. Aller dans les éléments
3. Trier et filtrer
4. Le bug apparaît

Bon :

Préconditions : l'utilisateur est connecté en tant qu'admin@becomeqa.com.
Le tableau des éléments affiche la vue par défaut (aucun filtre actif).

Étapes :
1. Naviguer vers https://lab.becomeqa.com/dashboard
2. Cliquer sur l'en-tête de colonne "Statut" pour trier par ordre croissant
3. Cliquer sur le menu déroulant "Filtrer" et sélectionner "Planifié"
4. Cliquer à nouveau sur l'en-tête de colonne "Statut" pour trier par ordre décroissant
5. Supprimer le filtre en cliquant sur "Effacer" dans le menu déroulant

Résultat attendu : le tableau revient à la vue par défaut affichant tous les éléments,
triés selon le dernier ordre (Statut décroissant).

Résultat obtenu : le tableau affiche tous les éléments mais l'ordre de tri 
se réinitialise par défaut (non trié), perdant l'état de tri de l'étape 2.

La différence : la première version oblige le lecteur à deviner ce que "trier et filtrer" signifie. La seconde n'exige aucune supposition.

Résultat attendu vs résultat obtenu : les deux sont obligatoires

Tout rapport de bug a besoin des deux :

Résultat attendu : ce qui devrait se passer selon la spécification, le bon sens, ou l'intention du développeur. S'il existe une exigence documentée, citez-la. "Selon les critères d'acceptation dans PROJ-142, le filtrage ne devrait pas affecter l'état du tri." Résultat obtenu : ce qui se passe réellement. Soyez précis. "Affiche une erreur" est faible. "Affiche 'Erreur interne du serveur' dans un toast rouge en haut de la page pendant 3 secondes" est utile.
N'écrivez pas "Attendu : ça fonctionne. Obtenu : ça ne fonctionne pas." C'est le problème le plus courant dans les rapports de bugs juniors. Le résultat attendu doit décrire le comportement correct spécifique, pas simplement "que ça fonctionne".

Sévérité et priorité : deux choses distinctes

La sévérité est l'impact sur le système : à quel point ce bug est-il grave techniquement ?
  • Critique : crash du système, perte de données, vulnérabilité de sécurité, bloque une fonctionnalité centrale pour tous les utilisateurs
  • Majeure : fonctionnalité significative cassée pour un sous-ensemble d'utilisateurs, avec contournement possible
  • Mineure : petit problème fonctionnel, cosmétique, peu susceptible d'affecter beaucoup d'utilisateurs
  • Triviale : faute de frappe, légère incohérence UI, aucun impact fonctionnel
La priorité est l'urgence métier : dans quel délai faut-il corriger ?

Une faute de frappe sur la page d'erreur d'un produit de santé peut être de sévérité Mineure mais de priorité Haute (question réglementaire). Une fonctionnalité admin cassée peut être de sévérité Majeure mais de priorité Faible (utilisée une fois par mois par 2 personnes).

Définir la sévérité et la priorité avec précision montre que vous comprenez l'impact métier, pas seulement le comportement technique.

Pièces jointes : montrez, ne dites pas seulement

Les captures d'écran capturent le résultat obtenu visuellement. Une capture qui montre le mauvais toast vaut plus que trois phrases pour le décrire.

Les enregistrements vidéo sont indispensables pour les bugs liés au timing : conditions de course, glitches d'animation, échecs intermittents. Un logiciel d'enregistrement d'écran (Loom, OBS, ShareX) prend 30 secondes à configurer et évite des heures de "Impossible à reproduire".

Les logs réseau (depuis DevTools du navigateur > onglet Réseau) sont essentiels pour les bugs au niveau de l'API. Ils montrent exactement quelle requête a été envoyée, quelle réponse est revenue, et le timing.

Les logs de console contiennent souvent l'erreur qui explique le bug. Les développeurs peuvent identifier immédiatement la cause racine à partir d'une stack trace d'erreur JavaScript.

Pour les bugs intermittents, enregistrez une vidéo à la première reproduction. Ne supposez pas que vous pourrez reproduire à nouveau pour le développeur.

Un exemple complet

Voici à quoi ressemble un rapport de bug bien rédigé :

Titre : La modale d'upload de fichier affiche un toast "Upload réussi" quand le fichier dépasse la limite de 5 Mo Environnement :
  • Navigateur : Chrome 124, Firefox 125
  • OS : Windows 11
  • Build : v2.4.1
  • Environnement : staging
Préconditions : utilisateur connecté en tant qu'admin@becomeqa.com Étapes de reproduction :

1. Naviguer vers https://staging.lab.becomeqa.com/dashboard

2. Cliquer sur le bouton "Uploader un fichier"

3. Sélectionner un fichier supérieur à 5 Mo (par ex. un .pdf de 10 Mo)

4. Cliquer sur "Uploader" dans la modale

Résultat attendu : l'upload échoue avec un message de validation indiquant que la taille du fichier doit être inférieure ou égale à 5 Mo. Le fichier n'est pas uploadé. Le toast de succès n'apparaît pas. Résultat obtenu : la modale se ferme, un toast "Upload réussi" apparaît brièvement. En naviguant vers la section Fichiers, le fichier n'est pas présent, indiquant que l'upload a échoué silencieusement. Aucune erreur n'est communiquée à l'utilisateur. Sévérité : Majeure. Les utilisateurs perdent leur upload sans aucun retour, et peuvent ne pas réaliser que le fichier n'a pas été sauvegardé. Priorité : Haute. Affecte tout utilisateur tentant d'uploader des fichiers dépassant la limite de taille. Pièces jointes : [capture d'écran montrant le toast de succès] [log réseau montrant la réponse 413]

Ce rapport donne à un développeur tout ce dont il a besoin : reproduction exacte, comparaison claire attendu/obtenu, évaluation précise de la sévérité, et preuves.

Erreurs courantes à éviter

"Ça ne fonctionne pas" sans dire ce qui devrait se passer. Spécifiez toujours le comportement attendu. Des étapes qui supposent des connaissances. "Se connecter en tant qu'admin." Lequel ? Quelle URL ? Quels identifiants ? Les préconditions manquantes. Les bugs qui n'apparaissent qu'avec certaines données, certains rôles utilisateur, ou après certaines actions préalables nécessitent ce contexte dans la section des préconditions. Les titres en une ligne. "Bug de paiement soumis." Soumis contre quel scénario ? L'inflation de sévérité. Appeler tout Critique rend Critique sans signification. Réservez-le aux pertes de données, problèmes de sécurité, et fonctionnalités complètement cassées pour tous les utilisateurs. L'absence de nettoyage des données de test. Si vos étapes de reproduction ont créé des données de test (un nouvel utilisateur, une commande, un fichier), notez-le. Quelqu'un devra faire le nettoyage sans forcément avoir accès à la base de données.

FAQ

Dois-je rédiger des rapports de bugs pour chaque problème que je trouve ?

Loguez tout ce qui ne fonctionne pas comme prévu. Les développeurs et les product owners peuvent fermer ou déprioritiser, mais ils ne peuvent pas corriger ce qu'ils ne connaissent pas. L'exception : les choses dont vous n'êtes pas sûr qu'elles soient des bugs. Soulevez-les d'abord dans un commentaire ou un message rapide.

Que faire si je ne peux pas reproduire le bug de façon cohérente ?

Loguez-le quand même. Notez dans le rapport : "Intermittent : reproduit 3 fois sur 10 tentatives. Déclencheur cohérent non identifié." Joignez une vidéo d'une reproduction. Un bug intermittent logué vaut mieux qu'un bug non logué.

À quel niveau de détail les étapes de reproduction doivent-elles être ?

Suffisamment détaillées pour qu'un développeur qui vient de rejoindre l'équipe puisse reproduire sans vous poser une seule question. Dans le doute, optez pour plus de détails.

Mon bug a été marqué "par conception". Avais-je tort ?

Pas nécessairement. "Par conception" signifie que le product owner a décidé que le comportement actuel est acceptable. C'est un résultat légitime. Ce qui compte, c'est que vous ayez documenté clairement le comportement. Si ça cause de la confusion chez les utilisateurs, cette conversation devrait avoir lieu avant que la décision produit soit prise, pas après.

→ See also: Comment Écrire un Cas de Test: Format, Exemples et Erreurs Courantes | Qu'est-ce que le Test Manuel? Guide Complet pour 2026