Erreur critique WordPress : que faire ?

« Il y a eu une erreur critique sur ce site. » Ce message s'affiche à la place de votre page : WordPress a rencontré une erreur PHP fatale et interrompt l'affichage plutôt que de montrer une page à moitié construite. L'erreur arrête l'exécution du code, elle ne supprime pas de contenu à elle seule, et la cause se trouve en général dans une extension, un thème ou un réglage de l'hébergement.

Ce guide part de deux éléments concrets que vous avez sous les yeux : le message affiché et l'e-mail de récupération que WordPress envoie à l'administrateur. Vous y trouverez ce que la documentation officielle dit du mode de récupération, un tableau des causes, la marche à suivre dans l'ordre, un calcul illustratif de la durée d'indisponibilité, le relevé de recherche des expressions liées et sept réponses aux questions courantes.

Que faire, dans l'ordre

1. Lire le message et chercher l'e-mail de récupération. Ouvrez la boîte de l'adresse d'administration du site, courrier indésirable compris. L'e-mail décrit le problème et contient le lien secret du mode de récupération : c'est l'indice le plus rapide, car il évite de tester au hasard.

2. Ouvrir le lien et se connecter. Le lien dépose un cookie sur votre poste, puis WordPress vous demande de vous connecter. Un bandeau signale que le mode est actif et liste les extensions ou thèmes mis en pause, avec l'erreur qui leur est associée.

3. Choisir entre désactiver, corriger ou contacter l'auteur. Désactiver l'extension est la solution immédiate, parfois temporaire. La corriger demande des compétences techniques. Écrire à son auteur avec le message d'erreur exact reste la voie la plus propre quand l'extension est indispensable.

4. Sans e-mail, désactiver les extensions par les fichiers. Depuis un accès FTP ou le gestionnaire de fichiers de l'hébergeur, renommer le dossier wp-content/plugins met toutes les extensions hors service d'un coup. C'est une pratique courante des techniciens, que les pages officielles consultées ne décrivent pas. Si le site revient, rendez son nom au dossier puis réactivez les extensions une par une depuis l'administration jusqu'à retrouver la fautive.

5. Lire le journal plutôt que deviner. Le manuel de développement WordPress indique que WP_DEBUG vaut false par défaut, que WP_DEBUG_LOG écrit les erreurs dans wp-content/debug.log et reste sans effet si WP_DEBUG n'est pas activé, et que WP_DEBUG_DISPLAY affiche les erreurs à l'écran par défaut. Les valeurs s'écrivent sans guillemets : la chaîne false entre guillemets est comprise comme vraie. Le même manuel ne recommande pas ces outils sur un site en production et demande une sauvegarde ou un site de test d'abord.

6. Restaurer une sauvegarde en dernier recours. Si rien ne suffit, revenir à la dernière version qui fonctionnait est la solution la plus sûre, à condition que la sauvegarde soit récente et déjà testée.

Toucher aux fichiers techniques d'un site en production peut aggraver la panne : au moindre doute, confiez l'intervention à quelqu'un qui connaît ce type d'incident.

Ce calcul est illustratif : il suppose 200 visites par jour réparties régulièrement, soit environ 8,3 par heure, ce qui ne correspond à aucun site réel. Sa leçon est ailleurs : le temps de rétablissement dépend moins de la compétence technique que de deux préparatifs faits avant la panne, une adresse d'administration qui fonctionne et une sauvegarde récente.

Les volumes sont faibles : ils ne justifient pas à eux seuls un long article. L'intérêt de la page est ailleurs, auprès de l'internaute qui tape le message affiché à l'écran en pleine panne et cherche une marche à suivre fiable. Le relevé montre aussi que la recherche autour de la sauvegarde pèse davantage que celle de l'erreur elle-même, ce qui rappelle que la préparation compte plus que la réparation.

Plan d'action en cinq points

Avant la panne. Contrôlez l'adresse e-mail d'administration dans les réglages, faites une sauvegarde avant chaque mise à jour et conservez un accès aux fichiers du site. Mettez à jour les extensions une par une plutôt que toutes ensemble : en cas d'erreur, la coupable est connue.

Pendant la panne. Cherchez l'e-mail de récupération, ouvrez le lien, notez l'erreur exacte affichée dans le bandeau, puis décidez de désactiver ou de corriger. Sans e-mail, passez par les fichiers.

Après la panne. Quittez le mode de récupération, vérifiez le site depuis un autre navigateur, puis relisez le journal d'erreurs. Un suivi régulier limite le risque : voir pourquoi un contrat de maintenance WordPress évite ce type d'incident, ou faites appel au dépannage WordPress urgent si la panne persiste.