▶ Structure technique dédiée — Expertise web & mobile — Basée en France

Site inaccessible : que faire dans les 30 premières minutes

Votre site ne répond plus. Chaque minute compte : perte de chiffre d'affaires, visiteurs détournés, réputation en jeu. Ce guide vous donne un protocole clair pour diagnostiquer, agir et communiquer pendant les 30 premières minutes d'une panne — avant même de faire appel à un prestataire.

Besoin d'une intervention immédiate ?

Diagnostic rapide en 3 étapes (Minutes 0-10)

Avant de toucher quoi que ce soit, prenez 10 minutes pour comprendre ce qui se passe. Un mauvais réflexe à ce stade peut aggraver la situation.

Étape 01

Confirmer que le site est réellement inaccessible

Ce n'est pas toujours une panne. Parfois c'est votre réseau, votre DNS local ou un cache navigateur périmé.

Vérifications :

  • Testez depuis un autre appareil (téléphone en 4G/5G, pas en Wi-Fi).
  • Demandez à un collègue de tester depuis un autre lieu.
  • Utilisez un outil externe (voir section Outils ci-dessous) : si l'outil confirme que le site répond normalement, le problème est local — pas besoin de déclencher l'alerte.

À noter : si le site est accessible sur mobile en 4G mais pas depuis votre bureau, c'est probablement un problème de réseau local, de DNS ou de proxy d'entreprise. Le site lui-même n'est pas en cause.

Étape 02

Identifier le type d'erreur

Ce que vous voyez à l'écran vous indique déjà la direction à suivre. Notez précisément ce qui s'affiche :

  • Page blanche → Erreur PHP fatale ou fichier corrompu. Le serveur fonctionne mais l'application plante.
  • Erreur 500 (Internal Server Error) → Le serveur reçoit la requête mais ne peut pas la traiter. Cause fréquente : code défectueux, dépendance manquante, espace disque plein.
  • Erreur 502 (Bad Gateway) ou 503 (Service Unavailable) → Le serveur web (Apache, Nginx) tourne, mais l'application derrière ne répond pas. Cause fréquente : PHP-FPM qui a crashé, processus saturés, maintenance en cours.
  • Erreur 403 (Forbidden) → Le serveur refuse l'accès. Cause fréquente : permissions fichiers modifiées, .htaccess corrompu, blocage IP.
  • Connexion impossible / timeout → Le serveur ne répond pas du tout. Cause fréquente : serveur éteint, problème réseau, DNS mal configuré.
  • Certificat SSL invalide → Le site essaie de répondre mais le navigateur bloque la connexion. Cause fréquente : certificat expiré, mauvaise configuration Let's Encrypt.

Réflexe essentiel : prenez une capture d'écran de l'erreur exacte avec l'URL visible. Si vous faites appel à un prestataire, cette capture fera gagner un temps précieux.

Étape 03

Identifier ce qui a changé récemment

Dans la grande majorité des cas, une panne n'arrive pas "toute seule". Quelque chose a changé dans les dernières heures ou les derniers jours.

Questions à se poser :

  • Une mise à jour a-t-elle été faite récemment ? (WordPress, plugin, thème, PHP, système)
  • Un déploiement de code a-t-il eu lieu ?
  • L'hébergeur a-t-il envoyé une notification ? (maintenance planifiée, migration, facturation impayée)
  • Le nom de domaine est-il expiré ? (vérifier sur whois.domaintools.com)
  • Un changement DNS a-t-il été effectué ?

Si vous identifiez un changement récent, notez-le. C'est souvent la cause directe, et la résolution consiste à revenir en arrière.

Checklist — Les 15 vérifications des 30 premières minutes

Cochez chaque étape au fur et à mesure. L'ordre compte.

Phase 1 — Confirmer (minutes 0-5)

  • ☑️ Tester le site depuis un autre appareil (mobile en 4G)
  • ◻️ Tester avec un outil externe (downforeveryoneorjustme.com)
  • ◻️ Noter l'heure exacte de début de la panne
  • ◻️ Capturer l'écran d'erreur avec l'URL visible

Phase 2 — Diagnostiquer (minutes 5-15)

  • ◻️ Identifier le code d'erreur (500, 502, 503, 403, timeout, SSL…)
  • ◻️ Vérifier le statut de l'hébergeur (page status officielle)
  • ◻️ Lister les changements récents (mise à jour, déploiement, DNS)
  • ◻️ Vérifier la validité du certificat SSL (sslshopper.com)
  • ◻️ Vérifier la propagation DNS (whatsmydns.net)
  • ◻️ Consulter les logs d'erreur si vous avez un accès

Phase 3 — Agir et communiquer (minutes 15-30)

  • ◻️ Si changement récent identifié : tenter l'annulation
  • ◻️ Contacter l'hébergeur si problème serveur
  • ◻️ Envoyer le message de crise en interne
  • ◻️ Envoyer le message de crise aux utilisateurs si nécessaire
  • ◻️ Si bloqué : transmettre le diagnostic à un prestataire technique

