Pourquoi les sites web tombent plus souvent qu’on ne le croit
Demandez à une équipe de raconter sa dernière panne : il est rarement question d'un incendie de datacenter. Les pannes réelles sont banales : un certificat SSL expiré un samedi, un enregistrement DNS modifié par le mauvais ticket, un déploiement qui passe la CI mais crashe au démarrage, un pool de connexions saturé pendant un pic de trafic, ou un script tiers qui se met à expirer. Les post-mortems le montrent : l'essentiel du downtime est auto-infligé et court — des minutes, pas des heures.
C'est précisément ce qui rend une panne coûteuse : elle survient au pire moment, elle est invisible depuis votre propre réseau, et chaque minute avant la détection est une minute de transactions perdues et de confiance entamée. Le problème n'est presque jamais que personne ne pouvait réparer — c'est que personne ne savait.
Ce que fait réellement la surveillance de panne
La surveillance des pannes (ou monitoring d'uptime) envoie une vraie requête HTTP vers votre site à intervalle fixe — typiquement toutes les 1 à 5 minutes — et évalue la réponse comme le ferait un navigateur : la connexion aboutit-elle, le code de statut est-il sain, combien de temps met la réponse, et la page contient-elle vraiment ce qu'elle devrait ? Quand un check échoue, le moniteur réessaie, confirme l'échec et vous alerte par email ou webhook.
C'est fondamentalement différent d'un simple ping. Le ping vous dit qu'un serveur est allumé ; il ne dit rien du serveur web, de la négociation TLS, de l'application ou de la base de données derrière. Un site peut répondre parfaitement au ping tout en servant une erreur 500 à chaque visiteur. S'il ne faut retenir qu'une chose : surveillez la couche HTTP, pas la couche réseau.
En panne pour tout le monde, ou seulement pour certains ?
Les pannes les plus dommageables ne ressemblent souvent à rien depuis votre bureau. Un nœud CDN défaille sur un continent, un changement DNS se propage inégalement, un incident de routage ralentit une région — et votre site est injoignable à Singapour tout en se chargeant instantanément à Bruxelles. La surveillance depuis un seul point est structurellement aveugle à cette classe de défaillances.
La solution : exécuter le même check depuis plusieurs régions géographiques et comparer. Si toutes les régions échouent, votre origine est en panne. Si une seule région échoue, vous êtes face à un problème CDN, DNS ou de routage — et cette distinction change qui vous appelez. Le multi-région transforme « ça marche chez moi » en fait mesuré.
Au-delà du up/down : certificats, contenu et parcours critiques
Un code 200 ne prouve pas que votre site fonctionne. La page peut s'afficher vide, l'API derrière votre checkout peut renvoyer {"items": []} indéfiniment, et votre certificat SSL peut être à trois jours de transformer chaque visite en avertissement de sécurité. Une surveillance mature superpose donc trois vérifications : le suivi d'expiration des certificats (alerte des semaines avant l'échéance), les assertions de contenu qui vérifient que la réponse contient vraiment ce dont vos utilisateurs ont besoin, et les scénarios multi-étapes qui rejouent de vrais parcours : connexion → panier → paiement.
Chaque couche attrape une classe de panne que la précédente ne voit pas : les pannes franches, le compte à rebours silencieux du certificat, les incidents « up mais cassé », et les défaillances d'intégration entre services individuellement sains.
Des alertes fiables : du signal, pas du bruit
Le moyen le plus rapide de rendre la surveillance inutile est de la laisser crier au loup. Si chaque micro-coupure de 30 secondes réveille l'équipe à 3 h du matin, les alertes seront coupées en un mois — et la vraie panne atterrira dans un canal silencieux. Une bonne alerte a des opinions : exiger plusieurs échecs consécutifs avant de déclarer l'incident, envoyer une notification de rétablissement, et retenir les brefs incidents mono-région dans une fenêtre calme qui n'escalade que si la région reste dégradée.
Configurée ainsi, une alerte redevient significative : quand elle sonne, on bouge. Combinée aux checks multi-région et aux assertions de contenu, vous apprenez l'incident quelques minutes avant le premier ticket support — ce qui est tout l'intérêt de la surveillance de panne.
