Votre site est en panne : que faire dans les quinze premières minutes

Un site qui ne répond plus se règle rarement dans le code. Le réflexe est d'ouvrir l'éditeur : résistez dix minutes. La faute n'est presque jamais là où vous auriez regardé en premier, et ces dix minutes passées à cerner le problème vous épargnent une heure de tâtonnements. L'ordre qui fonctionne tient en cinq gestes : confirmer que la panne est réelle, situer la couche fautive, chercher ce qui a changé, dire un mot à ceux qui vont s'en apercevoir, et seulement ensuite réparer.

Les quinze minutes, en un coup d'œil

Ce découpage n'a rien de militaire. Il sert à une seule chose : vous empêcher de passer les quinze minutes entières sur la première hypothèse venue, qui est aussi celle que vous avez le plus envie de croire.

1. Confirmer la panne, depuis l'extérieur

Votre navigateur ment. Il met en cache, il conserve d'anciennes entrées DNS, et votre réseau de bureau est peut-être le seul concerné au monde.

Trois vérifications suffisent, et elles prennent moins d'une minute :

• Le site en 4G, Wi-Fi coupé. Si la page s'affiche, le problème est votre connexion, pas le site. C'est le test le plus rentable de la liste.
• Une fenêtre de navigation privée. Elle écarte une session expirée, une extension de navigateur, un service worker resté en place après un déploiement.
• Quelqu'un dans une autre ville. Une panne régionale d'opérateur ressemble trait pour trait à une panne de serveur, vue depuis votre bureau.

Si les trois échouent, la panne est réelle, et vous le savez avant d'avoir ouvert le moindre fichier. Si l'une des trois réussit, vous venez d'économiser une heure à chercher une panne qui n'existait pas.

2. Identifier la couche fautive

Le message d'erreur exact vaut mieux que n'importe quelle intuition. Notez-le au mot près, avec l'heure, avant de continuer : dans une demi-heure vous ne vous en souviendrez plus, et c'est la seule information que personne ne pourra reconstituer.

Les trois codes de la famille 500 se distinguent mal à l'œil nu et ne se réparent pas du tout de la même façon : ce que chaque code veut dire mérite deux minutes de lecture avant la première commande.

3. Cinq commandes qui répondent en trente secondes

Une console vaut mieux qu'un navigateur pour cette étape : elle ne met rien en cache et elle vous donne le code brut.

curl -I https://exemple.fr            # le code renvoyé, sans le navigateur
dig +short exemple.fr                 # le domaine pointe-t-il encore au bon endroit
ping -c 3 exemple.fr                  # la machine est-elle seulement joignable
echo | openssl s_client -connect exemple.fr:443 2>/dev/null | openssl x509 -noout -dates
tail -n 100 /var/log/nginx/error.log  # ou storage/logs/laravel.log selon la pile

La première ligne suffit à trancher entre « rien ne répond » et « quelque chose répond mal », qui sont deux pannes sans aucun rapport. La deuxième attrape le cas que personne ne soupçonne assez tôt : un enregistrement DNS modifié la semaine dernière et propagé seulement maintenant. La dernière est celle qu'on saute toujours, et c'est presque toujours celle qui contient la réponse.

4. Se demander ce qui a changé

Presque toute panne suit un changement, et le changement n'est pas toujours le vôtre.

• Un déploiement ce matin, même minuscule, même « sans risque ».
• Une mise à jour automatique cette nuit, système, extension ou dépendance.
• Un certificat expiré à deux heures du matin.
• Un nom de domaine arrivé à échéance.
• Un prélèvement refusé chez l'hébergeur, avec un avis parti dans les indésirables.
• Une API tierce qui a changé de version sans prévenir personne.

Dans le cas rare où rien n'a bougé chez vous, le changement a eu lieu chez quelqu'un d'autre, et vous ne l'apprendrez pas par un message : votre hébergeur ne vous prévient pas, et ce n'est pas de la mauvaise volonté, c'est la façon dont ses alertes sont conçues.

5. Dire un mot, avant qu'on vous le demande

Si la panne dure plus de dix minutes, trois lignes sur le canal que vos clients lisent vraiment valent mieux qu'une explication parfaite publiée trois jours plus tard.

Le site est indisponible depuis 14 h 20. Nous avons identifié la cause et nous travaillons dessus. Prochain point à 15 h, au même endroit.

Ce message dit trois choses et pas une de plus : depuis quand, où vous en êtes, quand vous reparlerez. Ne promettez pas d'heure de rétablissement tant que la cause n'est pas connue : une promesse manquée coûte plus cher que le silence. Pour un client sous contrat, l'incident finira de toute façon dans le rapport du mois ; il vaut mieux qu'il y arrive avec vos mots plutôt qu'avec les siens.

6. Les cinq gestes qui aggravent la situation

• Redémarrer le serveur avant d'avoir lu le journal. Le redémarrage efface souvent la trace de ce qui a cassé. La panne revient deux heures plus tard, et vous n'en savez pas davantage.
• Toucher au DNS. Une modification de zone met des heures à se propager, et vous ajoutez alors une panne à la panne.
• Déployer un correctif non testé. Sous pression, la probabilité d'aggraver dépasse largement celle de réparer.
• Vider tous les caches en même temps. Vous perdez l'information qui vous aurait dit lequel était en cause, et vous chargez la base au pire moment.
• Annoncer une heure de rétablissement. Tant que la cause est inconnue, toute échéance annoncée est une échéance qui sera manquée.

7. Ensuite, la seule question qui compte

Pas pourquoi ça a cassé : vous le savez maintenant. La vraie question est : combien de temps ai-je mis à l'apprendre ?

Si la réponse est « c'est un client qui me l'a dit », la panne n'était pas l'incident. L'incident, c'était d'être le dernier informé. Et la facture n'a rien de symbolique : ce que coûte réellement une heure d'indisponibilité se chiffre, y compris pour un site qui ne vend rien en ligne.

Cette partie se règle en quelques minutes : une vérification qui tourne toute seule, un email dès que le site cesse de répondre, un autre au retour à la normale. Restent deux réglages qui comptent autant que l'outil lui-même, à quelle fréquence vérifier et ce qui transforme une vérification en alerte, faute de quoi vous aurez seulement remplacé le silence par du bruit. Et si vous hésitez encore entre un script maison et un service extérieur, la comparaison honnête est dans surveillance interne ou externe.

Quand ce n'est pas une panne

Un cas mérite son propre réflexe parce qu'il ressemble à une panne sans en être une : un certificat expiré. Le serveur répond parfaitement, c'est le navigateur qui refuse d'afficher la page. Rien dans vos journaux applicatifs ne le signalera, redémarrer quoi que ce soit n'y changera rien, et le seul indice est cet avertissement rouge que vos visiteurs voient avant vous.