Monitoring de site web — qui l’apprend en premier, vous ou votre client

Le monitoring d’un site répond à une seule question : qui apprend la panne en premier — vous ou votre client. Tout le reste, du choix de l’outil à la fréquence des contrôles, est soit une réponse à cette question, soit une distraction.

Le monitoring le plus simple demande une page au serveur toutes les quelques minutes et vérifie si la réponse porte le code 200, c’est-à-dire « en ordre ». Si c’est le cas, il en conclut que le site fonctionne. Mais un code 200 dit seulement que le serveur a renvoyé quelque chose — pas qu’il a renvoyé ce qu’il fallait.

Nous en avons la preuve sur notre propre site. Nous avons vérifié ce que notre site renvoie pour une adresse qui n’existe pas. Il envoie une page intitulée « 404 — page introuvable » — avec un code 200. Une personne voit une erreur. Un monitoring qui ne vérifie que le code voit une page qui fonctionne. Google appelle cela un soft 404 dans sa documentation et avertit que ces pages d’erreur peuvent se retrouver dans l’index.

Chez nous, c’est un compromis assumé, pas un oubli. Nos pages sont envoyées au navigateur en flux, par morceaux, pour que le contenu apparaisse plus vite — et la documentation de Next.js explique que le serveur doit alors confirmer « 200 » avant de savoir si l’adresse existe. En contrepartie, il ajoute une balise noindex à la page d’erreur, si bien que Google ne l’indexe pas. Cela suffit au moteur de recherche. Pas au monitoring, qui ne lit pas la balise. Et c’est justement pourquoi la question « le site répond-il ? » ne suffit pas.

Ce que vérifie réellement un monitoring

Le mot « monitoring » recouvre quatre contrôles différents. Ils se distinguent par ce qu’ils demandent au site — et donc par les pannes qu’ils sont capables de voir.

Code de réponse. Le monitoring appelle une adresse et vérifie si le serveur a répondu 200. Il détecte un serveur qui ne répond pas du tout, ainsi que les erreurs serveur. Il ne détecte rien de ce que le serveur renvoie avec un 200 — une page d’erreur, une page vide, une page qui a perdu la moitié de son contenu. Ce contrôle existe dans tous les outils et c’est généralement le premier que l’on configure ; il vaut donc la peine de savoir ce qu’il ne voit pas.

Contenu de la page. Le monitoring récupère la page et y cherche un texte précis — le nom de l’entreprise dans le pied de page, un titre, un numéro de téléphone. Si le texte manque, il déclenche l’alarme, même avec un code 200. C’est un réglage de plus, et il comble la principale lacune du premier contrôle. Choisissez un texte qui ne change pas à chaque mise à jour du contenu, et qui ne figure pas sur la page d’erreur.

Parcours complet. Le monitoring fait ce que fait un client : il ouvre un formulaire, le remplit, l’envoie et vérifie la confirmation — ou ajoute un produit au panier et va jusqu’au paiement. C’est le seul contrôle qui voit que le site « fonctionne » alors que l’entreprise ne reçoit aucune demande. Il est plus coûteux, plus difficile à maintenir et doit être adapté à chaque modification du formulaire ; il a donc du sens là où ce parcours est une source de revenus.

Dates d’expiration. Un certificat et un domaine ne se dégradent pas progressivement — ils cessent de fonctionner un jour précis, que vous connaissez à l’avance. Un monitoring qui ne vérifie que l’état actuel remarquera le problème le jour de la panne. Un monitoring qui vérifie la date vous avertira une semaine plus tôt.

Pour un site d’entreprise typique, un ensemble raisonnable comprend le code et le contenu de la page d’accueil et de la page de contact, ainsi que la date du certificat et celle du domaine. Le parcours complet — pour une boutique, et pour le formulaire dont dépendent les ventes.

Le site fonctionne-t-il — qui l’apprend en premier

La question « le site fonctionne-t-il ? » n’a de sens qu’avec une seconde : à quelle vitesse quelqu’un l’apprendra-t-il, et que fera-t-il. Un monitoring qui contrôle toutes les cinq minutes remarquera, au pire, une panne cinq minutes après son début. Mais c’est le plus court segment de toute l’histoire.

Un contrat qui garantit 99,9 % de disponibilité autorise 44 minutes d’indisponibilité par mois — nous détaillons le calcul dans l’article sur le contrat de maintenance. Dans ce cadre, les proportions sont claires. Passer de cinq minutes à une en économise quatre. La promesse « nous réagissons dans l’heure » consomme à elle seule plus que tout le budget mensuel autorisé. La durée d’une panne ne dépend pas de la fréquence des contrôles, mais de ce qui se passe après l’alerte.

