Documenter les messages d’erreur : créer un rapport utile pour le support

Un bon rapport distingue observations et suppositions. Notez le message, l’heure, l’environnement et les étapes de reproduction sans risque, sans divulguer de données confidentielles. Ce guide ne dépend pas du système d’exploitation ; le nom des fenêtres de version varie selon le logiciel.

1. Consigner l’incident

Notez la date, l’heure et le fuseau horaire, l’application concernée et sa version exacte. Ajoutez la version du système, le type d’appareil et le dernier fonctionnement correct connu. Écrivez « inconnu » plutôt que de deviner une information manquante. Précisez l’impact : un fichier, un utilisateur ou plusieurs postes ?

2. Décrire précisément l’erreur et les étapes

  1. Copiez si possible le message complet et son code. Sinon, faites une capture d’écran et transcrivez aussi le texte. Ne traduisez ni n’abrégez le code d’erreur.
  2. Numérotez les actions menant à l’erreur : état initial, fichier ou fonction ouverte, bouton précis et résultat. Remplacez au besoin les noms de fichiers par des noms neutres.
  3. Séparez résultat attendu et résultat observé. Écrivez « Enregistrer affiche l’erreur X » plutôt que « Le serveur est cassé » tant que la cause n’est pas établie.
  4. Indiquez si l’erreur survient toujours, parfois ou une seule fois. Ne répétez que des étapes sans risque avec des données de test ou une copie. Ne répétez pas paiements, suppressions ou opérations risquant de perdre des données pour reproduire le problème.

3. Preuves et tentatives précédentes

Ajoutez les changements connus juste avant l’incident et les mesures déjà essayées, avec chaque résultat. Ne modifiez pas plusieurs paramètres à la fois. Protégez le journal original ; ne partagez que les extraits nécessaires de la période pertinente. Un événement simultané est un indice, pas une preuve de causalité.

4. Vérifier avant l’envoi

Supprimez mots de passe, jetons de session, données personnelles et contenus confidentiels de la copie à envoyer. Vérifiez aussi la barre d’adresse, les chemins de fichiers et l’arrière-plan des captures. Un rectangle superposé dans un fichier modifiable ne constitue pas une suppression sûre. Rouvrez la pièce jointe finale et vérifiez le résultat. Utilisez le canal de support prévu et contrôlez destinataire et pièces jointes ; ne publiez pas de dossiers de diagnostic complets non vérifiés sur un forum.

Modèle à copier

  • Titre bref et impact :
  • Date, heure, fuseau horaire :
  • Application/version, système/version, appareil :
  • État initial et étapes numérotées :
  • Attendu / réellement observé :
  • Message complet et code :
  • Fréquence, dernier succès, changements connus :
  • Essais déjà effectués / résultat de chacun :
  • Pièces jointes vérifiées et expurgées :

Contrôle final : une autre personne doit comprendre la séquence sans demander les étapes élémentaires. Signalez séparément les problèmes indépendants.

Source

Mozilla: Bug Writing Guidelines – base pour des étapes précises, des résultats clairs et des rapports séparés ; la vérification de confidentialité complète la procédure générale de support.