Modèle de rapport de bug : Exemples gratuits téléchargeables (2026)

Qu'est-ce qu'un modèle de rapport de bug ?

Un modèle de rapport de bug est un formulaire standardisé qui capture tout ce dont un développeur a besoin pour comprendre, reproduire et corriger un défaut. Au lieu que chaque testeur rédige des rapports dans son propre style, un modèle garantit la cohérence — les mêmes champs, dans le même ordre, à chaque fois.

Le résultat est moins d'allers-retours, des corrections plus rapides et moins d'impasses du type « ça marche chez moi ». Que vous l'appeliez modèle de bug, modèle de suivi de bug ou rapport de défaut, l'objectif est identique : donner aux développeurs des informations exploitables dès le départ.

Le modèle de rapport de bug (prêt à copier-coller)

Voici un modèle de rapport de bug que vous pouvez copier directement dans votre outil de suivi, votre courriel ou votre documentation :


Title:        [Short, specific summary of the issue]
ID:           [BUG-0001]
Reporter:     [Your name]
Date:         [YYYY-MM-DD]
Priority:     [Critical / High / Medium / Low]
Status:       [Open]

Environment:
  - URL:          [https://example.com/checkout]
  - Browser:      [Chrome 120, macOS 14]
  - Device:       [Desktop / iPhone 14]
  - Resolution:   [1920x1080]
  - User account: [test@example.com]

Steps to Reproduce:
  1. [Go to ...]
  2. [Click ...]
  3. [Enter ...]
  4. [Observe ...]

Expected Result:
  [What should have happened]

Actual Result:
  [What actually happened]

Screenshot:
  [Attach annotated screenshot highlighting the issue]

Screen Recording:
  [Attach short screen recording (WebM/MP4) showing the bug in action]

Console Errors / Network Failures:
  [Paste any error-level console logs or failed network requests]

Notes:
  [Workarounds, frequency (always / intermittent), related tickets]

Exemples de titres de bug

Le titre est le champ le plus important — c'est ce que les développeurs parcourent en premier dans un backlog. Un bon titre de bug est spécifique, nomme le composant et décrit le dysfonctionnement. Vous trouverez ci-dessous des exemples de titres de bug montrant la différence entre un titre faible et un titre fort.

Titres faibles (à éviter) :

« Bouton cassé »
« Erreur »
« Ça ne marche pas »
« Bug sur la page d'accueil »

Titres forts :

« Le bouton 'Valider' du paiement fige la page pendant 5s puis affiche un écran blanc sur Safari mobile »
« L'upload de l'avatar du profil renvoie une erreur 500 lorsque le fichier dépasse 5 Mo »
« Le sélecteur de date chevauche le bouton 'Enregistrer' sur les écrans de moins de 768 px »
« Le formulaire d'inscription à la newsletter se soumet deux fois en appuyant sur la touche Entrée »

Un modèle utile est : [Composant] + [Action] + [Résultat inattendu] + [Condition]. Par exemple, « Le compteur du panier ne se met pas à jour après la suppression du dernier article sur Firefox. »

Étapes pour reproduire un bug : exemple

Des étapes de reproduction vagues sont la cause numéro un des tickets « impossible de reproduire ». Voici un exemple d'étapes pour reproduire un bug bien rédigé :

https://shop.example.com sur Chrome 120 (macOS 14)

Se connecter en tant que test@example.com

Ajouter « Souris sans fil » au panier

Naviguer vers /cart

Cliquer sur le bouton « Supprimer » à côté du produit

Observer : le produit disparaît, mais le compteur du panier dans l'en-tête affiche toujours « 1 »

Attendu : Le compteur du panier passe à « 0 » immédiatement après la suppression. Réel : Le compteur du panier reste à « 1 » jusqu'à un actualisation complète de la page.

L'essentiel est que n'importe qui — un développeur, un ingénieur QA ou un chef de produit — peut suivre ces étapes exactes et voir le même résultat.

Exemple de rapport de bug

Voici un exemple complet de rapport de bug utilisant le modèle ci-dessus, pour vous montrer à quoi il ressemble une fois rempli :


Title:        Cart counter does not update after removing last item on Firefox
ID:           BUG-0042
Reporter:     Sarah Chen
Date:         2026-08-05
Priority:     Medium
Status:       Open

Environment:
  - URL:          https://shop.example.com/cart
  - Browser:      Firefox 121, macOS 14
  - Device:       Desktop
  - Resolution:   1440x900
  - User account: test@example.com

Steps to Reproduce:
  1. Log in as test@example.com
  2. Add "Wireless Mouse" to the cart
  3. Go to /cart
  4. Click "Remove" next to the product

Expected Result:
  The header cart counter updates from "1" to "0" instantly.

Actual Result:
  The counter stays at "1" until the page is refreshed.

Screenshot:
  [Attached: annotated screenshot highlighting the stale counter]

Screen Recording:
  [Attached: 12s WebM recording showing the counter stuck after removal]

Console Errors / Network Failures:
  None

Notes:
  Reproducible 100% on Firefox. Works correctly on Chrome and Safari.
  Likely a state-sync issue in the cart event listener.

Modèle de suivi de bug

Si vous gérez les bugs au niveau de l'équipe, un modèle de suivi de bug (parfois appelé modèle de suivi de bogues) vous aide à organiser plusieurs rapports dans un tableur. Voici une structure simple :

ID	Titre	Priorité	Statut	Assigné	Rapporteur	Date	URL	Enregistrement	Reproductible
BUG-0042	Compteur de panier bloqué sur Firefox	Moyenne	Ouvert	—	Sarah C.	2026-08-05	/cart	✅	Oui
BUG-0043	Bouton de connexion inactif sur iOS 17	Haute	En cours	M. Lee	Tom K.	2026-08-04	/login	✅	Oui
BUG-0044	Export PDF : numéros de page manquants	Basse	Ouvert	—	Ana R.	2026-08-03	/reports	—	Intermittent

Vous pouvez créer cela dans Google Sheets, Excel, Notion ou tout autre outil déjà utilisé par votre équipe. L'important est que chaque colonne corresponde à un champ du modèle de rapport de bug ci-dessus, afin que les rapports individuels s'intègrent proprement dans le suivi.

Téléchargement : modèle de rapport de bug (Word et Markdown)

Vous voulez un fichier prêt à l'emploi ? Vous pouvez copier la section du modèle ci-dessus dans :

Microsoft Word — collez et enregistrez au format .docx pour un document Word modèle de rapport de bug que votre équipe peut remplir hors ligne.
Markdown — conservez le bloc de texte brut ci-dessus dans votre dépôt ou wiki pour un modèle de bug versionné.
Outil de suivi — mappez chaque champ à un champ personnalisé dans Jira, Linear, GitHub Issues ou Trello.

Le même modèle fonctionne sur tous les formats car il s'agit de texte brut — aucun formatage propriétaire à casser.

Comment BugCapturer remplit le modèle automatiquement

La plupart des champs du modèle de rapport de bug sont fastidieux à remplir à la main — et c'est là que les rapports deviennent négligés. BugCapturer, une extension de navigateur pour les rapports de bug et les retours web, automatise les parties répétitives :

Capture d'écran avec annotation : faites glisser pour sélectionner la zone problématique, ajoutez des flèches, des rectangles et du texte pour mettre en évidence les problèmes — aucun outil de capture d'écran séparé nécessaire.
Enregistrement d'écran (v1.2.0) : enregistrez l'onglet actif sous forme de vidéo WebM, puis rognez le clip et extrayez les images clés — tout dans le navigateur, sans téléchargement. Joignez l'enregistrement directement à votre rapport de bug.
Métadonnées techniques automatiques : l'URL, le navigateur, l'OS, la résolution d'écran et la zone d'affichage sont collectés automatiquement, donc le bloc Environnement se remplit tout seul.
Collecte de données de diagnostic : capture les journaux de console de niveau erreur et les requêtes réseau échouées (statut HTTP ≥ 400). Les URLs réseau sont automatiquement masquées pour les paramètres sensibles (jetons, mots de passe, clés API).
Export Excel/TSV (v1.2.0) : copiez en un clic une ligne de rapport de bug structurée sur 12 colonnes (URL, métadonnées, erreurs console, échecs réseau) dans votre presse-papiers. Collez directement dans Excel, Google Sheets ou Numbers pour un suivi au niveau de l'équipe.
Courriel en un clic : tout est regroupé dans un courriel structuré correspondant au modèle, prêt à être envoyé au développeur.

Le résultat est un rapport de bug qui correspond au modèle ci-dessus — sans la saisie manuelle.

Liste de vérification du rapport de bug

Avant de soumettre votre prochain rapport, confirmez que chaque champ est couvert :

Titre clair et spécifique (composant + action + résultat + condition)
Détails de l'environnement (URL, navigateur, OS, résolution)
Étapes numérotées pour reproduire
Résultat attendu vs résultat réel
Capture d'écran ou enregistrement annoté
Enregistrement d'écran (WebM) pour les bugs difficiles à décrire
Erreurs console / échecs réseau (le cas échéant)
Export Excel/TSV pour le suivi d'équipe (optionnel mais recommandé)
Priorité et reproductibilité notées

Utilisez ce modèle pour chaque rapport et vos développeurs passeront moins de temps à demander « qu'avez-vous fait ? » et plus de temps à corriger le bug.