C’est pourquoi la première question, lorsqu’on met en place un monitoring, n’est pas « à quelle fréquence contrôler ? », mais « qui reçoit la notification, et peut-il en faire quelque chose ? ». La fréquence compte pour une boutique à fort trafic, où chaque minute représente des commandes. Pour un site d’entreprise, cinq minutes suffisent, à condition qu’il y ait quelqu’un pour réagir.

Il existe une raison supplémentaire d’avoir votre propre monitoring, même si une entreprise externe s’occupe du site avec le sien. Les outils de surveillance de la disponibilité tiennent un rapport : quel pourcentage du temps le site a répondu dans le mois, combien d’interruptions il y a eu et combien de temps elles ont duré. C’est votre mesure indépendante du contrat. Si le prestataire promet 99,9 % et que votre monitoring affiche deux heures d’interruption dans le mois, vous avez un chiffre à discuter, pas une impression. Sans mesure propre, la seule source d’information sur le respect du contrat est le rapport de celui qui devait le respecter.

Monitoring gratuit — UptimeRobot et les autres

Pour vérifier le code de réponse et le contenu, il n’est pas nécessaire de payer. L’un des outils les plus connus est UptimeRobot, et il constitue un bon point de repère pour savoir ce que l’on obtient gratuitement et où commence l’offre payante.

Selon les tarifs d’UptimeRobot, l’offre gratuite comprend 50 moniteurs contrôlés toutes les 5 minutes, avec des notifications par e-mail. L’offre payante la moins chère contrôle toutes les 60 secondes et coûte 9 euros par mois en paiement annuel. Une réserve : dans la section des questions de la même page, le fournisseur présente l’offre gratuite comme destinée au « basic personal monitoring ». Avant de l’utiliser pour un site d’entreprise, lisez les conditions en vigueur, car celles des offres gratuites changent plus souvent que les tarifs.

L’alternative est un monitoring que vous hébergez vous-même — par exemple Uptime Kuma, un logiciel libre sous licence MIT. Il n’a pas de limite de moniteurs ni d’intervalle, mais il lui faut un serveur que quelqu’un entretient. Et voici un piège qui concerne tout monitoring, pas seulement l’auto-hébergé : le monitoring ne doit pas tourner sur le même serveur que le site. Si le serveur tombe, ce qui devait vous prévenir tombe avec lui.

Pour la même raison, le monitoring doit contrôler le site depuis l’extérieur, depuis Internet, comme le fait un client. Un serveur qui se contrôle lui-même peut affirmer que tout fonctionne alors que personne ne peut l’atteindre de l’extérieur — parce que le DNS, le certificat ou le réseau en chemin a lâché.

Qui reçoit l’alerte

Une alerte que personne ne lit n’est qu’une ligne de journal. La plupart des dispositifs de monitoring qui fonctionnent mal n’échouent pas à la détection, mais à la notification : les alertes arrivent dans une boîte que plus personne ne lit, ou chez une personne sans accès au serveur.

Trois décisions transforment le monitoring en quelque chose qui fonctionne :

• Nommer qui reçoit l’alerte — et à quelles heures. Si une entreprise externe s’occupe du site, l’alerte doit lui parvenir, mais aussi à quelqu’un chez vous. Ainsi, vous êtes au courant de la panne, que le prestataire se manifeste ou non, et vous pouvez vérifier à quelle vitesse il a réagi.
• Ce que cette personne peut faire. Une notification à trois heures du matin adressée à un dirigeant sans accès au serveur n’aboutit qu’à une chose : il le saura le matin. Le chemin d’escalade — qui reçoit l’alerte, qui sait réparer, qui décide de restaurer une sauvegarde — doit être écrit avant d’être nécessaire.
• Une confirmation avant l’alarme. Un contrôle échoué isolé est parfois un problème réseau passager du côté du monitoring. Les outils permettent de ne déclencher l’alarme qu’après confirmation — un contrôle répété ou un contrôle depuis un autre lieu. Sans cela, après quelques fausses alarmes, les gens cessent de réagir aux vraies, ce qui est pire que l’absence de monitoring, car cela donne l’impression que quelqu’un veille.

Il vaut aussi la peine de décider ce qui relève du journal et ce qui relève de l’alarme. Un temps de réponse du serveur plus long est une information à consulter une fois par semaine. Un site qui ne répond plus justifie de réveiller quelqu’un. Qui reçoit les deux sur son téléphone désactivera les notifications au bout d’une semaine.

Site en panne — les quinze premières minutes

