Meilleures pratiques de surveillance de sites Web réellement utilisées par les ingénieurs

La plupart des équipes disposent de la surveillance de site web. Beaucoup moins ont une surveillance qui détecte réellement les problèmes avant les clients, les ventes et le support. L’écart ne vient que rarement de l’outil. Il réside dans les pratiques qui l’entourent : ce qui est contrôlé, d’où, à quelle fréquence, ce qui déclenche une alerte, et qui décide quand une vérification est défaillante par rapport à quand le site est défaillant.

Ce playbook rassemble huit meilleures pratiques de surveillance de site web qui distinguent les configurations approuvées par les équipes SRE et DevOps de celles qui se transforment silencieusement en bruit. Chacune est concrète : seuils, intervalles, antipatterns, et ce qu’il faut continuer à faire une fois que ça fonctionne. Les mêmes pratiques s’appliquent que vous surveilliez la disponibilité d’un site marketing ou que vous effectuiez une surveillance synthétique complète des transactions sur un SaaS.

À quoi ressemble une « Bonne » surveillance (et pourquoi la plupart des configurations la manquent)

Une définition opérationnelle : votre surveillance est bonne si votre équipe apprend chaque problème visible par le client via un moniteur avant que vos clients ne le remarquent, et si les alertes que vous recevez sont presque toujours exploitables. Voilà tout le critère.

Trois chiffres permettent de suivre cette performance. Le temps moyen de détection (MTTD) indique si la surveillance est assez rapide. Le temps moyen de résolution (MTTR) indique si les données fournies par le moniteur suffisent pour résoudre le problème. La précision des alertes – le pourcentage d’alertes qui étaient réelles et nécessitaient une action immédiate – indique si votre équipe fera encore confiance aux alertes dans six mois. La plupart des équipes SRE mesurent le MTTD et le MTTR. La plupart des équipes ne mesurent pas la précision. C’est pourquoi de nombreuses rotations de garde se dégradent en reconnaissances silencieuses et en impuissance acquise.

Le reste de ce playbook vise à faire avancer ces deux chiffres dans la bonne direction simultanément.

Superposez les vérifications sur l’intégralité du chemin de la requête

Un seul contrôle HTTPS est un détecteur de fumée avec un seul capteur. Il vous dit qu’il y a un problème, mais pas où. Quand un utilisateur tape votre URL et attend le rendu de la page, la requête traverse au moins six couches : résolution DNS, handshake TCP, négociation TLS, réponse HTTP, chargement des ressources, et rendu côté client de la vue finale. Chaque couche échoue différemment et chaque échec vient d’une cause racine distincte.

La configuration pratique ressemble à ceci :

• DNS : Vérifiez que les enregistrements A, AAAA, CNAME et MX se résolvent aux valeurs attendues depuis plusieurs résolveurs. Les problèmes DNS sont les plus faciles à manquer et les plus difficiles à déboguer après coup. Les meilleurs outils de surveillance DNS surveillent les modifications non autorisées, les délais de propagation et les échecs spécifiques aux résolveurs.
• TCP et ICMP : Confirmez que le port est ouvert et que le chemin réseau est sain. Un changement de pare-feu qui bloque le port 443 ne sera pas détecté par une vérification HTTP depuis le même segment réseau.
• TLS : Validez la chaîne de certificats, la date d’expiration, la correspondance du nom d’hôte et le support des chiffrement. La plupart des pannes de certificat sont évitables – le certificat vient juste d’expirer un dimanche. Obtenez des alertes explicites à 60, 30, 14 et 3 jours. Voir comment surveiller l’expiration des certificats SSL pour les détails de configuration.
• HTTP : Code d’état, temps de réponse, et assertion de contenu. Un statut 200 avec un corps vide est une vérification échouée, pas réussie.
• Rendu et transaction : Faites passer un vrai navigateur par le parcours utilisateur, vérifiez un élément connu dans l’état final, et mesurez le temps jusqu’à l’interaction. La surveillance synthétique avec de vrais navigateurs détecte ce que le contrôle des protocoles ne peut pas — JavaScript cassé, scripts tiers qui bloquent, un fichier CSS manquant qui rend le bouton panier invisible.
• API : Traitez les API comme des points de terminaison de première classe. Un site qui charge mais ne peut pas finaliser un achat parce que l’API de paiement est en timeout est toujours en panne. La surveillance d’API mérite son propre calendrier de vérifications, séparé des pages qui en dépendent.

