« C’est encore en panne » est un signalement sincère. Mais il est aussi difficile à traiter. Le temps d’ouvrir le gestionnaire de tickets, l’écran exact, le bouton et le résultat se sont déjà brouillés dans votre mémoire. Dicter un rapport de bug peut préserver ces détails tant qu’ils sont frais, à condition de donner une structure à votre récit avant de commencer.
Voici une méthode courte pour transformer une défaillance observée en rapport qu’une autre personne pourra reproduire. Elle fonctionne aussi bien pour tester un projet personnel que pour ouvrir un ticket au travail ou contribuer à la maintenance d’un outil open source. Vous devrez quand même saisir les commandes exactes au clavier et relire le rapport final. La voix sert à raconter ce qui s’est passé, pas à inventer des preuves.
À retenir
- Notez séparément le résultat attendu et le résultat réel ; « ça ne marche pas » masque la différence.
- Reproduisez le problème une fois, puis dictez des étapes numérotées en regardant l’écran.
- Saisissez au clavier les URL, messages d’erreur, numéros de version et extraits de code exacts au lieu de les confier à la reconnaissance vocale.
- Supprimez les données personnelles et les secrets avant de joindre des captures d’écran ou des journaux.
Commencez par le problème, pas par un diagnostic
Un rapport de bug fait fausse route quand son titre annonce une théorie : « Le cache de la base de données est cassé. » Vous avez peut-être raison, mais la personne qui enquête a d’abord besoin de l’observation. Un meilleur titre indique l’action et le résultat : « Enregistrer un brouillon réinitialise la langue choisie dans les paramètres. » On peut le vérifier sans adopter votre théorie sur la cause.
La même règle aide quand vous dictez. Consacrez une phrase à la tâche que vous tentiez d’accomplir, puis une autre à ce que le logiciel a fait à la place. Ne commencez pas par un long récit de votre semaine ou par une supposition sur le composant défaillant. Si le problème est intermittent, précisez-le. S’il se produit à chaque fois sur votre machine, dites-le aussi, sans prétendre qu’il touche tout le monde.
Le guide de GitHub pour créer un ticket explique comment saisir un titre et une description explicites, et indique qu’un dépôt peut proposer un modèle de ticket. Utilisez ce modèle s’il existe. La structure orale ci-dessous vous aide à recueillir les faits avant d’en remplir les champs ; elle ne dispense pas de suivre les consignes propres au projet.
La note vocale en cinq rubriques
Ouvrez un brouillon privé plutôt que de publier directement dans un gestionnaire de tickets public. Placez le curseur dans l’éditeur et dictez cinq rubriques courtes, chacune sur une nouvelle ligne. Votre premier jet doit ressembler à un témoignage, pas à une annonce de version soigneusement rédigée :
- Contexte : Que cherchiez-vous à faire ? Nommez la page, la fonctionnalité ou l’opération.
- Étapes : Quelles actions ont provoqué le problème ? Numérotez-les dans l’ordre.
- Résultat attendu : Quel résultat pouviez-vous raisonnablement attendre ?
- Résultat réel : Que s’est-il passé à l’écran ? Ne citez un court message d’erreur qu’après l’avoir vérifié.
- Portée : Quand cela s’est-il produit, dans quel environnement, et pouvez-vous le reproduire ?
Voici un modèle à copier-coller. Remplacez chaque élément entre crochets par un détail observé. Si vous ignorez une information, écrivez « non vérifié » au lieu d’inventer une réponse plausible.
Titre : [action] provoque [résultat observé] Contexte : Je cherchais à [objectif] dans [fonctionnalité/page]. Étapes pour reproduire le problème : 1. [état initial exact] 2. [première action] 3. [action suivante] Résultat attendu : [ce qui aurait dû se passer] Résultat réel : [ce qui s’est passé, avec le texte vérifié du message d’erreur] Fréquence : [une fois / parfois / à chaque tentative sur cet appareil] Environnement : [version de l’application, système d’exploitation, navigateur si pertinent] Preuve : [capture d’écran sans données sensibles ou journal expurgé, si utile]
Ne lisez pas les crochets à voix haute en espérant qu’ils se transformeront en champs structurés. Saisissez d’abord les intitulés dans l’éditeur, puis dictez chaque rubrique. Si vous utilisez un clavier vocal de bureau comme Talkpad sur macOS ou Windows, placez le curseur dans votre brouillon privé et dictez une rubrique à la fois. Vous pourrez ainsi vous arrêter, examiner et corriger chaque partie avant publication.
Reproduisez une fois, puis décrivez les clics
La mémoire transforme une suite d’actions en résumé. « J’ai changé un paramètre et la page a planté » peut omettre l’actualisation, le changement de compte ou le formulaire non enregistré. Répétez la séquence si cela ne présente aucun risque, avec le brouillon ouvert à côté de l’application concernée. Faites une pause après chaque action pour noter ce que vous avez fait. Ne déclenchez pas à répétition un bug qui efface des données ou entraîne des frais uniquement pour améliorer votre formulation.
Décrivez les étapes littéralement : « Ouvrir les paramètres, choisir l’espagnol, cliquer sur Enregistrer, rouvrir les paramètres. » Évitez « aller dans les préférences habituelles et faire le nécessaire ». Si votre application comporte plusieurs boutons Enregistrer, précisez la section. Si le problème n’apparaît qu’après une actualisation, incluez cette étape. Une personne qui n’a jamais vu votre écran doit pouvoir suivre les instructions sans vous demander quel clic manque.
Vous pouvez dicter le récit, mais utilisez le clavier pour les chaînes fragiles. Un modèle peut transformer un nom de paquet en mots courants, changer la casse d’une option ou faire disparaître un signe moins. Collez une trace de pile ou un message d’erreur vérifié provenant de l’application au lieu de le dicter. Il en va de même pour une version précise comme 1.4.12. Consultez notre guide des noms et termes techniques pour les mots moins risqués qui méritent néanmoins une relecture attentive.
Distinguez le résultat attendu du résultat réel
C’est là qu’un rapport devient utile. « Le formulaire a échoué » n’apprend presque rien à la personne chargée de l’enquête. « Après avoir cliqué sur Enregistrer, j’ai vu la confirmation, mais la langue est revenue à l’anglais quand j’ai rouvert les paramètres » décrit un écart observable. Le résultat attendu peut être tout aussi simple : « L’espagnol devrait rester la langue enregistrée lorsque je rouvre les paramètres. »
Ne glissez pas de solution proposée dans la rubrique du résultat attendu. « L’application devrait utiliser un autre cache » est une suggestion d’implémentation, pas un résultat visible par l’utilisateur. Placez toute hypothèse dans une note clairement identifiée à la fin, en conservant l’incertitude. Votre collègue découvrira peut-être que la cause est une réponse de l’API, un client obsolète ou tout autre chose.
Si la reconnaissance vocale se trompe sur une négation, le rapport peut dire le contraire de ce qui s’est passé. Comparez « la boîte de dialogue ne s’est pas fermée » et « la boîte de dialogue s’est fermée ». Relisez ces phrases à l’écran avant de publier. C’est pour cette raison que notre méthode de relecture axée sur les risques donne la priorité aux négations, aux nombres et aux noms plutôt qu’aux retouches stylistiques.
Précisez l’environnement sans constituer un dossier d’expertise
Les informations minimales utiles sur l’environnement sont généralement la version de l’application, le système d’exploitation, le navigateur si le bug s’y produit et tout réglage nécessaire pour le reproduire. Indiquez si vous pouvez le reproduire dans une nouvelle session ou sur un autre appareil uniquement si vous l’avez effectivement testé. Un horodatage ou l’état du réseau importe s’il influe sur le résultat ; sinon, c’est une information superflue.
Examinez une capture d’écran avant de la joindre. Noms d’utilisateur, adresses e-mail, jetons, dossiers clients et aperçus de conversations peuvent se cacher dans les coins. Recadrez sur la zone pertinente ou masquez les détails sensibles avec un éditeur fiable. Les journaux méritent le même examen. Si le gestionnaire de tickets est public, partez du principe que la pièce jointe le sera aussi. Pour les questions de politique interne, consultez notre liste de contrôle de confidentialité pour la saisie vocale avant de dicter des informations confidentielles dans un outil.
Talkpad peut insérer un brouillon dicté dans l’application où se trouve votre curseur, mais il ne vérifie ni l’innocuité d’une capture d’écran ni l’exactitude d’une trace de pile. Ces vérifications vous reviennent. Si la politique de votre entreprise limite le traitement vocal des données d’incident, respectez-la et saisissez manuellement les éléments sensibles.
Deux relectures avant de publier
La première porte sur la reproductibilité. Partez de l’état initial indiqué et suivez vos étapes à la lettre. Le problème apparaît-il ? Les résultats attendu et réel sont-ils différents et clairement décrits ? Avez-vous omis une connexion ou un réglage qui change le résultat ? Si vous ne parvenez pas à reproduire le problème, modifiez la rubrique « Fréquence » pour le signaler plutôt que de masquer cette incertitude.
La seconde porte sur les risques. Comparez les numéros de version et les messages d’erreur avec leurs sources. Retirez les secrets du texte et des pièces jointes. Remplacez les suppositions par des faits observables ou qualifiez-les d’hypothèses. Raccourcissez l’introduction si elle retarde l’accès aux étapes. Notre boîte à outils pour réviser un brouillon dicté peut vous aider si le premier jet ressemble davantage à un flot de paroles qu’à des rubriques bien distinctes.
Un rapport utile n’a pas besoin d’être long. Certains bugs demandent trois étapes et deux phrases ; d’autres nécessitent un exemple contrôlé. Évitez le remplissage. L’objectif est de permettre à une autre personne de reproduire le comportement et de comprendre pourquoi vous attendiez un autre résultat. Si vous ne savez pas expliquer l’état initial, poursuivez un peu vos recherches avant de publier.
Questions fréquentes
Puis-je dicter un rapport de bug ?
Oui. Dictez le contexte, les étapes de reproduction ainsi que le comportement attendu et le comportement réel dans un brouillon privé. Saisissez au clavier et vérifiez les commandes, messages d’erreur, URL et numéros de version exacts avant de le partager.
Que doit contenir un rapport de bug ?
Un titre descriptif, le contexte initial, les étapes dans l’ordre, le résultat attendu, le résultat réel, les informations pertinentes sur l’environnement et, si nécessaire, des preuves sans données sensibles. Suivez le modèle de ticket du dépôt s’il en propose un.
Comment signaler un bug que je ne parviens pas à reproduire ?
Précisez qu’il s’est produit une seule fois ou de façon intermittente, consignez vos observations et l’environnement connu, et indiquez quelles tentatives n’ont pas permis de le reproduire. N’inventez pas les étapes que vous ignorez.
Faut-il joindre des journaux à un ticket public ?
Seulement après y avoir recherché des secrets et des informations personnelles. Supprimez ou masquez les données sensibles et ne partagez que le plus court extrait utile pour expliquer le problème. Respectez les règles de votre équipe en matière d’incidents et de confidentialité.
Télécharger Talkpad gratuitement – 2 500 mots par semaine avec l’offre gratuite.
Télécharger pour macOS
Télécharger pour Windows