# Comment surveiller son site web : uptime, erreurs et temps de réponse > Votre site peut être beau et bien référencé. Mais s’il tombe en panne, vos visiteurs ne voient rien. > URL : https://najumi.fr/article/comment-surveiller-son-site-web-uptime-erreurs-temps-de-reponse/ --- Développement [![nicolas](https://admin.najumi.fr/uploads/medium_team_1_1_00321a2c01.png?format=webp&width=500&quality=82) Nicolas Bardot Cofondateur de Najumi & Designer](https://najumi.fr/auteur/nicolas-bardot/) Date 25 septembre 2025 Temps de lecture 9 minutes ![Homme analysant les statistiques de son site sur son ordinateur](https://admin.najumi.fr/uploads/medium_employe_modifiant_des_documents_sur_un_ordinateur_de_bureau_au_bureau_min_b4da95b8e8.png?format=webp&width=750&quality=82) ## Introduction Votre site peut être beau et bien référencé. Mais s’il tombe en panne, vos visiteurs ne voient rien. Surveiller l’**uptime** (taux de disponibilité), les **erreurs** et le **temps de réponse** permet d’anticiper les problèmes et d’éviter les pertes de ventes ou de demande de contact. Pas besoin d’être ingénieur pour s’y mettre. Il suffit de quelques indicateurs clairs, d’alertes bien réglées et d’une routine simple quand quelque chose cloche. Dans cet article, on explique tout avec des mots courants. On définit les termes techniques à la première apparition. Et on vous propose une méthode concrète qui marche pour une PME, une association ou un indépendant. ## Pourquoi surveiller ? Une histoire très simple Imaginez une boutique physique. Vous ouvrez à 9 h. La porte doit s’ouvrir (disponibilité). Les clients doivent entrer sans faire la queue dehors (rapidité). Le terminal de carte bancaire doit fonctionner (fiabilité). Un site web, c’est pareil. Si la “porte” ne s’ouvre pas, personne n’achète. Si la page met longtemps à s’afficher, on part. Si le paiement ou le formulaire d’inscription rame, on abandonne. La surveillance sert à voir vite ce qui se passe, pour agir vite. C’est un filet de sécurité qui coûte peu et qui rassure tout le monde. ## Ce qu’il faut regarder (sans se noyer) Trois axes suffisent pour démarrer et couvrir 80 % des cas. **La disponibilité** : est-ce que le site répond, oui ou non. **La rapidité** : en combien de temps la page commence à s’afficher. **Les erreurs** : est-ce que des messages d’erreur techniques apparaissent pour certains visiteurs. On peut ajouter des détails plus tard, mais commencer simple aide à tenir dans le temps. ![Collègues analysant les données de leur site](https://admin.najumi.fr/uploads/homme_d_affaires_regardant_des_graphiques_financiers_min_3b4de3f4b7.png?format=webp&width=1024&quality=82) ### Disponibilité (uptime) L’**uptime** est le pourcentage de temps où votre site répond. Un bon niveau pour une PME est **99,9 %** ou plus sur un mois. Cela veut dire très peu d’interruptions perceptibles. Un outil vérifie régulièrement que votre page d’accueil répond et que la page “critique” répond aussi. On parle parfois d’**URL de santé** (une adresse comme `/health`) qui confirme que tout fonctionne côté serveur. ### Rapidité (temps de réponse) Le **temps de réponse** est le délai entre le clic et les premiers éléments visibles. Un indicateur courant côté serveur est le **TTFB** (Time To First Byte, temps jusqu’au premier octet). On peut aussi suivre l’expérience côté navigateur, par exemple la **réactivité** lorsqu’on clique ou tape. Plus c’est court, plus la visite est agréable. Un site rapide convertit mieux. Il donne aussi une meilleure image de marque. ### Erreurs (pour ne pas jouer aux devinettes) Une **erreur** côté serveur commence souvent par 5xx (ex. 500). Une **erreur** liée au contenu ou à l’adresse est souvent 4xx (ex. 404). Côté navigateur, on peut voir des messages techniques lorsqu’un script se bloque. Pas besoin de lire du code pour s’alarmer. S’il y a trop d’erreurs en peu de temps, c’est un signe. Le but est de **remonter le message**, mais aussi **le contexte** (sur quelle page, avec quel navigateur, à quel moment), pour réparer vite. ## Comment mesurer sans devenir expert Il existe deux approches. Elles se complètent bien. 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 (par exemple “ajouter au panier”). L’avantage est qu’on détecte les soucis tôt, même sans visiteurs. Les **mesures réelles** observent ce que vivent les vrais utilisateurs. On appelle cela **RUM** (Real User Monitoring, mesure côté utilisateur). L’avantage est qu’on voit la réalité selon le pays, l’appareil, la qualité du réseau. Les deux approches se complètent : les robots préviennent, les mesures réelles confirment l’impact. ## Alerter… sans stress Une alerte doit être rare, claire et actionnable. Trop d’alertes, et on ne lit plus rien. Mieux vaut définir **deux niveaux**. Un **avertissement** lorsqu’un indicateur se dégrade, pour regarder tranquillement. Un **critique** lorsqu’un service important ne marche plus, pour agir tout de suite. On prévoit aussi **qui** reçoit quoi, et **où** : e-mail pour l’avertissement, téléphone ou messagerie instantanée pour le critique. Enfin, il faut **un petit guide** relié à chaque alerte : que vérifier, dans quel ordre, qui prévenir. ## Des seuils “de départ” raisonnables Commencez avec des repères simples, puis affinez selon votre activité. **Uptime** : objectif **≥ 99,9 %** sur un mois. **Temps de réponse** au serveur (TTFB) : on commence à surveiller dès **600–800 ms**. On considère “critique” s’il dépasse **1200 ms** pendant plusieurs minutes. **Erreurs côté serveur** : si plus de **1 %** des requêtes finissent en 5xx pendant 5 minutes, c’est sérieux. **Erreurs côté navigateur** : si le même message touche beaucoup d’utilisateurs en peu de temps, il faut creuser. Rien n’est figé. Ces repères servent à démarrer, puis on ajuste avec l’habitude. ## Que faire quand ça sonne : un chemin simple Quand une alerte arrive, pas besoin d’improviser. On suit un chemin court et clair. On vérifie d’abord **ce qui a changé récemment** (mise en ligne, modification d’un texte, ajout d’un outil). On regarde **si le problème est général** ou limité à une région ou à un type d’appareil. On contrôle **les services externes** dont on dépend (paiement, emailing, recherche interne). Si une cause évidente apparaît, on **revient en arrière** sur le dernier changement. Sinon, on **réduit la charge** en désactivant une partie non essentielle. On **informe** les personnes concernées avec un message simple : ce qui se passe, l’impact, ce qu’on fait. L’objectif n’est pas de tout résoudre d’un coup, mais de **rétablir le service** vite, puis d’améliorer. ## Visualiser en un coup d’œil Un bon **tableau de bord** tient sur une seule page. Il répond à trois questions. Est-ce que le site est **disponible**. Est-ce qu’il est **rapide**. Qu’est-ce qui **casse** le plus souvent. Idéalement, on affiche en haut un petit **statut** global par pays ou par produit. En dessous, un graphique qui montre la **latence** moyenne et les cas “lents” pour ne pas oublier les visiteurs en difficulté. À droite, la **liste des erreurs** qui reviennent le plus. En bas, l’état des **dépendances** (paiement, e-mail, recherche). Ce tableau aide en cas de crise, mais il sert aussi au quotidien pour garder le niveau. ![Dashboard Monitoring de site web](https://admin.najumi.fr/uploads/3239755_1_min_6db6deec6d.png?format=webp&width=1024&quality=82) ## Données personnelles : la confiance d’abord Surveiller un site ne veut pas dire suivre des personnes. On ne garde pas les e-mails en clair dans les journaux techniques. On **masque** les identifiants. On **limite** ce qu’on collecte à ce qui est utile pour résoudre un incident. Et on respecte le **RGPD** : information, consentement pour les cookies non essentiels, durée de conservation raisonnable. Plus on est sobre, plus on est serein. ## Choisir ses outils sans se perdre Pas besoin de dix plateformes. Une **sonde d’uptime** pour vérifier à intervalle régulier que les pages clés répondent. Un **collecteur d’erreurs** pour voir les messages techniques avec leur contexte. Un outil de **mesure d’expérience** pour comprendre la vitesse côté visiteur. Et un **tableau de bord** qui rassemble l’essentiel. On peut partir sur des versions gratuites ou peu coûteuses. Le plus important est d’installer la base et de l’utiliser vraiment. On complétera plus tard si besoin. ## Checklist de départ (à cocher) - Vérifier **deux pages clés** : la page d’accueil et la page qui fait gagner de l’argent (ou le formulaire de contact). - Installer une **sonde automatique** toutes les minutes depuis plusieurs régions. - Activer la **collecte d’erreurs** côté site et côté serveur, avec le contexte utile (page, navigateur, moment). - Régler **deux niveaux d’alerte** (avertissement / critique) et choisir les bons canaux. - Créer un **tableau de bord d’une page** avec disponibilité, vitesse et erreurs. - Écrire un **petit guide d’incident** : qui fait quoi, dans quel ordre, qui informer. ## Adapter par pays et par appareil Tout le monde n’a pas la fibre. Certains utilisent des téléphones anciens. Il est utile de regarder séparément la situation sur **mobile** et sur **ordinateur**. Et d’observer les différences par **pays** si vous visez l’international. Une amélioration qui gagne quelques secondes sur mobile peut changer la donne. Elle réduit les abandons, rassure et améliore la conversion. ## Process d’amélioration continue La surveillance n’est pas qu’une alarme. C’est une manière de progresser. Une fois par mois, on regarde les **tendances**. On voit si des pages deviennent plus lentes. On note si un message d’erreur revient. On décide d’une **petite action** à chaque fois : alléger une image, simplifier une animation, corriger un lien cassé. Ce rythme modeste suffit pour garder un site sain sans y passer ses semaines. ## Budget et retour sur investissement La plupart des outils proposent des **offres accessibles**. Le vrai investissement est le **temps d’équipe** pour lire les signaux et agir. On mesure le retour avec des indicateurs simples : moins de pannes, **temps de résolution** plus court, moins d’e-mails “votre site ne marche pas”, plus de formulaires envoyés. Quand on passe de plusieurs heures à moins d’une heure pour régler un incident, tout le monde y gagne. ## Questions fréquentes (FAQ) **Dois-je surveiller toutes les pages ?** Non. Commencez par la page d’accueil, le parcours d’achat ou d’inscription, et une page de contenu représentative. Vous élargirez si nécessaire. **Faut-il une personne d’astreinte 24/7 ?** Pas au début. Réglez des alertes “critiques” uniquement pour les cas qui bloquent tout. Choisissez un canal qui réveille vraiment. Et testez de temps en temps votre capacité de réaction. **Un site lent mais disponible, est-ce grave ?** Oui, car les visiteurs partent. Une amélioration modeste sur le temps d’affichage peut augmenter les demandes de devis ou les ventes. La vitesse est un confort et un levier business. **Doit-on signer un SLA compliqué ?** Un **SLA** (accord de niveau de service) peut venir plus tard avec vos fournisseurs techniques. Commencez par un **objectif interne simple** : disponibilité visée et temps de résolution moyen. ## Plan d’action en 7 jours (démarrage rapide) - **Jour 1** : choisir les pages à surveiller et créer une URL de santé si besoin. - **Jour 2** : installer la sonde d’uptime multi-régions. - **Jour 3** : activer la collecte d’erreurs avec contexte. - **Jour 4** : régler les alertes et définir qui reçoit quoi. - **Jour 5** : construire le tableau de bord d’une page. - **Jour 6** : écrire le petit guide d’incident et faire un test “à blanc”. - **Jour 7** : ajuster les seuils et planifier une courte revue mensuelle. ## Conclusion Surveiller son site, ce n’est pas ajouter 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 ce qui compte. Alertez avec parcimonie. Et mettez en place un rituel simple pour améliorer un peu chaque mois. Avec cette base, votre site gagne en fiabilité. Vos visiteurs le ressentent. Et votre activité y trouve un vrai bénéfice durable. Najumi, l'agence digitale qui crée votre site web sur-mesure Attirez plus de clients avec un site web performant pensé pour convertir Réponse sous 24h - sans engagement Suggestion ## Vous pourriez aussi aimer [![Hacker qui est au téléphone sur son ordinateur](https://admin.najumi.fr/uploads/medium_pirate_avec_ordinateur_portable_1_min_0f6bc9c1de.png?format=webp&width=750&quality=82) 27 juin 2025 ## Cybersécurité 2026 : ces 5 menaces méconnues qui peuvent ruiner votre site Les attaques informatiques ne cessent d’évoluer, mais la plupart des équipes web se focalisent encore sur les mêmes basiques Lire le post Développement](https://najumi.fr/article/cybersecurite-2025-menaces-meconnues-ruiner-site/) [![Deux personnes se tournent vers l'utilisateur en se questionnant dans un environnement numérique](https://admin.najumi.fr/uploads/medium_data_scientists_performing_equipment_vulnerability_scans_server_farm_min_9a534afca1.png?format=webp&width=750&quality=82) 25 sept. 2025 ## Votre entreprise est-elle vraiment protégée ? 7 points à vérifier tout de suite Avez-vous déjà pris du recul sur les risques qui peuvent impacter votre entreprise aujourd’hui ? Lire le post Développement](https://najumi.fr/article/votre-entreprise-protegee-7-points/) [![Anonymous tenant un pétard](https://admin.najumi.fr/uploads/medium_unsplash_XTLISGA_Nyy8_min_3f5a9d5ded.png?format=webp&width=600&quality=82) 11 févr. 2025 ## L'importance de la cybersécurité dans le monde numérique moderne Un article mettant en lumière l'importance de la cybersécurité dans notre société actuelle Lire le post Développement](https://najumi.fr/article/importance-de-la-cybersecurite/) 2 projets disponibles ce mois-ci ## Discutons de votre projet Réservez 30 minutes avec Mathis. Nous analysons votre situation et nous vous proposons une solution adaptée. ![Avatar de Mathis Haumont](https://najumi.fr/_astro/mathis_linkedin.DzokqiJE_Z1gtodq.png) 30min avec Mathis Sans engagement ![Bureau de l'agence Najumi à Villeurbanne (Métropole de Lyon)](https://najumi.fr/_astro/contact-min.B43tq0Gr_Zj7Yja.png)