« Il y a eu une erreur critique sur ce site » : causes et solution pas à pas

Le message « Il y a eu une erreur critique sur ce site » signifie qu’une erreur PHP fatale empêche WordPress de s’exécuter. Dans la grande majorité des cas, le coupable est une extension, le thème, une version de PHP incompatible ou un manque de mémoire. La solution tient en trois temps : lire l’e-mail de récupération envoyé à l’administrateur (ou activer le journal de débogage), identifier le fichier fautif, puis désactiver l’extension ou le thème en cause par FTP, SFTP ou WP-CLI.

Ce message est volontairement vague : WordPress ne veut pas afficher de détails techniques à vos visiteurs. Voici comment retrouver la vraie cause, dans l’ordre où nous procédons nous-mêmes, du plus simple (aucun accès technique) au plus complet (accès au serveur).

• Que signifie exactement ce message ?
• Quelles sont les causes les plus fréquentes ?
• Comment utiliser le mode de récupération par e-mail ?
• Comment lire l’erreur exacte avec WP_DEBUG_LOG ?
• Comment désactiver une extension sans accès à l’administration ?
• Et si c’est le thème ?
• Version de PHP et mémoire : comment les vérifier ?
• Les erreurs à éviter
• Comment éviter que ça recommence ?
• Questions fréquentes
• Sources

Que signifie exactement ce message ?

Depuis WordPress 5.2, le cœur intègre un gestionnaire d’erreurs fatales. Avant cette version, une erreur PHP fatale produisait le fameux « écran blanc » : une page vide, sans aucune information. Aujourd’hui, WordPress intercepte l’erreur, affiche un message générique aux visiteurs (« Il y a eu une erreur critique sur ce site », la formulation exacte varie légèrement selon la version et la langue) et envoie un e-mail à l’adresse d’administration du site.

La documentation officielle de WordPress le résume ainsi : quelque chose dans votre site a provoqué une erreur critique qui empêche WordPress de fonctionner normalement. Le message ne dit rien de la cause : c’est à vous d’aller la chercher, dans l’e-mail ou dans les journaux.

Point important : l’erreur peut toucher tout le site ou seulement certaines pages (par exemple uniquement le tunnel de commande, ou uniquement l’administration). Notez précisément où elle apparaît, c’est souvent un premier indice.

Quelles sont les causes les plus fréquentes ?

La documentation WordPress cite les conflits d’extensions, les problèmes de compatibilité du thème, une version de PHP incompatible, les limites de mémoire et les fichiers corrompus. Dans la pratique, le déclencheur est presque toujours une modification récente.

Cause	Déclencheur typique	Indice dans le journal
Extension défectueuse ou en conflit	Mise à jour ou installation d’une extension	Chemin en wp-content/plugins/nom-extension/
Thème incompatible	Mise à jour du thème, modification de functions.php	Chemin en wp-content/themes/nom-theme/
Version de PHP incompatible	L’hébergeur a changé la version de PHP	Call to undefined function, erreurs de syntaxe sur du code ancien
Mémoire insuffisante	Import, page lourde, extension gourmande	Allowed memory size of ... bytes exhausted
Fichiers corrompus ou incomplets	Mise à jour interrompue, transfert FTP incomplet	Failed opening required, fichier introuvable

Avant toute manipulation, posez-vous une seule question : qu’est-ce qui a changé juste avant l’apparition de l’erreur ? Une mise à jour automatique dans la nuit, une extension ajoutée la veille, un changement de version de PHP annoncé par l’hébergeur. La réponse vous fait souvent gagner une heure.

Comment utiliser le mode de récupération par e-mail ?

C’est la méthode la plus simple, car elle ne demande aucun accès au serveur. Lorsque l’erreur survient, WordPress envoie à l’adresse e-mail d’administration (et au super administrateur sur un multisite) un message qui décrit le problème et contient un lien secret vers le « mode de récupération ».

1. Ouvrez la boîte de réception de l’adresse définie dans Réglages, Général, « Adresse e-mail d’administration ». Vérifiez aussi les indésirables.
2. Repérez dans l’e-mail le nom de l’extension ou du thème en cause, ainsi que le fichier et la ligne de l’erreur.
3. Cliquez sur le lien de récupération, puis connectez-vous avec un compte administrateur.
4. WordPress met en pause l’élément fautif pour votre session : vous pouvez alors accéder à l’administration, désactiver l’extension ou changer de thème.
5. Quittez le mode de récupération et vérifiez le site en navigation privée.

Deux limites à connaître. D’abord, par défaut, WordPress n’envoie pas un nouvel e-mail à chaque erreur : le délai entre deux e-mails de récupération est d’une journée (valeur par défaut du filtre recovery_mode_email_rate_limit). Si vous avez supprimé le premier e-mail, il faudra passer par une autre méthode. Ensuite, si votre site n’envoie pas d’e-mails (configuration SMTP absente ou cassée), vous ne recevrez rien. Le destinataire peut être changé avec la constante RECOVERY_MODE_EMAIL dans wp-config.php, ce qui est utile quand l’adresse d’administration est celle d’un ancien prestataire.

