Pourquoi le client apprend la panne avant l'agence
Sans surveillance, la panne se découvre par le mauvais bout : le client ouvre son site, voit une erreur, et vous écrit. Le délai entre la panne et votre réaction n'est plus mesuré par vous, il est mesuré par lui. À l'inverse, une surveillance mal réglée produit un autre échec : dix alertes par semaine dont neuf sont fausses, un canal que plus personne ne lit, et la vraie panne qui passe inaperçue au milieu du bruit.
Le but n'est donc pas de tout surveiller, mais de savoir, pour chaque site, trois choses : est-il joignable, répond-il avec le bon contenu, et ses échéances (certificat, domaine) sont-elles loin. Un second besoin s'ajoute en fin de mois : le client demande une preuve de disponibilité, et seule une mesure continue, horodatée, permet d'y répondre sans reconstituer l'histoire de mémoire.
Les types de sonde et ce que chacune détecte
Faites défiler le tableau
| Sonde | Ce qu'elle détecte | Ce qu'elle ne voit pas |
|---|---|---|
| HTTP (code de réponse) | Serveur arrêté, erreur 5xx, délai dépassé, site injoignable | Une page d'erreur renvoyée avec le code 200 |
| HTTP avec mot clé attendu | Page vide, message d'erreur applicatif, base de données absente, page de maintenance oubliée | Un défaut visuel ou une fonction cassée plus loin dans le parcours |
| Certificat TLS | Certificat expiré ou sur le point de l'être, chaîne incomplète, mauvais nom d'hôte | Un site hors ligne dont le certificat reste valide |
| DNS | Enregistrement A, AAAA ou MX modifié ou disparu, zone qui ne répond plus | Un serveur web en panne derrière un DNS correct |
| Expiration du domaine | Domaine proche de sa date d'échéance, renouvellement automatique non actif | L'état de santé du serveur |
| Battement de tâche planifiée | Sauvegarde, cron ou file de messages qui ne s'est pas exécuté dans le délai prévu | Une tâche qui s'exécute mais produit un mauvais résultat |
La règle de confirmation : n vérifications avant d'alerter
La plupart des faux positifs sont des pannes de quelques secondes : un redémarrage de service, une coupure réseau sur la sonde, un pic de charge. Une alerte déclenchée à la première erreur réveille quelqu'un pour rien. La parade tient en une règle : ne déclarer la panne qu'après n vérifications consécutives en échec, espacées d'un intervalle court.
Le coût de cette règle est connu et chiffrable : le délai de détection est à peu près l'intervalle multiplié par n. Avec une vérification par minute et trois échecs consécutifs, on alerte après environ trois minutes. Pour un site vitrine, ce délai est acceptable. Pour une boutique en période de soldes, on raccourcit l'intervalle plutôt que de supprimer la confirmation. Et lorsqu'un incident est déclaré, on continue de vérifier : la fin de l'incident se confirme elle aussi par plusieurs réussites de suite, sinon le site qui clignote produit une rafale de messages alternés.
Les causes de faux positifs à éliminer
- Sonde unique — une seule sonde placée dans un seul réseau confond sa propre coupure avec celle du site ; deux emplacements indépendants, ou une seconde vérification depuis un autre point, tranchent.
- Délai trop court — un délai de réponse fixé en dessous du temps de chauffe d'un site WordPress froid déclenche une alerte à chaque première visite après une période creuse.
- Code seul — un contrôle limité au code 200 rate la page blanche, tandis qu'un mot clé trop fragile (une phrase d'accroche qui change) alerte à chaque modification éditoriale ; choisissez un élément stable, comme le nom de la marque dans le pied de page.
- Redirections non suivies — une redirection de http vers https ou de l'apex vers www, mal gérée par la sonde, passe pour une erreur.
- Protection anti-robots — un pare-feu applicatif ou une limite de débit qui bloque l'adresse de la sonde produit des 403 réguliers ; autorisez l'adresse de la sonde plutôt que d'abaisser la protection du site.
- Maintenance non déclarée — une mise à jour planifiée qui coupe le service pendant quelques minutes déclenche une alerte et salit le rapport du mois ; on la déclare avant, voir plus bas.
Seuils de départ indicatifs, à ajuster par site
Faites défiler le tableau
| Paramètre | Valeur de départ indicative | Raison |
|---|---|---|
| Intervalle de vérification | 1 minute pour un site critique, 5 minutes pour un site vitrine | Plus l'intervalle est court, plus la détection est rapide, mais plus la charge de la sonde augmente |
| Échecs avant alerte | 3 vérifications consécutives | Filtre les coupures de quelques secondes sans retarder la détection de plus de quelques minutes |
| Délai maximal de réponse | 10 à 30 secondes selon le site | Au-delà, le visiteur a déjà quitté la page |
| Réussites avant fin d'incident | 2 vérifications consécutives | Évite les messages d'ouverture et de clôture en rafale sur un site instable |
| Alerte d'expiration du certificat | 30, 14 puis 7 jours avant l'échéance | Laisse le temps de comprendre pourquoi le renouvellement automatique a échoué |
| Alerte d'expiration du domaine | 60 puis 30 jours avant l'échéance | Un domaine expiré coûte plus cher à récupérer qu'un serveur en panne |
Mettre en place la surveillance d'un portefeuille
Dresser l'inventaire des sites
Listez chaque site avec son adresse, son hébergeur, la date d'échéance de son domaine et un contact côté client. Sans cet inventaire, il est impossible de dire quel site n'est pas surveillé.
Choisir un mot clé stable par site
Ouvrez la page d'accueil et retenez un texte présent dans toutes les réponses normales, par exemple le nom de la marque. Vérifiez-le à la main avec
curl -s https://votre-domaine.com | grep -c "Nom de la marque".Mesurer la réponse d'un site à la main
Avant de configurer la sonde, relevez le code et le temps de réponse avec
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://votre-domaine.com. Ce temps de référence sert à fixer le délai maximal.Contrôler le certificat
Lisez la date de fin de validité avec
echo | openssl s_client -connect votre-domaine.com:443 -servername votre-domaine.com 2>/dev/null | openssl x509 -noout -enddate, puis activez la sonde de certificat avec les seuils du tableau.Contrôler le DNS
Notez les valeurs attendues avec
dig +short A votre-domaine.cometdig +short MX votre-domaine.com, puis faites alerter la sonde DNS sur tout écart.Régler intervalle et confirmation
Appliquez les valeurs de départ du tableau, puis laissez tourner une semaine. Une alerte fausse se corrige en réglant la cause, jamais en désactivant la sonde.
Relier chaque sonde à un canal
Associez les alertes critiques à un canal qui réveille quelqu'un, et les avertissements à un canal qu'on lit dans la journée, comme détaillé plus bas.
Fenêtres de maintenance et canaux d'alerte
Une fenêtre de maintenance est une plage horaire déclarée à l'avance pendant laquelle les pannes d'un site ne déclenchent pas d'alerte. Elle remplit deux fonctions : épargner votre astreinte, et rester visible dans le rapport, où la période est comptée à part au lieu d'être cachée. Une fenêtre bien tenue indique le site, l'heure de début, l'heure de fin et le motif. Ne la prolongez pas par habitude : une fenêtre ouverte en permanence est une surveillance éteinte.
Pour les canaux, séparez l'urgent de l'informatif. Une panne confirmée d'un site de production part vers un canal qui sonne, par exemple une messagerie d'équipe avec notification mobile ou un appel d'astreinte. Un certificat à 14 jours de l'échéance part vers un canal lu chaque matin, comme une boîte e-mail partagée ou un fil dédié. Prévoyez aussi un second destinataire : une alerte lue par une seule personne tombe en panne le jour de ses congés.
Cassez la sonde avant de lui faire confiance
Une sonde qui n'a jamais alerté n'est pas prouvée. Sur un site de test, changez volontairement le mot clé attendu ou arrêtez le service web, puis vérifiez trois choses : le délai avant l'alerte correspond au calcul intervalle fois n, le message arrive sur le bon canal, et la clôture se déclenche au retour du service. Rejouez ce test après chaque changement de sonde ou de canal.
Le rapport mensuel : ce que le client lit en deux minutes
Le client ne lit pas un journal d'événements. Il veut savoir, en une page, si son site a tenu, ce qui s'est passé quand il ne l'a pas fait, et ce que vous avez changé depuis. Un rapport utile tient sur une page et se génère à partir des mêmes mesures que celles qui déclenchent vos alertes, sans retouche manuelle : un rapport retouché perd sa valeur de preuve.
Le calcul de la disponibilité mesurée est volontairement simple : les minutes pendant lesquelles le site a répondu, divisées par les minutes de la période, après retrait des fenêtres de maintenance déclarées. À titre d'illustration seulement, 22 minutes d'indisponibilité sur une période de 43 200 minutes représentent environ 0,05 % de temps perdu. C'est un exemple de calcul, pas un engagement : indiquez toujours la méthode à côté du résultat, et ne promettez jamais un chiffre à l'avance.
Modèle de rapport mensuel
Faites défiler le tableau
| Rubrique | Contenu | Exemple |
|---|---|---|
| Période et périmètre | Dates de début et de fin, site, sondes actives, intervalle de vérification | Du 1er au 30 du mois, page d'accueil et page de contact, vérification toutes les 5 minutes |
| Disponibilité mesurée | Pourcentage calculé, minutes d'indisponibilité, méthode de calcul | 22 minutes sur 43 200, maintenance déclarée exclue |
| Incidents horodatés | Début, fin, durée de chaque incident | Le 12, de 02 h 14 à 02 h 36, soit 22 minutes |
| Cause | Origine établie, ou mention explicite qu'elle reste inconnue | Redémarrage d'un service après une mise à jour de sécurité |
| Actions menées | Ce qui a été corrigé ou décidé | Redémarrage planifié désormais placé hors des heures d'ouverture |
| Fenêtres de maintenance | Plages déclarées, déduites du calcul, avec leur motif | Le 20, de 03 h 00 à 03 h 30, mise à jour du système |
Disponibilité mesurée par l'agence et SLA de l'hébergeur : deux notions
Le rapport de l'agence mesure ce que voit un visiteur : le site a-t-il répondu, avec le bon contenu, depuis l'extérieur. Le SLA de l'hébergeur est un engagement contractuel de l'infrastructure, avec ses propres définitions, ses exclusions et ses modalités de compensation. Les deux peuvent diverger sans que personne ne mente : une application qui plante alors que le serveur tourne ne compte pas contre l'hébergeur, mais elle compte contre le site.
Ne présentez donc jamais votre mesure comme la garantie de l'hébergeur, ni l'inverse. Dans le rapport, dites ce qui a été mesuré, par quelle sonde, depuis quel point. Si un incident relève de l'infrastructure, joignez la demande faite à l'hébergeur et sa réponse, et lisez les conditions de son engagement avant de promettre une compensation à votre client. Ce partage clair des responsabilités protège aussi la relation : vous documentez, vous ne promettez pas à la place d'un tiers.
Quand le portefeuille grandit
À cinq sites, une feuille de calcul et quelques sondes suffisent. À cinquante, la difficulté devient l'exhaustivité : un site oublié, un domaine dont personne ne surveille l'échéance, un contact client périmé. Nommez un responsable de l'inventaire, ajoutez la création de sondes à la liste de mise en ligne d'un nouveau projet, et recoupez chaque mois la liste des sites surveillés avec celle des contrats.
Les sondes de disponibilité répondent à la question « le site fonctionne-t-il ? ». Elles complètent, sans les remplacer, la supervision des ressources du serveur et l'audit de sécurité mensuel : disque plein, mémoire saturée ou mise à jour en retard sont des causes de panne qu'il vaut mieux voir arriver que constater.
La documentation officielle
Manuel de curl : https://curl.se/docs/manpage.html
Commande openssl s_client : https://docs.openssl.org/master/man1/openssl-s_client/
Commande openssl x509 : https://docs.openssl.org/master/man1/openssl-x509/
Outil dig : https://bind9.readthedocs.io/en/latest/manpages.html
Protocole RDAP et dates d'expiration d'un domaine : https://www.icann.org/rdap
Documentation d'Uptime Kuma : https://github.com/louislam/uptime-kuma/wiki
