Vérifier la disponibilité d’un site web

Vous cliquez sur un lien. La page ne charge pas. Ou pire : votre outil de collecte de données tourne dans le vide depuis une heure et vous ne savez pas pourquoi. Est-ce que le site cible est vraiment hors ligne, ou le problème vient-il de votre côté ?

Ce n’est pas une question anodine. Pour les équipes qui s’appuient sur la collecte de données web — veille concurrentielle, agrégation de prix, suivi de leads — une indisponibilité non détectée, c’est des données manquantes, des pipelines silencieusement cassés, et des décisions prises sur une base incomplète.

Dans cet article, on vous explique comment vérifier si un site web est hors ligne en quelques secondes, comment déterminer si un site est en maintenance ou en panne réelle, et surtout comment les professionnels font pour ne jamais l’apprendre trop tard.

Réponse rapide : comment vérifier la disponibilité d’un site web

La façon la plus rapide de savoir si un site est réellement en panne ou seulement inaccessible depuis votre connexion, c’est d’utiliser un site down checker. Ces services testent l’URL depuis leurs propres serveurs, indépendamment de votre réseau local.

Si ces outils confirment que le site fonctionne, mais que vous n’y accédez toujours pas : le problème vient de votre côté. Voir la section suivante.

« C’est juste moi » — Comment résoudre les problèmes d’accès locaux

Un site est accessible pour tout le monde sauf vous ? Voici les causes les plus fréquentes, dans l’ordre logique à tester :

1. Vider le cache du navigateur

Appuyez sur Ctrl+F5 (Windows) ou Cmd+Shift+R (Mac) pour forcer un rechargement complet. Votre navigateur stocke parfois une version obsolète ou corrompue de la page.

2. Tester un autre navigateur ou le mode navigation privée

Si le site charge sous Chrome mais pas sous Firefox (ou vice versa), une extension ou un cache corrompu interfère. Le mode privé désactive la plupart des extensions automatiquement.

3. Vérifier votre connexion internet

D’autres sites chargent-ils normalement ? Si non, le problème est votre connexion. Essayez :

• Redémarrer votre box ou routeur
• Passer du Wi-Fi aux données mobiles (ou l’inverse)
• Lancer un test de débit sur fast.com

4. Vider le cache DNS

Votre machine conserve un enregistrement local des adresses de sites. Il peut devenir obsolète ou corrompu.

Windows :

ipconfig /flushdns

Mac :

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

5. Changer de serveur DNS

Les serveurs DNS de votre FAI peuvent connaître des dysfonctionnements. Passer sur un DNS public comme Google (8.8.8.8) ou Cloudflare (1.1.1.1) règle souvent le problème. Cherchez « changer serveur DNS » + votre système d’exploitation pour les instructions détaillées.

6. Désactiver votre VPN

Les VPN acheminent votre trafic via des serveurs tiers, ce qui peut provoquer des conflits d’accès. Déconnectez-le temporairement pour vérifier s’il est en cause.

« Le site est vraiment en panne » — Pourquoi les sites tombent

Si le site est inaccessible pour tout le monde, vous ne pouvez pas y remédier vous-même. Mais comprendre les causes permet d’anticiper le temps de rétablissement.

Exemple concret :

Amazon Web Services garantit un taux de disponibilité de 99,99 % sur la plupart de ses services. Cela semble très solide — jusqu’à ce qu’on fasse le calcul : 99,99 % de disponibilité autorise encore 52,6 minutes de coupure par an. AWS héberge environ 30 % de l’infrastructure cloud mondiale et publie des post-mortems détaillés après chaque incident. La leçon n’est pas que les pannes sont acceptables — c’est que même la meilleure infrastructure exige une surveillance active et continue.

Surcharge du serveur

C’est la cause la plus courante. Quand trop d’utilisateurs accèdent simultanément à un site (vente flash, breaking news, buzz viral), les serveurs saturent et cessent de répondre.

Temps de rétablissement habituel : quelques minutes à quelques heures, selon la capacité à scaler l’infrastructure.

Panne de l’hébergeur ou du cloud provider

Les sites tournent sur l’infrastructure d’AWS, Google Cloud, OVHcloud, ou d’autres hébergeurs. Quand ces plateformes ont un problème, tous leurs clients tombent en même temps.

En 2017, une simple faute de frappe lors d’une opération de maintenance chez AWS a paralysé une large partie d’internet, emportant Slack, Quora et Trello dans son sillage. En 2021, une panne chez OVHcloud a affecté des milliers de sites européens en quelques minutes. Ça arrive, même aux meilleurs.

