Pendant une panne, l’agence a trois rôles tenus par des personnes différentes dès que l’équipe le permet : une personne technique, une personne qui parle au client, une personne qui tient le lien avec l’hébergeur. Le fait de départ est un code, pas une impression : l’accueil répond 500, 502, 504, ou ne répond pas. Tant que ces trois rôles sont dans la même tête, le client reçoit des nouvelles contradictoires et personne ne garde la chronologie.
Qui fait quoi
| Rôle | Fait | Ne fait pas |
|---|---|---|
| Technique | Rejoue la requête, lit le code et les journaux, propose retour arrière ou correctif | N’écrit pas au client en parallèle |
| Parole client | Envoie l’état, l’heure du prochain point, la décision de retour arrière | N’annonce pas une cause non vérifiée par le rôle technique |
| Lien hébergeur | Ouvre ou relance le ticket avec l’heure, l’URL, le code, ce qui a déjà été tenté | Ne promet pas l’heure du datacenter |
Si vous n’êtes que deux, fusionnez lien hébergeur et technique. Ne fusionnez pas la parole client avec le reste : la personne qui a les mains dans les journaux oublie l’heure du prochain point. Les messages eux-mêmes suivent un canevas stable ; la crise ajoute seulement la répartition des rôles et le droit de revenir en arrière.
Les vingt premières minutes
- Le rôle technique note l’heure et le code de l’URL convenue (accueil, paiement). Il vérifie si c’est tout le vhost ou une seule URL, depuis un réseau autre que le serveur.
- Il regarde l’heure du dernier déploiement et le dernier changement DNS. La plupart des crises d’agence commencent là, pas dans un mystère.
- La parole client envoie le constat et l’heure du prochain point. Pas une durée de réparation.
- Si le déploiement est le candidat, le critère de retour arrière s’applique sans débat de vingt minutes supplémentaires. Exemple de critère, à écrire au calme : pas de HTTP 200 sur l’accueil vingt minutes après la mise en ligne, alors que la sauvegarde d’avant déploiement est identifiable.
- Le lien hébergeur n’ouvre le ticket que si la cause n’est pas le déploiement, ou si le serveur ne répond plus du tout. Le ticket contient l’heure, l’URL, le code, et la phrase pas de changement de notre côté depuis HH:MM seulement si c’est vrai.
Un 503 que vous avez posé vous-même pour une maintenance n’est pas une crise. C’est un créneau. La crise, c’est le même code en dehors du créneau, ou un créneau dépassé. La pose volontaire est décrite dans gérer une erreur 503.
Revenir en arrière ou corriger en avant
Le retour arrière est le défaut quand vous avez une sauvegarde ou un artefact d’avant le déploiement, et que le site d’avant répondait. Corriger en avant (patch sur la production déjà cassée) se justifie quand le retour arrière est impossible : migration de base déjà irréversible, ou correctif de sécurité qui ne doit pas être défait. Écrivez le choix dans le ticket en une ligne, avec l’heure. Le client l’entend dans le message suivant, en langage clair : retour à la version de 9 h 12, ou correctif maintenu et vérifié.
Ne lancez pas, dans la même demi-heure, un changement de DNS, une mise à jour d’extension et un vidage de cache pour voir. Vous ne saurez pas ce qui a rétabli le 200. Un seul geste, puis un nouveau contrôle HTTP.
Ce que voient les visiteurs du client
Le client décide du message à ses propres clients. Vous lui proposez une phrase factuelle : le service est interrompu depuis telle heure, les commandes passées avant cette heure ne sont pas perdues, ou vous ne pouvez pas encore le garantir. Vous ne publiez pas à sa place sur ses comptes. Une page d’état n’a de sens que si l’URL est déjà connue. Le cadre est celui d’une page d’état. Sinon, le canal habituel du client suffit.
Si des paiements sont en jeu, dites ce que vous avez vérifié : la page de paiement répond ou non, les commandes en base s’arrêtent à quelle heure. Ne dites pas que rien n’a été perdu sans avoir regardé.
Le lendemain, à froid
La crise se ferme par une page : chronologie (heure, code, geste), rôle de chacun, ce qui a manqué (sauvegarde introuvable, critère de retour arrière absent, deux personnes ont écrit au client), une seule modification de la fiche pour la fois suivante. Pas une liste de dix outils. La chronologie vient du ticket, tenu comme dans documenter un incident.
Le livrable à préparer avant la prochaine panne est la carte des rôles, avec les noms et le critère de retour arrière, glissée dans le dossier du client. Le jour même, vous ne rédigez plus cette carte : vous la tenez.