Un site en panne ne prévient personne
Votre site peut être beau et bien référencé. S'il ne répond plus, vos visiteurs ne voient rien.
Et vous, souvent, vous l'apprenez trop tard. Par un client qui appelle. Par un formulaire resté vide tout un week-end.
Surveiller un site, c'est éviter cette découverte tardive. Pas besoin d'être ingénieur. Il suffit de trois indicateurs clairs, d'alertes bien réglées et d'une routine simple quand quelque chose cloche. Je vous explique la méthode avec des mots courants.
TL;DR : surveiller son site web, c'est suivre trois choses : la disponibilité (uptime), le temps de réponse et les erreurs. Une sonde automatique vérifie vos pages clés à intervalle régulier et vous alerte avant vos clients. Ajoutez deux niveaux d'alerte, une procédure d'incident courte et quelques réflexes de sécurité, et la plupart des pannes deviennent des incidents brefs.
Pourquoi surveiller son site web quand on est une PME ?
Parce qu'une panne ou une lenteur coûte des demandes de contact sans laisser de trace visible.
Imaginez une boutique physique. Vous ouvrez le matin. La porte doit s'ouvrir : c'est la disponibilité. Les clients doivent entrer sans faire la queue dehors : c'est la rapidité. Le terminal de paiement doit fonctionner : c'est la fiabilité.
Un site web, c'est pareil. Si la porte ne s'ouvre pas, personne n'achète. Si la page tarde, on part. Si le formulaire bloque, on abandonne.
Il y a aussi un effet sur Google. Selon la documentation de Google Search, les erreurs serveur 5xx ralentissent l'exploration, et les URL déjà indexées finissent par sortir de l'index si l'erreur persiste. Une panne qui dure ne coûte donc pas seulement des visites du jour.
La surveillance sert à voir vite ce qui se passe, pour agir vite. C'est un filet de sécurité simple, qui rassure tout le monde.
Quels indicateurs surveiller sur un site web ?
Trois indicateurs suffisent pour démarrer : la disponibilité, le temps de réponse et les erreurs.
On peut ajouter des détails plus tard. Commencer simple aide à tenir dans le temps.

