Comment rédiger un bon rapport de bug (pour une IA ou un développeur)

Un bon rapport de bug permet à quelqu'un d'autre, un développeur ou une IA, de voir le même problème que vous, sans avoir à vous poser de questions. Il lui faut un titre précis, les étapes exactes pour le reproduire, ce que vous attendiez, ce qui s'est réellement passé, tout message d'erreur recopié mot pour mot, et l'endroit où le problème est survenu : quelle page, quel navigateur, quel appareil, quel utilisateur. Un bug par rapport, avec une capture d'écran si cela aide.

La plupart des bugs prennent plus de temps à comprendre qu'à corriger. Un rapport clair supprime cette partie de compréhension. C'est encore plus vrai avec les outils d'IA : une IA ne peut pas poser de question de suivi sur ce que vous vouliez dire par « le paiement est bizarre », alors elle devine, et une mauvaise supposition peut en casser une autre.

Le modèle

Copiez-le et remplissez-le :

Titre : [Ce qui ne va pas, et où] — ex. « Le formulaire de réservation refuse les horaires après 18 h »

Étapes pour reproduire :
1. ...
2. ...
3. ...

Attendu : [ce qui devrait se passer]
Obtenu : [ce qui s'est passé à la place]

Message d'erreur : [texte exact, le cas échéant]
Où : [page/URL, navigateur, appareil, connecté avec quel utilisateur]
Fréquence : [à chaque fois / parfois / une seule fois]
Capture d'écran ou enregistrement : [joint]

Le reste de ce guide explique chaque partie.

Étape 1 : reproduire le bug d'abord

Avant de rédiger, essayez de refaire apparaître le bug. Vous saurez quelles étapes comptent vraiment et s'il survient à chaque fois.

• Partez d'un état propre : rafraîchissez la page, ou déconnectez-vous puis reconnectez-vous.
• Notez chaque clic et chaque saisie.
• Cherchez le chemin le plus court qui déclenche le bug.
• Essayez un second navigateur ou un autre compte. Si cela n'arrive qu'à un seul utilisateur, c'est un indice majeur.

Pour aller plus loin, voir comment déboguer une application créée par IA.

Étape 2 : rédiger un titre précis

Le titre doit dire ce qui ne va pas et où, pour que quelqu'un qui parcourt une liste sache de quel bug il s'agit.

Étape 3 : lister les étapes exactes

Numérotez-les. Soyez littéral : quelle page, quel bouton, ce que vous avez saisi.

1. Connectez-vous en tant que client (compte de test : customer@example.com).
2. Ajoutez le « Kit de démarrage » au panier.
3. Saisissez le code promo WELCOME10 et cliquez sur Appliquer.
4. Cliquez sur Paiement.

« Essayez de payer avec un code » omet les détails qui comptent souvent : quel utilisateur, quel produit, quel code, et si le code a bien été appliqué au préalable.

Étape 4 : résultat attendu et résultat obtenu

C'est le cœur du rapport. Indiquez les deux, car la différence est le bug.

• Attendu : la page de paiement s'ouvre avec la réduction de 10 % affichée dans le total.
• Obtenu : le bouton affiche un chargement pendant une seconde, puis rien ne se passe. Sans code promo, le paiement fonctionne.

Sans « attendu », le lecteur ne sait pas forcément que le comportement est anormal. Sans « obtenu », il ne sait pas quoi chercher.

Étape 5 : recopier les erreurs exactement

Les messages d'erreur sont le chemin le plus rapide vers la cause. Copiez-les en texte, mot pour mot, sans les paraphraser.

Où les trouver :

• À l'écran : tout message affiché par l'application.
• Console du navigateur : ouvrez les outils de développement (F12, ou clic droit → Inspecter) et regardez l'onglet Console pour les lignes rouges.
• Onglet Réseau : dans les outils de développement, repérez la requête en échec et notez son URL et son code d'état (par exemple POST /api/checkout → 500).
• Journaux du serveur, si vous y avez accès.

Une ligne comme TypeError: Cannot read properties of undefined (reading 'percent') at checkout.ts:48 pointe souvent directement vers le problème.

Étape 6 : ajouter le contexte

• Où : l'URL de la page, l'environnement (aperçu, préproduction ou production).
• Qui : quel utilisateur ou quel rôle : administrateur, membre, déconnecté.
• Appareil et navigateur : « Safari sur iPhone » et « Chrome sur Windows » peuvent faire une vraie différence.
• Données : tout ce qui est inhabituel dans l'enregistrement : texte très long, caractères spéciaux, grand nombre d'éléments.
• Quand cela a commencé : « depuis la modification des codes promo d'hier » est une information précieuse.
• À quelle fréquence : à chaque fois, ou une fois sur dix essais.

Étape 7 : montrer le problème

Une capture d'écran avec le problème entouré, ou un court enregistrement d'écran, supprime toute ambiguïté, surtout pour les bugs de mise en page. Si votre outil d'IA accepte les images, joignez-en une. Recadrez pour retirer tout élément privé, y compris les clés et les données d'autres personnes.

Rédiger des rapports de bug pour un générateur IA

La même structure fonctionne comme prompt. Deux ajouts aident :

• Dites ce qui ne doit pas changer, pour que la correction ne crée pas un nouveau problème.
• Demandez de vérifier la correction, pas seulement de l'écrire.

Connecté en tant que client, avec le « Kit de démarrage » dans le panier et le code WELCOME10 appliqué, un clic sur Paiement ne fait rien. Attendu : la page de paiement s'ouvre avec 10 % de réduction sur le total. Obtenu : un bref chargement, puis rien. L'onglet réseau montre que POST /api/checkout a renvoyé 500. Le paiement sans code fonctionne. Trouve la cause et corrige-la sans changer le calcul des prix pour les commandes sans code. Vérifie ensuite le paiement avec un code en pourcentage, un code à montant fixe et sans code.

Si vous n'êtes pas sûr de la cause, demandez d'abord un diagnostic :

Ne change pas encore le code. D'après ce rapport, quelles sont les causes probables, et qu'est-ce qui confirmerait chacune d'elles ?

Erreurs courantes

• « C'est cassé. » Pas d'étapes, pas de résultat attendu, rien sur quoi agir.
• Plusieurs bugs dans un même rapport. Certains seront corrigés, d'autres oubliés.
• Des erreurs paraphrasées. « Un truc undefined » masque la partie utile.
• Oublier l'utilisateur ou le rôle. Beaucoup de bugs n'affectent que les administrateurs, ou seulement les nouveaux utilisateurs.
• Ne décrire que la correction voulue (« ajoute une vérification de null ») au lieu du problème.
• Partager des secrets dans les captures d'écran ou les journaux collés.

Liste de vérification

• J'ai reproduit le bug et trouvé les étapes les plus courtes.
• Le titre dit ce qui ne va pas et où.
• Les étapes sont numérotées et littérales.
• Le résultat attendu et le résultat obtenu sont tous deux indiqués.
• Les messages d'erreur sont recopiés exactement, avec la requête en échec et le code d'état.
• La page, l'environnement, l'utilisateur, l'appareil et le navigateur sont précisés.
• J'ai indiqué la fréquence du problème et quand il a commencé.
• Une capture d'écran ou un enregistrement est joint, sans données privées.
• Un seul bug par rapport.

Signaler des bugs à l'agent de Mythex

Dans un projet Mythex, le rapport est le prompt. Quelques fonctionnalités aident :

• Joignez une capture d'écran de l'aperçu ou de l'écran d'erreur, jusqu'à 5 fichiers par message.
• /fix concentre l'agent sur la correction d'un bug ; le mode Plan lui permet d'enquêter avant de modifier.
• /test demande à l'agent de reproduire les parcours dans l'aperçu lui-même et de signaler ce qu'il voit.
• Revenir à ce point annule une correction qui a aggravé les choses.

La page de la documentation déboguer avec des prompts utilise la même structure étapes / attendu / obtenu. Pour la boucle de correction et de vérification autour de cela, voir comment itérer sur une application créée par IA.

Questions