Supervision de site web : savoir avant vos clients
La supervision de disponibilité répond à une question : la page d'accueil répond-elle ? La plupart des vraies pannes sont plus discrètes. Le site est debout et le formulaire de contact échoue depuis trois semaines, ou le tunnel de commande fonctionne pour tout le monde sauf pour les clients utilisant un moyen de paiement.
Ce guide couvre quoi superviser, comment fixer des seuils qui veulent dire quelque chose, et comment garder des alertes crédibles.
Au-delà du « est-il debout »#
Les pannes qui coûtent de l'argent sont généralement partielles. Supervisez les résultats qui vous importent, pas seulement la réponse du serveur.
| Supervision | Détecte | Fréquence |
|---|---|---|
| Disponibilité HTTP | Serveur en panne, échec DNS | Toutes les 1–5 minutes |
| Vérification de transaction | Formulaire cassé, tunnel de commande cassé | Toutes les 15–60 minutes |
| Taux d'erreur | Exceptions en hausse après un déploiement | En continu |
| Expiration de certificat | La panne classique du dimanche matin | Quotidienne, alerte 30 jours avant |
| Expiration de domaine | La pire panne possible | Quotidienne, alerte 60 jours avant |
| Core Web Vitals | Dégradation lente que personne ne remarque | Hebdomadaire |
| Couverture Search Console | Des pages qui sortent de l'index | Hebdomadaire |
| Taille du disque et de la base | Croissance silencieuse vers une limite dure | Quotidienne |
| Succès des sauvegardes | Des sauvegardes arrêtées depuis des mois | Quotidienne |
Une transaction synthétique qui envoie un vrai formulaire vers une adresse de test est la supervision la plus rentable pour la plupart des sites d'entreprise. Les formulaires cassés sont invisibles et coûteux.
Fixer des seuils qui veulent dire quelque chose#
Une supervision qui alerte au moindre soubresaut apprend aux gens à l'ignorer, et alors elle ne fonctionne plus quand cela compte. Les seuils devraient refléter ce qui vous ferait réellement agir.
- Exigez deux ou trois échecs consécutifs avant d'alerter, depuis plus d'un emplacement.
- Alertez sur le taux d'erreur plutôt que sur des erreurs individuelles : une seule 500 est du bruit, un changement de taux est un signal.
- Fixez les alertes de performance sur une tendance sur plusieurs jours, pas sur une mesure lente isolée.
- Séparez les gravités : site en panne vers un téléphone ; une page lente vers un résumé hebdomadaire.
- Adressez les alertes à une personne, pas à une boîte partagée dont personne n'est responsable.
- Passez en revue chaque alerte déclenchée : si elle n'a demandé aucune action, changez le seuil ou supprimez la supervision.
Quoi faire quand une alerte se déclenche#
Avoir un ordre des opérations écrit transforme un incident d'improvisation en procédure, ce qui compte surtout quand la personne d'astreinte n'est pas celle qui a construit le site.
- Confirmez que c'est réel : chargez le site vous-même depuis un autre réseau.
- Vérifiez d'abord l'évident : y a-t-il eu un déploiement, un certificat a-t-il expiré, l'hébergeur signale-t-il un incident ?
- Publiez un message de statut si des clients sont touchés. Le silence est pire qu'une mauvaise nouvelle.
- Rétablissez le service avant de diagnostiquer. Revenez en arrière sur le déploiement, puis enquêtez tranquillement.
- Notez ce qui s'est passé, pourquoi, et ce qui l'aurait détecté plus tôt.
- Ajoutez la supervision qui l'aurait détecté. C'est ainsi que la liste ci-dessus s'enrichit correctement.
Le résultat le plus utile d'un incident, c'est une nouvelle supervision et une façon de moins pour que cela se reproduise en silence.
Des réglages par défaut sensés pour un petit site#
Vous n'avez pas besoin d'une plateforme d'observabilité. Pour la plupart des sites d'entreprise, cet ensemble suffit et se configure en une après-midi.
- Une vérification de disponibilité sur l'accueil et sur une page profonde, toutes les cinq minutes, depuis deux emplacements.
- Un envoi synthétique de formulaire quotidien, vers une adresse lue par un humain.
- Des alertes d'expiration de certificat et de domaine, bien à l'avance.
- Une alerte sur les erreurs serveur depuis l'application, avec un seuil de taux.
- Un e-mail hebdomadaire avec les Core Web Vitals et la couverture Search Console.
- Une confirmation quotidienne que la sauvegarde a tourné et que sa taille paraît normale.
Questions fréquentes
À quelle fréquence vérifier la disponibilité ?
Toutes les une à cinq minutes est la norme, depuis au moins deux emplacements géographiques pour qu'un problème réseau sur un nœud de supervision ne vous réveille pas à 3 h du matin. Des vérifications plus fréquentes changent rarement l'issue, car le temps de détection est faible comparé au temps de correction.
Quelle disponibilité attendre ?
Un hébergement mutualisé correct délivre environ 99,9 %, soit à peu près neuf heures d'indisponibilité par an. Les plateformes infogérées et les bonnes configurations cloud atteignent 99,95 % ou mieux. Ce qui compte plus que le chiffre, c'est de savoir si l'indisponibilité est faite de minutes éparses ou d'une longue panne unique en heures ouvrées.
Les outils de supervision gratuits suffisent-ils ?
Pour la disponibilité d'un petit site, en général oui : les offres gratuites couvrent une poignée de vérifications à intervalle de cinq minutes. Ce qui manque généralement aux offres gratuites, ce sont les transactions synthétiques et les vérifications multi-étapes, c'est-à-dire précisément là où se trouve la supervision utile. Prévoyez un petit budget spécifiquement pour cela.
Comment éviter la fatigue d'alerte ?
Supprimez les supervisions qui n'ont jamais demandé d'action, exigez plusieurs échecs consécutifs avant d'alerter, et séparez l'urgent de l'informatif. Puis passez en revue les alertes déclenchées chaque mois. Un canal d'alertes que les gens mettent en sourdine est pire que pas d'alertes du tout, car il crée la croyance que quelqu'un surveille.
supervision site websupervision de disponibilitésupervision synthétiquesuivi des erreursgestion d'incidentalertes site web