La disponibilité (uptime)
Définition. L'uptime est la part du temps pendant laquelle votre site répond.
Un objectif courant est de 99,9 % de disponibilité, soit environ 43 minutes d'interruption tolérées par mois. Ce repère parle mieux qu'un pourcentage : il dit combien de temps votre site peut être fermé sans que ce soit anormal.
Un outil vérifie à intervalle régulier que votre page d'accueil répond, ainsi que la page qui compte le plus pour vous. On parle parfois d'URL de santé, une adresse technique qui confirme que le serveur et la base de données fonctionnent.
Le temps de réponse
Définition. Le temps de réponse est le délai entre la demande d'une page et l'arrivée des premiers éléments.
L'indicateur courant côté serveur est le TTFB (Time To First Byte, temps jusqu'au premier octet). Google recommande de viser un TTFB de 0,8 seconde ou moins. Au-delà, tout le reste de la page démarre en retard.
La vitesse vécue sur mobile est un sujet à part entière. Je la détaille dans notre article sur le site lent sur mobile et les Core Web Vitals.
Les erreurs
Définition. Une erreur est une réponse anormale du site, signalée par un code technique.
Les codes de réponse HTTP se lisent simplement. Un code en 5xx (par exemple 500) signale un problème côté serveur. Un code en 4xx (par exemple 404) signale une page introuvable ou un lien cassé. Côté navigateur, un script bloqué peut aussi casser un formulaire sans aucun code visible.
Pas besoin de lire du code pour s'inquiéter. Si les erreurs se multiplient en peu de temps, c'est un signal. L'important est de remonter le message avec son contexte : quelle page, quel navigateur, à quel moment.
Comment améliorer et garantir l'uptime d'un site web ?
On ne garantit pas un uptime parfait, mais on réduit fortement les pannes et leur durée.
Quatre leviers font l'essentiel du travail.
Des mises à jour suivies. Un CMS, une extension ou une bibliothèque non mise à jour est une cause fréquente de panne et de piratage. Cybermalveillance.gouv.fr rappelle que les mises à jour corrigent des failles de sécurité exploitées par les attaquants. On les applique d'abord sur une copie du site, puis en production.
Des sauvegardes testées. Une sauvegarde qu'on n'a jamais restaurée n'est qu'une promesse. Testez la restauration de temps en temps.
Un hébergement adapté. Un site qui tombe à chaque pic de trafic manque de ressources ou de cache. C'est un sujet à trancher avec votre prestataire.
Une surveillance active. C'est elle qui transforme une panne de plusieurs heures en incident de quelques minutes, parce que quelqu'un est prévenu tout de suite.
Ce suivi régulier est le cœur d'une maintenance de site web.
Comment mesurer sans devenir expert ?
Deux approches se complètent : les tests automatiques préviennent, les mesures réelles confirment.
Les tests automatiques jouent le rôle d'un robot qui visite votre site à intervalle régulier. Ils ouvrent une page, vérifient qu'un mot attendu est présent, et peuvent simuler un petit parcours, comme l'envoi d'un formulaire. Avantage : on détecte les soucis tôt, même sans visiteurs.
Les mesures réelles observent ce que vivent les vrais utilisateurs. On parle de RUM (Real User Monitoring). Avantage : on voit la réalité selon l'appareil, le réseau et le pays.
Les robots donnent l'alerte. Les mesures réelles montrent qui est touché.
Comment régler des alertes qui servent vraiment ?
Une alerte doit être rare, claire et actionnable, sinon plus personne ne la lit.
Définissez deux niveaux.
L'avertissement. Un indicateur se dégrade. On regarde tranquillement, dans la journée.
Le critique. Un service important ne marche plus. On agit tout de suite.
Prévoyez aussi qui reçoit quoi, et où. L'e-mail suffit pour l'avertissement. Le critique mérite un canal qui interrompt vraiment : SMS, appel ou messagerie instantanée.
Pour les seuils de départ, restez simple :
- Disponibilité : alerte critique dès que la page d'accueil ou le formulaire ne répond plus lors de deux vérifications de suite.
- Temps de réponse : avertissement quand le TTFB dépasse durablement le repère de Google.
- Erreurs serveur : critique quand plus d'une requête sur cent échoue en 5xx pendant plusieurs minutes.
- Erreurs navigateur : avertissement quand un même message touche beaucoup de visiteurs en peu de temps.
Rien n'est figé. Ces repères servent à démarrer, puis on les ajuste avec l'habitude.
Que faire quand une alerte sonne ?
Suivre un chemin court, écrit à l'avance, plutôt qu'improviser.
- Vérifier ce qui a changé récemment : mise en ligne, nouvelle extension, modification de contenu.
- Regarder si le problème est général ou limité à un appareil ou à une région.
- Contrôler les services externes dont vous dépendez : paiement, envoi d'e-mails, réservation.
- Si une cause évidente apparaît, revenir en arrière sur le dernier changement.
- Sinon, réduire la charge en désactivant une fonction non essentielle.
- Informer les personnes concernées : ce qui se passe, l'impact, ce que vous faites.
L'objectif n'est pas de tout résoudre d'un coup. C'est de rétablir le service, puis de comprendre.
Quelles menaces méconnues peuvent faire tomber un site ?
Les pannes les plus graves viennent souvent de failles discrètes, que la surveillance aide à repérer tôt.
Les mots de passe robustes, le certificat SSL et les sauvegardes restent indispensables. Mais plusieurs menaces passent à côté de ces basiques. Pour chacune, je donne le signal à surveiller.
Les modules tiers compromis
Un site repose sur des dizaines de briques externes : extensions WordPress, bibliothèques JavaScript, modules divers. Une seule mise à jour malveillante ou une version obsolète suffit à ouvrir une porte. L'OWASP classe les composants vulnérables et obsolètes parmi les dix risques majeurs des applications web.
Le réflexe. Tenir l'inventaire des extensions et de leurs versions, et être alerté quand une faille connue touche l'une d'elles.
La fraude au dirigeant, dopée à l'IA
Les voix de synthèse et la vidéo truquée rendent les arnaques par téléphone ou visioconférence plus crédibles. Le scénario classique : un faux dirigeant demande en urgence un accès au site ou à l'hébergement.
Le réflexe. Toute demande d'accès sensible se vérifie par un second canal, connu à l'avance. Personne ne transmet un mot de passe sur la seule foi d'un appel.
Les attaques par identifiants réutilisés
Les bases d'identifiants volés circulent. Des robots les testent en masse sur les pages de connexion : c'est le credential stuffing décrit par l'OWASP. Ils testent peu de combinaisons par compte, ce qui les rend discrets.
Le réflexe. Activer la double authentification sur chaque compte d'administration, y compris sur la copie de test. Les clés d'accès (passkeys) suppriment même le mot de passe. Côté surveillance : une alerte sur les pics de connexions échouées.