Quand quelque chose casse, la couche qui alerte en premier est votre point de départ pour la cause racine. Une équipe qui surveille uniquement HTTP n’obtient qu’une seule information : indisponible. Une équipe qui surveille les six couches obtient un arbre des défaillances.

Faites fonctionner la surveillance synthétique et RUM côte à côte, pas l’un à la place de l’autre

Les deux méthodes répondent à des questions différentes et ne sont pas substituables. Le tableau ci-dessous résume la répartition choisie par la plupart des équipes après une période de test de trois mois.

La surveillance synthétique exécute des contrôles scriptés sur un horaire fixe depuis des emplacements fixes. Les données sont cohérentes dans le temps et immunes aux baisses de trafic. Elle fonctionne également à 3 heures du matin quand aucun utilisateur réel n’est présent pour remarquer un déploiement qui a cassé la page de connexion. C’est pourquoi la surveillance synthétique est l’outil adapté pour les rapports SLA, la détection des régressions et les alertes proactives.

La RUM (Real User Monitoring) capture les données de performance et d’erreur depuis les navigateurs réels. Elle reflète la vraie distribution des appareils, réseaux et géographies de vos utilisateurs. C’est la seule source qui peut vous dire qu’une tranche de 2 % des utilisateurs Android sous un opérateur spécifique voit un temps de premier octet de 9 secondes. La RUM est l’outil adéquat pour comprendre l’expérience réelle et prioriser le travail d’ingénierie.

Utilisez la synthétique pour savoir que le site est en ligne et fonctionne normalement. Utilisez la RUM pour savoir comment ce comportement affecte les utilisateurs qui vous paient. Les équipes qui choisissent l’un et ignorent l’autre se retrouvent soit surprises par des cas limites (synthétique uniquement), soit apprennent les pannes via Twitter (RUM uniquement).

Surveillez depuis les géographies qui génèrent du revenu

Un contrôle depuis votre centre de données voisin vous dit si ce centre est en ligne. Il ne vous dit pas si un utilisateur à São Paulo passe une bonne journée.

La règle est simple : placez des points de contrôle dans chaque région qui contribue de façon significative au chiffre d’affaires, plus une ou deux régions qui servent de contrôle. Si 35 % de vos ventes viennent d’EMEA, vous avez besoin d’au moins deux points de contrôle dans cette région – un dans un marché principal comme Francfort ou Londres, un autre dans un marché secondaire comme Madrid ou Stockholm. Une couverture EMEA avec un seul point de contrôle masque les pannes des FAI régionaux et les défaillances des CDN.

Trois schémas à mettre en place :

1. Confirmation multi-géo pour les alertes. Exigez qu’un échec se répète dans au moins deux régions distinctes dans les 60 secondes avant de déclencher une alerte. Une région qui échoue isolément est généralement un problème local d’opérateur ou un problème du point de contrôle, pas une panne du site.
2. Seuils régionaux. Tokyo et Iowa ne chargent pas votre site à la même vitesse et ils ne devraient pas partager un même seuil. Suivez la latence au 95e centile par région et alertez sur les écarts régionaux, pas sur la moyenne globale.
3. Agents privés dans les réseaux d’entreprise. Si vous vendez à des entreprises qui accèdent à votre app depuis derrière leur propre pare-feu, faites tourner un point de contrôle dans cet environnement. Les agents privés détectent les problèmes causés par le réseau du client, pas le vôtre, ce qui reste pourtant évident pour le client.

Le réseau de points de contrôle Dotcom-Monitor couvre plus de 30 pays ; la liste exacte à activer dépend de là où votre argent vient, pas de là où se trouve votre centre de données.

Définissez les seuils à partir des bases de référence, pas à partir de chiffres ronds

Le péché le plus courant en surveillance est « alerter si le temps de réponse > 3 secondes ». Trois secondes est un chiffre rond. Votre site ne se soucie pas des chiffres ronds. Si votre p95 réel est 4,2 secondes et stable, vous serez alerté 24 fois par jour pour un comportement normal. Si votre p95 réel est 0,8 seconde et se dégrade à 2,5 secondes, vous n’aurez aucune alerte car 2,5 est toujours inférieur à 3.

