Site inaccessible : l'arbre de décision complet

Le problème : un message qui ne dit rien

Chrome affiche “Ce site est inaccessible”, Firefox préfère “Impossible d’accéder à ce site” ou “Délai de connexion dépassé”. Dans les deux cas, c’est le même message vide de sens : il ne dit ni où est le problème, ni qui doit le régler. Ton appareil ? Ta box internet ? Le DNS de ton domaine ? Le serveur d’hébergement ? Le certificat SSL qui a expiré ?

Bonne nouvelle : ce message générique cache en réalité un nombre limité de causes, et chacune se diagnostique en quelques minutes avec des outils gratuits. Pas besoin d’être développeur pour trancher — juste suivre l’arbre de décision dans l’ordre, du plus probable (et du plus simple à vérifier) au plus technique.

Pourquoi ce message ne dit rien

Le navigateur affiche ce texte générique parce qu’il ne sait pas lui-même où la chaîne s’est cassée. Entre le moment où tu tapes une adresse et celui où la page s’affiche, il y a cinq étapes qui peuvent toutes échouer séparément :

• Ton appareil ou ton navigateur — cache corrompu, extension qui bloque, VPN mal configuré
• Ton réseau local — Wi-Fi instable, box en carafe, DNS de ton opérateur qui déconne
• La résolution DNS — le nom de domaine ne pointe plus vers la bonne adresse IP
• Le serveur d’hébergement — panne, surcharge, pare-feu qui bloque ton IP
• Le certificat SSL — expiré, mal installé, chaîne de certification incomplète

L’astuce, c’est de tester chaque couche dans l’ordre logique, en éliminant d’abord ce qui ne dépend que de toi avant de soupçonner l’hébergeur ou le domaine.

1. Élimine ton propre appareil et réseau

C’est l’étape la plus rapide et la plus souvent ignorée. Avant de crier au bug serveur :

• Teste le site depuis un autre appareil (ton téléphone en 4G, pas en Wi-Fi)
• Ouvre le site dans une fenêtre de navigation privée — ça élimine le cache et les extensions
• Désactive temporairement ton VPN ou proxy si tu en utilises un
• Vérifie que ce n’est pas seulement CE site qui déconne : ouvre google.com

Si le site s’affiche normalement depuis ton téléphone en 4G, le problème est chez toi (box, DNS de ton FAI, cache local) — pas côté site. Vide le cache DNS de ton ordinateur (ipconfig /flushdns sous Windows, sudo dscacheutil -flushcache sous macOS) et réessaie.

2. Confirme que ce n’est pas que toi : isitdown

Si le problème persiste sur plusieurs appareils et réseaux différents, va sur un service comme isitdown.re ou équivalent (“down for everyone or just me”). Tu colles ton nom de domaine, et l’outil teste l’accès depuis ses propres serveurs, indépendamment de ta connexion.

• Si l’outil dit que le site est down pour tout le monde → le problème est bien côté site (DNS, serveur ou SSL). Passe à l’étape 3.
• Si l’outil dit que le site fonctionne → le problème reste localisé chez toi ou ton FAI. Change de réseau, redémarre ta box, ou contacte ton opérateur.

3. Vérifie le DNS avec ping et dig

Le DNS, c’est l’annuaire qui traduit ton nom de domaine (exemple.fr) en adresse IP. Si cette traduction est cassée ou obsolète, le navigateur ne sait littéralement pas où aller.

Avec ping (dans un terminal, Windows/macOS/Linux) :

ping exemple.fr

Si tu obtiens “Impossible de trouver l’hôte” ou un timeout total, le DNS ne résout pas — ou plus rien ne répond à cette adresse.

Avec dig (plus précis, sur macOS/Linux ou via un outil en ligne type MXToolbox) :

dig exemple.fr

Compare l’IP retournée avec celle réellement configurée chez ton hébergeur. Un décalage signifie souvent qu’une migration récente n’a pas été propagée, ou qu’une zone DNS a été mal modifiée. C’est exactement le sujet traité dans notre guide sur les DNS qui ne propagent pas — utile si tu viens de changer d’hébergeur ou de registrar. Si tu as justement changé d’hébergeur récemment, vérifie aussi que la migration a été faite sans perdre le référencement — un DNS mal basculé peut aussi faire chuter les positions.

4. Vérifie que le serveur répond vraiment

Le DNS pointe au bon endroit, mais rien ne charge ? Le problème se situe côté serveur. Plusieurs symptômes distincts :

• Timeout complet, aucune réponse → le serveur est probablement down, surchargé, ou un pare-feu bloque ton IP (fréquent après plusieurs tentatives de connexion échouées, notamment en SSH)
• Erreur 502, 503 ou 504 → le serveur répond, mais mal. Ce sont trois erreurs différentes : la 502 Bad Gateway signale un problème de communication entre le proxy et l’origine, la 503 indique un service temporairement indisponible (souvent une surcharge), et la 504 Gateway Timeout signifie que le serveur d’origine a mis trop de temps à répondre
• Erreur 523 “Origin Is Unreachable” (si tu utilises Cloudflare) → Cloudflare ne parvient pas à joindre ton serveur d’origine, souvent un souci de configuration DNS ou de pare-feu côté hébergeur — détail complet dans notre article sur l’erreur 523 Cloudflare
• Erreur 500 → le serveur répond, mais une erreur applicative bloque tout, à diagnostiquer dans les logs (guide complet erreur 500)

À ce stade, connecte-toi au panel de ton hébergeur (cPanel, Plesk, ou l’espace client) pour voir s’il signale une panne ou une maintenance en cours.

5. Quand ça vient de la surcharge des ressources serveur

Si le site charge par intermittence, ou plante uniquement aux heures de pointe, la cause fréquente est un dépassement des ressources PHP allouées. Trois directives à connaître :

• memory_limit : la mémoire max qu’un script PHP peut utiliser. Trop bas → écran blanc ou erreur “Allowed memory size exhausted”. À régler dans wp-config.php ou le php.ini de l’hébergeur. Valeur de départ raisonnable : 256M.
• max_execution_time : le temps max qu’un script peut tourner avant d’être coupé. Trop bas → timeout sur les pages lourdes ou les imports. À régler dans php.ini ou .htaccess. Valeur de départ : 60 secondes.
• max_input_vars : le nombre max de champs qu’un formulaire peut envoyer. Trop bas → formulaires complexes qui ne s’enregistrent pas. Valeur de départ : 3000.

Le détail complet de chaque directive (avec les autres, post_max_size, upload_max_filesize) est dans notre guide des directives PHP WordPress.

6. Vérifie le certificat SSL

Si tu vois un avertissement “connexion non privée” plutôt qu’un vrai “site inaccessible”, c’est un problème de SSL, pas de serveur. Le symptôme classique : NET::ERR_CERT_DATE_INVALID signale un certificat expiré — cause fréquente et facile à corriger, détaillée dans notre article sur le certificat SSL expiré.

Tableau récapitulatif

FAQ

Quand passer la main à un pro

Si après ces cinq étapes le site reste inaccessible, ou si tu n’as plus accès ni au panel d’hébergement ni au registrar du domaine, ne perds pas de temps à chercher seul plus loin. C’est le moment de faire intervenir quelqu’un qui a les accès techniques (SSH, logs serveur, configuration DNS) et l’habitude de ce genre de pannes — surtout si le prestataire d’origine ne répond plus, un cas fréquent traité dans notre guide sur la récupération d’un site après un prestataire disparu. Un diagnostic mal posé fait perdre des heures ; un diagnostic bien posé, cinq minutes.