Supervision d’un site web : quelles alertes mettre en place ?

Superviser un site, c’est être prévenu avant vos clients qu’un élément ne fonctionne plus. Une supervision utile combine quatre choses : un test externe de disponibilité, la vérification des parcours qui rapportent de l’activité (contact, commande, connexion), le suivi des erreurs et de la charge côté serveur, et des alertes envoyées à une personne identifiée qui sait quoi faire. Plus d’alertes ne signifie pas une meilleure surveillance : une alerte sans action possible finit ignorée.

Ce guide s’adresse aux dirigeants et responsables de PME qui doivent fixer le périmètre avec un prestataire. Il ne promet pas de détection de tous les incidents ni de délai d’intervention, qui relèvent du contrat. Notre page DevOps et hébergement présente l’accompagnement que nous proposons sur ce sujet.

Que faut-il surveiller en priorité ?

Partez de ce qui compte pour l’activité, pas de ce que l’outil sait mesurer. Pour un site de PME, quatre familles couvrent l’essentiel :

• La disponibilité : le site répond-il, avec un code de réponse normal ?
• Les parcours clés : le formulaire de contact arrive-t-il, la commande s’enregistre-t-elle, la connexion fonctionne-t-elle ?
• Les erreurs et la performance : taux d’erreurs, lenteur anormale, pages qui plantent.
• Les échéances : renouvellement du nom de domaine, expiration du certificat HTTPS, fin d’abonnement d’un service tiers.

Une page d’accueil qui s’affiche ne prouve pas que le reste fonctionne. Notre checklist de maintenance insiste sur ce point : un contrôle de disponibilité ne remplace pas un envoi complet de formulaire.

Quels signaux suivre pour un service en ligne ?

Le livre sur l’ingénierie de la fiabilité publié par Google (SRE) propose quatre « signaux d’or » pour un service exposé aux utilisateurs (Monitoring Distributed Systems) :

• La latence : le temps de réponse. Le livre précise qu’il faut suivre séparément les requêtes réussies et en échec, car une erreur lente est pire qu’une erreur rapide.
• Le trafic : la demande subie par le système, par exemple le nombre de requêtes par seconde.
• Les erreurs : la part de requêtes qui échouent, explicitement (erreur 500) ou implicitement (page affichée mais contenu faux).
• La saturation : à quel point la ressource la plus contrainte est utilisée. Le texte note que beaucoup de systèmes se dégradent avant d’atteindre 100 % d’utilisation, d’où l’intérêt d’un seuil cible.

Ces notions viennent de grands systèmes distribués, mais le raisonnement s’adapte à un petit site : on regarde si les visiteurs obtiennent une réponse, si elle est rapide, si elle est correcte, et si l’hébergement approche de ses limites.

Quelle différence entre surveillance externe et interne ?

La même source distingue deux approches complémentaires. La surveillance dite « boîte noire » teste le comportement visible de l’extérieur, comme un visiteur : charger une page, soumettre un formulaire de test, vérifier un texte attendu. Elle détecte ce qui se passe maintenant. La surveillance « boîte blanche » s’appuie sur les métriques et journaux internes : erreurs applicatives, usage de la mémoire, remplissage du disque, files d’attente. Elle peut révéler un problème imminent ou masqué par des relances automatiques.

Pour une PME, une base raisonnable est un test externe depuis plusieurs lieux sur les pages critiques, complété par le suivi des erreurs applicatives et des ressources de l’hébergement. Le niveau d’outillage dépend de l’enjeu : un site vitrine n’a pas les besoins d’une application métier.

Quelles alertes sont réellement utiles ?

Une alerte doit déclencher une action, et la même source rappelle que chaque alerte envoyée à un humain doit être actionnable. Voici des alertes courantes, à adapter :

Choisissez une alerte pour un risque que vous savez traiter. Évitez les alertes pour chaque fluctuation : elles créent de la fatigue et font manquer les vraies urgences.

À qui envoyer les alertes et comment les organiser ?

Définissez pour chaque alerte un destinataire principal et un remplaçant, avec un canal fiable (courriel surveillé, messagerie d’équipe, SMS pour les urgences). Une alerte envoyée à une boîte que personne ne lit n’existe pas.

Prévoyez une fiche d’incident courte : qui prévenir, quoi vérifier d’abord, comment contacter l’hébergeur, comment décider d’un retour arrière, et qui informe les clients. Précisez les horaires de prise en charge réels : une alerte envoyée à 3 h du matin ne sert que si quelqu’un est prévu pour la traiter, ce qui doit être écrit au contrat plutôt que supposé.

Enfin, regardez la supervision comme un maillon de la chaîne de mise en ligne : après chaque déploiement, l’observation des erreurs permet de décider vite d’un retour arrière, comme expliqué dans notre guide sur le DevOps pour une PME.

Comment mettre en place une supervision minimale en six étapes ?

1. Listez les parcours critiques et les pages qui doivent répondre.
2. Choisissez les contrôles externes : disponibilité, présence d’un texte attendu, certificat.
3. Ajoutez le suivi des erreurs côté application et côté serveur.
4. Déclarez les échéances de domaine, certificat et abonnements.
5. Définissez les destinataires et la procédure en cas d’alerte, puis testez-la en déclenchant une alerte volontairement.
6. Relisez les alertes chaque mois : supprimez celles qui sont inutiles, ajoutez celles qui auraient évité un incident.

La supervision ne remplace pas la sécurité. Elle aide à voir un comportement anormal, mais n’empêche pas une compromission : voir notre article sur le DevSecOps. Ne mettez pas de données personnelles dans les journaux sans nécessité, et limitez les accès aux outils de supervision.

Exemple fictif : un site avec formulaire de devis

Cet exemple est fictif et ne décrit ni un client ni un résultat mesuré.

Un artisan a un site dont la page d’accueil s’affiche normalement, mais dont le formulaire de devis n’envoie plus de courriel depuis un changement de messagerie. Aucune alerte n’existait sur ce parcours. Il ajoute un test périodique qui soumet une demande identifiable comme test, un contrôle du certificat et un rappel pour le domaine. Les alertes vont à deux personnes, avec une procédure d’une page. Dans cet exemple, la supervision ne rend pas la panne impossible : elle réduit le temps pendant lequel elle passe inaperçue.

FAQ

Un outil gratuit de test de disponibilité suffit-il ?

Il peut suffire pour un site vitrine simple, si vous surveillez aussi le formulaire et les échéances. Vérifiez la fréquence des contrôles, les lieux de test et les canaux d’alerte proposés.

La supervision garantit-elle une disponibilité de 100 % ?

Non. Elle détecte et signale, elle ne supprime pas les pannes. Les objectifs de disponibilité et les délais d’intervention doivent être définis et écrits séparément.

Qui doit recevoir les alertes dans une petite entreprise ?

Une personne qui peut agir, et un suppléant. Si le prestataire est chargé de la supervision, convenez des horaires et des moyens de vous joindre.

Conclusion

Une bonne supervision tient en peu d’éléments : un test externe, quelques parcours vérifiés, des erreurs suivies, des échéances connues et des alertes qui aboutissent à quelqu’un. Commencez petit, testez vos alertes et améliorez-les après chaque incident. Pour cadrer cela avec votre site ou votre application, consultez notre page DevOps et hébergement ou contactez-nous.