Comment lire l’erreur exacte avec WP_DEBUG_LOG ?

Pas d’e-mail ? Il faut faire parler WordPress. Connectez-vous en FTP, SFTP ou via le gestionnaire de fichiers de votre hébergeur, ouvrez le fichier wp-config.php à la racine du site et, juste avant la ligne « C’est tout, ne touchez pas à ce qui suit », ajoutez ou modifiez ces lignes :

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

Rechargez la page en erreur, puis ouvrez le fichier wp-content/debug.log. Cherchez la ligne qui commence par PHP Fatal error : elle indique le message, le fichier et le numéro de ligne. Le chemin du fichier suffit généralement à identifier le coupable (dossier d’une extension ou d’un thème).

Pourquoi WP_DEBUG_DISPLAY à false ? Pour que les erreurs soient écrites dans le fichier sans s’afficher à vos visiteurs. La documentation WordPress rappelle d’ailleurs que ces outils de débogage ne sont pas recommandés sur un site en production : ils sont faits pour le diagnostic. Une fois le problème réglé, remettez WP_DEBUG à false et supprimez le fichier debug.log, qui peut contenir des chemins et des informations utiles à un attaquant.

Si debug.log reste vide, l’erreur se produit peut-être avant le chargement de WordPress (dans wp-config.php lui-même, par exemple). Consultez alors le journal d’erreurs PHP de l’hébergement, disponible dans la plupart des panneaux d’administration (cPanel, Plesk, espace client de l’hébergeur).

Comment désactiver une extension sans accès à l’administration ?

Par FTP ou SFTP

WordPress ne charge une extension que si son dossier existe. Renommer le dossier revient donc à la désactiver, sans rien supprimer.

1. Connectez-vous avec votre client FTP ou SFTP (FileZilla, Cyberduck, ou le gestionnaire de fichiers de l’hébergeur).
2. Allez dans wp-content/plugins/.
3. Renommez le dossier de l’extension identifiée, par exemple woocommerce en woocommerce-off.
4. Rechargez le site. S’il revient, vous tenez le coupable.
5. Si vous n’avez aucune piste, renommez le dossier plugins entier en plugins-off : toutes les extensions sont désactivées d’un coup. Recréez ensuite un dossier plugins, remettez-y les extensions une par une et testez à chaque fois.

Avec WP-CLI

Si vous avez un accès SSH et que WP-CLI est installé (c’est le cas chez de nombreux hébergeurs), c’est plus rapide et plus propre. L’option globale --skip-plugins permet de lancer la commande sans charger les extensions, donc sans déclencher l’erreur :

# Lister les extensions actives
wp plugin list --status=active --skip-plugins --skip-themes

# Désactiver une extension précise
wp plugin deactivate nom-de-l-extension --skip-plugins

# Tout désactiver sauf une extension indispensable
wp plugin deactivate --all --exclude=woocommerce --skip-plugins

Notez que --skip-plugins ne concerne pas les extensions « must-use » (dossier wp-content/mu-plugins), qui restent chargées. Si l’erreur vient de là, il faut renommer le fichier concerné par SFTP.

Et si c’est le thème ?

Si le journal pointe vers wp-content/themes/, ou si la désactivation des extensions n’a rien changé, testez le thème. Le principe est le même : renommez le dossier du thème actif par FTP. WordPress bascule alors sur un thème par défaut installé (Twenty Twenty-Five, Twenty Twenty-Four…), à condition qu’il en reste au moins un dans wp-content/themes/. Gardez donc toujours un thème par défaut installé, même si vous ne l’utilisez pas.

Avec WP-CLI, la commande wp theme activate twentytwentyfive --skip-themes --skip-plugins fait la même chose. Si vous utilisez un thème enfant, vérifiez aussi le thème parent : une mise à jour du parent peut casser une fonction surchargée dans l’enfant.

Attention : changer de thème modifie l’apparence du site et peut réinitialiser certains réglages de widgets ou de menus. C’est un test de diagnostic, pas une solution définitive. Une fois la cause trouvée, corrigez le thème et réactivez-le.

Version de PHP et mémoire : comment les vérifier ?

La version de PHP

WordPress recommande aujourd’hui PHP 8.3 ou plus récent. Les versions 7.4 et suivantes restent acceptées pour les environnements anciens, mais elles ne reçoivent plus de correctifs de sécurité. Le piège classique : l’hébergeur fait passer le site en PHP 8.x, et une vieille extension ou un thème non maintenu utilise une fonction supprimée. L’erreur apparaît alors sans que vous n’ayez rien touché.

Vérifiez la version active dans le panneau de votre hébergeur. Si l’erreur a commencé au moment d’un changement de version, revenir temporairement à la précédente remet le site en ligne, le temps de mettre à jour ou de remplacer le composant incompatible. Ne restez pas durablement sur une version obsolète : c’est une dette de sécurité. Nous avons détaillé les évolutions du langage dans notre article sur PHP 8.

