Comment faire un bon rapport d’erreur11 min read

Un standardiste de service après vente répond à un client au téléphone

Aïe ! Un bug a été identifié. Pas de problème, on reste zen et on fait un rapport d’erreur pour structurer et initier sa résolution…


Point sur le vocabulaire

Avant d’aller plus loin, voici les définitions de quelques termes utilisés dans cet article.

Bug
Terme anglais signifiant “insecte”. Il désigne communément une erreur dans un programme informatique.


Qu’est-ce qu’un rapport d’erreur ?

C’est un document, une fiche, un ticket dans lequel on décrit le problème rencontré avec un produit afin de le résoudre.

Le produit en question peut être un logiciel, un site internet, un appareil physique…

On peut aussi le trouvé sous l’appellation :

  • Rapport d’étonnement
  • Bug
  • Issue
  • Ticket (informatique)
  • Rapport d’anomalie
  • Problem Report

A chaque entreprise son appellation. Dans la suite de cet article nous le nommerons rapport d’erreur.

Suivant la personne qui va rédiger le rapport d’erreur (un utilisateur, un client, un développeur, …), le degré de détail et la précision des informations peuvent varier. Ce qui influencera la rapidité et la qualité de sa résolution.

Le but du rapport d’erreur est de fournir un état des lieux précis pour délimiter le périmètre de l’erreur, intégrer toutes les informations utiles à sa compréhension afin de la reproduire et d’initier le processus résolution.

Les problématiques

Le niveau de détail

Image par PublicDomainPictures de Pixabay 

Plus il y a de détails dans le rapport, plus il sera facile de reproduire l’erreur pour la comprendre et la résoudre. Mais quels éléments fournir ? Comment savoir quels détails sont importants ?

Il faut avoir un modèle de rapport d’erreur à compléter avec un formulaire de détails requis en fonction de votre activité. Il ne sera peut-être pas possible / utile / pertinent de remplir l’intégralité du formulaire, mais les données recueillies donneront un niveau de détail suffisant pour commencer l’enquête.

La reproductibilité de l’erreur

Les Visiteurs – Gaumont 1993

C’est le besoin essentiel du rapport d’erreur. On ne peut bien corriger une erreur que si on arrive à la reproduire. Donc non-seulement il faut donner suffisamment de détails pour circonscrire la configuration dans laquelle survient l’erreur. Mais il faut aussi décrire précisément le cheminement qui a mené à cette erreur !

Si on arrive à reproduire l’erreur de manière systématique alors on arrivera à la supprimer définitivement !

L’imputabilités des erreurs

Usual Suspects – 1995 PolyGram Filmed Entertainment

Une erreur est une erreur.

Mais suivant si elle est due à :

  • Une erreur humaine du développeur
  • Une utilisation non appropriée du produit
  • Un manque de maturité ou de précision du besoin initial

La manière de la résoudre sera différente. Peut-être même que ce ne sera pas du tout une erreur.

Proposition de rapport d’erreur

Proposition 1 : rapide et efficace

Johnny Knoxville

Un très bon rapport d’erreur, au ratio efforts / efficacité excellent, est tout simplement de filmer l’erreur. Vous prenez une appareil photo ou un logiciel d’enregistrement de votre écran d’ordinateur, et vous reproduisez l’erreur.

Cette vidéo donnera une très bonne idée de l’origine de l’erreur à la personne en charge de la résoudre. Et dans la majorité des cas, cela suffira.

Cependant, suivant le contexte de l’erreur, il peut être difficile de la filmer. Vous pourriez ne pas y être autorisé. La vidéo pourrait ne pas montrer suffisamment de détails pour comprendre l’erreur… C’est pourquoi nous vous proposons une seconde manière de faire plus complète.

Proposition 2 : exhaustive et universelle

Voici la liste des éléments que nous vous suggérons de décrire dans votre rapport d’erreur :

  • la configuration
  • le comportement problématique
  • le comportement attendu
  • des pistes éventuelles de solution (facultative)
  • une solution temporaire de contournement (facultative)