Une alerte est arrivée ou un client a appelé : le site est en panne. Avant que quiconque commence à réparer, il vaut la peine de prendre quelques minutes pour établir ce qui ne fonctionne pas exactement, et depuis quand, car c’est ce qui détermine qui appeler. L’ordre qui fait gagner le plus de temps :

1. La panne n’existe-t-elle que chez vous ? Ouvrez le site sur un téléphone, avec les données mobiles, pas sur le réseau du bureau. S’il fonctionne, le problème vient de votre connexion ou de votre navigateur, pas du serveur. Un monitoring qui contrôle de l’extérieur tranche immédiatement — à défaut, le téléphone est le remplaçant le plus rapide.
2. Que voyez-vous exactement ? Aucune réponse, une erreur 500, un avertissement de certificat, une page blanche, la page de l’hébergeur à la place de la vôtre — chaque cas renvoie à une cause différente. Un avertissement de certificat, c’est le certificat. La page du registraire ou un avis d’expiration, c’est le domaine. Une page blanche ou une erreur 500, c’est généralement l’application : une extension, le thème, la dernière modification.
3. Qu’est-ce qui a changé récemment ? Une mise à jour, une nouvelle extension, une modification sur le serveur, un déplacement du DNS. La plupart des pannes ont pour cause une action réalisée dans les dernières vingt-quatre heures, et annuler ce seul changement est plus rapide que chercher la cause à partir de zéro.
4. Est-ce le fournisseur ? Les hébergeurs et les fournisseurs DNS publient des pages d’état de leurs services. Si la panne vient de chez eux, votre travail s’arrête au signalement et à l’information des clients.
5. Y a-t-il un point de retour ? Si la cause n’est pas visible et que le site doit revenir, la question est : à partir de quelle sauvegarde, et combien de données depuis ce moment seront perdues. C’est une décision du propriétaire, pas du prestataire, et il est préférable qu’il connaisse la réponse avant d’avoir à la prendre ; comment organiser les sauvegardes pour que cette décision reste simple, nous l’expliquons dans l’article sur les sauvegardes.

Il vaut la peine de garder ces cinq étapes au même endroit que vos accès. Un quart d’heure passé à comprendre ce qui s’est passé raccourcit généralement une panne davantage qu’un monitoring plus rapide.

Erreurs 500 et 503 — ce que dit le monitoring

Deux codes d’erreur serveur apparaissent le plus souvent dans les alertes, et ils ne signifient pas la même chose.

500, selon la spécification HTTP, signifie que le serveur a rencontré « an unexpected condition » qui l’a empêché de traiter la requête. Autrement dit : quelque chose s’est cassé et le serveur ne sait pas quoi. Sur un site WordPress, il s’agit le plus souvent d’une erreur dans une extension ou dans le thème, souvent juste après une mise à jour ou un changement de version de PHP.

503 signifie que le serveur est « currently unable to handle the request due to a temporary overload or scheduled maintenance » — momentanément surchargé ou en travaux planifiés. C’est le code qu’un site devrait renvoyer lui-même pendant une maintenance, idéalement avec un en-tête Retry-After qui indique quand revenir.

Pour le moteur de recherche, la différence est plus faible qu’il n’y paraît. Selon Google, les erreurs 5xx — ces deux codes, ainsi que le 429 — amènent Googlebot à ralentir temporairement l’exploration. Les adresses indexées restent dans l’index, mais celles qui renvoient durablement une erreur serveur finissent par en être retirées. Une panne courte ne nuira pas. Un site qui renvoie une erreur 500 pendant plusieurs jours parce que personne n’a reçu l’alerte, si.

Ce que signifie chaque code serveur — y compris 502 et 504, que vous verrez aussi dans les alertes — et qui appeler pour chacun, est détaillé dans un article séparé sur les erreurs serveur.

D’où la règle pour les travaux planifiés : si le site doit être indisponible, qu’il renvoie 503, et non une page « en travaux » avec un code 200. Pour Google, cette dernière est un nouveau contenu à cette adresse, et pire que notre soft 404 du début de l’article : celui-ci porte au moins une balise noindex, alors qu’une page « en travaux » n’en porte généralement aucune.

Des pannes avec une date dans le calendrier : certificat et domaine

La plupart des pannes ne se prévoient pas. Deux se prévoient — au jour près.

Le certificat. La durée de validité maximale des certificats de site a été ramenée à 200 jours en mars 2026 et continuera de baisser — le calendrier est détaillé dans l’article sur les certificats SSL. Avec un renouvellement automatique, le problème n’existe généralement pas, tant que l’automatisme fonctionne. Lorsqu’il cesse de fonctionner — parce que le serveur, le DNS ou la configuration a changé — vous l’apprenez le jour où les navigateurs commencent à afficher un avertissement à vos visiteurs. Un monitoring de la date du certificat transforme cela en notification une semaine à l’avance.

