Bonnes pratiques de surveillance de site Web réellement utilisées par les ingénieurs

La plupart des équipes disposent d’une surveillance de site web. Bien moins ont une surveillance qui détecte réellement les problèmes avant que les clients, les ventes et le support ne le fassent. L’écart n’est que rarement dû à l’outil. Ce sont les pratiques qui l’entourent : ce qui est vérifié, d’où, à quelle fréquence, ce qui déclenche une alerte, et qui décide quand un contrôle est cassé versus quand le site est cassé.

Ce manuel rassemble huit meilleures pratiques de surveillance de site Web qui distinguent les configurations auxquelles les équipes SRE et DevOps font confiance de celles qui se transforment silencieusement en bruit. Chacune est concrète : seuils, intervalles, anti-modèles, et ce qu’il faut continuer à faire une fois que cela fonctionne. Les mêmes pratiques s’appliquent que vous fassiez une surveillance de disponibilité sur un site marketing ou une surveillance synthétique complète des transactions sur un checkout SaaS.

À quoi ressemble une “bonne” (et pourquoi la plupart des configurations la manquent)

Une définition de travail : votre surveillance est bonne si votre équipe apprend chaque problème affectant les clients via un moniteur avant d’en apprendre par un client, et si les alertes que vous recevez sont presque toujours exploitables. C’est cela le seul critère.

Trois chiffres la mesurent. Le temps moyen pour détecter (MTTD) vous dit si la surveillance est assez rapide. Le temps moyen pour résoudre (MTTR) vous dit si les données remontées par le moniteur suffisent à résoudre le problème. La précision des alertes — le pourcentage d’alertes réelles nécessitant une action immédiate — vous indique si votre équipe fera encore confiance aux alertes dans six mois. La majorité des équipes SRE mesurent le MTTD et le MTTR. La plupart ne mesurent pas la précision. C’est pourquoi tant de rotations en astreinte se dégradent en simples reconnaissances silencieuses et en état d’impuissance apprise.

Le reste de ce manuel consiste à améliorer ces deux chiffres simultanément.

Superposez les contrôles sur le chemin complet de la requête

Un seul contrôle HTTPS est comme un détecteur de fumée avec un seul capteur. Il vous indique qu’il y a un problème, pas où. Quand un utilisateur tape votre URL et attend que la page s’affiche, la requête traverse au moins six couches : résolution DNS, poignée de main 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 a sa propre cause racine.

La configuration pratique ressemble à ceci :

• DNS : Vérifier que les enregistrements A, AAAA, CNAME et MX résolvent vers les valeurs attendues à partir de plusieurs résolveurs. Les problèmes DNS sont les plus faciles à manquer et les plus pénibles à diagnostiquer après coup. Les meilleurs outils de surveillance DNS surveillent les changements non autorisés, les délais de propagation, et les défaillances spécifiques aux résolveurs.
• TCP et ICMP : Confirmer que le port est ouvert et que le chemin réseau est sain. Un changement de firewall bloquant le port 443 ne sera pas détecté par un contrôle HTTP depuis le même segment réseau.
• TLS : Valider la chaîne de certificats, la date d’expiration, la correspondance du nom d’hôte, et le support des chiffrements. La plupart des pannes de certificats sont évitables — le certificat a simplement expiré un dimanche. Recevez des alertes explicites à 60, 30, 14 et 3 jours avant expiration. Voir comment surveiller l’expiration des certificats SSL pour les détails de configuration.
• HTTP : Code de statut, temps de réponse et assertion de contenu. Un statut 200 avec un corps vide est un échec, pas un succès.
• Rendu et transaction : Pilotez un vrai navigateur à travers le parcours utilisateur, affirmez la présence d’un élément connu dans l’état final et mesurez le temps d’interactivité. La surveillance synthétique avec de vrais navigateurs détecte ce que les contrôles protocolaires ne peuvent pas — JavaScript cassé, scripts de tiers qui bloquent, fichier CSS manquant rendant le bouton du panier invisible.
• API : Traitez les API comme des points d’accès de première classe. Un site qui charge mais ne peut pas finaliser un paiement car l’API de paiement est en timeout est toujours cassé. La surveillance des API mérite un planning de contrôle propre, séparé des pages qui en dépendent.