Temps de rétablissement habituel : quelques heures en général. Les grands fournisseurs ont de très forts incitatifs financiers à résoudre les problèmes vite.

Maintenance planifiée

Certaines interruptions sont volontaires. Les équipes techniques mettent le site hors ligne pour déployer des mises à jour, effectuer des migrations de base de données ou faire évoluer l’infrastructure. Les organisations bien rodées planifient ça en dehors des heures de pointe et communiquent en amont.

Temps de rétablissement habituel : généralement annoncé à l’avance sur la page de statut ou les réseaux sociaux.

Cyberattaques (DDoS)

Les attaques par déni de service distribué (DDoS) inondent un site de fausses requêtes jusqu’à l’empêcher de servir les vraies. Elles touchent particulièrement les plateformes de jeux en ligne, les services financiers et les sites à forte exposition médiatique.

Temps de rétablissement habituel : très variable. Certaines attaques sont mitigées en minutes, d’autres persistent plusieurs jours.

Certificat SSL expiré ou domaine non renouvelé

Un site a besoin d’un certificat SSL valide et d’un nom de domaine actif pour fonctionner. Si une équipe oublie de renouveler l’un ou l’autre (c’est plus fréquent qu’on ne le croit), le site devient inaccessible jusqu’à ce que quelqu’un le remarque.

Temps de rétablissement habituel : quelques heures une fois le problème identifié.

Déploiement de code défaillant

Un développeur pousse une mise à jour qui casse quelque chose de critique. Le site fonctionnait parfaitement une heure avant ; depuis le dernier déploiement, il est hors service.

Temps de rétablissement habituel : souvent rapide, car un rollback vers la version précédente suffit généralement.

Comment vérifier si un service spécifique est en maintenance

Les grandes plateformes disposent de pages de statut officielles où elles communiquent sur les incidents en cours. C’est votre premier réflexe quand un service critique ne répond plus :

• Google Cloud : status.cloud.google.com
• Amazon / AWS : status.aws.amazon.com
• Microsoft / Azure : status.azure.com
• Cloudflare : cloudflarestatus.com
• GitHub : githubstatus.com
• OVHcloud : status.ovhcloud.com

Pour les autres services, cherchez « [nom du service] statut » ou « [nom du service] panne » sur X (ex-Twitter) — les équipes y publient généralement des mises à jour en temps réel pendant les incidents. Sur Downdetector.fr, vous pouvez également vérifier si un site est accessible en France à un instant précis.

Pannes FAI en France : Free, Orange, SFR — ce que vous devez savoir

En France, une proportion significative des « sites inaccessibles » ne sont pas des pannes du site lui-même, mais des dysfonctionnements du réseau de votre fournisseur d’accès. C’est l’une des questions les plus fréquemment posées par les utilisateurs français.

Les trois grands FAI — Free, Orange et SFR — ont chacun des antécédents de pannes régionales ou nationales qui rendent temporairement inaccessibles des dizaines de milliers de sites, sans que ces sites soient eux-mêmes en cause.

Astuce : si plusieurs sites non liés tombent en même temps et que votre voisin avec un autre FAI y accède sans problème, la panne est presque certainement chez votre opérateur, pas sur les sites en question. Passer sur vos données mobiles ou un VPN permettra de confirmer.

Quand s’inquiéter — et quand simplement patienter

Pour les responsables de site : quand « est-il en panne ? » devient votre responsabilité

Si vous gérez un site web — qu’il soit petit ou critique pour votre activité — la question change de nature. Vous ne vous demandez plus « est-il en panne ? » Vous vous demandez : « comment le savoir avant mes utilisateurs ? »

Selon une étude Gartner, les pannes informatiques coûtent en moyenne 5 600 € par minute aux entreprises. Is It Down Right Now Pour un site e-commerce en heure de pointe ou une plateforme SaaS dont des clients dépendent, même une interruption de dix minutes peut effacer la marge d’une journée entière.

La France le sait mieux que quiconque. Le 13 octobre 2021, une erreur humaine lors d’une reconfiguration réseau chez OVHcloud a paralysé une large partie du web français. En moins de 30 minutes, plus de 14 000 signalements avaient été recensés sur Downdetector. Pannes Au total, entre 12 000 et 16 000 clients ont été impactés, représentant 120 000 services. Freelance World Parmi les victimes : data.gouv.fr, le site de l’aéroport de Strasbourg, et des centaines de boutiques e-commerce qui ne pouvaient pas vendre.

