Réduire le temps de réaction, c’est raccourcir le délai entre le constat et le premier geste utile, pas le délai jusqu’au correctif parfait. Quatre durées se notent dans le ticket, séparément : la détection (heure du contrôle ou du message client), l’accusé de réception (une personne nommée prend le ticket), le diagnostic (code, périmètre, déploiement récent), le rétablissement (l’URL répond comme convenu). L’agence peut être rapide à réparer et lente à accuser réception. Le client, lui, mesure souvent la deuxième.
Où partent les minutes
L’alerte arrive sur une liste où chacun pense que l’autre regarde. Ou elle arrive la nuit sur une boîte que personne n’ouvre avant 9 h, alors que le contrat parle d’astreinte. Ou la personne qui accuse réception n’a pas le compte d’hébergement, et elle attend un collègue pour savoir si le serveur répond. Ou le dernier déploiement n’est pas dans un journal : on cherche dans les chats.
Aucun de ces délais ne se gagne avec un outil de plus. Ils se gagnent avec un destinataire unique, des accès déjà dans le coffre de la personne d’astreinte, et l’heure du dernier déploiement écrite dans le ticket de mise en ligne. Tant que ces trois-là manquent, chronométrer la réparation ne sert à rien : l’horloge a déjà tourné avant le premier curl.
Les cinq premières minutes
- Ouvrez l’URL depuis un réseau autre que le serveur, ou lancez
curl -sS -o /dev/null -w "%{http_code}\n" "https://example.com/". Notez le code et l’heure. Un 200 chez vous et un 502 chez le client se note aussi : ce n’est pas encore rétabli. - Testez une deuxième URL du même hôte. Une seule page en 404 n’est pas une panne de plateforme. Tout le vhost en 502 l’est.
- Lisez l’heure du dernier déploiement et du dernier changement DNS. Si c’est dans l’heure, le retour arrière est le premier geste, pas une recherche générale.
- Accusez réception dans le ticket : votre nom, l’heure. Envoyez au client, si le niveau le prévoit, le constat et l’heure du prochain point. Pas la cause.
- Seulement ensuite, journaux et hébergeur. Si vous commencez par les journaux, le message client part quarante minutes plus tard avec une cause encore fausse.
Le test d’URL suffit pour l’étape 1 si vous n’avez pas de terminal. Savoir lire le code obtenu, y compris un 502 face à un 404, évite de traiter une page absente comme une panne générale : analyser le code HTTP et erreurs 4xx et 5xx.
Ce qui doit être prêt avant l’incident
La personne d’astreinte ouvre le coffre sans appeler un associé : panneau, DNS, WordPress. Le journal des déploiements est un endroit unique, pas le souvenir du développeur. Le canal client est déjà choisi. Le critère de retour arrière est déjà écrit : par exemple, pas de 200 sur l’accueil vingt minutes après un déploiement, avec une sauvegarde identifiée.
Sans critère, les cinq premières minutes deviennent un débat. Avec un critère, elles deviennent un geste. Le débat se fait le lendemain, sur la fiche, pas pendant le 502.
Relire les durées, pas une moyenne vague
En fin de mois, pour les incidents de niveau 1, notez les quatre heures. Vous verrez si c’est la détection (contrôle trop espacé), l’accusé (mauvais destinataire) ou le diagnostic (pas d’accès, pas de journal de déploiement). Une seule de ces causes se corrige par mois. Corriger les trois d’un coup ne se voit pas dans le ticket suivant.
Le livrable est le canevas des cinq minutes, imprimé ou épinglé, plus les quatre heures remplies dans chaque ticket de niveau 1. Un ticket sans heure d’accusé de réception ne compte pas comme une réaction rapide. Il compte comme une réaction non mesurée, même si le site est revenu.