Lorsqu’un problème survient, la couche qui déclenche l’alerte en premier est votre point de départ pour la cause racine. Une équipe qui ne surveille que le HTTP reçoit une seule information : indisponible. Une équipe surveillant les six couches obtient un arbre de fautes.

Faites fonctionner la surveillance synthétique et RUM côte à côte, pas l’une à 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 avoir testé les deux pendant un trimestre.

La surveillance synthétique exécute des contrôles scriptés selon un planning fixe depuis des emplacements fixes. Les données sont cohérentes dans le temps et insensibles aux baisses de trafic. Elle fonctionne aussi à 3 h du matin quand il n’y a aucun utilisateur réel pour remarquer le déploiement qui a cassé la page de connexion. Voilà pourquoi la surveillance synthétique est l’outil idéal pour les rapports SLA, la détection des régressions et les alertes proactives.

RUM capture les données de performances et d’erreurs depuis les navigateurs réels. Elle reflète la distribution réelle des appareils, réseaux et zones géographiques de vos utilisateurs. C’est la seule source qui peut vous dire qu’une tranche de 2 % des utilisateurs Android sur un opérateur spécifique voit un temps au premier octet de 9 secondes. RUM est l’outil adapté pour comprendre l’expérience réelle et prioriser le travail d’ingénierie.

Utilisez la synthétique pour savoir que le site est opérationnel et se comporte normalement. Utilisez RUM pour savoir comment ce comportement correspond aux personnes qui vous payent. Les équipes qui choisissent l’une au détriment de l’autre se retrouvent soit surprises par des cas limites (synthétique seul) soit apprennent les pannes via Twitter (RUM seul).

Surveillez depuis les zones géographiques générant des revenus

Un contrôle depuis votre centre de données voisin vous indique 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 contribuant significativement aux revenus, plus une ou deux régions de contrôle. Si 35 % de vos ventes viennent d’EMEA, il vous faut au moins deux points de contrôle EMEA — un dans un marché principal comme Francfort ou Londres, un dans un secondaire comme Madrid ou Stockholm. Une couverture EMEA avec un seul point masque les pannes régionales d’ISP ou les défaillances aux extrémités des CDN.

Trois configurations valant la peine d’être mises en place :

1. Confirmation multi-géo pour l’alerte. Exigez que le problème soit détecté dans au moins deux régions distinctes en moins de 60 secondes avant d’alerter. Une région défaillante isolément est généralement un problème d’opérateur régional ou un problème sur un point de contrôle unique, pas une panne du site.
2. Seuils régionaux. Tokyo et Iowa ne chargent pas votre site à la même vitesse et ne devraient pas partager le même seuil. Suivez la latence p95 par région et alertez sur déviation régionale, pas moyenne globale.
3. Agents privés dans les réseaux d’entreprise. Si vous vendez à des entreprises accédant à votre app derrière leur propre firewall, déployez un point de contrôle dans cet environnement. Les agents privés détectent les problèmes causés par le réseau client, pas le vôtre, mais qui restent à leurs yeux vos problèmes.

Le réseau de points de contrôle Dotcom-Monitor couvre plus de 30 pays ; la liste à activer dépend de la provenance de vos revenus, pas de l’emplacement de votre centre de données.

Fixez des seuils à partir des bases, pas à partir de nombres ronds

Le péché le plus courant en surveillance est « alerter si le temps de réponse > 3 secondes ». Trois secondes est un nombre rond. Votre site s’en fiche des nombres ronds. Si votre vrai p95 est 4,2 secondes et stable, vous serez alerté 24 fois par jour pour un comportement normal. Si votre vrai p95 est 0,8 seconde et dégrade à 2,5 secondes, vous n’aurez rien parce que 2,5 reste sous 3.

La solution est un seuil relatif à la base :

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

Cette formule fait trois choses à la fois. Le multiplicateur 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 condition « deux fenêtres consécutives » élimine les faux positifs dus à des pics puis récupérations rapides, cause majeure des nuisances d’alerte.

Le calcul des bases est la partie que la plupart des équipes sautent. Recalculez-les chaque semaine à partir des 14 jours précédents, en excluant les fenêtres de déploiement et les périodes d’incidents connus. Les produits de détection d’anomalies qui basent automatiquement sont un raccourci valide si vous ne voulez pas gérer ça manuellement, mais vérifiez ce qu’ils excluent. Une base contaminée par l’incident de la semaine dernière vaut moins que pas de base du tout.

