Ce message signale une erreur fatale de PHP qu’une extension, un thème ou un bout de code ajouté vient de déclencher. WordPress l’a interceptée, a arrêté le chargement et répond en HTTP 500. Le site n’est pas perdu : ni le contenu ni la base de données ne sont touchés. Il faut identifier le coupable, et pour cela reprendre l’accès.

La réponse en trois lignes

Si vous accédez encore à l’administration, désactivez la dernière extension installée ou mise à jour. Sinon, renommez le dossier wp-content/plugins en plugins-off par FTP : le site revient, et vous réactivez ensuite une extension à la fois.

Ce que le message dit — et ce qu’il ne dit pas

Depuis WordPress 5.2, un gestionnaire d’erreurs surveille la fin de chaque requête. Il n’intervient pas pour n’importe quoi : il ne retient que cinq types d’erreurs PHP, toutes fatales — E_ERROR, E_PARSE, E_USER_ERROR, E_COMPILE_ERROR et E_RECOVERABLE_ERROR.

Un simple avertissement ou une notice ne déclenche donc jamais ce message. C’est un repère de diagnostic utile : si votre site affiche une page entièrement blanche sans aucun texte, ce n’est pas ce mécanisme qui est à l’œuvre, et la cause se cherche ailleurs. De même, un éditeur qui refuse d’enregistrer avec « La réponse n’est pas une réponse JSON valide » n’a pas rencontré d’erreur fatale : c’est l’API REST qui ne répond pas.

La formulation vous dit où vous êtes

WordPress n’affiche pas toujours la même phrase, et la différence est riche d’information :

  • « Il y a eu une erreur critique sur ce site. » — version courte, servie aux visiteurs. Elle ne dit délibérément rien de plus.
  • « … Veuillez consulter la boîte de réception de l’e-mail de l’administrateur du site pour des instructions. » — cette phrase n’apparaît que sur une page protégée : l’administration ou la page de connexion. Sa présence prouve qu’un e-mail de récupération a bien été déclenché.
  • « … plaçant celui-ci en mode de récupération. » — vous êtes déjà entré en mode de récupération par le lien reçu.

Pourquoi l’e-mail de récupération n’arrive pas

WordPress envoie un lien qui ouvre le site en mode de récupération : l’extension fautive y est mise en pause pour vous seul — le reste du monde continue de voir le site en erreur — le temps de la réparer. En théorie, c’est la voie royale. En pratique, cet e-mail se perd, et trois mécanismes l’expliquent.

1. L’erreur ne s’est pas produite au bon endroit

C’est la raison la plus fréquente, et elle est invisible pour qui n’a pas lu le code. WordPress n’envoie l’e-mail que si l’erreur survient sur une page « protégée » : l’administration, wp-login.php, ou certaines requêtes Ajax de dépannage. Une erreur fatale déclenchée par la visite de votre page d’accueil est écartée d’emblée, avec la mention interne non-protected endpoint.

Autrement dit : si votre site public affiche l’erreur critique et que rien n’arrive dans votre boîte, ce n’est ni un bug ni un problème de messagerie, c’est le fonctionnement prévu. Chargez https://votre-site.fr/wp-login.php : si le plantage se reproduit là, l’envoi est déclenché.

Second filtre, dans la même logique : WordPress doit pouvoir attribuer l’erreur à une extension ou à un thème. Une erreur fatale venue du cœur, de wp-config.php ou d’un mu-plugin n’ouvre aucun mode de récupération, et n’envoie rien.

2. Il part sur l’adresse du site, pas sur la vôtre

L’e-mail n’est pas envoyé à l’adresse de votre compte utilisateur, mais à l’adresse de contact du site — celle de Réglages → Général, stockée dans l’option admin_email. Sur un site repris, refait ou installé par un prestataire, cette adresse appartient souvent à quelqu’un d’autre, ou n’existe plus.

Vous n’avez pas besoin de l’administration pour la corriger : une constante dans wp-config.php a priorité sur le réglage.

define( 'RECOVERY_MODE_EMAIL', 'vous@votre-domaine.fr' );

Placez-la avant la ligne /* C’est tout, ne touchez pas à ce qui suit ! */, puis rechargez la page en erreur pour provoquer un nouvel envoi.

3. Le piège des vingt-quatre heures

Voici le point que presque aucun article ne mentionne, et qui explique beaucoup de situations bloquées : WordPress n’envoie qu’un seul e-mail de récupération par jour. La limite est d’une journée entière, et le lien reçu reste valable au moins aussi longtemps. Recharger la page vingt fois ne produira pas un second message.