Voici en détail ce que doit contenir les description de chacun de ces éléments.

Configuration

Vous y décrivez le contexte dans lequel se produit l’erreur.

Si c’est un logiciel, vous donnez son nom et son numéro de version.

Si c’est un appareil physique, vous donnez son nom et son numéro de série…

Le but est d’identifier l’élément sur lequel se produit l’erreur pour que la personne en charge de la correction puisse reproduire l’environnement de la mise en échec.

Comportement problématique

Expliquez en quoi le comportement que vous observez est une erreur. Ce qu’il fait de mal. Vous pouvez ici joindre tout type d’illustration pour compléter votre propos : une vidéo, des photos, des impressions d’écran…

Le but est que le correcteur soit en mesure de reproduire le cheminement qui a mené à l’erreur.

Comportement attendu

Maintenant vous expliquez quel comportement vous attendiez du produit. Ce que vous auriez aimé qu’il fasse à la place de l’erreur.

Peut-être que l’erreur n’en est pas totalement une, et qu’il existe bien une façon d’obtenir ce que vous cherchez. Le problème est alors un problème de parcours utilisateur, d’ergonomie. La façon d’arriver à vos fins n’est pas suffisamment claire, explicite ou ergonomique. Dans tous les cas, décrire le comportement attendu donnera des informations au correcteur pour mieux répondre au besoin de l’utilisateur.

Piste de solution

Voici une information supplémentaire à apporter à votre rapport d’erreur.

Nous ne tenons pas pour obligatoire la “piste de solution” car elle peut être déjà présente dans le comportement attendu.

C’est à travers elle que l’utilisateur peut suggérer les corrections à apporter au produit afin qu’il ait le comportement attendu. Cela sous-entend que l’utilisateur ait une connaissance suffisante du fonctionnement du produit. Cette piste de solution peut être le point de départ du processus de correction. Et elle peut faire gagner un temps considérable au correcteur.

Solution de contournement

La solution de contournement aussi nous semble facultative car ce point n’est pas forcément applicable en fonction de l’erreur.

Une solution de contournement est la “manœuvre” qu’un utilisateur fait pour arriver à ses fins malgré la survenue d’une erreur. Il arrive à obtenir ou à faire ce qu’il veut, mais cela consiste en une ruse, une astuce, un détournement du produit de son objet initial.

Fournir la solution de contournement au correcteur lui montre comment vous faîtes. Il peut en tirer plusieurs renseignements :

  • comment améliorer le parcours utilisateur
  • comprendre comment il est possible de détourner l’utilisation du produit
  • avoir une idée de la gravité / priorité de l’erreur à résoudre. Si cette solution de contournement est acceptable au moins temporairement, il pourra prioriser la résolution d’autres erreurs plus graves.

Le processus de résolution d’une erreur

Route de montagne avec une signalisation pour indiquer le chemin à emprunter
Image par Erich Westendarp de Pixabay 

Rédiger un rapport d’erreur n’est que la première étape dans le processus de résolution. Et le découvreur de cette erreur (l’utilisateur) a encore un rôle à jouer dans ce processus.

Les paragraphes suivants vont décrire les quelques étapes de ce processus que nous vous suggérons.

1. La découverte

C’est tout simplement la découverte de l’erreur par l’utilisateur. Celui-ci rédige le rapport d’erreur soit dans un éditeur de texte classique soit dans un logiciel dédié (voir la liste des ressources que nous recommandons en fin d’article.)

Puis l’utilisateur va l’envoyer au correcteur qui va se charger de la résolution.

2. L’échange

Le correcteur prend connaissance du rapport d’erreur. Il va tenter de la reproduire de son côté afin de s’assurer qu’il comprend bien le rapport et qu’il ne lui manque aucune information. Si le rapport est incomplet, il va engager un dialogue avec l’utilisateur pour réunir ces informations.

3. La résolution

Une fois que le correcteur a en sa possession toutes les informations dont il a besoin, il peut se lancer dans la phase de résolution de l’erreur. Celle-ci peut être plus ou moins longue suivant la complexité de l’erreur ou son degré de priorité.

