Site en panne : le protocole des 60 premières minutes

Un site en panne, ce n’est presque jamais une ligne de code : c’est un téléphone qui sonne, un formulaire qui ne rentre plus, et trois personnes qui proposent trois manipulations différentes en même temps. La règle qui sauve le plus de sites n’est pas technique, elle est comportementale : ne rien casser de plus que ce qui est déjà cassé. Cet article suit le protocole que nous appliquons en intervention, en trois temps : constater, isoler, réparer. Aucune de ces étapes ne demande de supprimer quoi que ce soit.

Avant tout : ne touchez à rien pendant cinq minutes

La plupart des pannes que nous reprenons se sont aggravées dans le quart d’heure suivant leur apparition : quelqu’un a supprimé une extension au lieu de la désactiver, ou vidé le cache serveur juste avant que le journal d’erreurs ne soit lu. La cause a disparu, la panne est restée. Trois réflexes, avant toute manipulation, divisent par deux le temps de diagnostic :

• Noter l’heure exacte du premier symptôme. Pas « ce matin » : « 9 h 42 ». Les journaux se lisent par horodatage, et la minute près suffit à isoler la bonne ligne parmi des milliers.
• Noter la dernière action effectuée sur le site. Mise à jour, publication, modification de zone DNS, changement d’offre chez l’hébergeur. Le plus souvent, la cause tient dans cette phrase.
• Capturer le message affiché, en entier, adresse comprise. Il disparaît dès qu’un cache est vidé, et il ne revient pas toujours.

Identifier le symptôme exact

Un site ne tombe pas « en panne » : il tombe d’une façon précise, qui désigne déjà une famille de causes.

Écran blanc ou page vide

C’est une erreur PHP fatale que le serveur a choisi de ne pas afficher : extension incompatible, mémoire PHP insuffisante, module PHP disparu après une montée de version côté hébergeur. Pour transformer ce vide en message lisible, ajoutez ces trois lignes dans wp-config.php, avant le commentaire « C’est tout, ne touchez pas à ce qui suit ! » :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Le journal se remplit dans wp-content/debug.log et la dernière ligne « Fatal error » donne le fichier fautif, donc le nom de l’extension. La troisième constante évite d’exposer vos chemins serveur aux visiteurs pendant que vous cherchez (documentation WordPress sur le débogage).

« Il y a eu une erreur critique sur ce site »

Message natif de WordPress depuis la version 5.2. Le site n’est pas perdu : WordPress a détecté l’erreur, mis en pause le composant fautif et envoyé un lien de récupération par courriel, qui ouvre un tableau de bord dégradé désignant le coupable. Si personne ne voit jamais ce courriel, c’est qu’il part vers l’adresse d’administration renseignée dans Réglages puis Général, souvent celle du prestataire précédent, et qu’il finit dans les indésirables. Le lien reste valable vingt-quatre heures par défaut, et WordPress n’en envoie qu’un par jour.

Erreur 500 ou 503

Le problème est côté serveur, et le navigateur ne dit rien d’utile : la vraie information est dans le journal d’erreurs de l’hébergeur. Regardez ensuite le .htaccess à la racine, souvent réécrit par une extension de cache, puis les limites de ressources de votre offre. Si l’erreur arrive par vagues plutôt qu’en continu, ce n’est pas une panne mais une saturation : voir le diagnostic d’un site lent ou saturé.

« Erreur lors de la connexion à la base de données »

Quatre causes : identifiants modifiés, service de base arrêté, serveur saturé, table corrompue. Les identifiants se lisent dans wp-config.php, sur DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Ne les modifiez pas avant d’avoir demandé à l’hébergeur si le service tourne : une fois sur deux, ils sont bons et c’est le serveur qui ne répond pas. Réécrire un mot de passe correct par un mot de passe faux ajoute une panne à la panne.

Le site s’affiche, mais complètement déstructuré

Texte brut, images empilées : les feuilles de style ne se chargent pas. Quatre suspects : l’adresse de site enregistrée en base qui ne correspond plus à l’adresse réelle, un certificat expiré, du contenu appelé en HTTP dans une page HTTPS, un cache serveur corrompu. Le certificat mérite une mention à part : expiré, il ne dégrade pas l’affichage, il rend le site inaccessible derrière un avertissement rouge. Les certificats gratuits se renouvellent tous les trois mois, et un renouvellement automatique qui échoue en silence est une panne banale.

Les quatre vérifications qui règlent la moitié des cas

Avant de toucher au moindre fichier, quatre contrôles gratuits, dix minutes.

1. Domaine, certificat, facture. Un domaine expiré coupe le site et la messagerie d’un coup, ce qui rend le diagnostic déroutant. Vérifiez l’expiration chez votre bureau d’enregistrement, la validité du certificat dans le cadenas du navigateur, l’état des factures. Une facture impayée depuis trois semaines est une cause de panne banale.
2. La page d’état de l’hébergeur. Si un incident y est déclaré, arrêtez de chercher : toute manipulation faite pendant l’incident brouillera le diagnostic ensuite.
3. La panne est-elle visible depuis ailleurs ? Testez depuis un téléphone en données mobiles, Wi-Fi coupé, en navigation privée. Si le site s’affiche, le problème est local : cache du navigateur ou résolution DNS de votre réseau.
4. Une mise à jour a-t-elle eu lieu dans les vingt-quatre dernières heures ? WordPress applique les correctifs mineurs du cœur automatiquement, et beaucoup d’extensions s’actualisent seules. La liste se lit dans Tableau de bord puis Mises à jour. Si oui, suivez plutôt la marche à suivre après une mise à jour qui casse le site.