Les extensions de navigateur détournées
Des extensions gratuites installées pour le SEO, les captures d'écran ou les cookies peuvent être rachetées puis modifiées. Elles lisent alors ce qui passe dans le navigateur, y compris une session d'administration ouverte.
Le réflexe. Limiter les extensions sur les postes qui administrent le site, et relire leurs autorisations de temps en temps.
Les services cloud facturés à l'usage
Les fonctions serverless et les services facturés à la requête sont pratiques. Mal configurés, ils peuvent être détournés : l'attaque devient alors aussi financière, avec des milliers d'exécutions facturées.
Le réflexe. Donner à chaque service les seuls droits nécessaires, et régler une alerte de budget chez votre fournisseur cloud.
Pour aller plus loin, le guide d'hygiène informatique de l'ANSSI reste la référence en français. Nous avons aussi publié une checklist en 7 points pour vérifier si votre entreprise est protégée et un article sur l'importance de la cybersécurité.
Surveiller un site sans pister ses visiteurs, c'est possible ?
Oui : on surveille des pages et des serveurs, pas des personnes.
Ne gardez pas d'e-mails ou d'identifiants en clair dans les journaux techniques. Masquez-les. Limitez la collecte à ce qui sert à résoudre un incident, et fixez une durée de conservation. La CNIL a publié une recommandation sur les mesures de journalisation qui cadre ces pratiques.
Les mesures réelles côté visiteur relèvent aussi des règles de la CNIL sur les cookies et autres traceurs. Plus la surveillance est sobre, plus elle est simple à assumer.
Quels outils choisir pour surveiller son site ?
Quatre briques suffisent, et beaucoup existent en version gratuite.
- Une sonde de disponibilité, qui vérifie vos pages clés à intervalle régulier, depuis plusieurs régions.
- Un collecteur d'erreurs, qui remonte les messages techniques avec leur contexte.
- Un outil de mesure d'expérience, pour la vitesse côté visiteur.
- Un tableau de bord d'une page, qui répond à trois questions : le site est-il disponible, est-il rapide, qu'est-ce qui casse le plus souvent ?

Le plus important n'est pas l'outil. C'est d'installer la base et de la regarder vraiment. Une courte revue mensuelle des tendances suffit souvent : une page qui ralentit, une erreur qui revient, un lien cassé. À chaque revue, une petite action.
Par où commencer ? La checklist de départ
Six actions couvrent l'essentiel pour une PME.
- Choisir deux pages clés : l'accueil et la page qui vous rapporte des clients (formulaire, réservation, paiement).
- Installer une sonde automatique sur ces pages.
- Activer la collecte d'erreurs côté site et côté serveur, avec le contexte utile.
- Régler deux niveaux d'alerte et choisir les bons canaux.
- Activer la double authentification sur tous les comptes d'administration.
- Écrire un petit guide d'incident : qui fait quoi, dans quel ordre, qui prévenir. Puis le tester une fois « à blanc ».
Questions fréquentes
Dois-je surveiller toutes les pages de mon site ?
Non. Commencez par la page d'accueil, le parcours qui génère des demandes ou des ventes, et une page de contenu représentative. Vous élargirez si nécessaire.
Faut-il une astreinte permanente pour un site de PME ?
Pas au début. Réservez les alertes critiques aux pannes qui bloquent tout, et choisissez un canal qui vous prévient vraiment. Testez de temps en temps votre capacité de réaction.
Un site lent mais disponible, est-ce grave ?
Oui, car les visiteurs partent avant d'avoir vu votre offre. La lenteur ne déclenche aucune alerte de panne, c'est pour cela qu'il faut suivre le temps de réponse à part.
Comment améliorer l'uptime de mon site ?
En combinant des mises à jour suivies, des sauvegardes testées, un hébergement adapté au trafic et une surveillance active qui prévient tout de suite. C'est la durée des pannes qui baisse le plus.
Faut-il signer un engagement de disponibilité avec son prestataire ?
C'est utile quand le site porte une part importante de votre activité. Commencez par un objectif interne simple, puis formalisez-le dans votre contrat de maintenance. Pour en parler, voyez notre offre de maintenance de site web.
En résumé
Surveiller son site, ce n'est pas empiler des écrans compliqués. C'est s'assurer que la porte s'ouvre, que la visite est fluide et que les incidents ne durent pas.
Commencez petit. Mesurez la disponibilité, le temps de réponse et les erreurs. Alertez avec parcimonie. Fermez les portes discrètes : modules tiers, comptes sans double authentification, extensions douteuses.
Votre site est ancien et difficile à maintenir ? Une refonte peut repartir sur une base saine. Parlons de votre projet : devis gratuit et sans engagement.
Nicolas Bardot est cofondateur de Najumi, agence web basée à Villeurbanne. Il cadre les projets web en amont et veille à ce que chaque site reste clair, rapide et fiable pour les visiteurs, bien après sa mise en ligne.