Pour les contrôles de disponibilité, règle équivalente : exigez deux échecs consécutifs venant de deux géographies distinctes avant d’alerter. Un échec unique depuis un endroit est presque toujours un hoquet du point de contrôle. Deux échecs de deux endroits, c’est réel.

Concevez l’alerte, pas seulement le contrôle

Un contrôle vous dit que quelque chose est arrivé. Une alerte demande à un humain d’agir. Ce sont deux problèmes différents et la plupart des équipes ne conçoivent que le premier.

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

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

Le modèle qui fonctionne :

1. Trois niveaux de gravité, trois canaux. Critique (site down, paiement cassé) → SMS ou téléphone. Avertissement (dégradation soutenue) → push ou chat avec mention à l’astreinte. 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, n’alertez pas aussi sur les 14 contrôles HTTP en aval qui en dépendent. Le groupe d’alertes et suppression des dépendances sont incontournables ; si votre plateforme ne les supporte pas, préparez-vous à perdre du sommeil.
3. Grille d’escalade, pas chaîne d’escalade. Si l’astreinte primaire ne répond pas sous 5 minutes, alertez le secondaire et notifiez le canal. L’escalade en série vous coûte 5 minutes par étape durant une panne.
4. Heures silencieuses pour les alertes non critiques. Les régressions de performance à 2 h du matin un dimanche ne méritent généralement pas un réveil à 2 h. Les alertes critiques, oui. Soyez honnête sur ce qui est critique lors de la configuration.

Et mesurez la précision. Chaque mois, comptez les alertes déclenchées et notez-les : incident réel, faux positif, action non requise. Si la précision est sous 80 %, réparez 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 que votre code. Une page checkout moderne charge des scripts d’un processeur de paiement, d’un gestionnaire de tags, d’un fournisseur d’analytics, d’un widget de 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 méritent leurs propres moniteurs :

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

Documentez quels tiers bloquent quels parcours utilisateurs. Lorsqu’un tiers échoue, le runbook doit indiquer si l’action correcte est « revenir en mode dégradé », « attendre la résolution », ou « contacter l’astreinte du fournisseur ». Sans cette carte, chaque incident tiers devient un exercice d’improvisation.

Reliez chaque moniteur à un runbook

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

Réglez ça une fois pour toutes : chaque moniteur doit pointer vers une entrée de runbook. Le runbook n’a pas besoin d’être élaboré. Trois sections suffisent :

1. Ce que couvre ce contrôle en une phrase. (« Valide que la transaction checkout EU complète en moins de 5 secondes depuis Francfort et Amsterdam. »)
2. Les cinq premières vérifications quand elle se déclenche. Liens vers pages statut, dashboards, déploiements récents, alertes associées, page de statut du fournisseur.
3. Schémas de faux positifs connus, si pertinents. (« Le point de contrôle Francfort expire parfois pendant la maintenance du fournisseur 02:00-02:30 UTC samedi. Supprimé. »)

Le premier runbook prend 15 minutes à écrire. Chaque incident suivant sur ce moniteur en prend 15 de moins. Le calcul est évident et la plupart des équipes ne le font toujours pas.

Validez les moniteurs et auditez la couverture trimestriellement

Un moniteur non testé est un souhait, pas une garantie. Deux pratiques comblent les lacunes.

Faites un exercice de chaos sur les alertes. Une fois par trimestre, cassez volontairement un contrôle — arrêtez un endpoint de test, faites expirer un certificat en environnement de préproduction, abaissez le seuil de temps de réponse à 0 — et vérifiez que l’alerte se déclenche, s’escalade et atteint la bonne personne. Environ un tiers des alertes échouent à leur premier exercice. Causes fréquentes : rotations d’astreinte obsolètes, tokens d’intégration expirés, canaux Slack plus lus.

Auditez la carte de couverture trimestriellement. Maintenez un document unique listant chaque parcours utilisateur, chaque dépendance externe, et chaque catégorie d’URLs. Pour chaque ligne, listez les moniteurs qui la couvrent. Les lignes vides sont des gaps. Les nouvelles fonctionnalités ajoutées le dernier trimestre se trouvent souvent dans ces gaps.

L’audit produit aussi l’effet inverse : des moniteurs couvrant des URLs n’existant plus. Supprimez-les. Un moniteur sur un endpoint 410 génère du bruit sans fin et ne protège rien.