Et pour les équipes qui s’appuient sur des outils de collecte de données comme Octoparse, 61 % des incidents critiques dans les PME françaises en 2024 ont impliqué des vulnérabilités liées au cloud ou à l’interconnexion d’applications SaaS Twitter — ce qui signifie qu’une panne non détectée se traduit directement par des pipelines silencieusement vides, des analyses faussées, des décisions prises sur des données incomplètes.

La différence entre détecter une panne en 30 secondes et l’apprendre une heure plus tard par un email d’un client mécontent — c’est précisément là que se joue la résilience opérationnelle d’un service numérique.

Des outils comme UptimeRobot, Pingdom ou Better Uptime proposent des offres gratuites ou à faible coût qui suffisent amplement pour les petits sites. Le principe est simple : des checks automatisés toutes les minutes (ou plus fréquemment) et une alerte immédiate dès qu’une anomalie est détectée.

Vos scrapers tombent sans prévenir ?

Octoparse détecte les anomalies dans vos flux de données avant qu’elles n’impactent vos analyses. Alertes en temps réel, reprise automatique, zéro donnée manquante.

→ Essayer Octoparse gratuitement

Comment les professionnels font du monitoring sérieux

Le simple taux de disponibilité (uptime) est le point de départ, mais les équipes techniques sérieuses vont bien au-delà. Voici les métriques qui comptent vraiment :

• Temps de réponse : Temps de réponse du serveur

La durée entre la requête et le premier octet renvoyé par le serveur. Un temps de réponse qui dégrade progressivement est souvent le premier signal d’une surcharge à venir — bien avant que le site ne tombe.

• Taux d’erreurs : Taux d’erreurs HTTP

Tout code HTTP en 4xx ou 5xx signale un dysfonctionnement. Un pic de 500 (Internal Server Error) est souvent annonciateur d’une panne imminente.

• Performance géographique : Performance géographique

Pour les services à audience internationale, la distance physique entre l’utilisateur et le serveur impacte directement la vitesse. Des tests depuis plusieurs zones géographiques permettent de détecter des dégradations locales invisibles depuis un seul point d’observation.

• Débit : Débit (throughput)

Le volume de requêtes traitées avec succès par unité de temps. Une chute soudaine du débit sans baisse du trafic est un signal d’alarme fort.

Le monitoring synthétique : simuler un vrai utilisateur

Le monitoring synthétique consiste à envoyer des utilisateurs virtuels automatisés sur un site pour tester en continu des parcours critiques — sans attendre qu’un vrai utilisateur signale un problème. Pour un site e-commerce, cela peut ressembler à ceci :

• Connexion au compte
• Ajout d’un produit au panier
• Passage en caisse
• Vérification que la confirmation de commande s’affiche correctement

Ce type de surveillance teste également :

• Les endpoints API critiques (disponibilité, temps de réponse, exactitude des données retournées)
• La présence et le bon rendu d’éléments clés de la page (textes, images, liens)
• Les performances de chargement dans des conditions contrôlées et reproductibles

Octoparse : Web Scraping facile pour tous

Télécharger

S'inscrire

Transformer les sites web vers Excel, CSV, Google Sheets ou base de données.

Auto-détecter les sites Web et extraire les données sans aucun codage.

Scraper les sites populaires en quelques clics avec les modèles pré-construits.

Ne se trouver jamais bloqué grâce aux proxies IP et à l’API avancée.

Service Cloud pour programmer le scraping de données.

Le Real User Monitoring (RUM) : ce qui se passe avec vos vrais visiteurs

Contrairement au monitoring synthétique qui simule des comportements, le RUM mesure l’expérience réelle de chaque visiteur :

• Temps de chargement des pages mesuré depuis la requête initiale jusqu’à l’interactivité complète
• Performance de chargement des ressources lourdes (images, scripts, polices)
• Erreurs JavaScript qui ralentissent ou brisent l’affichage côté client

Le monitoring d’infrastructure : la fondation de tout le reste

Le monitoring synthétique et le RUM signalent les symptômes. Le monitoring d’infrastructure diagnostique les causes. Les indicateurs à surveiller :

• Santé des serveurs : CPU, RAM, utilisation disque
• Performance des bases de données : temps de réponse aux requêtes, disponibilité, nombre de connexions actives
• Réseau : latence, perte de paquets

