Le monitoring d’une page web spécifique part du principe que chaque URL a son propre contrat. L’accueil peut être servi par un cache pendant que l’URL de commande interroge une base et un prestataire de paiement. Surveiller la première rassure. Elle ne dit rien de la seconde. On choisit les URL dont l’échec a une conséquence, et on écrit pour chacune le code, la redirection et le texte attendus.
Ce que l’accueil ne prouve pas
Une page d’accueil en 200 prouve que cette URL-là, éventuellement mise en cache, a renvoyé du HTML. Elle ne prouve pas que :
/contactcontient encore le formulaire ;/panierou l’étape de paiement répondent sans erreur applicative ;/compte/connexions’affiche, même sans tester un mot de passe ;- une fiche produit très liée, si votre chiffre en dépend, n’est pas devenue une 404 après un import.
Le cache CDN renforce l’écart. Il peut continuer à servir l’accueil alors que l’origine est arrêtée. La page qui n’est pas en cache, elle, échoue tout de suite. Si vous ne la contrôlez pas, vous découvrez l’incident par un client.
Tenez la liste courte. Le guide du site vitrine en donne l’échelle : quelques URL. Une boutique ajoute le tunnel, pas l’ensemble du catalogue, sauf méthode à part pour les 404 massives. Chaque URL ajoutée « au cas où » est une alerte de plus à classer.
Écrire le contrat de cette URL
Pour une page, notez quatre lignes, celles de la définition du monitoring :
- Code final. Souvent 200. Une URL volontairement redirigée a pour contrat le 301 et l’URL d’arrivée, pas un 200 sur l’ancienne adresse.
- Redirections acceptées. Zéro, ou une seule, de HTTP vers HTTPS. Une chaîne plus longue est un échec même si le HTML final est bon.
- Chaîne présente. Un libellé qui n’existe que sur cette page : « Valider la commande », le nom du formulaire, un identifiant stable dans le HTML. Évitez une phrase que le marketing réécrit chaque mois.
- Chaîne interdite, si vous avez déjà vu une page d’erreur habillée en 200 ou un texte parasite. L’absence de cette chaîne fait partie du succès.
Le temps de réponse se compare à l’habitude de cette URL, pas à celle de l’accueil. Les seuils se règlent donc par page.
Vérifiez le contrat à la main avec un test d’URL le jour où vous l’écrivez. Vous confirmez que la chaîne est bien dans le HTML public, pas seulement dans un bloc chargé après coup par un script que le contrôle HTTP ne exécute pas. Si l’essentiel de la page n’existe qu’en JavaScript, un contrôle de code source ne voit qu’une coquille : il faut alors un parcours de navigateur, ce qui est un autre outil, plus lourd, à réserver à une ou deux URL.
Session, cache, méthode HTTP
Une sonde sans cookie reçoit la version anonyme. C’est ce que voit un nouveau visiteur, et c’est souvent le bon test. Pour une page réservée aux comptes, la sonde verra la redirection vers la connexion. Surveillez cette redirection explicitement, ou ouvrez un compte de test dont le seul droit est de voir une page factice. Ne placez pas un mot de passe d’administrateur dans la configuration du contrôle.
N’envoyez pas de POST répété vers un formulaire de contact ou de commande. Vous créeriez des messages et, parfois, des paiements. Le GET qui vérifie la présence du formulaire détecte le modèle cassé, le plugin désactivé, la 500. Il ne détecte pas un envoi qui échoue au moment du POST. Ce dernier cas se teste au déploiement, pas toutes les cinq minutes.
SiteGarde suit les URL que vous avez listées, pas « le site » comme un bloc. Si une page critique n’est pas dans la liste, elle n’est pas surveillée, quel que soit l’état de l’accueil.