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

Un bon rapport de bogue 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 copié mot pour mot, et l'endroit où cela s'est produit : quelle page, quel navigateur, quel appareil et quel utilisateur. Un bogue par rapport, avec une capture d'écran si cela aide.

La plupart des bogues prennent plus de temps à comprendre qu'à corriger. Un rapport clair élimine la partie compréhension. Cela compte encore plus avec les outils 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 casser autre chose.

Le modèle

Copiez-le et remplissez-le :

Titre : [Ce qui ne va pas, et où] — par ex. « Le formulaire de réservation refuse les heures 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é comme 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 d'abord

Avant de rédiger, essayez de faire réapparaître le bogue. Vous saurez quelles étapes comptent, et si cela se produit à chaque fois.

• Partez d'un état propre : actualisez la page, ou déconnectez-vous puis reconnectez-vous.
• Notez chaque clic et chaque élément saisi.
• Essayez de trouver le chemin le plus court qui déclenche le bogue.
• Essayez un second navigateur ou un autre compte. Si cela ne se produit que pour un utilisateur, c'est un indice important.

Pour approfondir, voir comment déboguer une app créée par IA.

Étape 2 : Écrire 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 bogue il s'agit.

Étape 3 : Lister les étapes exactes

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

1. Connectez-vous comme client (compte de test : customer@example.com).
2. Ajoutez le « Starter kit » au panier.
3. Saisissez le code promo WELCOME10 et cliquez sur Appliquer.
4. Cliquez sur Paiement.

« Essayer de payer avec un code » omet les détails qui comptent souvent : quel utilisateur, quel produit, quel code, et si le code a été appliqué avant.

Étape 4 : Attendu contre obtenu

C'est le cœur du rapport. Indiquez les deux, car l'écart est le bogue.

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

Sans « attendu », le lecteur ne sait peut-être pas que le comportement est incorrect. Sans « obtenu », il ne sait pas quoi chercher.

Étape 5 : Copier les erreurs exactement

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

Où les trouver :

• À l'écran : tout message affiché par l'app.
• 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 en ligne).
• Qui : quel utilisateur ou quel rôle : administrateur, membre, non connecté.
• Appareil et navigateur : « Safari sur iPhone » et « Chrome sur Windows » peuvent faire une 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 c'est apparu : « après la modification d'hier sur les codes promo » est une information précieuse.
• Fréquence : à chaque fois, ou une fois sur dix essais.

Étape 7 : Le montrer

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

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

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

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

Connecté comme client, avec le « Starter kit » 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 rabais sur le total. Obtenu : un bref cercle de 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 des commandes sans code. Vérifie ensuite le paiement avec un code en pourcentage, un code de montant fixe et sans code.

Si vous ne connaissez pas la cause, demandez d'abord un diagnostic :

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

Erreurs courantes

• « C'est cassé. » Aucune étape, aucun résultat attendu, rien sur quoi agir.
• Plusieurs bogues dans un rapport. Certains sont corrigés, d'autres se perdent.
• Des erreurs paraphrasées. « Une chose undefined » cache la partie utile.
• Oublier l'utilisateur ou le rôle. Beaucoup de bogues ne touchent que les administrateurs, ou que 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 des captures d'écran ou des journaux collés.

Liste de vérification

• J'ai reproduit le bogue 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 copiés exactement, avec la requête en échec et son code d'état.
• La page, l'environnement, l'utilisateur, l'appareil et le navigateur sont inclus.
• J'ai indiqué la fréquence et le moment où le problème est apparu.
• Une capture d'écran ou un enregistrement est joint, sans données privées.
• Un bogue par rapport.

Signaler des bogues à l'agent de Mythex

Dans un projet Mythex, le rapport est la requête. Quelques fonctions 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 bogue; le mode Plan lui permet d'enquêter avant de modifier.
• /test demande à l'agent de reproduire les parcours dans l'aperçu même et de signaler ce qu'il observe.
• Revenir à ce point annule une correction qui a empiré les choses.

La page déboguer avec des requêtes de la documentation utilise la même structure étapes / attendu / obtenu. Pour la boucle de correction et de vérification qui l'entoure, voir comment itérer sur une app créée par IA.

Questions