« On a découvert que le site était en panne parce qu’un client nous a appelés, le lendemain matin. » Cette phrase revient régulièrement chez les petites agences qui gèrent quelques sites WordPress sans budget pour un service de supervision professionnel. Avant d’investir dans un outil dédié, il existe une solution minimale, largement suffisante pour détecter une panne nocturne avant que le client ne s’en aperçoive.
L’idée est simple : interroger le site à intervalle régulier depuis un serveur indépendant, vérifier que la réponse HTTP est cohérente, et alerter par email si ce n’est pas le cas. Aucun agent à installer sur le site surveillé, aucun abonnement mensuel, juste un script et une tâche planifiée.
Le script de base : curl et un code de sortie
La brique centrale de ce dispositif est curl, capable de récupérer uniquement le code de statut HTTP retourné par une URL sans télécharger la page entière :
#!/bin/bash
URL="https://exemple.fr"
CODE=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$URL")
if [ "$CODE" != "200" ]; then
echo "Alerte : $URL a répondu $CODE le $(date)" | mail -s "Site en panne : $URL" contact@agence.fr
fiCe script vérifie que le code retourné est bien 200. Un code 500 signale une erreur serveur (souvent un plugin qui plante ou une base de données inaccessible), un code 503 peut indiquer un mode maintenance ou une surcharge, et une absence totale de réponse dans le délai de 10 secondes défini par --max-time signale un serveur injoignable, ce qui est traité comme une chaîne vide par curl, donc différente de « 200 » également.
Planifier l’exécution avec cron, depuis un autre serveur
Le point souvent oublié : ce script doit tourner depuis une machine différente de celle qui héberge le site surveillé. Si le serveur du site tombe en panne complète, un cron qui tournerait dessus ne pourrait jamais alerter de quoi que ce soit. Une petite instance cloud à quelques euros par mois, ou même un poste toujours allumé au bureau, suffit comme point d’observation externe.
# crontab -e sur le serveur de supervision
*/5 * * * * /usr/local/bin/check-site.sh >> /var/log/check-site.log 2>&1Une exécution toutes les cinq minutes représente un bon compromis : elle détecte une panne en moins de 300 secondes dans le pire des cas, sans générer de charge notable ni sur le site surveillé, ni sur le serveur de supervision. Pour plusieurs sites, il suffit de dupliquer la logique dans une boucle ou un fichier de configuration séparé listant les URL à vérifier.
Éviter les fausses alertes
Un ping HTTP brut génère facilement des faux positifs si on ne l’affine pas un minimum :
- Un pic de charge ponctuel peut ralentir la réponse au-delà du
--max-timedéfini sans que le site soit réellement en panne : prévoir une seconde tentative avant d’alerter évite ce bruit. - Une mise à jour WordPress ou un plugin en mode maintenance renvoie parfois un code 503 volontaire : il faut accepter ce cas ou prévoir une fenêtre d’exclusion pendant les créneaux de maintenance planifiée.
- Vérifier uniquement le code HTTP ne détecte pas un site qui répond « 200 » mais affiche une page d’erreur PHP visible ou un écran blanc : pour aller plus loin, on peut chercher une chaîne de caractères attendue dans le corps de la page avec l’option
-oretirée et ungrepsur le contenu récupéré.
Les limites assumées de cette approche
Cette méthode a un mérite : elle coûte presque rien et se met en place en une heure. Elle a aussi des limites qu’il faut connaître avant de la présenter comme une solution complète à un client exigeant :
- Aucune notion d’historique de disponibilité exploitable pour un rapport mensuel : le log grossit, mais personne ne le lit sans effort supplémentaire de traitement.
- Pas d’escalade : si l’email d’alerte tombe lui-même dans un dossier spam ou si la boîte mail est pleine, personne ne voit jamais rien passer.
- Un seul point d’observation : si le serveur de supervision et le site surveillé traversent tous deux un incident réseau régional au même moment, ni l’un ni l’autre ne peut le détecter correctement.
- Aucune vérification multi-région : un site injoignable depuis l’Europe mais accessible depuis les États-Unis (cas rare mais réel de filtrage réseau) passera inaperçu.
Ce script n’a pas vocation à remplacer un outil de supervision professionnel pour un client qui dépend de son site pour son chiffre d’affaires. Il a vocation à combler le vide, aujourd’hui, pour une agence qui n’a encore rien.
En résumé
Un ping HTTP planifié par cron ne demande ni compétence avancée ni budget particulier, et couvre déjà le scénario le plus fréquent : un site qui tombe la nuit sans que personne ne s’en rende compte avant le lendemain. Ce n’est qu’une fois ce filet minimal en place que la question d’un outil de supervision plus complet, avec alerting multicanal et tableaux de bord, mérite d’être posée sérieusement.
