Surveiller la disponibilité d’un site internet

De nombreux propriétaires de site découvrent une panne de la même façon : un client qui appelle, un message sur les réseaux sociaux, ou une chute soudaine des demandes de contact. Entre le moment où le site tombe et celui où quelqu'un le signale, plusieurs heures peuvent s'écouler sans que personne n'agisse.

Un site surveillé automatiquement change cette équation : une alerte part dès les premières minutes d'indisponibilité, avant même que les visiteurs ne s'en aperçoivent. Ce guide détaille ce qu'il faut surveiller, avec quelle fréquence, comment lire un taux de disponibilité et ce que Google fait d'un site qui ne répond plus.

Ce qu'une panne coûte côté référencement

Une panne ne prive pas seulement les visiteurs d'une page : elle touche aussi les robots. Dans sa documentation destinée aux robots d'exploration, mise à jour en février 2026, Google indique que les erreurs serveur de type 5xx et 429 conduisent ses robots à ralentir temporairement l'exploration. Les URL déjà indexées sont conservées dans l'index, mais elles finissent par en être retirées si l'erreur persiste. La documentation ne donne aucun délai chiffré : mieux vaut ne jamais compter sur une tolérance de quelques jours.

Une indisponibilité voulue (migration, mise à jour lourde) se signale proprement avec un code 503, plutôt qu'avec une page vide ou une erreur 500. Notre guide sur le mode maintenance WordPress et celui sur la page de maintenance propre détaillent la marche à suivre.

Mettre en place une surveillance, sans complexité

1. Choisir ce qui doit être surveillé en priorité. La page d'accueil et les pages qui génèrent des demandes (contact, panier, formulaire de devis) méritent une vérification plus fréquente que le reste du site.

2. Définir un canal d'alerte fiable. Un e-mail seul peut passer inaperçu en dehors des horaires de bureau ; un SMS ou une notification sur une application mobile raccourcit le délai entre la panne et l'intervention.

3. Fixer un seuil de tolérance raisonnable. Une alerte à la moindre lenteur ponctuelle finit par être ignorée ; un seuil calibré limite les fausses alertes tout en restant réactif.

4. Relier la surveillance à une procédure claire. Savoir qu'un site est en panne ne sert à rien sans savoir qui prévenir et dans quel ordre agir : contact de l'hébergeur, accès de secours, personne à joindre en cas d'urgence. Le guide site internet hors ligne : que faire peut servir de base à cette procédure.

5. Vérifier régulièrement que la surveillance elle-même fonctionne. Un test volontaire (mettre le site en maintenance quelques secondes, par exemple) confirme que les alertes partent bien avant d'en avoir réellement besoin.

Fréquence de contrôle et délai de détection

Le délai maximal avant une alerte se calcule simplement : intervalle entre deux contrôles multiplié par le nombre d'échecs consécutifs exigés avant de déclencher l'alerte. Exemple illustratif : un contrôle toutes les 5 minutes, avec alerte après 2 échecs de suite, signale une panne en 10 minutes environ ; un contrôle toutes les minutes avec le même seuil la signale en 2 minutes. Exiger 2 ou 3 échecs consécutifs filtre les micro-coupures sans retarder sensiblement l'intervention.

Plusieurs outils proposent une formule gratuite, et UptimeRobot est cité comme tel par plusieurs guides francophones. Les limites (nombre de sites, fréquence des contrôles, canaux d'alerte) changent d'une offre à l'autre : à vérifier sur le site de l'éditeur avant de s'engager.

Quand la question se pose : le calendrier des recherches

Les relevés Google Ads obtenus via DataForSEO pour la France, sur les 12 mois de septembre 2025 à août 2026, apportent trois enseignements. D'abord, « surveiller site web » ne pèse que 10 recherches par mois : les internautes cherchent surtout « monitoring site web », autour de 260 recherches mensuelles. Ensuite, cette demande est irrégulière : 590 en mars 2026, 390 en septembre 2025, mais seulement 110 en juillet 2026. Enfin, « Uptime Robot », le nom d'outil le plus recherché du sujet, reste stable autour de 720 recherches par mois et monte à 1 000 en mars 2026.

Ces ordres de grandeur sont indicatifs, car le planificateur arrondit les volumes. Ils dessinent toutefois deux fenêtres, mars et septembre, où l'intérêt pour le sujet remonte : un bon repère pour installer et tester la surveillance avant ces périodes plutôt que de la découvrir après une panne.

Lire un taux de disponibilité sans se tromper

Un hébergeur annonce volontiers « 99,9 % de disponibilité ». Le tableau ci-dessus se calcule en multipliant la part d'indisponibilité par la durée de la période : 0,1 % d'une année de 8 760 heures fait 8,76 heures. Le même taux sur un mois de 30 jours ne laisse que 43 minutes. Quatre questions à poser avant de se fier à un engagement :

• Sur quelle période est-il mesuré ? Un taux annuel peut masquer une très mauvaise semaine.
• Que compte-t-on comme indisponibilité ? Les maintenances planifiées sont parfois exclues du calcul.
• Qui mesure, et depuis où ? Une mesure interne à l'hébergeur ne voit pas un problème de DNS ou de certificat ; un contrôle externe indépendant se place du point de vue du visiteur.
• Quel recours en cas de dépassement ? Un engagement sans compensation précise reste un simple argument commercial.

Un taux élevé ne dit rien non plus de la partie applicative : une page vide ou un formulaire cassé peuvent s'afficher avec un code 200. D'où l'intérêt de surveiller le contenu d'une page clé et pas seulement la réponse du serveur.

Au-delà du « le site répond »

Quatre vérifications complètent utilement le contrôle de disponibilité. La première concerne le certificat SSL, dont l'expiration provoque un avertissement bloquant pour le visiteur. La deuxième est la date de renouvellement du nom de domaine. La troisième est la détection de liens cassés sur les pages qui convertissent. La quatrième est le suivi, dans la Search Console, des problèmes serveur rencontrés par Googlebot : il confirme côté Google ce que l'outil de surveillance voit côté visiteur.

Enfin, la surveillance ne fait que prévenir : pour que l'alerte débouche sur une réparation, il faut quelqu'un qui intervienne et une sauvegarde saine à restaurer. Voir à ce sujet la sauvegarde externalisée et le test de restauration.