L’utilisateur n’est pas sollicité pendant cette phase.

4. La validation

A présent, le correcteur estime qu’il a résolu l’erreur. Il est indispensable qu’il valide cette résolution avec l’utilisateur qui a découvert l’erreur avant de clore le dossier !

Il est bien trop courant que les clôtures d’erreur relèvent de décisions unilatérales du service client sans impliquer l’utilisateur ! Dans la majorité des cas, cette résolution est satisfaisante. Mais il arrive qu’elle ne satisfasse pas l’utilisateur à cause d’un malentendu ou d’un manque d’information. L’utilisateur se retrouve alors au point de départ, avec une erreur et il lui est souvent compliqué de relancer un processus de résolution. C’est pourquoi, il doit être il doit être impliqué dans la clôture du dossier.

Donc idéalement, il se passe la chose suivante : le correcteur montre à l’utilisateur la correction qu’il a apportée, ils font ensemble quelques tests pour valider la robustesse de la solution.

Si la solution ne satisfait pas l’utilisateur, on recommence le cycle en étape 2 : l’échange.

Si la solution satisfait l’utilisateur, celui-ci accorde le statut “clos” au rapport d’erreur pour le refermer définitivement.

Quelques ressources pour construire des rapports d’erreur

Il existe un grand nombre d’outils informatiques et de modèles de document pour rédiger des rapport d’erreur ou faire du suivi d’erreur aka bugtracking en anglais. En voici un court échantillon :

Gitlab : c’est celui que nous utilisons. C’est un freemium en ligne dont la version gratuite est pleinement satisfaisante d’autant que le suivi d’erreur n’est qu’un des nombreux services proposés. Il permet même la création de rapports d’erreurs par mail. Vous envoyer un rapport d’erreur à une adresse mail particulière. Son texte est alors converti en un rapport d’erreur dans l’application, qui vous permettra de suivre la résolution.

Github : freemium en ligne similaire à Gitlab qui propose les mêmes fonctionnalités.

Mantis Bug Tracker : c’est un logiciel installable sur vos serveurs, opensource et gratuit, hautement personnalisable. Entièrement et uniquement dédié au processus de résolution d’erreur. Nous l’avons utilisé dans une autre vie.

Modèle de suivi de résolution d’erreur sur Trello : vous devez sûrement connaître Trello, l’outil de gestion de projet à tout faire basé sur la méthode des kanbans. Voici un modèle de projet Trello pour gérer les remontées d’erreur par les équipes internes ou les clients.

Conclusion

Les bugs, les erreurs, les problèmes sont le lot de tous les développement de produits, quels qu’ils soient. Les processus de résolution sont cependant propres à chaque métier et chaque type d’activité. La proposition que nous vous faisons dans cette article a été éprouvée sur de nombreux projets de développement logiciels dans le web, dans l’aéronautique, dans l’automobile…

Elle est relativement exhaustive mais il vous faudra très probablement l’adapter à vos méthodes pour la rendre plus pertinente et efficace.

Il existe aussi une variante à la résolution d’erreur qui est la gestion des suggestions. C’est lorsqu’un utilisateur vous fait part d’une idée pour améliorer votre produit. Pour cela nous vous renvoyons à notre article sur l’intelligence collective, qui décrit des processus et présente des outils dédiés, ainsi que notre focus sur Fider un outils de collecte de suggestion que nous utilisons.

Références

Voici quelques références qui nous ont été utiles dans la rédaction de cet article.

[Medium] Managing Remote Teams — Use Checklists par Eric Eliott
[Livre] S’organiser pour réussir – David Allen

Et vous ?

Quels outils utilisez-vous pour résoudre les problèmes qui surviennent dans vos développement ?
Quelles sont vos méthodes de résolution ?
Vos processus sont-ils différents de ceux que nous avons évoqué dans l’article ?
N’hésitez pas à nous partager votre retour d’expérience en commentaire !

Related Posts

Leave a Reply