Un site qui tombe en panne ne prévient jamais. On clique, la page reste blanche, et le téléphone devient soudain très tentant. Sauf qu’appeler un pro dans les trois premières minutes coûte souvent cher pour rien, alors que dix minutes de vérifications calmes suffisent à savoir si le problème vient de vous, de l’hébergeur ou d’une vraie attaque. Voici le protocole que je déroule avant de décrocher le combiné, et les cas précis où il faut au contraire appeler tout de suite.
D’abord, savoir si la panne vient de vous ou du site
La première erreur, c’est de supposer que le site est mort alors que c’est votre connexion, votre navigateur ou un cache local qui joue des tours. Avant de paniquer, ouvrez le site sur un autre navigateur : si vous êtes sur Chrome, essayez Firefox.
Ensuite, passez en navigation privée avec Ctrl+Shift+N, parce qu’un cache saturé ou un cookie corrompu peut afficher une page blanche qui n’existe que pour vous. Testez enfin depuis votre téléphone en 4G, et surtout pas en wifi : si le site s’affiche en 4G mais pas sur votre poste de bureau, le problème est dans votre réseau local, pas chez l’hébergeur.
Dernier test, le plus bête et le plus efficace : demandez à un collègue ou à un ami d’essayer d’accéder au site depuis chez lui. S’il le voit normalement, vous perdez cinq minutes à chercher une panne qui n’existe pas. Si personne n’y arrive, vous tenez une vraie panne, et là seulement commence le diagnostic sérieux.
Ce qu’il faut regarder dans l’interface d’hébergement
Une fois la panne confirmée, direction le tableau de bord de votre hébergeur, que ce soit cPanel, Plesk ou une interface maison. C’est là que dorment les indices, et c’est souvent la partie que les non-techniciens sautent alors qu’elle prend deux minutes.
Cherchez d’abord les alertes : un bandeau de maintenance, une notification de panne côté serveur, ou un avertissement de dépassement de ressources. Ces messages expliquent à eux seuls une bonne partie des coupures, et ils vous évitent de chercher plus loin.
Ensuite, ouvrez la section des ressources : processeur, mémoire vive, espace disque. Si l’une de ces jauges est collée à son maximum, vous avez votre cause probable, et ce n’est pas votre code qu’il faut réparer mais votre consommation. Terminez par les logs d’erreur, sous « Error Log » ou « Logs » selon l’interface. Faites défiler jusqu’aux dernières lignes qui correspondent à l’heure exacte de la panne : c’est là qu’apparaît le nom du fichier ou du module fautif.
Vérifier tout ça soi-même prend un quart d’heure, et ça change la conversation avec le prestataire. Au lieu de dire « mon site ne marche plus », vous dites « erreur 500 depuis 14 h 20, logs PHP sur le fichier functions.php ». Le diagnostic part déjà plus vite, et la facture aussi. Pour comprendre comment un prestataire sérieux travaille ce genre de situation, jetez un œil à miridan-web.fr, on y voit la logique de prise en charge.
Les gestes à faire dans la première heure
Notez l’heure exacte et la nature de la panne, à la minute près. Cette information paraît anodine, elle sert ensuite à croiser les logs du serveur avec votre chronologie, et sans elle vous naviguez à l’aveugle. Capturez tout ce que vous voyez : screenshots des messages d’erreur, codes HTTP affichés, extraits des journaux applicatifs. Une capture vaut mieux qu’un souvenir approximatif trois heures plus tard.
Identifiez le périmètre avant de toucher à quoi que ce soit. Est-ce que tout le site est tombé, ou seulement une fonctionnalité comme le formulaire de contact ou le tunnel de paiement ? Est-ce que tout le monde est bloqué, ou seulement les visiteurs d’une zone géographique précise ? La réponse oriente complètement le diagnostic, et elle évite de chercher au mauvais endroit pendant une heure. Sur ce point, voir aussi notre article sur nom entreprise libre delai.
Les cas qui imposent de ne rien toucher
Il y a des situations où le réflexe de bricoleur devient destructeur. Supprimer un plugin, redéployer une version, restaurer une sauvegarde : chacun de ces gestes peut effacer les preuves dont l’expert a besoin, ou écraser des données encore récupérables.
Le cas le plus net est celui d’une redirection vers un site suspect : c’est un piratage, et tant que le nettoyage n’a pas commencé, les traces du pirate restent exploitables. Voici les cas où l’on s’arrête net et où l’on décroche le téléphone.
- Une redirection vers un domaine inconnu ou un site douteux : c’est un piratage, on ne touche à rien et on appelle immédiatement.
- L’application métier ne démarre plus du tout, alors que le reste du site fonctionne.
- Des données récentes ont disparu ou sont corrompues, et vous doutez que la sauvegarde disponible soit réellement restaurable dans cet état.
- Le tunnel de paiement est cassé, ce qui signifie que des clients essaient de commander et échouent en silence.
- Le prestataire ne répond pas, ou tarde à communiquer un délai de rétablissement.
Dans ces cinq cas, chaque minute passée à bricoler détruit de la valeur. Le doute sur la sauvegarde est particulièrement révélateur : si personne ne peut vous dire quand elle a été faite et ce qu’elle contient exactement, vous n’avez pas de sauvegarde, vous avez un fichier.
Lire les symptômes pour orienter le diagnostic
Chaque panne a une signature, et apprendre à la lire fait gagner un temps précieux. Une page blanche ou une erreur 500 signale presque toujours un problème PHP : un plugin incompatible, un fichier mal fermé. Un « Site down » ou un « 502 Bad Gateway » pointe vers un serveur surchargé ou un processus PHP qui plante.
Une erreur 404 sur toutes les pages, y compris celles qui marchaient hier, sent le fichier .htaccess corrompu ou une base de données inaccessible. L’impossibilité de se connecter à l’admin, elle, évoque une attaque par force brute ou un conflit de plugins.
Ces correspondances ne sont pas des certitudes, ce sont des directions. Un site lent mais accessible, par exemple, peut venir d’une surcharge passagère, d’une base de données qui rame ou simplement d’images trop lourdes. Le degré d’urgence varie donc énormément d’un cas à l’autre : une page blanche sur un site vitrine peut attendre le lendemain matin, un tunnel de paiement cassé un vendredi après-midi ne peut pas.
Ce qui se joue vraiment dans la première heure
La panne elle-même n’est jamais le pire qui puisse arriver. Le pire, c’est ce qu’on fait pendant les trente minutes qui suivent, quand la panique pousse à cliquer partout. Vérifier d’où vient le problème, lire les logs, noter l’heure, capturer les erreurs : ces gestes simples transforment une urgence floue en problème documenté, et un problème documenté se résout bien plus vite. Demander un point écrit au prestataire, avec statut, délai et état des sauvegardes, vous donne aussi une trace si la relation tourne mal.
Reste une question à se poser à froid, une fois le calme revenu : si votre site tombait demain à la même heure, sauriez-vous en dix minutes si c’est vous, l’hébergeur ou un pirate ?