Message de crise prêt à envoyer

Pendant que vous diagnostiquez, vos utilisateurs voient une page d'erreur. Si votre site est utilisé par des clients ou des collaborateurs, communiquez dès que possible — même si vous n'avez pas encore la solution.

Template — Communication interne (équipe / direction)

Objet : [URGENT] Site [nom du site] inaccessible depuis [heure]

Bonjour,

Le site [URL] est inaccessible depuis [heure approximative].

Ce qu'on sait :

  • Type d'erreur observée : [500 / timeout / certificat / page blanche]
  • Le problème affecte [tous les utilisateurs / certains / uniquement en interne]
  • Dernier changement connu : [mise à jour / déploiement / aucun identifié]

Ce qu'on a fait :

  • Vérification externe effectuée → le site est [confirmé down / accessible depuis l'extérieur]
  • Hébergeur contacté : [oui, en attente de retour / non, pas encore]
  • Prestataire technique prévenu : [oui / non / pas de prestataire identifié]

Prochaine mise à jour : dans [30 min / 1 heure].

[Votre nom]

Template — Communication externe (clients / utilisateurs)

Objet : Interruption temporaire de [nom du site/service]

Bonjour,

Nous rencontrons actuellement une interruption technique sur [nom du site].
Nos équipes sont mobilisées pour rétablir le service dans les meilleurs délais.

En attendant, vous pouvez nous joindre par email à [adresse]
ou par téléphone au [numéro].

Nous vous tiendrons informés dès le rétablissement.

Merci de votre compréhension.
L'équipe [nom de l'entreprise]

Conseils

  • Envoyez ce message dans les 15 premières minutes, même si vous n'avez pas encore de solution.
  • Ne donnez pas de délai de résolution que vous ne pouvez pas tenir.
  • Mettez à jour toutes les 30 minutes à 1 heure tant que le problème dure.
  • Si vous avez un réseau social actif, publiez un message court : "Nous sommes informés du problème d'accès à notre site et travaillons à sa résolution. Merci de votre patience."

Outils de vérification rapide

Vous n'avez pas besoin d'être développeur pour utiliser ces outils. Ils sont gratuits, en ligne, et donnent un diagnostic en quelques secondes.

Disponibilité

  • downforeveryoneorjustme.com — Le site est-il accessible depuis l'extérieur ? À utiliser en premier.
  • ping.pe — Accessibilité depuis plusieurs pays + temps de réponse. Utile si le problème semble géographique.
  • Sucuri SiteCheck — Vérification publique de disponibilité et signaux de sécurité côté site.

DNS

  • whatsmydns.net — Propagation DNS dans le monde entier (après un changement DNS/serveur).
  • dnschecker.org — Vérification DNS multi-résolveurs pour confirmer propagation et cohérence des enregistrements.

Performance

  • PageSpeed Insights (Google) — Performance, Core Web Vitals, erreurs de chargement.
  • webpagetest.org — Analyse détaillée des temps de chargement (waterfall, TTFB, rendu).
  • gtmetrix.com — Audit vitesse et recommandations d'optimisation.

Serveur / statut

  • httpstatus.io — Code de réponse HTTP exact (200, 301, 403, 500…).
  • mxtoolbox.com — Outils réseau (DNS, MX, blacklist, tests SMTP) utiles pour valider l'infrastructure et certains blocages.

Monitoring

  • Uptime Robot — Monitoring continu + alertes simples.
  • Better Uptime — Monitoring + incidents + timeline de statut.

Astuce : si le site renvoie un code 200 (OK) sur httpstatus.io mais que vous voyez une erreur dans votre navigateur, le problème est probablement côté client (cache, extensions navigateur, proxy).

Comprendre les erreurs courantes

Chaque code d'erreur raconte une histoire différente. Voici les cas les plus fréquents, ce qu'ils signifient concrètement et ce que vous pouvez tenter.

Erreur 500 — Internal Server Error

Ce que ça veut dire : le serveur a reçu votre requête mais n'a pas réussi à la traiter. C'est l'erreur la plus courante et la plus vague.

Causes fréquentes :

  • Fichier .htaccess corrompu (WordPress/Apache)
  • Plugin ou thème qui provoque une erreur fatale PHP
  • Limite mémoire PHP atteinte
  • Espace disque plein sur le serveur
  • Version de PHP incompatible avec le code

Ce que vous pouvez tenter (si vous avez un accès FTP/SSH) :

  • Renommer le fichier .htaccess en .htaccess_backup → recharger le site
  • Renommer le dossier /wp-content/plugins/ en /wp-content/plugins_disabled/ → recharger
  • Vérifier les logs d'erreurs (emplacement courant : /var/log/apache2/error.log ou dans le panneau de l'hébergeur)

