Le monitoring de site web recouvre en réalité trois tâches distinctes sous un même nom : le monitoring de disponibilité (le site est-il accessible ?), le monitoring de performance (est-il rapide ?) et la surveillance SSL/expiration (sera-t-il encore considéré comme fiable la semaine prochaine ?). La plupart des équipes ne mettent en place que le premier, puis se font surprendre par une page de paiement qui se charge lentement ou par un certificat expiré qu'aucun de ces contrôles n'aurait détecté. Comprendre la différence, et utiliser les trois, c'est ce qui sépare « on l'a appris par un client » de « on l'a su en premier ».
Qu'est-ce que le monitoring de disponibilité (uptime) ?
Le monitoring de disponibilité répond à une seule question : un utilisateur peut-il accéder à votre site ou à votre API en ce moment même ? Un service de monitoring envoie des requêtes HTTP(S) périodiques (ou un simple ping TCP/ICMP pour les services non web) vers votre endpoint depuis un ou plusieurs emplacements, puis analyse la réponse.
Un contrôle de base vérifie :
- La connectivité : le serveur a-t-il répondu, et ce dans le délai imparti ?
- Le code de statut HTTP : une réponse 2xx est saine ; un 4xx indique généralement un problème côté client ou de routage ; un 5xx signifie que le serveur lui-même est en échec.
- La correspondance de contenu (facultative) : certains contrôles vérifient aussi la présence d'une chaîne ou d'un champ JSON précis dans la réponse, ce qui permet de repérer un serveur qui renvoie 200 OK sur une page d'erreur.
Le piège d'un monitoring limité à la disponibilité, c'est qu'un serveur peut renvoyer 200 OK en moins d'une seconde alors que la page réelle est cassée, à moitié affichée ou sert des données obsolètes. Le code de statut seul ne prouve pas que le site fonctionne ; il prouve seulement que le serveur a répondu.
TipLancez vos contrôles de disponibilité depuis plusieurs régions géographiques si votre audience est internationale. Un contrôle depuis une seule région peut complètement passer à côté d'une panne chez un FAI régional ou sur un nœud de CDN.
Si vous voulez simplement une réponse ponctuelle immédiate, notre outil gratuit pour vérifier si un site est en panne vous indique si un site est accessible depuis l'extérieur, un bon premier contrôle avant de vous plonger dans l'historique du monitoring.
Qu'est-ce que le monitoring de performance ?
Le monitoring de performance mesure le temps que prend réellement une réponse saine, et si ce temps se dégrade. C'est un mode de défaillance différent d'une indisponibilité : le site est en ligne, il renvoie 200, mais il est suffisamment lent pour que les utilisateurs partent.
Indicateurs de performance typiques :
- Temps de réponse / time to first byte (TTFB) : le temps que met le serveur à commencer à renvoyer des données.
- Temps de chargement complet de la page : pertinent pour les contrôles synthétiques en navigateur qui affichent la page, et pas seulement pour la récupération du HTML.
- Tendance dans le temps : une réponse lente isolée peut n'être que du bruit ; une hausse régulière sur plusieurs jours révèle un problème de capacité ou de base de données en formation.
Le monitoring synthétique (des contrôles scriptés qui simulent une action réelle d'utilisateur, comme la connexion ou la finalisation d'un achat) se situe du côté performance du spectre. Il détecte des problèmes qu'un simple ping de disponibilité ne verra jamais, comme un script tiers défaillant qui bloque l'affichage de la page alors que le serveur répond instantanément.
| Type de contrôle | Répond à | Ne détecte pas |
|---|---|---|
| Disponibilité (HTTP/ping) | Le site est-il accessible ? | La lenteur, une interface cassée, un certificat sur le point d'expirer |
| Performance (temps de réponse / synthétique) | Est-il assez rapide ? | Les pannes totales, repérées plus tard qu'avec un ping rapide |
| SSL/expiration | La connexion sera-t-elle toujours fiable ? | Rien concernant la vitesse ou l'accessibilité |
Qu'est-ce que la surveillance de l'expiration des certificats SSL ?
Les certificats SSL/TLS ont une période de validité fixe, et les navigateurs rejettent purement et simplement un site dès que son certificat expire : les visiteurs voient une page d'avertissement bloquante, pas un chargement lent. C'est sans doute la catégorie de panne la plus évitable, puisque la date d'expiration est connue dès l'émission du certificat.
La surveillance SSL vérifie :
- Le nombre de jours restants avant l'expiration, avec des alertes bien avant l'échéance pour que le renouvellement ne se fasse pas dans la précipitation.
- La validité de la chaîne : le certificat est signé par une autorité racine de confiance et la chaîne intermédiaire est correctement servie, et pas seulement l'existence d'un certificat.
- La correspondance du nom d'hôte : le certificat couvre bien le domaine servi, ce qui compte après une migration ou lors du remplacement de certificats wildcard.
Les certificats émis par des systèmes automatisés comme Let's Encrypt sont renouvelés fréquemment et expirent rarement si l'automatisation fonctionne. Mais l'automatisation peut échouer silencieusement, généralement lorsqu'un hook de renouvellement casse après une migration de serveur. Surveiller la date d'expiration indépendamment du système de renouvellement est le seul moyen de détecter cette défaillance avant un client. Nous détaillons les avantages et inconvénients des certificats automatisés et commerciaux dans notre comparatif Let's Encrypt ou certificats SSL commerciaux, et le fonctionnement de la chaîne de confiance dans Les certificats SSL expliqués.
Vous pouvez vérifier ponctuellement n'importe quel certificat en ligne (date d'expiration, émetteur, chaîne) avec notre outil gratuit de vérification SSL.
WarningUn certificat peut être parfaitement valide aujourd'hui et échouer demain si son automatisation de renouvellement est tombée en panne silencieusement il y a plusieurs semaines. Vérifiez les dates d'expiration indépendamment du système qui a émis le certificat.
Comment ces trois contrôles fonctionnent-ils ensemble ?
Pris isolément, chaque contrôle répond à une question précise. Combinés, ils couvrent tout le parcours, de « y a-t-il quelqu'un ? » à « l'expérience est-elle acceptable ? » jusqu'à « le navigateur laissera-t-il seulement entrer le visiteur ? ». Un incident réel en déclenche souvent plusieurs :
- Le pool de connexions à la base de données s'épuise → les temps de réponse grimpent (performance) → puis le serveur finit par ne plus répondre du tout (disponibilité).
- Une modification du TTL DNS se propage de manière inégale → certaines régions voient le nouveau serveur, d'autres reçoivent des réponses obsolètes (disponibilité, selon la région).
- Une tâche cron de renouvellement de certificat échoue après un déménagement de serveur → disponibilité et performance restent au vert jusqu'au jour de l'expiration, où le site devient de fait inaccessible pour quiconque utilise un navigateur moderne (SSL/expiration).
Ce dernier scénario illustre précisément pourquoi s'appuyer uniquement sur des pings de disponibilité donne une fausse impression de sécurité. Le contrôle réussit toutes les cinq minutes pendant des semaines, puis échoue de façon catastrophique à une date fixe qu'il était possible de connaître à l'avance.
Que doit réellement couvrir un dispositif d'alertes ?
Au minimum, un dispositif de monitoring doit combiner :
- Un contrôle de disponibilité/HTTP sur chaque endpoint public, depuis plusieurs régions.
- Une alerte sur seuil de temps de réponse, et pas seulement un état binaire en ligne/hors ligne.
- Une alerte d'expiration SSL avec suffisamment d'avance pour agir : des jours, pas des heures.
- Une page de statut publique ou interne, pour que les parties prenantes reçoivent la même information que votre équipe au lieu de l'apprendre par un ticket de support.
La fonctionnalité de monitoring d'InfraNest exécute les contrôles de disponibilité, de performance et d'expiration SSL depuis un seul tableau de bord, pour tous les fournisseurs que vous utilisez : plus besoin d'assembler trois outils distincts (et trois boîtes de réception d'alertes) pour avoir une vue d'ensemble. Elle alimente aussi directement les pages de statut si vous souhaitez publier ces données de santé.
Configurez ensemble vos contrôles de disponibilité, de performance et d'expiration SSL avec le monitoring InfraNest : un seul tableau de bord, tous vos fournisseurs, et plus aucune panne surprise liée à un certificat.
Questions fréquentes
#Le monitoring de disponibilité suffit-il à lui seul ?
Non. Le monitoring de disponibilité confirme seulement qu'un serveur répond, pas que les pages se chargent rapidement ni que le certificat SSL est toujours valide. Un site peut renvoyer un code de statut sain tout en étant lent ou, dans le cas d'un certificat expiré, inaccessible dans un navigateur alors que le serveur répond parfaitement.
#Combien de temps à l'avance faut-il être alerté de l'expiration d'un certificat SSL ?
Réglez l'alerte avec suffisamment d'avance pour pouvoir réellement corriger un processus de renouvellement défaillant, et pas seulement pour constater le problème : de plusieurs jours à deux semaines environ est courant, car l'automatisation du renouvellement peut échouer silencieusement bien avant la date d'expiration effective.
#Quelle est la différence entre un contrôle par ping et un contrôle de monitoring synthétique ?
Un ping ou un contrôle HTTP de base confirme qu'un serveur répond, généralement en moins d'une seconde. Un contrôle synthétique simule un parcours utilisateur réel, comme la connexion ou le paiement, dans un navigateur, et détecte les problèmes front-end et de scripts tiers qu'un simple ping ne voit jamais.
#Un monitoring depuis un seul emplacement suffit-il pour connaître la disponibilité mondiale ?
Pas de manière fiable. Des problèmes chez un FAI régional, des pannes de nœuds de CDN ou des délais de propagation DNS peuvent rendre un site inaccessible depuis une partie du monde alors qu'un contrôle depuis une seule région le signale toujours comme opérationnel.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
