Rédiger un rapport d'incident

Quel utilisateur n'a pas fait remonté une anomalie lors d'un projet informatique ? Lorsqu'un utilisateur est confronté à un problème sur son poste de travail, il est important de le faire connaître au service dédié afin de l'identifier et de le résoudre, mais également pour l'historiser en cas de récidive.

Formaliser un rapport d'incident

Pour un échange fluide entre les différents interlocuteurs, et pour une prise en charge rapide, voici ci-dessous des conseils pour formaliser le rapport d'incident :

• Le résumé doit être clair et concis et précis. Un bogue référencé par un mot est insuffisant et inutile pour la compréhension du problème.
• Une capture d'écran ne suffit pas. Celle-ci doit être accompagnée du détail de la manipulation afin de comprendre le cheminent fait par l'utilisateur.
• Indiquer les différentes étapes suivies et les compléter par les résultats obtenus.
• Décrire le résultat attendu.
• Recopier les messages d'erreur, surtout s'ils contiennent des nombres et qu'ils ne sont pas explicites pour le rapporteur.
• Séparer nettement les faits ("J'ai fait...") des spéculations ("Je pense que..."); Le premier est obligatoire l'autre ne l'est pas.
• Décomposer les rapports de bogues. Ne pas créer de rapport de bogue fourre-tout.
• Compléter les rapports si des demandes sont faites dans ce sens pour mieux cerner et comprendre l'origine du problème.

L'objectif étant pour le service de maintenance ou les développeurs de reproduire l'incident à l'aide des informations fournies. L'utilisateur doit être le plus explicite : ce qui va de soit pour lui ne l'est pas forcément pour les intervenants.

Comprendre l'environnement de travail de l'utilisateur permet d'éviter des retours du style "ça marche sur mon poste", ou "l'effet démo" : lorsque l'utilisateur reproduit sa manipulation devant l'intervenant le problème n'est plus présent.

En espérant vous avoir inspirer pour vos prochains rapport de bogue ;) !