Ce qu’il faut rechercher dans une plateforme de surveillance

La plupart des plateformes peuvent pinger une URL. Les différences apparaissent dans les cas plus complexes. Lors de l’évaluation des outils, allez au-delà des démos dashboard et demandez-vous :

• Peut-elle piloter une transaction réel-navigateur avec logique conditionnelle ? Les enregistrements statiques cassent dès que la page change. La surveillance transactionnelle scriptable (style Selenium ou propriétaire) survit à l’évolution normale du produit.
• Combien de protocoles natifs supporte-t-elle ? HTTP, HTTPS, DNS, FTP, SMTP, IMAP, POP3, TCP, UDP, ICMP. En externaliser certains vers un autre outil multiplie les fournisseurs et les authentifications.
• Quelle est la véritable couverture du réseau de points de contrôle ? Un vendeur avec 200 « points de contrôle » tous hébergés sur trois régions cloud ne compte pas comme global. Demandez la liste des villes.
• Peut-elle s’exécuter depuis votre réseau interne ? Des agents privés sont indispensables pour la surveillance d’environnements de test, d’apps internes et de déploiements clients privatifs.
• Comment gère-t-elle les dépendances et regroupements d’alertes ? Une plateforme qui alerte 14 fois pour un seul échec DNS vous empoisonne la vie.
• À quoi ressemble l’export des données ? Si vous ne pouvez pas extraire les résultats bruts des contrôles dans votre propre stack analytique, vous ne pourrez pas enquêter sur les incidents complexes.
• Intégrations avec vos outils d’incidents. PagerDuty, Opsgenie, Slack, Microsoft Teams, ServiceNow, Jira. Les intégrations natives surpassent toujours les connecteurs webhook.

Pour une checklist plus complète avec grilles de notation, consultez comment choisir le meilleur outil de surveillance de site web et concurrents et alternatives à Datadog pour le contexte de chaque acteur.

Modes de défaillance communs

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

• Un seul seuil global pour un site multi-régions. La région rapide dérive à la hausse, la région lente se dégrade, la moyenne globale paraît correcte, et l’alerte ne se déclenche jamais.
• Contrôles statut 200 sans assertion de contenu. Un 200 vide d’une page d’erreur CDN passe la vérification et casse en production.
• Transactions synthétiques dépendant d’un vrai compte client. Mot de passe expiré, MFA activé, compte bloqué. Utilisez un compte de service avec un scope explicite de surveillance.
• Alertes de certificat à 7 jours seulement. 7 jours est le délai butoir, pas l’avertissement. À ce moment, quelqu’un est déjà en mode pompier. Alertez à 60, 30, 14 et 3 jours. La surveillance des certificats SSL doit être en place.
• Pas de corrélation avec les déploiements. Si vos alertes ne disent pas « ceci s’est déclenché 3 minutes après le déploiement abc123 », chaque incident commence par une revue manuelle du journal git. Reliez votre CI à vos annotations de surveillance.
• Seuils d’alerte 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 en réalité désactivé.
• Surveillance de la page d’accueil mais pas du parcours monétaire. La disponibilité de la page d’accueil est un indicateur de vanité. Disponibilité du checkout, de l’inscription et de la connexion sont le cœur du business.

Pour des spécificités de couche applicative — particulièrement sur les API, parcours scriptés et topologies microservices — combinez cela avec les meilleures pratiques de surveillance des applications web. Et pour l’aspect SEO sur pourquoi les budgets de latence comptent, voir comment la vitesse du site affecte le SEO.

Mettez ce manuel en action

Choisissez trois pratiques dans cette liste que votre configuration actuelle ne gère pas. Implémentez-les ce sprint. Faites l’exercice de chaos sur les nouveaux moniteurs avant de considérer la tâche terminée. Puis auditez la précision dans 30 jours.

Si la plateforme est le goulot d’étranglement, Dotcom-Monitor couvre toute la pile dans un seul endroit : surveillance synthétique avec véritables navigateurs, contrôles multi-protocole, réseau global 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 surveillance des applications web, surveillance API, surveillance DNS, et surveillance des certificats SSL, ou passez directement à l’aperçu de la surveillance d’entreprise pour les environnements plus importants.

Questions fréquemment posées