Si vous avez perdu le premier e-mail, ou changé l’adresse après coup, il faut effacer la trace de l’envoi précédent. En SQL, depuis phpMyAdmin ou Adminer :

DELETE FROM wp_options WHERE option_name = 'recovery_mode_email_last_sent';

Adaptez le préfixe wp_ à celui de votre installation : il est indiqué par $table_prefix dans wp-config.php. Le prochain chargement de la page en erreur déclenchera un nouvel envoi.

Reprendre la main sans attendre l’e-mail

C’est la méthode la plus rapide, et elle ne dépend d’aucune boîte aux lettres. Il vous faut un accès FTP, SFTP ou le gestionnaire de fichiers de l’hébergeur.

1. Neutraliser toutes les extensions d’un coup

Renommez le dossier wp-content/plugins en plugins-off. WordPress ne trouve plus rien à charger et désactive tout. Si le site revient, la cause est bien une extension.

cd /chemin/vers/le/site/wp-content
mv plugins plugins-off

Rétablissez ensuite le nom d’origine et réactivez les extensions une par une depuis l’administration, en rechargeant le site après chacune. Celle qui fait retomber le site en erreur est votre coupable.

2. Si le site reste en erreur, regarder du côté du thème

Renommez le dossier du thème actif dans wp-content/themes. Faute de le trouver, WordPress bascule sur un thème par défaut, à condition qu’il soit encore présent. C’est la raison pour laquelle il ne faut jamais supprimer le dernier thème par défaut d’une installation.

3. Si rien n’y fait

Le problème est en amont des extensions : du code déposé dans un mu-plugin (wp-content/mu-plugins, chargé avant tout le reste et impossible à désactiver depuis l’administration), une version de PHP changée par l’hébergeur, ou la mémoire épuisée. Le journal tranche.

Lire la vraie erreur, la seule méthode fiable

Tout ce qui précède identifie qui plante. Le journal PHP dit pourquoi, en une ligne, avec le fichier et le numéro de ligne. Ajoutez ceci dans wp-config.php :

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

Rechargez la page en erreur, puis ouvrez wp-content/debug.log. La dernière ligne commençant par PHP Fatal error nomme le fichier fautif — et son chemin contient le dossier de l’extension responsable.

Deux erreurs à ne pas commettre. Ne laissez jamais WP_DEBUG_DISPLAY à true sur un site en ligne : les chemins du serveur s’afficheraient à tous les visiteurs. Et retirez ces trois lignes une fois le problème réglé, car le journal grossit sans limite.

Autre voie, plus radicale : désactiver le gestionnaire lui-même pour voir l’erreur brute de PHP à l’écran.

define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

À réserver à une préproduction, ou au temps d’un seul rechargement sur un site en ligne : l’erreur brute expose l’arborescence du serveur.

Les causes, par ordre de fréquence

  1. Une extension mise à jour qui exige une version de PHP plus récente que celle du serveur. C’est de loin le premier cas.
  2. La version de PHP relevée par l’hébergeur, qui casse une extension ancienne restée sans mise à jour. Symptôme typique : personne n’a rien touché sur le site.
  3. Deux extensions incompatibles qui déclarent la même fonction ou la même classe. L’erreur porte alors la mention Cannot redeclare.
  4. Du code collé dans functions.php depuis un tutoriel, avec une accolade ou un point-virgule de trop — E_PARSE. Ici, l’erreur apparaît à la seconde où le fichier est enregistré.
  5. La mémoire PHP épuisée, qui produit un Allowed memory size … exhausted. Voir notre guide sur l’erreur 500.

Vérifier que c’est vraiment terminé

Regarder la page ne suffit pas. Une page qui s’affiche correctement peut continuer à répondre 500, par exemple si un cache sert encore l’ancienne réponse. Le contrôle tient en une commande :

curl -I https://votre-site.fr/

La première ligne doit indiquer HTTP/2 200. Videz ensuite les caches dans l’ordre : extension, hébergeur, CDN. Vous pouvez aussi passer l’adresse à notre testeur d’en-têtes, qui lit la réponse réelle sans rien installer. Vérifiez enfin que /robots.txt répond bien 200 : une erreur prolongée sur ce seul fichier fait cesser l’exploration du site entier.

Une erreur 500 qui dure coûte cher

Tant que le diagnostic n’est pas fait, votre site répond aux moteurs comme un serveur en panne. C’est le pire signal possible sur plusieurs jours, et il est évitable : si la réparation doit prendre du temps, mieux vaut passer volontairement en maintenance avec un statut 503, qui dit « je reviens » là où le 500 dit « je suis cassé ». La différence entre ces deux signaux est détaillée ici.