Ce que vous ne devez pas faire :

  • Ne supprimez pas de fichiers sans sauvegarde préalable.
  • Ne changez pas la version de PHP "pour tester" sans savoir ce que ça implique.

Erreur 502 / 503 — Serveur surchargé ou processus down

Ce que ça veut dire : le serveur web (Nginx, Apache) fonctionne mais l'application derrière (PHP-FPM, Node, etc.) ne répond pas.

Causes fréquentes :

  • PHP-FPM qui a crashé ou dont les workers sont saturés
  • Pic de trafic qui dépasse la capacité du serveur
  • Processus bloqué en boucle (requête SQL longue, import massif)
  • Mise à jour système en cours côté hébergeur

Ce que vous pouvez tenter :

  • Si hébergement mutualisé : contacter le support de l'hébergeur (c'est souvent de leur côté)
  • Si serveur dédié/VPS : redémarrer PHP-FPM (sudo systemctl restart php8.x-fpm) si vous avez un accès SSH
  • Vérifier le statut de l'hébergeur (page status ou Twitter de OVH, Scaleway, etc.)

Timeout / Connexion refusée

Ce que ça veut dire : le serveur ne répond pas du tout. Le navigateur attend, puis abandonne.

Causes fréquentes :

  • Serveur éteint ou inaccessible (panne infrastructure, facture impayée)
  • Pare-feu qui bloque les connexions
  • Mauvaise configuration DNS (le domaine pointe vers une IP qui n'existe pas/plus)
  • Attaque DDoS en cours

Ce que vous pouvez tenter :

  • Vérifier la propagation DNS avec whatsmydns.net
  • Vérifier le statut du serveur depuis le panneau de contrôle de l'hébergeur
  • Si VPS/dédié : essayer de se connecter en SSH — si SSH ne répond pas non plus, le serveur est probablement down → contacter l'hébergeur

Certificat SSL invalide / NET::ERR_CERT_DATE_INVALID

Ce que ça veut dire : le certificat de sécurité (HTTPS) a expiré ou est mal configuré. Le site existe toujours mais le navigateur empêche l'accès.

Causes fréquentes :

  • Certificat Let's Encrypt non renouvelé automatiquement (tâche cron cassée)
  • Certificat acheté expiré et non remplacé
  • Mauvaise configuration après changement de serveur

Ce que vous pouvez tenter :

  • Vérifier la date d'expiration du certificat sur sslshopper.com
  • Si Let's Encrypt : relancer le renouvellement (sudo certbot renew) en SSH
  • Si hébergement mutualisé : contacter le support pour forcer le renouvellement

Arbre de décision — Que faire maintenant ?

Après le diagnostic, vous êtes dans l'une de ces situations. Suivez le chemin qui correspond à votre cas.

→ Le site est accessible depuis l'extérieur mais pas depuis votre réseau

C'est un problème local. Videz votre cache DNS (ipconfig /flushdns sur Windows, sudo dscacheutil -flushcache sur Mac). Testez depuis un autre réseau. Si le problème persiste, contactez votre administrateur réseau.

✅ Pas besoin de prestataire.

→ L'erreur est une 500 et vous avez identifié un changement récent

Annulez le changement (restaurer le .htaccess, désactiver le plugin, revenir au commit précédent). Si la restauration résout le problème, documentez ce qui s'est passé et identifiez la cause avant de réappliquer le changement.

✅ Résolvable en autonomie si vous avez un accès FTP/SSH.

→ L'erreur est une 502/503 et vous êtes en hébergement mutualisé

Contactez le support de votre hébergeur. C'est presque toujours un problème de leur côté. Demandez un délai estimé de résolution.

✅ Pas d'action technique de votre part.

→ Le serveur ne répond pas du tout (timeout) et vous n'avez pas d'accès SSH

Contactez votre hébergeur en urgence. Si le serveur est un VPS/dédié géré par un prestataire, contactez ce prestataire. Si personne ne répond dans les 30 minutes, c'est un signal d'alerte sur votre organisation technique.

⚠️ Vous avez besoin d'un intervenant technique.

→ Le certificat SSL est expiré et vous ne savez pas comment le renouveler

C'est une intervention simple mais technique. Si vous n'avez pas d'accès SSH ou si vous ne savez pas utiliser Certbot, faites appel à votre hébergeur ou à un prestataire.

⚠️ Intervention rapide (15-30 min) par quelqu'un qui a les accès.

→ Vous ne comprenez pas l'erreur, vous n'avez pas les accès, ou rien ne fonctionne

Documentez tout ce que vous avez observé (captures d'écran, codes d'erreur, heure de début, changements récents). Transmettez ces informations à un prestataire technique. Plus votre description est précise, plus l'intervention sera rapide et ciblée.

⚠️ Vous avez besoin d'un intervenant technique.

Votre site est en panne et vous êtes bloqué ?

Transmettez code d'erreur, heure de début, changements récents et captures. Nous vous orientons rapidement.

Décrire la situation Appeler directement