Votre surveillance web doit détecter plus que les pannes

En ligne ne veut pas dire fonctionnel

Le contrôle le plus simple demande une page et vérifie si le serveur répond. S'il reçoit un code de réussite, le site est déclaré disponible.

Le voyant peut rester vert alors qu'un formulaire échoue, qu'une redirection se trompe, qu'un certificat approche de son expiration, qu'une politique disparaît ou qu'un contenu important change. Le serveur a répondu. Le site n'a pas forcément rempli son rôle.

Mesurer la disponibilité est utile. Ce n'est que la première question.

Surveillez les promesses faites par le site

Commencez par les actions publiques qui comptent. Une association peut dépendre des inscriptions, des documents et du formulaire de contact. Un organisme public peut dépendre d'avis et d'instructions. Une organisation militante peut avoir une échéance pour recevoir des réponses.

La surveillance n'a pas à reproduire chaque parcours. Elle doit couvrir les quelques pages et fonctions dont la panne créerait un préjudice opérationnel immédiat.

Surveillez la configuration qui change en silence

Certaines pannes se produisent aux frontières du site. Les redirections bougent, un certificat se renouvelle mal, une mise en ligne supprime un en-tête ou une politique de sécurité s'affaiblit.

Ces détails restent invisibles pendant l'édition ordinaire. Ils appartiennent donc aux contrôles récurrents qui enregistrent l'état attendu et signalent tout changement.

• Validité et expiration du certificat HTTPS.
• Domaine canonique et comportement des redirections.
• En-têtes et politiques de sécurité du navigateur.
• Titres, marqueurs de contenu et types de réponse attendus.
• Évolutions de performance assez fortes pour toucher les visiteurs.
• Formulaires ou intégrations importants qui peuvent être testés sans risque.

Une alerte n'est pas un processus opérationnel

Une boîte pleine d'alertes ne prouve pas qu'un site est géré. Chaque condition surveillée a besoin d'un responsable et d'un circuit de réponse.

La trace indique ce qui a changé, quand, quelles pages sont touchées, si le constat se répète et quelle action est attendue. L'équipe doit savoir quand examiner l'application, contacter l'hébergeur ou demander une décision de contenu ou de politique.

Ce qu'il faut demander dans un rapport

Un décideur n'a pas besoin d'un tableau de requêtes brutes. Un rapport utile sépare les problèmes actuels de ceux qui sont résolus, montre le service touché, conserve les preuves et identifie la prochaine action.

Demandez ce qui est contrôlé, à quelle fréquence, ce qui est volontairement exclu, qui reçoit les alertes et ce qui suit. Si la réponse s'arrête à la notification, l'organisation a acheté la détection sans la réponse.