Comment bien rédiger un ticket pour signaler un retour ?
L’une des étapes clés lors de la création ou de la refonte d’un site web est la phase de recette, qui a lieu après les développements. Chez Advency, le chef de projet effectue une série de tests avant de vous livrer le site. Mais comme la confiance n’exclut pas le contrôle, il est essentiel que vous aussi, en tant que client, procédiez à votre propre recette. Cela implique de signaler les potentielles anomalies rencontrées via des tickets.
Attention : un ticket mal rédigé peut ralentir sa prise en charge. Un ticket incomplet risque même de ne pas être traité. Pas d’inquiétude, on vous guide sur comment rédiger des tickets efficaces et complets !
Qu’est-ce qu’un ticket ?
Un ticket est une demande formalisée, créée dans un outil dédié, pour signaler un bug ou une évolution. Il permet un suivi structuré et collaboratif de la correction.
Chez Advency, nous utilisons Pandra, une plateforme de ticketing qui centralise les retours de nos clients. Chaque ticket est horodaté, assigné à la bonne personne, et suit un cycle de vie clair jusqu’à sa résolution.
Pourquoi bien rédiger un ticket ?
Pour réduire le temps de résolution
Un ticket clair et complet permet aux équipes techniques de reproduire rapidement le bug et d’y apporter une solution. Plus vous fournissez d’informations dès le départ, plus le traitement sera rapide.
Un ticket incomplet entraîne des allers-retours inutiles pour obtenir des précisions. Soyez exhaustif, tout le monde y gagne du temps.
Parce qu’un ticket passe entre plusieurs mains
En moyenne, un ticket passe entre les mains de 3 ou 4 personnes différentes : chef de projet, développeur, intégrateur, designer… ainsi que vous-même ou un collègue pendant vos congés. Quelques jours peuvent s’écouler entre la création du ticket et sa recette, et il est fréquent d’avoir oublié le contexte initial : vous serez ravi de pouvoir reproduire la situation exacte décrite dans le ticket plutôt que d’avoir à vous en souvenir afin de vérifier que la résolution est conforme.
De ce fait, pensez à rédiger pour des personnes qui n’ont pas votre environnement ni vos repères. Soyez précis et explicite pour éviter toute perte d’information.
1 problème = 1 ticket
C’est la règle d’or : 1 ticket = une anomalie. Il est préférable de créer 10 tickets bien détaillés que regrouper plusieurs problèmes dans un seul. Cela facilite le suivi, accélère les corrections et évite de bloquer des déploiements.
Quels éléments mettre dans un ticket ?
Maintenant que vous savez pourquoi il est important de détailler le contenu d’un ticket, il est temps de savoir les éléments importants à mettre dans un ticket.
- Un bon ticket répond aux éléments suivants :
- Nom explicite en titre du ticket
- Description détaillée du soucis rencontré (on évite “ça ne marche pas”)
- Le résultat attendu
- Comment reproduire le bug :
- Exemple : “Aller sur la page X”
- “Cliquer sur le bouton Y”
- “Observer le message d’erreur Z”
- Lien de la page concernée
- Type d’appareil (ordinateur, smartphone)
- Système d’exploitation (Windows, macOS, iOS, Android…)
- Navigateur utilisé (Chrome, Firefox, Safari…)
- Capture d’écran en pièce jointe
Faut-il continuer à créer des tickets une fois le projet mis en ligne ?
Une fois le site en ligne, une période de garantie est généralement prévue, suivie (si le contrat le stipule) d’une Tierce Maintenance Applicative (TMA).
Que ce soit pour signaler une anomalie ou demander une évolution, vous pouvez continuer à créer des tickets. Le chef de projet identifiera s’il s’agit d’une maintenance corrective ou évolutive, et les équipes concernées prendront le relais.
