Surveiller le site d’un client, c’est interroger ses URL depuis l’extérieur et comparer la réponse à un attendu écrit : code HTTP 200 (ou 301 vers la bonne adresse), et un mot présent dans le HTML, en général le nom du site. SiteGarde fait cette requête, garde l’historique et envoie un e-mail quand l’état change. Le panneau de l’hébergeur, qui se teste lui-même depuis son réseau, ne remplace pas cette requête.
Ce que vous écrivez avant d’ajouter l’URL
Pour chaque site, une fiche courte :
| URL | Code attendu | Mot attendu dans le HTML | Qui reçoit l’e-mail |
|---|---|---|---|
| https://example.com/ | 200 | le nom du site | boîte d’astreinte de l’agence |
| page devis ou paiement | 200 | un libellé stable du formulaire | la même boîte |
| variante http | 301 vers https | rien, le code suffit | personne la nuit |
| préproduction | hors fiche client |
Le mot attendu évite de prendre pour sain un 200 qui affiche une page d’erreur d’hébergeur, un parking de domaine, ou une installation WordPress vierge. Choisissez un mot qui ne disparaît pas à chaque changement de slogan. Le titre du site dans le <title> ou un texte du pied de page conviennent mieux qu’une promotion du mois.
Ce que le contrôle ne voit pas
Il ne voit pas le chiffre d’affaires, ni si un humain trouve le bouton. Il ne prouve pas qu’un formulaire envoie un e-mail : un 200 sur la page de contact ne poste pas le formulaire. Il ne remplace pas Search Console, qui décrit l’indexation avec un décalage. Ces limites se notent sur la fiche, pour ne pas répondre au client le monitoring est vert quand sa question porte sur un mail jamais reçu.
Un certificat proche de l’expiration et un domaine proche de l’expiration sont d’autres contrôles, avec d’autres seuils (plusieurs jours, pas cinq minutes). Les coller dans la même alerte que le HTTP 500 réveille l’équipe pour un événement qui se traite dans la semaine. Séparez les canaux : immédiat pour le code inattendu, digest du matin pour le certificat.
La définition de ce qu’est une surveillance externe, et de ce qu’elle n’est pas, est posée dans qu’est-ce que le monitoring web. Pour vérifier à la main le même type de requête, le pas à pas tester la disponibilité sert au moment où vous ajoutez la fiche, pas tous les jours.
La fréquence suit le contrat, pas l’habitude
Si aucun délai n’est promis, un contrôle par heure sur l’accueil détecte une panne avant le coup de fil du matin, sans produire une alerte à chaque microcoupure. Si le contrat promet une prise en charge en trente minutes, l’intervalle doit être plus court que trente minutes, et il faut deux échecs de suite avant d’écrire à qui que ce soit. Un seul échec isolé se journalise. Il ne devient pas un incident client.
Ne pointez pas le contrôle vers une URL qui change (article du jour, produit en stock). Le jour où la page est retirée, vous aurez un 404 qui ressemble à une panne. Les URL de la fiche sont stables. Quand une refonte change l’adresse de la page devis, la fiche change le même jour, dans le ticket de mise en ligne.
Plusieurs clients dans le même outil
Un compte par agence, des projets ou des noms qui portent le nom du client, pas site 3. L’e-mail d’alerte arrive d’abord à l’agence. Le client reçoit, s’il doit le recevoir, le message réécrit par l’agence, pas le flux brut de tous les sites. Un regroupement par hébergeur aide le matin où douze sites tombent ensemble : c’est un incident d’infrastructure, pas douze pannes applicatives. Organiser ce portefeuille est le sujet du monitoring multi-clients.
Le livrable est la fiche d’URL signée avec le contact du client : ce qui est surveillé, le code, le mot, le destinataire, ce qui ne l’est pas. Sans cette fiche, chaque alerte relance le débat est-ce grave ?. Avec elle, le débat a déjà eu lieu au calme.