Pendant une panne, vos clients vous jugent sur deux choses : la rapidité avec laquelle le problème est résolu, et ce qu’ils entendent pendant ce temps. Vous ne maîtrisez pas toujours la première. La seconde dépend entièrement de vous, et c’est celle que la plupart des équipes improvisent.
L’improvisation tourne mal de façon prévisible. Personne ne publie rien pendant une heure parce que tout le monde est occupé à corriger le problème. Trois personnes publient trois versions différentes. La mise à jour parle d’« une dégradation sur le cluster eu-west » et les clients n’ont aucune idée de ce que cela signifie pour eux. Ce guide vous donne un plan d’une page pour trancher ces questions à l’avance, et des modèles à copier.
Le plan d’une page
Rédigez-le une fois, rangez-le là où la personne d’astreinte le trouvera, et relisez-le deux fois par an.
Rôles
Responsable de l’incident : pilote l’incident, fixe la gravité, coordonne la correction.
Chargé de communication : rédige et publie chaque mise à jour destinée aux clients. Ce n’est pas la personne qui corrige le problème : corriger et rédiger en même temps, c’est sacrifier l’un des deux.
Support : répond aux questions entrantes avec un lien vers la page de statut, et fait remonter ce que signalent les clients.
Dans une petite équipe, les mêmes personnes portent plusieurs casquettes. L’essentiel est de décider qui fait quoi avant la panne, pas pendant. En l’associant à un planning d’astreinte, les deux premiers rôles ont toujours un nom.
Niveaux de gravité
Trois niveaux suffisent à la plupart des équipes :
Majeur : le produit, le paiement ou la connexion est en panne ou inutilisable pour la plupart des clients. Mise à jour toutes les 30 minutes.
Mineur : une fonctionnalité est cassée ou lente, ou une partie de vos clients est touchée. Mise à jour toutes les heures.
Maintenance : travaux planifiés. Annonce à l’avance, mise à jour au début et à la fin.
Canaux
Page de statut : toujours, pour chaque incident visible par les clients. C’est la source de vérité vers laquelle renvoient les autres canaux.
Notifications aux abonnés : notifications par e-mail et messagerie depuis la page de statut, pour que les clients n’aient pas à actualiser sans cesse.
Bannière dans l’application : pour les incidents majeurs, si votre produit en a une.
E-mail direct : pour les incidents majeurs qui ont touché des comptes clés, et pour le résumé qui suit.
Réseaux sociaux : pour les incidents majeurs, avec un lien vers la page de statut, pas une version différente de l’histoire.
Engagements
Première mise à jour dans les 15 minutes qui suivent la découverte d’un problème visible par les clients.
Chaque mise à jour indique quand viendra la suivante.
Chaque incident se termine par une mise à jour « résolu ».
Les incidents majeurs font l’objet d’un court résumé écrit sous cinq jours ouvrés.
Ce que contient une bonne mise à jour
Chaque mise à jour, à chaque étape, répond à quatre questions, dans cet ordre :
Ce qui est touché, avec les mots des clients : « le paiement », « l’application mobile », « la connexion », pas le nom interne du service.
Ce qu’ils constatent : des erreurs, des lenteurs, des e-mails manquants.
Ce qu’ils peuvent faire, le cas échéant : une solution de contournement, ou « aucune action n’est nécessaire ».
Quand ils en sauront plus.
À éviter : les hypothèses sur la cause, les noms internes et le jargon, les reproches adressés à un fournisseur ou à un collègue nommé, et les promesses sur l’heure de résolution, sauf si vous en êtes sûr. « Nous prévoyons de résoudre le problème d’ici 30 minutes » est une promesse que vos clients vous rappelleront.
Des modèles pour chaque étape
Remplacez les passages entre crochets. Gardez un ton simple et posé.
Investigation en cours
Nous examinons des signalements [d’erreurs / de lenteurs] lorsque [les clients tentent de finaliser leur commande]. [Les autres parties du site fonctionnent normalement.] Nous publierons une mise à jour d’ici [30 minutes].
Cause identifiée
Nous avons identifié la cause : [un problème chez notre prestataire de paiement / une mise à jour défectueuse déployée à 14:05]. [Les paiements par carte échouent ; les factures et Swish ne sont pas concernés.] Nous [annulons la mise à jour / travaillons avec le prestataire] et publierons une nouvelle mise à jour d’ici [30 minutes].
Sous surveillance
Un correctif est en place et [le paiement] fonctionne de nouveau. Nous surveillons la situation pour nous assurer qu’elle reste stable. [Les commandes passées entre 14:05 et 14:40 peuvent apparaître en attente ; elles seront traitées automatiquement.] Prochaine mise à jour d’ici [une heure], ou plus tôt en cas de changement.
Résolu
Cet incident est résolu. Entre [14:05 et 14:40 CET], [les paiements par carte ont échoué pour la plupart des clients]. [La cause était une mise à jour défectueuse, que nous avons annulée.] [Nous ajoutons un contrôle pour que ce type d’erreur bloque une mise en production avant qu’elle n’atteigne les clients.] Nous vous prions de nous excuser pour la gêne occasionnée.
Pas encore de nouvelles
Nous travaillons toujours sur [les erreurs de paiement]. Rien n’a changé depuis la dernière mise à jour. Prochaine mise à jour d’ici [30 minutes].
Ce dernier modèle compte plus qu’il n’y paraît. Une page de statut qui n’a pas bougé depuis une heure fait croire aux clients que personne ne s’en occupe.
E-mail aux clients concernés
Pour les incidents majeurs qui touchent des comptes clés, un court e-mail après l’incident vaut plus que n’importe quelle page de statut. Envoyez-le au nom d’une personne, pas depuis une adresse no-reply.
Objet : À propos de la panne du paiement aujourd’hui
Bonjour [prénom], aujourd’hui entre 14:05 et 14:40, les paiements par carte ont échoué pour la plupart de nos clients, vous y compris. La cause était une mise à jour défectueuse de notre côté, que nous avons annulée. [Les commandes que vous avez passées pendant ce créneau ont maintenant été traitées.] Nous [ajoutons un contrôle automatique qui bloque ce type de mise en production]. Si vous avez constaté quelque chose qui ne correspond pas à ce récit, répondez à cet e-mail et je m’en occuperai personnellement. [Nom, fonction]
Réseaux sociaux
Restez bref et renvoyez vers la page de statut pour les détails :
Nous constatons des erreurs au moment du paiement et nous y travaillons. Suivez les mises à jour ici : [lien vers la page de statut]
Le paiement fonctionne de nouveau. Merci pour votre patience, et désolés pour la gêne. Résumé : [lien vers la page de statut]
Après l’incident
Pour les incidents majeurs, publiez un court résumé sur la page de statut ou par e-mail dans les jours qui suivent : ce qui s’est passé, combien de temps, qui a été touché, quelle en était la cause et ce que vous changez. Notre modèle de postmortem couvre l’analyse interne qui vient en premier, et la façon d’en tirer une version destinée aux clients.
Examinez ensuite la communication elle-même. Combien de temps a pris la première mise à jour ? Les heures de mise à jour promises ont-elles été tenues ? Le support a-t-il reçu des questions auxquelles les mises à jour auraient dû répondre ? Corrigez le plan, pas seulement le système.
Un plan facile à suivre
Un plan ne fonctionne que s’il est plus rapide de le suivre que de l’ignorer. Quelques éléments font la différence :
Savoir avant vos clients. Uptimecheck vérifie vos sites et vos API jusqu’à chaque minute depuis Stockholm, Londres et New York, confirme chaque échec depuis un second emplacement et alerte la personne d’astreinte : le compte à rebours de 15 minutes démarre quand le problème commence, pas quand arrive le premier ticket de support.
Des modèles prêts dans l’outil. Les pages de statut Uptimecheck proposent un premier jet prêt à l’emploi pour chaque étape (investigation, cause identifiée, surveillance, résolu) dans la langue de la page, ainsi que vos propres modèles enregistrés, où {components} insère les éléments concernés.
Prévenir les bonnes personnes. Les abonnés suivent toute la page ou seulement les composants qu’ils utilisent, par e-mail, Slack, Microsoft Teams, Discord ou webhook, et seuls ceux qui suivent les composants concernés sont notifiés.
Annoncer les maintenances à l’avance. Les maintenances planifiées s’affichent sur la page et sont envoyées par e-mail aux abonnés avant leur début.
Notre guide pour créer une page de statut qui inspire confiance explique ce qu’il faut mettre sur la page elle-même.
Checklist
Désignez à l’avance le responsable de l’incident, le chargé de communication et le support.
Mettez-vous d’accord sur trois niveaux de gravité et un rythme de mises à jour pour chacun.
Faites de la page de statut la source de vérité ; les autres canaux y renvoient.
Publiez la première mise à jour dans les 15 minutes, même si vous savez seulement que vous enquêtez.
Dites ce qui est touché, ce que constatent les clients, ce qu’ils peuvent faire et quand ils en sauront plus.
Donnez l’heure de la prochaine mise à jour, et tenez-la.
Clôturez chaque incident par une mise à jour « résolu ».
Envoyez un court résumé après les incidents majeurs, et analysez la communication autant que la correction.