Le message arrive un mardi à 9 h 12 : « le site ne marche plus ». Trois mots, et déjà deux allers-retours à prévoir avant même de commencer à chercher. Un ticket d’assistance correctement rédigé fait l’inverse : il contient la moitié du diagnostic, et l’intervention démarre dans la minute. Voici les sept informations qui changent tout, un modèle à copier tel quel, et ce que vous êtes en droit d’exiger en retour.
Pourquoi un ticket écrit vaut mieux qu’un appel
Le téléphone rassure, l’écrit répare. Un appel laisse une trace dans une mémoire, un ticket laisse une trace dans un historique. La différence se voit trois semaines plus tard, quand le même symptôme réapparaît et que personne ne se souvient de ce qui avait été fait.
- Rien ne se perd. Le message d’erreur exact, l’heure, l’adresse de la page : autant d’éléments qu’on ne dicte pas au téléphone sans les déformer.
- La priorisation devient possible. Entre une boutique à l’arrêt et une faute de frappe à corriger, l’ordre n’est pas discutable. Encore faut-il que les deux demandes soient écrites côte à côte.
- Le dossier se reprend. Un autre intervenant relit le fil et sait où en est l’affaire, sans vous faire tout raconter une deuxième fois.
- Vous gardez une preuve de ce qui a été demandé et livré, utile le jour où un désaccord de périmètre apparaît.
Une nuance honnête : si la boutique est totalement à l’arrêt un samedi de forte activité, on appelle d’abord et on ouvre le ticket ensuite, qui sert alors de compte rendu. Pour tout le reste, notre assistance technique par tickets traite plus vite une demande écrite qu’un appel commenté.
Les sept informations qui font gagner une heure
- L’adresse exacte de la page. Pas « la page contact » : l’adresse complète, copiée depuis la barre du navigateur. Un site de trente pages contient souvent trois formulaires différents ; savoir lequel est concerné évite d’en tester trois.
- Ce que vous faisiez, étape par étape. « J’ai cliqué sur Ajouter au panier, puis sur Commander, et la page est restée blanche. » Trois phrases valent mieux qu’un adjectif.
- Ce que vous attendiez, et ce qui s’est passé. Cette distinction sépare la panne du malentendu : une fonction qui n’a jamais existé n’est pas en panne, elle est à développer.
- Depuis quand, et ce qui a changé avant. Mise à jour, publication, modification d’une zone DNS, changement d’offre chez l’hébergeur : la dernière modification est toujours la première suspecte.
- Le navigateur, l’appareil et le réseau. Un défaut visible uniquement sur Safari iOS, ou uniquement depuis le wifi du bureau, n’a rien à voir avec un défaut visible partout : dans le second cas la cause est sur le serveur, dans le premier elle est ailleurs.
- Une capture d’écran, ou mieux, une courte vidéo. Le message d’erreur complet, pas résumé de mémoire. Les codes comptent : 403, 404, 500 et 503 mènent à quatre pistes différentes.
- La reproductibilité. « À chaque fois » et « une fois sur cinq » ne se traitent pas de la même façon. Demandez à un collègue de refaire le parcours depuis un autre poste : sa réponse vaut souvent une heure de recherche.
Le modèle de ticket à copier
Copiez ce bloc, remplissez ce que vous savez, laissez vide le reste : un modèle rempli à moitié reste dix fois plus utile qu’un message libre.
Objet : fonction concernée + symptôme en quatre mots Adresse concernée : l’adresse complète de la page Depuis quand : date et heure du premier symptôme Ce qui a changé avant : mise à jour, publication, DNS, hébergement, rien Étapes pour reproduire : 1. … 2. … 3. … Résultat attendu : ce qui aurait dû se passer Résultat obtenu : le message exact, recopié ou en capture Environnement : navigateur et version, appareil, réseau Reproductible : oui / non / par intermittence Impact : combien de personnes, quelle fonction bloquée Urgence proposée : P1, P2, P3 ou P4 Accès : disponibles / à créer Pièces jointes : capture, vidéo, export du journal d’erreurs
Un exemple rempli, pour montrer ce que cela donne en vrai :
Objet : formulaire de devis, aucun courriel reçu Adresse concernée : la page « demande de devis » du site Depuis quand : jeudi 14 h environ, un client nous l’a signalé vendredi matin Ce qui a changé avant : mise à jour de six extensions mercredi soir Étapes : 1. remplir les quatre champs 2. cliquer sur Envoyer 3. le message « merci » s’affiche Résultat attendu : réception d’un courriel sur l’adresse contact Résultat obtenu : rien, ni dans la boîte ni dans les indésirables Environnement : Chrome sur Windows, et Safari sur iPhone, même symptôme Reproductible : oui, trois essais sur trois Impact : toutes les demandes commerciales entrantes Urgence proposée : P2
Ce ticket-là se traite sans une seule relance. Le message de confirmation qui s’affiche alors que rien n’arrive oriente vers l’envoi de courriel et non vers le formulaire, et la mise à jour de la veille désigne la piste à ouvrir en premier.
Urgent, important, ou simplement agaçant
Une échelle de priorité honnête se définit par l’impact, jamais par l’émotion. Tout marquer urgent revient à ne rien prioriser, et retarde les vraies urgences.
| Niveau | Ce que cela recouvre | Exemple |
|---|---|---|
| P1 | Site totalement indisponible ou compromis | Erreur 500 sur toutes les pages, redirection vers un site inconnu |
| P2 | Fonction commerciale bloquée, le reste fonctionne | Paiement refusé, formulaire muet, connexion client impossible |
| P3 | Dégradation visible sans blocage | Image déformée sur mobile, page qui met huit secondes à s’afficher |
| P4 | Demande d’évolution ou de confort | Ajouter un champ, changer une couleur, créer une page |
Un repère simple pour trancher : si la panne coûte de l’argent chaque heure, c’est P1 ou P2. Si elle vous agace sans rien coûter, c’est P3. Si elle améliore quelque chose qui fonctionne déjà, c’est P4. Avant d’ouvrir un ticket de premier niveau, passez en revue les vérifications à faire avant d’ouvrir un ticket. Chez Aloha Pixel, une intervention se réserve à l’unité sur la page ticket d’assistance : le ticket est facturé 89 € pour une heure d’intervention en visioconférence, et le pack de cinq tickets 399 € (TVA non applicable, art. 293 B du CGI). Le premier créneau est proposé sous 48 h.
Préparer les accès avant d’en avoir besoin
La moitié des retards d’intervention ne vient pas du diagnostic mais de l’attente d’un mot de passe. Rassemblez ces cinq accès une fois pour toutes, dans un gestionnaire de mots de passe, et la question ne se posera plus : l’administration du site, l’hébergement, le gestionnaire du nom de domaine, la messagerie associée au domaine et les outils de mesure. Les deux derniers sont systématiquement oubliés, alors qu’un formulaire muet se diagnostique du côté de la messagerie et qu’un incident se mesure dans la console de recherche.
Quatre règles suffisent à rendre tout cela sûr : un compte nominatif par intervenant plutôt qu’un compte partagé, aucun mot de passe transmis par courriel ou par messagerie instantanée, une double authentification activée sur les comptes sensibles, et un retrait des accès en fin de mission. Vous restez titulaire de tous vos comptes, sans exception. Le guide d’hygiène informatique de l’ANSSI détaille cette gestion des comptes, et les mesures de sécurité essentielles complètent le tableau côté site.
Ce que vous êtes en droit d’attendre en retour
Un ticket bien rédigé mérite une contrepartie. Voici ce qu’il faut exiger, de préférence avant de signer.
- Un accusé de réception confirmant la prise en compte et le niveau de priorité retenu, éventuellement différent de celui que vous proposiez, avec la raison.
- Un délai de prise en charge annoncé, écrit noir sur blanc, et non « dès que possible ».
- Un point d’étape dès que l’intervention dépasse la durée annoncée, même pour dire qu’on cherche encore.
- Une explication en français compréhensible. « Le cache était corrompu » n’est pas une explication ; « une extension de cache servait une version périmée de la page d’accueil, nous l’avons vidée et exclu la page de commande » en est une.
- Un compte rendu écrit en fin d’intervention : cause, correction, mesure de prévention.
Attention à une confusion volontairement entretenue dans beaucoup de contrats : le délai de réponse n’est pas le délai de résolution. Une garantie de réponse en deux heures n’engage à rien sur la remise en ligne. Demandez les deux chiffres séparément.
Notre position : ce qui entre dans un suivi, ce qui n’y entre pas
Poser une frontière claire rassure plus que cela ne freine. Relèvent du suivi technique : les correctifs, les mises à jour supervisées, les restaurations, les incidents de disponibilité et les petites modifications de contenu. Relèvent d’un projet : une nouvelle fonctionnalité, la refonte d’une page, une intégration à un logiciel de gestion, la création d’un espace client.
Cette ligne protège les deux parties. Elle évite au client de voir son suivi se transformer en file d’attente permanente, et au prestataire de livrer gratuitement, par petits bouts, un développement qui aurait mérité un cadrage. Quand une demande bascule du côté projet, elle est chiffrée à part et planifiée : plus lent à annoncer, beaucoup plus rapide à livrer. Nos formules incluant le suivi technique reposent sur cette distinction, et les demandes qui relèvent d’un projet suivent un chemin différent.
Questions fréquentes
Que faire si je n’arrive pas à reproduire le problème ?
Signalez-le tel quel, avec l’heure exacte à laquelle il s’est produit et ce que vous faisiez. Les journaux du serveur conservent les erreurs horodatées : une heure précise suffit souvent à retrouver la trace d’un incident qui ne se reproduit plus.
Dois-je donner mes accès administrateur ?
Oui, mais jamais les vôtres. Créez un compte dédié au nom de l’intervenant, avec double authentification, et supprimez-le en fin de mission. Vous gardez ainsi la trace de qui a fait quoi, et vous reprenez la main en une manipulation.
Combien de temps avant une réponse ?
Cela dépend du niveau de priorité annoncé, et ce délai doit figurer par écrit dans votre contrat. Exigez deux chiffres distincts : le délai de prise en charge et le délai de résolution visé selon le niveau.
Puis-je envoyer plusieurs demandes dans un seul ticket ?
Non. Un sujet par ticket. Trois demandes dans un même message rendent le suivi illisible, empêchent toute priorisation et garantissent qu’au moins l’une des trois sera oubliée.
Ce qu’il faut retenir
Un bon ticket n’est pas un exercice administratif, c’est la moitié du diagnostic déjà faite. Les sept informations tiennent en cinq minutes de rédaction et font gagner une heure d’intervention. Gardez le modèle dans vos notes et utilisez-le dès la prochaine demande : la différence se verra au premier échange.
À lire aussi : ce qui arrive quand la maintenance est ignorée
