Erreur critique WordPress : un message produit par WordPress lui-même
« Il y a eu une erreur critique sur ce site » est le message que WordPress affiche depuis la version 5.2 quand une erreur PHP fatale interrompt l’exécution d’un plugin, d’un thème ou du cœur. Contrairement à une erreur 500 générique ou à une page blanche, ce texte n’est pas produit par le serveur web mais par WordPress lui-même, via son mécanisme de protection contre les erreurs fatales (fatal error handler) : au lieu de laisser le site planter sans explication, WordPress intercepte l’échec, affiche ce message aux visiteurs et, surtout, envoie un e-mail à l’administrateur avec un lien de récupération.
Cette distinction change la méthode de diagnostic. Une erreur 500 générique ou une page blanche indiquent que le mécanisme de protection n’a pas pu s’exécuter — mémoire épuisée avant que WordPress ait pu réagir, ou erreur survenue trop tôt dans le chargement. Le message d’erreur critique, lui, signifie que WordPress a bien intercepté le problème et propose déjà un point d’entrée pour le résoudre : le mode de récupération. C’est le symptôme le plus fréquent aujourd’hui sur les installations à jour, largement plus courant que la page blanche pure.
Utiliser le lien de récupération envoyé par e-mail
Dès qu’une erreur critique survient, WordPress envoie automatiquement un e-mail à l’adresse administrateur du site, avec pour objet quelque chose comme « Votre site rencontre un problème technique ». Ce message contient un lien de mode de récupération valable 24 heures, à usage unique.
En cliquant sur ce lien puis en se connectant avec un compte administrateur, WordPress ouvre wp-admin en mode protégé : les plugins ou le thème identifiés comme responsables de l’erreur sont automatiquement mis en pause, sans être désinstallés ni perdre leur configuration. Il devient alors possible d’accéder à Extensions pour désactiver définitivement l’extension fautive, ou de consulter le détail technique de l’erreur directement dans l’interface d’administration — sans avoir besoin d’un accès FTP ni de modifier wp-config.php.
Si l’e-mail n’arrive pas, vérifiez d’abord le dossier spam et l’adresse configurée dans Réglages > Général : sur certains hébergements mutualisés, l’envoi de mail sortant via la fonction PHP mail() est peu fiable et l’e-mail peut simplement ne jamais partir. C’est une limite connue de cette fonctionnalité, pas un signe que le mode de récupération est indisponible — il reste accessible par un autre chemin (voir plus bas).
Faire apparaître le détail technique de l’erreur
Le message affiché aux visiteurs est volontairement vague pour ne pas exposer d’informations techniques au public. Pour voir la cause exacte, deux options.
Dans le mode de récupération (via le lien reçu par e-mail), un bandeau affiche directement le message d’erreur PHP complet une fois connecté : fichier concerné, ligne, et nature de l’échec (fonction non définie, classe manquante, mémoire épuisée). C’est la méthode la plus rapide quand l’e-mail est arrivé.
Sans accès à cet e-mail, activez les journaux de diagnostic dans wp-config.php, en ajoutant ces lignes avant /* C'est tout, ne touchez pas à ce qui suit ! */ :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY reste à false pour ne pas afficher l’erreur aux visiteurs pendant le diagnostic — seul le fichier wp-content/debug.log reçoit le détail. Rechargez la page en erreur, puis ouvrez ce fichier : la dernière entrée pointe le fichier et la ligne exacts.
Les causes les plus fréquentes
Une mise à jour de plugin ou de thème est de loin la cause la plus fréquente, en particulier quand elle survient juste après une montée de version de WordPress ou de PHP côté serveur. Une fonction supprimée dans la nouvelle version d’une extension, ou un appel à une fonction PHP qui n’existe plus dans la version installée sur le serveur, provoque une erreur fatale immédiate.
Un conflit entre deux extensions qui déclarent la même fonction ou la même classe produit le même symptôme, un scénario fréquent juste après l’installation d’un nouveau plugin qui n’a jamais été testé aux côtés des autres déjà actifs sur le site. L’épuisement de la limite mémoire PHP (memory_limit) arrive ensuite : un plugin de e-commerce ou un constructeur de pages gourmand peut consommer plus de mémoire que l’hébergement n’en alloue par défaut, avec une erreur qui apparaît de façon intermittente — sur certaines pages seulement, ou sous forte charge — plutôt que systématiquement.
Une incompatibilité de version PHP, fréquente après un changement d’hébergeur, fait planter du code écrit pour une version antérieure du langage : un plugin ancien, jamais mis à jour depuis plusieurs années, est le profil le plus exposé. Le message de journal correspondant mentionne typiquement une fonction dépréciée ou un type d’argument désormais rejeté par PHP.
Corriger selon la cause identifiée
Si le mode de récupération a déjà mis un plugin en pause, désactivez-le définitivement depuis Extensions, vérifiez auprès de son auteur si une version corrigée existe, et ne le réactivez qu’après avoir confirmé la compatibilité avec la version actuelle de WordPress et de PHP du site.
Sans mode de récupération accessible, désactivez manuellement via FTP ou le gestionnaire de fichiers de l’hébergeur en renommant le dossier du plugin suspect (wp-content/plugins/nom-du-plugin en nom-du-plugin-désactive) — WordPress désactive automatiquement tout plugin dont le dossier n’est plus reconnu, sans perte de réglages. Si le journal ne cible aucune extension précise, renommez le dossier plugins entier pour toutes les désactiver d’un coup, rechargez la page, puis réactivez-les une par une jusqu’à reproduire l’erreur : le fautif est identifié en quelques minutes. Procédez de la même façon avec le thème actif en cas de doute, en basculant temporairement vers un thème par défaut (Twenty Twenty-Four ou équivalent).
Si la mémoire est en cause, augmentez la limite dans wp-config.php :
define( 'WP_MEMORY_LIMIT', '256M' );
Cette valeur reste plafonnée par la configuration PHP globale du serveur : si l’hébergement impose une limite plus basse au niveau serveur, la définition dans WordPress ne peut pas la dépasser. Les paliers de mémoire PHP par défaut varient sensiblement d’un hébergeur à l’autre pour un tarif affiché similaire, un critère à vérifier directement avant de choisir où héberger un site chargé en plugins.
Quand le message revient après chaque correction
Si l’erreur critique réapparaît après avoir désactivé plusieurs extensions successivement, la cause peut être ailleurs qu’un plugin isolé : fichiers cœur WordPress corrompus après une mise à jour interrompue, ou limite de ressources serveur (nombre de processus PHP simultanés, quota d’exécution) plutôt qu’un problème de code. Notre article sur l’erreur 508 Resource Limit Is Reached détaille ce second cas, reconnaissable à un message qui évoque explicitement une limite de ressources plutôt qu’une fonction ou une classe PHP précise.
Restaurer une sauvegarde antérieure à la dernière mise à jour reste la solution la plus rapide quand le diagnostic par élimination prend trop de temps face à un site qui doit rester accessible. Notre guide complet sur la sauvegarde et la restauration de votre site détaille la marche à suivre, y compris pour restaurer uniquement les fichiers ou uniquement la base de données selon l’origine de l’erreur.
Éviter que l’erreur ne revienne
Tester les mises à jour de plugins, de thèmes et de PHP sur un site de préproduction avant de les appliquer en production reste la mesure la plus efficace contre ce type d’incident. Garder un nombre restreint d’extensions actives réduit mécaniquement les risques de conflit entre elles, et vérifier la compatibilité PHP annoncée par un plugin avant de l’installer évite les mauvaises surprises découvertes après coup.
Un hébergement WordPress correctement dimensionné en mémoire PHP et en version du langage réduit la fréquence de ces erreurs, sans les éliminer totalement : aucun hébergement ne protège contre un plugin mal codé ou une mise à jour bâclée par son auteur. Garder l’e-mail administrateur du site à jour et surveillé reste le réflexe le plus simple pour recevoir le lien de récupération dès qu’un incident survient, plutôt que de le découvrir au prochain passage d’un visiteur.