Tous ces facteurs sont interconnectés. Une base de données qui ralentit peut dégrader le temps de réponse du serveur, ce qui finit par provoquer des timeouts, puis une panne complète. C’est pourquoi le monitoring professionnel n’est pas une option : c’est une infrastructure à part entière.

Pour aller plus loin

Un site en panne, c’est rarement un cas isolé. Si vos pipelines de collecte tombent régulièrement, le problème vient souvent d’ailleurs :

• Cloudflare : codes d’erreur et comment les éviter — quand le site est accessible pour tout le monde, sauf votre scraper
• Comment scraper sans être bloqué — parce qu’une IP bannie ressemble exactement à une panne
• Utiliser un serveur proxy pour le web scraping — quand changer de DNS ne suffit plus
• Qu’est-ce que le web scraping ? — poser les bases pour ne plus subir ces interruptions

Maîtriser ces sujets, c’est passer de « mon scraper est cassé » à « je sais exactement pourquoi et comment le relancer en deux minutes ».

Arrêtez de collecter à l’aveugle.

Octoparse surveille vos sources de données 24h/24, détecte les pannes et reprend automatiquement — sans intervention manuelle. Utilisé par des équipes data en France et dans le monde entier.

→ Démarrer votre essai gratuit sur Octoparse.fr

FAQ

• Comment savoir si un site est en panne pour tout le monde ou seulement pour moi ?
• Utilisez un outil comme downforeveryoneorjustme.com, isitdownrightnow.com ou totalbug.com (référence française). Ces services vérifient l’URL depuis des serveurs externes et confirment si le site est globalement inaccessible ou si le problème est limité à votre connexion.
• Pourquoi un site serait-il inaccessible seulement pour moi ?
• Le plus souvent, c’est un problème local : cache navigateur corrompu, DNS obsolète, interférence d’un VPN, connexion internet défaillante, ou parfois un blocage IP si votre adresse a été détectée comme trafic suspect. Videz votre cache, changez de navigateur ou connectez-vous depuis un autre réseau.
• Comment savoir si c’est une panne Free, Orange ou SFR et non le site lui-même ?
• Si plusieurs sites non liés deviennent inaccessibles simultanément depuis votre connexion, vérifiez downdetector.fr/statut/free (ou orange, ou sfr). Si des signalements apparaissent dans les dernières minutes, c’est votre FAI. Confirmer en basculant sur vos données mobiles : si le site charge, c’est bien votre box ou votre opérateur fixe qui est en cause.
• Comment déterminer si un site est en maintenance planifiée ou en panne réelle ?
• Consultez d’abord la page de statut officielle du service (status.monservice.com est le format standard). Les maintenances planifiées sont généralement annoncées à l’avance avec une heure de fin. Une panne réelle se caractérise par une absence de communication initiale, des signalements croissants sur Downdetector.fr, et parfois des messages d’erreur 503 ou 502.
• Combien de temps dure généralement une panne de site ?
• La grande majorité des pannes se règlent en quelques minutes à quelques heures. Les grands services comme Google, AWS ou OVHcloud ont des équipes dédiées et des incitations financières très fortes pour rétablir le service vite. Pour des sites plus petits, ça peut prendre plus longtemps — surtout si le propriétaire n’est pas encore au courant.
• Que signifie une erreur 500 sur un site ?
• Une erreur 500 (ou n’importe quel code commençant par 5) signifie que quelque chose a mal tourné côté serveur — c’est leur problème, pas le vôtre. Vous ne pouvez rien faire d’autre qu’attendre le correctif. Les erreurs en 4xx (comme la 404) indiquent en revanche que la ressource demandée n’existe pas ou que vous n’avez pas les droits d’accès.
• Peut-on savoir pourquoi un site est tombé ?
• Rarement avec certitude depuis l’extérieur, mais certains indices aident. Un pic brutal de signalements sur Downdetector.fr pointe vers une panne généralisée. Une annonce sur la page de statut indique une maintenance planifiée. Une panne courte sans communication est souvent un déploiement raté suivi d’un rollback rapide. Et si des sites concurrents tombent en même temps, c’est probablement une panne d’hébergeur.
• Comment Octoparse gère-t-il les pannes de sites cibles lors d’une collecte de données ?
• Octoparse intègre des mécanismes de reprise automatique et de détection d’erreurs HTTP. Lorsqu’un site cible retourne des codes 5xx ou ne répond plus, le scraper peut être configuré pour mettre en pause la tâche, réessayer après un délai paramétrable, ou déclencher une alerte — évitant ainsi de polluer vos datasets avec des données vides ou incomplètes.