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, il déclare le site disponible.
Ce contrôle peut rester au vert alors que votre formulaire de contact échoue, qu'une redirection envoie les gens au mauvais endroit, qu'un certificat est sur le point d'expirer, qu'une politique de sécurité du navigateur disparaît ou qu'une page importante est remplacée par un contenu inattendu. Le serveur a répondu. Cela ne veut pas dire que le site a rempli son rôle.
Mesurer la disponibilité est utile. Ce n'est que la première question.
Vérifiez les pages dont les gens dépendent
Commencez par les quelques actions pour lesquelles le public vient sur votre site. Pour une association professionnelle, ce peut être les inscriptions, l'accès aux documents et le formulaire de contact. Pour un organisme public, les avis de réunion et les instructions pour les services. Pour une organisation militante, une page d'action qui doit recevoir des réponses avant une échéance.
Inutile de tester chaque parcours sur le site. Couvrez les quelques pages et fonctions dont la panne nuirait immédiatement à votre activité.
Surveillez la configuration qui change en silence
Certaines pannes se produisent dans la configuration du site plutôt que sur une page. Les règles de redirection bougent. Un certificat se renouvelle mal. Une mise en ligne supprime un en-tête de sécurité. Une politique de sécurité du contenu s'affaiblit, ou se met à bloquer un service dont le site a besoin.
Rien de tout cela ne se voit quand on modifie des pages : c'est pourquoi ces points relèvent de contrôles récurrents. Une surveillance utile enregistre l'état attendu de chaque réglage et vous prévient quand il change.
- 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.
Chaque alerte a besoin d'un responsable
Une boîte pleine d'alertes ne veut pas dire que le site est géré. Chaque élément surveillé a besoin d'un responsable et d'un plan pour la suite.
La trace doit indiquer ce qui a changé, quand cela a été constaté pour la première fois, quelles pages sont touchées, si cela s'est reproduit et ce qui doit se passer ensuite. Votre équipe web doit savoir quand examiner l'application, quand appeler l'hébergeur et quand l'organisation doit prendre une décision de contenu ou de politique.
Ce qu'il faut demander dans un rapport
Vous n'avez 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é, joint les preuves et indique la prochaine étape.
Demandez ce que le système contrôle, à quelle fréquence, ce qu'il laisse volontairement de côté, qui reçoit les alertes et ce qui se passe quand l'une d'elles arrive. Si la réponse s'arrête à l'envoi d'une notification, vous avez acheté la détection sans la réponse.
Leland Fiegel