La mémoire allouée

Si le journal affiche Allowed memory size of ... bytes exhausted, WordPress manque de mémoire. Par défaut, WordPress demande 40 Mo pour un site simple et 64 Mo pour un multisite. Vous pouvez relever cette limite dans wp-config.php :

define( 'WP_MEMORY_LIMIT', '256M' );

Cette constante ne peut pas dépasser la limite fixée par PHP (memory_limit) sur le serveur. Si l’hébergeur plafonne plus bas, il faut modifier le php.ini ou lui demander. Et gardez un œil critique : un site vitrine qui a besoin de 512 Mo cache souvent une extension mal conçue. Augmenter la mémoire soigne le symptôme, pas la cause.

Les erreurs à éviter

• Supprimer une extension au lieu de la désactiver. Renommer le dossier suffit. Supprimer peut faire perdre des réglages, et réinstaller une extension WooCommerce ou de formulaires sans précaution peut réserver des surprises.
• Laisser WP_DEBUG actif. Afficher les erreurs PHP en production expose des chemins de fichiers et fait mauvaise impression. Désactivez-le dès le diagnostic terminé.
• Tout réinstaller dans la précipitation. Réinstaller WordPress ne corrige pas une extension incompatible. Diagnostiquez d’abord.
• Restaurer une sauvegarde sans comprendre. La restauration remet le site en ligne, mais la prochaine mise à jour automatique reproduira la même erreur si la cause n’est pas identifiée.
• Modifier des fichiers sans copie. Téléchargez wp-config.php sur votre poste avant d’y toucher. Une virgule oubliée dans ce fichier produit elle-même une erreur fatale.

Comment éviter que ça recommence ?

L’erreur critique est rarement une fatalité. Elle survient presque toujours après une mise à jour non testée ou un environnement qui a évolué sans que personne ne vérifie la compatibilité. Quelques règles simples réduisent fortement le risque :

• tester les mises à jour importantes (extensions de paiement, constructeur de pages, thème) sur une copie du site avant la production ;
• garder une sauvegarde récente des fichiers et de la base, restaurable en quelques minutes ;
• limiter le nombre d’extensions et supprimer celles qui ne sont plus maintenues (notre sélection des extensions WordPress utiles peut servir de point de départ) ;
• surveiller la disponibilité du site pour être alerté avant vos clients, avec un des outils de monitoring du marché ;
• vérifier que le site sait envoyer des e-mails, pour recevoir le lien de récupération le jour où il servira.

C’est exactement le travail d’une maintenance régulière, que nous avons décrit dans notre article sur la maintenance des sites WordPress. Si vous préférez ne plus gérer ces incidents vous-même, notre offre d’hébergement et maintenance WordPress (formule selon le niveau de suivi, voir nos tarifs indicatifs) inclut les mises à jour, les sauvegardes et la surveillance. Pour un site plus complexe ou un développement sur mesure qui plante, notre équipe WordPress peut intervenir directement sur le code.

Questions fréquentes

Je n’ai reçu aucun e-mail de récupération, pourquoi ?

Soit l’adresse d’administration n’est plus consultée, soit le site n’envoie pas d’e-mails, soit un e-mail a déjà été envoyé dans les dernières 24 heures (délai par défaut entre deux envois). Passez par WP_DEBUG_LOG ou par FTP.

L’erreur critique pénalise-t-elle mon référencement ?

Une erreur fatale renvoie généralement un code HTTP 500. Google ralentit alors l’exploration du site et, si l’erreur dure, finit par retirer les pages de l’index. Quelques heures d’interruption n’ont en principe pas de conséquence durable, plusieurs jours si.

Le site fonctionne mais l’administration affiche l’erreur, que faire ?

La démarche est identique : le journal debug.log indiquera l’extension qui plante uniquement dans l’administration. Désactivez-la par FTP ou WP-CLI.

L’erreur est apparue après une mise à jour automatique, dois-je désactiver les mises à jour ?

Non. Les mises à jour corrigent des failles de sécurité. Mieux vaut les garder, surveiller le site après chaque mise à jour et disposer d’une sauvegarde prête à restaurer.

Mon hébergeur peut-il m’aider ?

Il peut vous donner accès aux journaux d’erreurs PHP, changer la version de PHP ou relever la limite mémoire. En revanche, il ne corrigera généralement pas le code d’une extension ou d’un thème.

Sources

• WordPress Advanced Administration Handbook : Common WordPress errors
• Make WordPress Core : Fatal Error Recovery Mode in 5.2
• Référence du filtre recovery_mode_email_rate_limit
• Debugging in WordPress (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY)
• Editing wp-config.php (WP_MEMORY_LIMIT)
• WP-CLI : wp plugin deactivate
• WP-CLI : paramètres globaux –skip-plugins et –skip-themes
• WordPress.org : configuration requise (PHP, MySQL, MariaDB)
• Google : effet des codes HTTP et des erreurs serveur sur l’exploration