Une partie de mon travail consiste à gérer les retours de mes collègues ou clients lorsque j’ai mal fait mon travail, ou lorsqu’un cas auquel je n’avais pas pensé se produit. C’est quelque chose de tout à fait sain. Je suis d’ailleurs bien plus rassuré d’avoir des retours après des tests sur une intégration, plutôt qu’aucun retour du tout. Sauf que mon enthousiasme pour gérer un retour est directement proportionnel à la qualité des renseignements fournis par son expéditeur.
Et malheureusement, il m’arrive de recevoir ce genre d’e-mails.
Si vous envoyez ce genre de message, ou si vous pensez qu’il s’agit d’une façon appropriée de vous adresser à un autre être humain par courrier électronique, alors félicitations, vous venez de vous qualifier pour le titre de « La Pire Personne Au Monde », juste entre les prêtres pédophiles et les mamans qui congèlent leurs bébés.
Parce qu’un tel message n’aide personne. Il y a de grandes chances pour que le site ait été testé en bonne et due forme « SUR MAC » lors de son intégration. Et si la possibilité d’un bug sur une page en particulier n’est pas à exclure, « LE SITE NE MARCHE PAS » n’aide pas beaucoup à savoir ce qui cloche exactement. Et le « CORRIGEZ ASAP » ne m’incite pas vraiment à avoir de l’empathie pour ce problème qui vous semble si urgent.
Voici les informations que j’aime voir figurer lorsqu’on me remonte un bug en intégration.
- Assurez-vous que le problème ne vienne pas de vous. Pensez à rafraîchir le cache de votre navigateur, et vérifiez que celui-ci est configuré avec le niveau de zoom par défaut. (S’il est important de prévoir que son site s’affiche correctement selon différents niveaux de zoom, vous obtiendrez bien plus de respect de la part de vos intégrateurs en leur précisant que le problème survient à un certain niveau de zoom).
- Précisez de quoi vous parlez. S’il s’agit d’un problème sur une fiche produit, je veux savoir quel produit. Si c’est un problème lors d’un paiement, je veux savoir quel moyen de paiement. (Et si c’est un cheval, je veux savoir dans quelle course.) N’hésitez surtout pas à mettre une URL directement dans votre message de retour. C’est ça de temps en moins passé à rechercher où est le problème pour chercher comment résoudre le problème.
- Précisez votre environnement de test : système d’exploitation, navigateur, appareil. Il n’est pas nécessaire de vérifier vous-même si le problème se produit sur plusieurs de ces critères. Dites-moi juste sur quoi vous avez testé, et je me charge du reste.
- Faites une capture d’écran. Rien de mieux qu’une capture d’écran pour comprendre un problème, plutôt que d’essayer de décrire en cinq paragraphes avec un jargon différent du mien (« il y a un décalage sur le drop sous le calque dans le push FD »). Et ne m’envoyez pas simplement une capture du bout de la page qui saute. Une capture d’écran complète de tout votre système peut me permettre d’identifier certains éléments extérieurs qui ont pu déclencher ce bug (« Oh, un plugin Skype. »).
- Précisez comment reproduire le bug. Si le bug n’apparaît qu’après une suite d’actions, précisez quelles actions vous avez effectué. Comme dans le cas précédent, une vidéo d’enregistrement de votre écran peut valoir mieux qu’un long discours pour des cas complexes.
- Priorisez. Si vous insistez pour m’envoyer une liste de cinquante retours par e-mails, alors indiquez moi ce que vous souhaiteriez voir résolu en priorité. (Et, non, désolé, mais tout mettre en priorité haute, ce n’est pas prioriser).
Merci d’avance !
Nico, le
Petit point bonus : le mail intégralement dans le titre, et en majuscules. Genre : « BUG BUG BUG – PROBLÈME SUR LE SITE ».
Il m’est arrivé de répondre, juste dans le titre : « ET OU SE SITUE LE BUG ? »
osternaud_clem, le
Je rencontre ça assez souvent. Je pense que je vais l’imprimer et extraire des chapitres pour les lettres dans ma signature :)
Gwen, le
Toujours la question « d’éduquer » le client, c’est vrai dans tous les domaines…
D’accord dans l’ensemble, et bien ri, aussi au type de réponse de Nico :), mais je te trouve assez sévère sur certains points : pas sûr par exemple qu’un client « sur Mac » sache faire une copie d’écran (bah oui, y a des peintres et on peut pas leur reprocher).
Le truc vraiment choquant dans ton exemple, c’est pas tant la mauvaise qualité du retour (le client peut ne rien caler sans être de mauvaise volonté pour autant), c’est sa forme : ce client est un c** épicétou !
Albanu, le
Ne te plain pas, tu as eu une phrase quand même…
J’ai reçu ça un jour : « Marche pas ! »…
Autant dire que je n’ai même pas répondu..
Simon Tripnaux, le
Pour ce qui est des priorités, il est bien entendu bon de recommander de commencer par l’ergonomie fonctionnelle en premier, pour aller progressivement vers des détails graphiques qui ne bloquent pas les interactions du site.
Steve B., le
Mais est ce que par définition, un utilisateur de MAC a le niveau suffisant pour rédiger un retour de qualité?
Steve B., le
[troll]Mais est ce que par définition, un utilisateur de MAC a le niveau suffisant pour rédiger un retour de qualité?[/troll]
cendrieR, le
En tant qu’IT, j’essaie au maximum d’être clair, de fournir la capture d’écran, et de mettre des priorités (et de faire proxy entre mon patron et le support pour l’écrit). Mais on n’est jamais à l’abri d’un oubli.
Je garde la liste sous le coude pour les prochaines fois, merci !
Gring, le
Une capture d’écran complète ? Ça va pas la tête ? On verrait les onglets ouverts sur Youporn !
Et puis de toutes façons, l’informatique là, c’est des conneries, c’est pas mon truc. Bon, et pendant que vous y êtes, j’ai mon Outlook là qui ne marche pas, réparez le moi pendant que je vais à la machine à café.
shavounet, le
Un petit tour sur http://supportdetails.com/ peut aider aussi :)
Mais je pense que le must est d’utiliser un petit outil de bug tracking. Rien que pour pouvoir dire au client « ha non c’est pas un bug, vous me l’avez fait corriger [là] »
shavounet, le
Quelle classe d’ailleurs…
Trevör, le
Très bon article ! Je sais pas si tu as vu les sessions WWDC 2013 d’Apple, il y a des ingénieurs qui ont parlé de la façon de faire un bug report, par exemple ils y expliquent que même si on pense que son problème est très courant et qu’un autre l’a déjà rapporté, il est tout de même important d’en faire un du fait que cela apporte toujours un supplément d’infos intéressant.
Ou même que si un bug ne s’est présenté à nous qu’une seule fois et qu’on est pas parvenu a le reproduire, il est tout de même important de leur en faire part.
Szed, le
Dans le genre, j’ai un client pas mal aussi.
Quand il vois un bug, il sélectionne (à la souris) toute sa page, et me copie colle cela dans son mail,
avec un bon gros « CA BUG » …
Va te débrouiller avec ca x)
Bronco, le
Salut ^^
En effet, le mail laconique peut être également rapproché de la plainte sans scrupules du gus qui vient te chercher à la pause pour te dire: « mon ordi y marche pas, faut que tu viennes voir »…
Je te soutiens très fraternellement dans ta douleur XD
Jack NUMBER, le
On pourrait résumer comme ceci :
1. Neutralité (videz votre cache, désactivez vos plugins et reproduisez le bug)
2. Emplacement (indiquez site > page > zone > élément, ainsi que l’URL)
3. Environnement (indiquez votre système, le navigateur et leurs versions)
4. Illustration (envoyez une capture d’écran complète)
5. Scénario (indiquez comment reproduire le bug)
6. Priorité (donnez un niveau d’importance)
C’est un peu direct mais c’est pour que chacun puisse développer à sa sauce ;)