La solution est un seuil relatif à la base de référence :

Alertez lorsqu’un p95 soutenu sur une fenêtre de 10 minutes dépasse (p95 de base × 1,5) ou (p95 de base + 2σ), selon la plus grande valeur, et que la condition persiste sur deux fenêtres d’évaluation consécutives.

Cette formule fait trois choses en même temps. Le facteur 1,5× s’adapte à la page pour qu’une page rapide et une page lente puissent partager la même règle. Le terme 2σ supprime la volatilité normale. La règle de « deux fenêtres consécutives » élimine les faux positifs dus aux pics ponctuels.

Le calcul de la base de référence est la partie que la plupart des équipes sautent. Recalculez la base de référence chaque semaine à partir des 14 jours précédents, en excluant les fenêtres de déploiement et les périodes d’incident connues. Les produits de détection d’anomalie qui calculent automatiquement les bases de référence sont une bonne solution de facilité si vous ne voulez pas gérer cela manuellement, mais vérifiez ce qu’ils excluent. Une base de référence contaminée par un incident récent est pire qu’aucune base du tout.

Pour les contrôles de disponibilité, la règle équivalente : exigez deux échecs consécutifs de deux géographies distinctes avant de déclencher une alerte. Un échec unique depuis un seul endroit est presque toujours un problème de point de contrôle. Deux échecs de deux sources sont réels.

Concevez l’alerte, pas seulement la vérification

Une vérification vous dit qu’un événement s’est produit. Une alerte dit à un humain de faire quelque chose. Ce sont des problèmes différents et la plupart des équipes conçoivent uniquement le premier.

Le travail de l’ingénierie des alertes est d’envoyer la bonne information à la bonne personne dans un format qui lui permet d’agir en moins de 60 secondes. Les obstacles sont souvent :

• Trop d’alertes. Si l’ingénieur de garde moyen est appelé plus de trois fois par service, la prochaine alerte sera traitée avec moins d’attention. Ce n’est pas un défaut moral. C’est la nature de l’attention humaine.
• Alertes sans contexte. « Paiement lent » n’est pas exploitable. « Paiement p95 4,8s (base 1,1s) depuis régions EU, commencé à 14:32 UTC, corrélé avec déploiement abc123 à 14:30 » est exploitable.
• Mauvais canal. Slack n’est pas une alerte de garde. Email non plus. SMS, push ou appel téléphonique sont des alertes. Les mélanger dilue le signal.

Le schéma qui fonctionne :

1. Trois niveaux de gravité, trois canaux. Critique (site inaccessible, paiement cassé) → SMS ou téléphone. Avertissement (dégradation soutenue) → push ou chat avec mention du garde. Info (échec unique, dérive de base) → tableau de bord ou résumé quotidien. Ne jamais alerter sur info.
2. Suppression des dépendances. Si DNS échoue, ne déclenchez pas aussi l’alerte sur les 14 contrôles HTTP en aval qui dépendent du DNS. Le regroupement d’alertes et la suppression des dépendances sont indispensables ; si votre plateforme ne les supporte pas, vous payez en sommeil.
3. Réseau d’escalade, pas chaîne. Si le premier ingénieur de garde ne répond pas en 5 minutes, alertez le second et notifiez le canal. L’escalade en série vous coûte 5 minutes par niveau alors que le site est en panne.
4. Heures calmes pour non critique. Les régressions la nuit vers 2h du matin le dimanche ne nécessitent généralement pas un réveil à 2h. Les cas critiques oui. Soyez honnête en configurant les règles.

Et mesurez la précision. Chaque mois, comptez les alertes déclenchées et étiquetez-les : incident réel, faux positif, action non requise. Si la précision est en dessous de 80 %, corrigez les alertes les plus bruyantes avant d’en ajouter de nouvelles.

Couvrez les éléments que vous ne contrôlez pas

