{"id":32295,"date":"2026-01-05T13:19:19","date_gmt":"2026-01-05T13:19:19","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/website-monitoring-best-practices\/"},"modified":"2026-07-15T21:12:10","modified_gmt":"2026-07-15T21:12:10","slug":"website-monitoring-best-practices","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/fr\/website-monitoring-best-practices\/","title":{"rendered":"Bonnes pratiques de surveillance de site Web r\u00e9ellement utilis\u00e9es par les ing\u00e9nieurs"},"content":{"rendered":"
\"Ing\u00e9nieur
Une bonne surveillance vous indique ce qui a cass\u00e9, o\u00f9 et pourquoi\u2014avant que vos clients ne le fassent.<\/figcaption><\/figure>\n

La plupart des \u00e9quipes disposent d’une surveillance de site web. Bien moins ont une surveillance qui d\u00e9tecte r\u00e9ellement les probl\u00e8mes avant que les clients, les ventes et le support ne le fassent. L’\u00e9cart n’est que rarement d\u00fb \u00e0 l’outil. Ce sont les pratiques qui l’entourent : ce qui est v\u00e9rifi\u00e9, d’o\u00f9, \u00e0 quelle fr\u00e9quence, ce qui d\u00e9clenche une alerte, et qui d\u00e9cide quand un contr\u00f4le est cass\u00e9 versus quand le site est cass\u00e9.<\/p>\n

Ce manuel rassemble huit meilleures pratiques de surveillance de site Web qui distinguent les configurations auxquelles les \u00e9quipes SRE et DevOps font confiance de celles qui se transforment silencieusement en bruit. Chacune est concr\u00e8te : seuils, intervalles, anti-mod\u00e8les, et ce qu\u2019il faut continuer \u00e0 faire une fois que cela fonctionne. Les m\u00eames pratiques s\u2019appliquent que vous fassiez une surveillance de disponibilit\u00e9 sur un site marketing ou une surveillance synth\u00e9tique compl\u00e8te des transactions sur un checkout SaaS.<\/p>\n

\u00c0 quoi ressemble une “bonne” (et pourquoi la plupart des configurations la manquent)<\/h2>\n

Une d\u00e9finition de travail : votre surveillance est bonne si votre \u00e9quipe apprend chaque probl\u00e8me affectant les clients via un moniteur avant d\u2019en apprendre par un client, et si les alertes que vous recevez sont presque toujours exploitables. C’est cela le seul crit\u00e8re.<\/p>\n

Trois chiffres la mesurent. Le temps moyen pour d\u00e9tecter (MTTD) vous dit si la surveillance est assez rapide. Le temps moyen pour r\u00e9soudre (MTTR) vous dit si les donn\u00e9es remont\u00e9es par le moniteur suffisent \u00e0 r\u00e9soudre le probl\u00e8me. La pr\u00e9cision des alertes \u2014 le pourcentage d\u2019alertes r\u00e9elles n\u00e9cessitant une action imm\u00e9diate \u2014 vous indique si votre \u00e9quipe fera encore confiance aux alertes dans six mois. La majorit\u00e9 des \u00e9quipes SRE mesurent le MTTD et le MTTR. La plupart ne mesurent pas la pr\u00e9cision. C\u2019est pourquoi tant de rotations en astreinte se d\u00e9gradent en simples reconnaissances silencieuses et en \u00e9tat d\u2019impuissance apprise.<\/p>\n

Le reste de ce manuel consiste \u00e0 am\u00e9liorer ces deux chiffres simultan\u00e9ment.<\/p>\n

Superposez les contr\u00f4les sur le chemin complet de la requ\u00eate<\/h2>\n

Un seul contr\u00f4le HTTPS est comme un d\u00e9tecteur de fum\u00e9e avec un seul capteur. Il vous indique qu’il y a un probl\u00e8me, pas o\u00f9. Quand un utilisateur tape votre URL et attend que la page s\u2019affiche, la requ\u00eate traverse au moins six couches : r\u00e9solution DNS<\/a>, poign\u00e9e de main TCP, n\u00e9gociation TLS, r\u00e9ponse HTTP, chargement des ressources, et rendu c\u00f4t\u00e9 client de la vue finale. Chaque couche \u00e9choue diff\u00e9remment et chaque \u00e9chec a sa propre cause racine.<\/p>\n

\"Sch\u00e9ma
Un contr\u00f4le par couche. Chaque couche a une surface de d\u00e9faillance distincte et une correction sp\u00e9cifique.<\/figcaption><\/figure>\n

La configuration pratique ressemble \u00e0 ceci :<\/p>\n