Gérer un incident client, c’est une série de messages datés, pas une résolution silencieuse suivie d’un c’est réparé. Le premier message part dès que vous avez constaté le fait : l’URL, le code HTTP (500, 502, 504, ou délai sans réponse), l’heure, et l’heure du prochain point. Il ne contient pas la cause. Vous ne la connaissez en général pas encore, et une cause devinée qui change une heure plus tard est ce dont le client se souviendra.
Le premier message
Canal écrit dans le contrat ou, à défaut, l’e-mail du contact nommé. Objet stable : nom du site, incident , code. Corps, cinq lignes :
- Ce qui est constaté, avec l’URL et le code, depuis quelle heure.
- Ce qui fonctionne encore si vous le savez (le blog répond 200, le paiement non).
- Ce que vous êtes en train de faire (qualification, ticket hébergeur avec sa référence).
- L’heure du prochain message, même si rien n’a bougé.
- Le nom de la personne qui écrit. Les suivants partent du même nom, ou vous annoncez le relais.
Vous n’écrivez pas tout le site est tombé si vous n’avez testé que l’accueil. Vous n’écrivez pas une heure de rétablissement. Vous écrivez une heure de prochain point. La différence compte : la première est une promesse technique, la seconde est une promesse de communication, que vous pouvez tenir.
La cadence tant que ce n’est pas rétabli
Chaque message reprend l’état actuel, pas l’historique complet. Trois phrases : état (toujours 502 sur l’URL de paiement), fait nouveau (l’hébergeur a accusé réception, ou un retour arrière est en cours), prochaine heure. Si vous avez écarté une piste, vous pouvez le dire : ce n’est pas le certificat, il est valide jusqu’au 12 mars. Cela montre que le temps passe sur des vérifications, pas sur l’attente.
Le client qui répond des nouvelles ? cinq minutes avant l’heure promise a souvent raison d’être tendu, et tort seulement si vous avez déjà tenu les heures précédentes. Si vous avez manqué une heure, le message suivant commence par le retard, pas par une explication longue.
Tenez un seul fil. Le technique va dans le ticket interne : hypothèses, commandes, captures. Le client ne reçoit pas ce fil. Il reçoit l’état. La façon de conserver le détail pour plus tard est celle de documenter un incident.
Ce que vous ne dites pas
| Tentation | À la place |
|---|---|
| C’est un pic de trafic sans chiffre ni journal | Cause non établie. Nous regardons les journaux d’accès et le code HTTP. |
| L’hébergeur est nul | La référence du ticket hébergeur et l’heure de sa dernière réponse |
| Ce sera rétabli dans vingt minutes | L’heure de votre prochain message |
| Deux personnes qui écrivent au client | Un nom dans le ticket, les autres se taisent vers l’extérieur |
| Un correctif décrit dans le détail avant qu’il soit en production | Retour arrière en cours ou correctif en cours de vérification |
Un 404 et un 503 ne se racontent pas de la même façon. Le 404 peut être une URL jamais publiée. Le 503 peut être votre maintenance. Qualifier le code avant d’écrire évite d’annoncer une panne générale pour une page absente. La distinction de familles de codes est dans erreurs 4xx et 5xx.
Clôturer pour de bon
Le message de clôture attend que vous ayez revu l’URL vous-même : code attendu, heure de fin, ce qui a été fait en une ou deux phrases, et si des contenus ont été restaurés depuis une sauvegarde (dans ce cas, dites jusqu’à quelle heure les contenus sont revenus). Proposez au client le canal habituel pour les suites, et fermez le fil d’incident. Laisser le fil ouvert au cas où mélange le prochain ticket avec celui-ci.
Si l’incident a été visible des visiteurs du client, une phrase publique (page d’état, bandeau, message sur le canal qu’il utilise déjà) se décide avec lui, pas à sa place. Une page d’état a un intérêt quand les incidents se répètent ou que les visiteurs sont nombreux : le cadre est celui d’une page d’état. Vous ne l’inventez pas au milieu de la nuit si personne ne l’a préparée.
Le livrable, une fois calmé, est le fil de messages plus le ticket. Relisez-les le lendemain : est-ce que chaque message avait une heure suivante, est-ce qu’une seule personne a parlé, est-ce que la clôture dit si une sauvegarde a écrasé des contenus. Ce sont les trois points que le client, lui, a déjà jugés. Le prochain incident n’a pas besoin d’un nouveau ton : il réutilise le même canevas.