Votre site n’est pas seulement votre code. Une page de paiement moderne charge des scripts d’un processeur de paiement, d’un gestionnaire de balises, d’un fournisseur d’analytique, d’un widget chat, d’un outil de test A/B, d’un CDN, et parfois d’un service de détection de fraude. Chacun peut faire tomber la page.

Les dépendances tierces doivent avoir leurs propres moniteurs :

• Temps de réponse CDN par région. Les CDN échouent, surtout pendant les événements régionaux.
• Temps aller-retour du paiement en contrôle API synthétique contre le point de statut du gateway ou sandbox.
• Temps de chargement des balises analytics et gestionnaire de tags mesuré dans la transaction synthétique. Une balise analytique bloquante ajoute 2 secondes à chaque page ; vous devez le savoir.
• Fournisseurs d’authentification externes (OAuth, SSO). Si votre bouton « se connecter avec Google » cesse de fonctionner, vous devez le savoir avant votre support.
• Fournisseurs DNS. Faites de la surveillance DNS depuis plusieurs résolveurs pour détecter les retards de propagation et les pannes partielles chez le fournisseur.

Documentez quels tiers bloquent quels parcours utilisateurs. Lorsqu’un tiers échoue, le runbook doit indiquer si la bonne action est une « solution de secours », « patienter », ou « contacter le garde du fournisseur ». Sans cette carte, chaque incident tiers devient un exercice d’improvisation.

Assurez que chaque moniteur est lié à un runbook

Les cinq minutes les plus coûteuses de tout incident sont celles où l’ingénieur de garde cherche à comprendre ce que l’alerte signifie.

Réglez cela une fois pour toutes : chaque moniteur doit être associé à une fiche runbook. Le runbook n’a pas besoin d’être élaboré. Trois sections suffisent :

1. Ce que cette vérification couvre en une phrase. (« Valide que la transaction de paiement EU se complète en moins de 5 secondes depuis Francfort et Amsterdam.»)
2. Les cinq premières choses à vérifier lors du déclenchement. Liens vers page de statut, tableaux de bord, déploiements récents, alertes associées, page de statut du fournisseur.
3. Schémas connus de faux positifs, s’il y en a. (« Le point de contrôle de Francfort expire parfois durant la maintenance du fournisseur, samedis 02:00-02:30 UTC. Supprimée. »)

La première rédaction d’un runbook prend 15 minutes. Chaque incident suivant sur ce moniteur en prend 15 de moins. Le calcul est évident et pourtant la plupart des équipes ne le font toujours pas.

Validez les moniteurs et auditez la couverture chaque trimestre

Un moniteur non testé est un souhait, pas une garantie. Deux pratiques permettent d’identifier les lacunes.

Faites un test chaos des alertes. Une fois par trimestre, cassez délibérément une vérification – arrêtez un endpoint test, faites expirer un certificat dans un environnement de staging, abaissez le seuil de temps de réponse à 0 – et confirmez que l’alerte se déclenche, s’escalade, et arrive à la bonne personne. Environ un tiers des alertes échouent leur premier test. Causes courantes : rotations de garde périmées, tokens d’intégration expirés, canaux Slack que personne ne lit plus.

Auditez la carte de couverture trimestriellement. Maintenez un document unique listant chaque parcours utilisateur, chaque dépendance externe et chaque catégorie d’URL. Pour chaque ligne, listez les moniteurs qui la couvrent. Les lignes vides sont des lacunes. Les nouvelles fonctionnalités ajoutées au cours du trimestre se trouvent généralement dans les lignes vides.

L’audit produit aussi le constat inverse : des moniteurs sur des URL qui n’existent plus. Supprimez-les. Un moniteur sur un endpoint 410 génère du bruit pour toujours et ne protège rien.

Ce qu’il faut rechercher dans une plateforme de surveillance

La plupart des plateformes peuvent pinguer une URL. Les différences apparaissent dans les cas complexes. Lors de l’évaluation des outils, ne vous limitez pas aux démos de tableau de bord et demandez-vous :