Le domaine. Un domaine expiré coupe à la fois le site et la messagerie, et après la période de rétablissement, n’importe qui peut l’enregistrer — nous le décrivons avec les coûts de maintenance. La cause la plus fréquente n’est pas le manque d’argent, mais un rappel envoyé à une adresse que personne ne lit. Un monitoring de la date du domaine est un second rappel, indépendant du registraire.

Ces deux contrôles sont disponibles d’emblée dans la plupart des outils de monitoring, et on les configure une fois pour toutes.

Monitoring du serveur — ce qui ne se voit que de l’intérieur

Tout ce qui précède contrôle le site de l’extérieur, comme le voit un client. Le monitoring du serveur regarde de l’intérieur : l’espace disque, la charge du processeur, la mémoire, les erreurs écrites dans les journaux et les tâches planifiées. Sur un hébergement mutualisé, la plupart de ces éléments échappent à votre contrôle et c’est le fournisseur qui répond de ce qui se passe à l’intérieur. Sur votre propre serveur ou un serveur virtuel, c’est votre responsabilité ou celle du prestataire.

Du point de vue du propriétaire du site, deux points comptent plus que le reste, car ce sont des causes fréquentes de pannes qui paraissent soudaines vues de l’extérieur :

• L’espace disque. Un journal qui grossit sans limite, ou des sauvegardes stockées sur le même serveur, peuvent remplir un disque en quelques semaines. Quand l’espace manque, tout ce qui écrit quoi que ce soit cesse de fonctionner — y compris les formulaires et la base de données. Une alerte au-delà d’un seuil d’occupation défini vous laisse des semaines au lieu de minutes.
• Les tâches qui ne se sont pas exécutées, en silence. Une sauvegarde qui n’a pas été créée, un renouvellement de certificat qui a échoué, un envoi de notifications qui s’est bloqué. De l’extérieur, le site fonctionne, et le problème n’apparaît que le jour où cette sauvegarde ou ce certificat est nécessaire. Le bon réglage déclenche l’alarme en cas d'absence de signal de réussite, et pas seulement en cas d’erreur.

Si un prestataire s’occupe du site, le monitoring du serveur est son outil de travail. Pour vous, il suffit de savoir qu’il existe et d’en recevoir une phrase une fois par mois : les sauvegardes ont-elles tourné, et combien d’espace reste-t-il.

Le monitoring des performances n’est pas les Core Web Vitals

Un monitoring de disponibilité mesure aussi le temps de réponse du serveur, et il vaut la peine de le suivre — une hausse soudaine est souvent le premier symptôme d’un problème, avant que le site cesse de répondre. Mais ce ne sont pas les données que regarde Google.

Google évalue la vitesse d’une page sur la base des Core Web Vitals, des mesures issues de vrais utilisateurs de Chrome, collectées sous forme de moyenne sur 28 jours. Ce sont des données importantes, mais elles ne conviennent pas aux alertes : une dégradation y apparaît progressivement, au fil des semaines suivantes, et non une heure après le déploiement qui l’a causée. Le monitoring des performances et les Core Web Vitals répondent donc à deux questions différentes — « quelque chose vient-il de casser ? » et « comment le site se comporte-t-il pour les utilisateurs sur le dernier mois ? » — et l’un ne remplace pas l’autre.

Ce que cet article laisse volontairement de côté

• Le suivi des positions dans Google — d’autres outils et une autre question ; nous en parlons dans l’article sur le référencement et l’indexation Google.
• L’analyse du trafic — l’analyse d’audience vous dit qui est venu, pas si le site fonctionnait.
• L’accessibilité au sens des WCAG — la « disponibilité » d’un site ne doit pas être confondue avec son accessibilité pour les personnes en situation de handicap ; c’est un autre sujet.
• Ce qu’il faut faire après une panne — la restauration depuis une sauvegarde et l’accord avec le prestataire sur qui réagit et dans quel délai, c’est-à-dire le contrat de maintenance.

Le résumé le plus court : un monitoring qui ne demande qu’un code 200 vous dira que le serveur est vivant — pas que le site fonctionne. Ajoutez un contrôle du contenu, les dates du certificat et du domaine, et pour une boutique le parcours d’achat complet. Et avant de choisir un outil, notez qui recevra l’alerte à trois heures du matin et ce qu’il pourra en faire, car c’est ce segment, et non la fréquence des contrôles, qui décide de la durée d’une panne.