Isoler la cause sans rien supprimer

Quand ces contrôles ne donnent rien, il faut isoler : couper large, constater, rétrécir par moitiés. Un seul verbe est autorisé, renommer, jamais supprimer. Une extension supprimée emporte parfois ses données ; désactivée, elle ne perd rien.

Par FTP ou depuis le gestionnaire de fichiers de l’hébergeur, renommez le dossier wp-content/plugins en plugins-off : WordPress ne trouve plus aucune extension et les désactive toutes, sans perdre leurs réglages. Si le site revient, la cause est là. Remettez le nom d’origine, puis réactivez par moitiés : avec vingt-quatre extensions, la dichotomie désigne la coupable en cinq essais. Même logique pour le thème, en renommant son dossier dans wp-content/themes. Avec un accès SSH, WP-CLI fait la même chose plus proprement :

wp plugin deactivate --all
wp theme activate twentytwentyfour
wp plugin activate nom-de-l-extension

Remettre en ligne proprement plutôt que vite

Remettre un site debout et le remettre en état sont deux choses différentes : un site qui s’affiche parce que l’extension de paiement est désactivée n’est pas réparé, il est amputé. Listez ce qui a été désactivé avant de déclarer l’incident clos.

La restauration d’une sauvegarde est un choix, pas un bouton magique : elle vous ramène au jour de la sauvegarde, et les commandes reçues depuis sont perdues. Indolore sur un site vitrine, une restauration à vingt-quatre heures efface une journée de ventes sur une boutique. Posez la question avant de cliquer : que perd-on exactement ?

Pendant l’intervention, servez une page de maintenance plutôt qu’une erreur brute, et une page qui répond en code 503 avec un en-tête Retry-After. C’est ce que fait WordPress pendant ses propres mises à jour, via le fichier .maintenance, qui renvoie un 503 Service Unavailable avec un Retry-After: 600. Une page de maintenance qui répond 200 raconte aux moteurs que ce contenu vide est la version définitive de votre page d’accueil : c’est ainsi que l’on perd du référencement pendant une panne, pas à cause de la panne elle-même.

Après la panne : le compte rendu qui évite la récidive

Une panne réparée sans compte rendu se reproduira, parce que personne ne saura ce qui avait été fait. Cinq lignes, écrites le jour même :

• Symptôme : ce qui était visible, et depuis quelle heure.
• Cause identifiée : l’extension, la version de PHP, le certificat, le quota.
• Correction appliquée : ce qui a été modifié, désactivé ou restauré.
• Conséquence sur les données : ce qui a été perdu, et sur quelle plage horaire.
• Mesure de prévention : ce qui empêchera la même panne de revenir.

Sur cette dernière ligne, trois mesures reviennent toujours. Une sauvegarde stockée hors du serveur principal et restaurée au moins une fois, parce qu’une sauvegarde jamais testée n’est qu’une hypothèse. Une préproduction, pour qu’aucune mise à jour ne se joue en direct. Une supervision qui teste le site chaque minute : c’est la différence entre apprendre la panne par un outil à 3 h 12 et par un client mécontent à 10 h 30. Ces fondations sont détaillées dans les huit mesures de sécurité essentielles et dans ce qui arrive quand la maintenance est ignorée.

Notre position : à partir de quand il faut passer la main

Nous ne pensons pas qu’un dirigeant doive apprendre à déboguer PHP, mais qu’il doit reconnaître le moment où continuer seul coûte plus cher que d’appeler. Cinq critères, sans ambiguïté :

• Trente minutes sans le moindre progrès sur le diagnostic.
• La panne touche la base de données, où les erreurs sont irréversibles.
• Redirections inconnues, pages étrangères, comptes administrateurs que vous n’avez pas créés : ce n’est plus une panne mais une intrusion (fiche réflexe Cybermalveillance.gouv.fr).
• Le site vend, et nous sommes en pleine journée.
• Aucune sauvegarde récente n’existe, ou personne ne sait si elle fonctionne.

Ce que fait une assistance technique par tickets : prise en charge horodatée, accès sécurisés puis révoqués, diagnostic documenté plutôt qu’une série d’essais, remise en ligne, rapport écrit. C’est ce dernier point qui sépare une intervention d’un dépannage : après un dépannage vous êtes de nouveau en ligne, après une intervention vous savez pourquoi vous étiez tombé. Chez nous, un ticket d’assistance est à 89 € et le pack de cinq tickets à 399 € (TVA non applicable, art. 293 B du CGI) : un prix fixe plutôt qu’un taux horaire, parce que quand un site est à terre, personne n’a envie de surveiller le compteur.

Conclusion

La panne n’est jamais le vrai problème : le vrai problème, c’est l’absence de filet. Sans sauvegarde testée, sans préproduction et sans supervision, le moindre incident devient une catastrophe ; avec les trois, il devient une parenthèse de vingt minutes. Si vous lisez ces lignes avec un site à terre, commencez par les quatre vérifications : une fois sur deux, elles suffisent.

À lire aussi : sécuriser un site WordPress pas à pas et des sauvegardes réellement testées

Ouvrir un ticket d’assistance Faire diagnostiquer mon site