• Peut-elle automatiser une transaction en vrai navigateur avec logique conditionnelle ? Les enregistrements statiques cassent lorsque la page change pour la première fois. La surveillance transactionnelle scriptable (type Selenium ou propriétaire) supporte l’évolution normale du produit.
• Combien de protocoles natifs sont pris en charge ? HTTP, HTTPS, DNS, FTP, SMTP, IMAP, POP3, TCP, UDP, ICMP. Chaque protocole externalisé à un outil distinct est une relation fournisseur et un identifiant de connexion supplémentaire.
• À quoi ressemble vraiment la couverture mondiale de points de contrôle ? Un fournisseur avec 200 « points de contrôle » tous hébergés dans trois régions cloud n’est pas mondial. Demandez la liste des villes.
• Peut-elle fonctionner depuis votre réseau interne ? Les agents privés sont nécessaires pour surveiller les environnements de staging, les applications internes et les déploiements privés clients.
• Comment gère-t-elle les dépendances d’alertes et leur regroupement ? Une plateforme qui génère 14 alertes pour une seule panne DNS vous rendra insomniaque.
• À quoi ressemble l’export des données ? Si vous ne pouvez pas extraire les résultats bruts dans votre propre système analytique, vous ne pourrez pas enquêter sur les incidents complexes.
• Intégrations avec vos outils de gestion d’incidents. PagerDuty, Opsgenie, Slack, Microsoft Teams, ServiceNow, Jira. Les intégrations natives sont supérieures aux solutions par webhook.

Pour une checklist d’achat plus approfondie avec des grilles d’évaluation, consultez comment choisir le meilleur outil de surveillance de site et les concurrents et alternatives à Datadog pour comprendre où se situe chaque acteur.

Modes d’échecs courants

Les schémas ci-dessous apparaissent dans presque toutes les revues de surveillance. Aucun ne nécessite de nouveaux outils pour être corrigé.

• Un seuil global pour un site multi-régions. La région rapide devient plus lente, la région lente se dégrade, la moyenne globale semble correcte, et l’alerte ne se déclenche jamais.
• Contrôles avec statut 200 sans assertion de contenu. Un 200 vide venant d’une page d’erreur CDN passe le contrôle et entre en production.
• Transactions synthétiques dépendant d’un compte client réel. Mot de passe expiré, MFA activé, compte verrouillé. Utilisez un compte service avec un périmètre de surveillance explicite.
• Alertes de certificat uniquement à 7 jours. Sept jours est la date limite, pas l’alerte. À ce moment, quelqu’un est déjà en train d’éteindre le feu. Alertez à 60, 30, 14 et 3 jours. La configuration de la surveillance des certificats SSL doit être prête en avance.
• Aucune corrélation avec les déploiements. Si vos alertes ne montrent pas « cette alerte s’est déclenchée 3 minutes après le déploiement abc123 », chaque incident commence par une revue manuelle de git log. Connectez votre CI à vos annotations de surveillance.
• Seuils d’alerte qui ne sont jamais resserrés. Si vous avez mis « > 5 secondes » il y a deux ans et que le site est maintenant deux fois plus rapide, ce seuil est fonctionnellement désactivé.
• Surveillance de la page d’accueil mais pas du parcours de conversion. La disponibilité de la page d’accueil est un indicateur de vanité. La disponibilité du paiement, de l’inscription et de la connexion est ce qui compte.

Pour des détails spécifiques à la couche applicative – notamment autour des API, des parcours scriptés et des topologies de microservices – associez ceci avec les meilleures pratiques de surveillance des applications web. Et pour tout ce qui concerne le SEO et l’importance des budgets de latence, consultez comment la vitesse du site affecte le SEO.

Mettez ce playbook en pratique

Choisissez trois pratiques dans cette liste que votre configuration actuelle ne gère pas. Mettez-les en œuvre lors de ce sprint. Faites le test chaos sur les nouveaux moniteurs avant de les considérer terminés. Puis auditez la précision dans 30 jours.

Si la plateforme est le goulot d’étranglement, Dotcom-Monitor couvre toute la chaîne en un seul endroit : surveillance synthétique en vrai navigateur, contrôles multi-protocoles, réseau mondial de points de contrôle avec agents privés, et fonctionnalités d’ingénierie d’alerte conçues pour les schémas ci-dessus. Voir la surveillance applicative web, la surveillance API, la surveillance DNS, et la surveillance des certificats SSL, ou passez directement à la vue d’ensemble de la surveillance entreprise pour les environnements plus larges.

Questions fréquemment posées