Pourquoi le format est plus souvent négligé que le contenu
Un format de rapport de bug, c'est 10 champs fixes répartis en quatre groupes : identité → environnement → symptôme → preuves. Une fois l'ordre fixé, un développeur sait immédiatement où chercher, sans vous redemander. Vous trouverez ci-dessous la liste complète des champs, les règles de rédaction avec de bons et de mauvais exemples pour chacun, et les 7 erreurs de format qui ruinent discrètement des rapports par ailleurs corrects.
La même information rédigée dans un autre format coûte deux fois plus de temps à traiter. Un format incohérent provoque trois problèmes :
La valeur d'un format n'est pas dans son aspect rangé, mais dans le fait que le même champ se trouve toujours au même endroit.
Le format standard d'un rapport de bug : 10 champs
| # | Champ | Rôle | Obligatoire ? | Comment le rédiger |
|---|---|---|---|---|
| 1 | Titre | Permet au développeur de décider s'il ouvre le ticket | Obligatoire | Composant + action + résultat inattendu + condition (voir exemples de titres de bug) |
| 2 | ID | Permet à tous de référencer le même enregistrement | Obligatoire (auto) | BUG-0042, jamais « celui de tout à l'heure » |
| 3 | Gravité / Priorité | Base de la planification | Recommandé | La gravité mesure le dommage, la priorité l'urgence métier — à garder séparées |
| 4 | Environnement | Détermine si le rapport est reproductible | Obligatoire | URL, version du navigateur, OS, appareil, résolution, compte |
| 5 | Prérequis | L'état de départ pour la reproduction | Recommandé | « Connecté en compte entreprise, 2 articles déjà dans le panier » |
| 6 | Étapes de reproduction | Amène quelqu'un au même écran | Obligatoire | Numérotées, une action par étape (voir rédiger les étapes de reproduction) |
| 7 | Résultat attendu | Base pour décider « est-ce un défaut ? » | Obligatoire | Décrivez ce qui devrait se passer, jamais « ça ne fonctionne pas correctement » |
| 8 | Résultat obtenu | Description factuelle | Obligatoire | Symptôme + chiffres + texte exact de l'erreur, sans spéculation |
| 9 | Preuves | Évite au développeur de tout rejouer | Fortement recommandé | Captures annotées, enregistrement d'écran, logs console, requêtes en échec |
| 10 | Notes | Contexte supplémentaire | Optionnel | Fréquence, contournements, tickets liés |
Comment rédiger chaque champ
Identité : titre, ID, gravité et priorité
- Titre : une ligne couvrant où, ce que vous avez fait, ce qui a mal tourné et sous quelle condition. 40 bons et mauvais exemples en vis-à-vis : exemples de titres de bug.
- ID : laissez le système le générer. La numérotation manuelle produit toujours des doublons.
- Gravité vs priorité : le duo le plus souvent fusionné en un seul champ.
| Champ | Question à laquelle il répond | Qui décide | Exemple |
|---|---|---|---|
| Gravité | Quel dommage le défaut lui-même cause-t-il ? | Testeur / déclarant | Perte de données = critique ; une faute de frappe = mineure |
| Priorité | Quand allons-nous le corriger ? | Produit / lead technique | Une faute de frappe dans le bandeau principal en semaine de lancement = priorité haute |
Environnement : environnement et prérequis
Le champ environnement doit couvrir les six éléments : URL, navigateur et version, système d'exploitation, appareil, résolution ou viewport, et type de compte. Écrire « Chrome » seul revient à n'écrire rien — les différences de comportement entre versions de navigateur sont banales sur le web.
Le prérequis le plus souvent oublié n'est pas l'état de connexion mais l'état des données : « 2 articles dans le panier », « compte au 3e jour de l'essai », « une première demande de remboursement a déjà été faite sur cette commande ». C'est exactement ce qui bloque la reproduction.
Symptôme : étapes de reproduction, résultat attendu et résultat obtenu
- Étapes de reproduction : numérotées, une action par étape, des données réelles. La méthode complète est dans rédiger les étapes de reproduction.
- Résultat attendu : décrivez ce qui devrait se produire et citez la source quand c'est possible (une exigence, l'identifiant d'un critère d'acceptation, ou simplement la logique métier). « Ça devrait marcher correctement » renvoie le jugement au développeur.
- Résultat obtenu : uniquement des faits, avec chiffres et texte exact de l'erreur. Aucune spéculation — les hypothèses du type « probablement un problème de cache » vont dans les notes, marquées « suspecté ».
Preuves : captures / enregistrements / logs, et notes
- Les captures doivent être annotées : entourez la zone du problème et ajoutez flèches ou texte, pour éviter de parcourir une capture plein écran.
- Les enregistrements d'écran doivent durer 10 à 30 secondes et ne garder que le moment pertinent — un enregistrement de cinq minutes ne sera pas regardé.
- Les logs doivent contenir seulement l'utile : sorties console de niveau erreur, requêtes réseau en échec (HTTP ≥ 400), et les corps de requête et réponse de l'endpoint concerné.
- Les notes doivent porter deux éléments : la fréquence (systématique / intermittent, avec une probabilité) et un contournement éventuel.
Différences de format selon trois canaux
| Canal | Présentation des champs | Le piège |
|---|---|---|
| Outil de suivi (Jira / Linear / GitHub Issues) | Champs personnalisés + modèle de description | Les infos d'environnement placées en fin de description et noyées dans le texte — leur place est dans des champs dédiés |
| E-mail ou messagerie (envoyé à un client ou un intervenant externe) | Blocs de texte brut | Pas de TL;DR, et des pièces jointes nommées au hasard que le lecteur doit trier parmi une douzaine de fichiers |
| Tableur (Excel / Google Sheets / Feishu Bitable) | Une ligne par bug, colonnes = champs | L'ordre des colonnes ne correspond pas aux 10 champs, le filtrage et le tri deviennent inutilisables |
Le canal change, les champs non. Une information manquante n'est pas pardonnée parce qu'elle a été envoyée par e-mail.
7 erreurs de format qui ruinent un rapport
capture-1.png, que le déclarant lui-même ne saura plus associer trois jours plus tard.Checklist de format
Vérifiez chaque ligne avant d'envoyer :
- Les 10 champs sont présents, dans le même ordre que la dernière fois ?
- Les six éléments d'environnement (URL / navigateur / OS / appareil / résolution / compte) sont remplis ?
- Résultat attendu et résultat obtenu rédigés séparément ?
- Étapes numérotées, une action par étape ?
- Captures annotées et enregistrements sous 30 secondes ?
- Aucune spéculation non vérifiée dans le résultat obtenu ?
- Fréquence indiquée clairement (systématique / intermittent + probabilité) ?
FAQ
Existe-t-il un « format standard » de rapport de bug ?
Aucune norme sectorielle contraignante n'existe, mais un consensus de fait oui : titre, environnement, étapes de reproduction, résultat attendu, résultat obtenu et preuves figurent dans pratiquement tous les référentiels (IEEE 829, ISTQB et la plupart des modèles de défaut commerciaux). Les 10 champs ci-dessus complètent ce socle avec l'identité et les notes.
Peut-on modifier l'ordre des champs ?
Oui, tant qu'il reste cohérent et stable dans l'équipe. L'intérêt d'un ordre fixe est la mémoire musculaire : les développeurs savent où balayer. Changer souvent l'ordre nuit plus qu'un ordre sous-optimal.
Quelle est la vraie différence entre gravité et priorité ?
La gravité décrit le dommage objectif du défaut (jugé par le test), la priorité l'urgence de la correction (jugée par le produit). Les deux peuvent diverger : une faute de frappe dans le bandeau principal a une gravité faible, mais si le lancement est dans trois jours, sa priorité est haute.
Un bug simple a-t-il vraiment besoin des 10 champs ?
Non. Un bug simple peut se contenter du titre, de l'environnement et du résultat obtenu — mais jamais sans l'environnement, première cause des tickets « impossible à reproduire ». Les champs sont optionnels, leur emplacement ne l'est pas.
Quelle différence entre un « format » et un « modèle » ?
Un format est la spécification des champs : lesquels existent, dans quel ordre, et comment chacun se rédige. Un modèle est un fichier squelette que l'on copie et remplit. Les deux fonctionnent ensemble : définir les champs par le format, puis les livrer sous forme de modèle. Pour le squelette à remplir, voir modèle de rapport de bug (versions Word et Markdown).
Le format peut être automatisé, le jugement reste à vous
Pour être précis sur la frontière : BugCapturer ne décide pas ce qui constitue un défaut et ne rédige pas votre titre — cela demande votre compréhension de ce que vous avez observé. En revanche, ce que l'on oublie et ce qui coûte du temps peut se remplir seul :
- Contexte technique automatique : URL, navigateur, système d'exploitation, résolution d'écran et taille de viewport sont écrits dans le champ environnement, sans recopie manuelle.
- Données de diagnostic : les logs console de niveau erreur et les requêtes réseau en échec (HTTP ≥ 400) sont collectés, avec anonymisation automatique des paramètres sensibles (jetons, mots de passe, clés d'API).
- Captures annotées : sélectionnez la zone puis ajoutez flèches, cadres et texte — « où c'est faux » reste figé dans l'image.
- Enregistrement d'écran : capturez l'onglet courant et découpez le clip, pour transmettre une courte vidéo vérifiable.
- Partager ou synchroniser : générez un lien de partage ouvrable sans inscription par des intervenants externes, ou poussez le rapport vers Feishu Bitable ou un webhook générique.
Le jugement reste le vôtre. Le reste, l'outil s'en charge.
Pour aller plus loin
- Modèle de rapport de bug : tous les champs avec un squelette à copier
- Exemples de titres de bug : 40 bons et mauvais titres comparés
- Rédiger les étapes de reproduction : 5 exemples complets
- Signaler les bugs efficacement
- Checklist QA de site web