Par Aurélien Debord ·
À retenir
Le message « Une erreur critique est survenue sur ce site » signale une erreur fatale PHP qui empêche WordPress de générer la page. Dans neuf cas sur dix, c'est un plugin, un thème ou une mise à jour qui en est la cause.
La méthode la plus rapide pour s'en sortir : ouvrir l'email de récupération envoyé par WordPress, ou activer
WP_DEBUGdans lewp-config.phppour lire le message d'erreur exact, puis désactiver le composant fautif via FTP. Pensez à sauvegarder votre site avant toute manipulation.
Vous ouvrez votre site et à la place de votre page d'accueil, vous tombez sur ça : « Une erreur critique est survenue sur ce site ». Parfois c'est le front qui plante, parfois c'est l'admin, parfois les deux. Et le message ne dit rien de plus, ce qui n'aide pas vraiment à comprendre ce qui se passe.
Bonne nouvelle : derrière ce message volontairement vague se cache presque toujours une cause précise et identifiable. On va voir d'où vient cette erreur, comment lire ce qu'elle essaie de vous dire, et comment la corriger selon son origine.
Depuis WordPress 5.2, ce message a remplacé ce qu'on appelait avant l'écran blanc de la mort (le fameux White Screen of Death). Avant, quand une erreur fatale survenait, vous tombiez sur une page blanche sans la moindre indication. Aujourd'hui WordPress affiche au moins un message lisible et, surtout, il vous envoie un email.
Concrètement, une erreur critique est une erreur fatale PHP. Le code qui fait tourner WordPress, vos plugins ou votre thème a rencontré quelque chose qu'il ne peut pas exécuter : une fonction qui n'existe pas, une incompatibilité de version, un fichier corrompu, une mémoire saturée. PHP s'arrête net, et comme il ne peut pas finir de construire la page, WordPress affiche le message générique pour ne pas exposer les détails techniques aux visiteurs.
C'est pour ça que le message est aussi peu bavard côté public. Les vraies informations, elles, sont ailleurs : dans l'email de récupération et dans les logs. C'est là qu'il faut aller chercher.
Quand l'erreur survient, WordPress envoie automatiquement un email à l'adresse de l'administrateur du site (celle définie dans Réglages > Général). Cet email est votre meilleur point de départ.
Il contient deux choses précieuses. D'abord, il vous dit quel plugin ou quel thème a déclenché l'erreur, avec souvent le fichier et la ligne exacte concernés. Ensuite, il vous fournit un lien de connexion en mode récupération. Ce lien vous permet d'accéder à votre admin même quand le front est cassé, avec le composant fautif automatiquement désactivé.
Vous ne recevez pas l'email ? Vérifiez d'abord vos spams. Si rien n'arrive, c'est souvent que votre site n'envoie pas correctement les emails (un problème fréquent en soi). Dans ce cas, passez directement au diagnostic via les logs ci-dessous.
Une fois en mode récupération, vous corrigez ou supprimez le composant en cause, et votre site repart. Dans beaucoup de cas, ça suffit. Mais si vous n'avez pas accès à cet email, ou si l'erreur est plus profonde, il faut mettre les mains dans le cambouis.
Le message public ne dit rien, mais PHP, lui, sait exactement ce qui a planté. Pour le faire parler, on active le mode débogage de WordPress.
Connectez-vous à votre site en FTP (ou via le gestionnaire de fichiers de votre hébergeur), ouvrez le fichier wp-config.php à la racine, et cherchez la ligne qui contient WP_DEBUG. Remplacez-la par ceci :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );La première ligne active le débogage. La deuxième enregistre toutes les erreurs dans un fichier debug.log situé dans wp-content/. La troisième évite d'afficher les erreurs publiquement, pour ne pas montrer du code technique à vos visiteurs pendant que vous travaillez.
Rechargez la page qui plante, puis ouvrez wp-content/debug.log. Vous y trouverez une ligne du type :
PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /wp-content/plugins/mon-plugin/fichier.php on line 42
Cette ligne vaut de l'or. Elle vous donne le type d'erreur, le fichier concerné et la ligne exacte. À partir de là, vous savez quel composant accuser.
N'oubliez pas de repasser WP_DEBUG à false une fois le problème résolu. Laisser le débogage actif en production peut exposer des informations sensibles et grossir le fichier de log indéfiniment.
Maintenant qu'on sait lire l'erreur, voyons les coupables habituels. Dans notre expérience, l'écrasante majorité des erreurs critiques rentre dans l'une de ces catégories.
C'est la cause numéro un. Un plugin que vous venez de mettre à jour, un plugin incompatible avec votre version de PHP, ou deux plugins qui se marchent dessus. L'erreur apparaît souvent juste après une mise à jour ou une nouvelle installation.
Comment ça arrive : un développeur publie une mise à jour qui utilise une fonction d'une version récente de PHP que votre serveur n'a pas, ou un plugin appelle une fonction d'un autre plugin qui a été désactivé. Le code casse, PHP s'arrête.
La solution : désactiver les plugins. Si vous avez accès à l'admin (ou au mode récupération), faites-le depuis l'interface. Sinon, passez par FTP : allez dans wp-content/plugins/ et renommez le dossier plugins en plugins-off. Ça désactive tout d'un coup et votre site devrait revenir. Recréez ensuite un dossier plugins vide, remettez les dossiers de plugins un par un dedans, et rechargez votre site après chaque ajout. Celui qui fait réapparaître l'erreur est votre coupable.
Même logique que pour les plugins, mais avec votre thème. Une mise à jour du thème, une modification dans functions.php, ou un thème qui n'a pas suivi les évolutions de PHP.
Comment ça arrive : vous (ou quelqu'un) avez collé un bout de code dans le functions.php du thème via l'éditeur de fichiers de l'admin, avec une erreur de syntaxe. Comme cet éditeur sauvegarde sans vérifier, le site plante immédiatement, et vous perdez l'accès à l'admin pour annuler. Classique.
La solution : via FTP, allez dans wp-content/themes/ et renommez le dossier de votre thème actif. WordPress basculera automatiquement sur un thème par défaut (Twenty Twenty-Quatre par exemple) s'il en trouve un, et votre site repartira. Si c'est un snippet ajouté dans functions.php qui pose problème, ouvrez le fichier et retirez le code fautif (l'email de récupération ou le debug.log vous indique la ligne).
Le debug.log affiche quelque chose comme Allowed memory size of 134217728 bytes exhausted. WordPress a tout simplement manqué de mémoire pour exécuter une opération.
Comment ça arrive : un site qui grossit, un plugin gourmand (un constructeur de page, un plugin e-commerce, un outil d'import), ou une limite mémoire trop basse définie par votre hébergeur. L'erreur apparaît souvent sur des pages précises, comme l'éditeur ou une page d'import.
La solution : augmentez la limite mémoire dans wp-config.php, en ajoutant cette ligne avant la mention /* That's all, stop editing! */ :
define( 'WP_MEMORY_LIMIT', '256M' );Si ça ne suffit pas, le problème vient peut-être de la limite serveur définie par votre hébergeur, qu'il faudra augmenter dans le php.ini ou via leur panneau. Et si un plugin consomme une mémoire anormale, c'est lui qu'il faut remettre en question, pas la limite.
WordPress et ses extensions évoluent avec PHP. Un site qui tourne sur une version de PHP trop ancienne (ou parfois trop récente pour un vieux plugin) peut déclencher des erreurs fatales.
Comment ça arrive : votre hébergeur met à jour la version de PHP par défaut, ou vous migrez votre site, et un plugin ancien utilise une syntaxe qui n'existe plus. À l'inverse, un plugin tout neuf peut exiger PHP 8.x alors que votre serveur tourne encore en 7.4.
La solution : dans le panneau de votre hébergeur, repérez le réglage de version PHP. Testez une version différente (revenez sur la précédente si vous venez de la changer, ou montez en 8.1/8.2 si vous êtes resté sur une version obsolète). Le debug.log vous oriente : une erreur de syntaxe pointe souvent vers une incompatibilité de version. Sur le long terme, mieux vaut maintenir plugins et thème à jour pour rester compatible avec les versions PHP supportées.
Ici le message est différent : « Erreur lors de l'établissement d'une connexion à la base de données ». C'est une variante d'erreur critique qui mérite sa propre rubrique parce que la cause est ailleurs.
Comment ça arrive : les identifiants de la base dans wp-config.php ne correspondent plus (mot de passe changé, base déplacée après une migration), le serveur de base de données est surchargé ou tombé, ou une table a été corrompue.
La solution : ouvrez wp-config.php et vérifiez les quatre constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Comparez-les avec les informations réelles dans le panneau de votre hébergeur. Si tout est correct mais que l'erreur persiste, la base est peut-être à réparer : ajoutez define( 'WP_ALLOW_REPAIR', true ); dans wp-config.php, puis rendez-vous sur votresite.com/wp-admin/maint/repair.php pour lancer la réparation. Retirez la ligne une fois terminé. Si vous venez de migrer ou cloner votre site, c'est souvent là que ça coince ; notre guide pour dupliquer un site WordPress détaille les bons réglages de base de données.
Plus rare, mais ça arrive : un fichier de WordPress lui-même est endommagé, souvent à cause d'un transfert FTP interrompu ou d'une mise à jour qui a mal tourné.
Comment ça arrive : une mise à jour de WordPress coupée en cours de route, un disque serveur plein au mauvais moment, ou une intervention manuelle hasardeuse sur les fichiers du core.
La solution : réinstallez le core proprement. Téléchargez une version fraîche depuis wordpress.org, et remplacez via FTP les dossiers wp-admin/ et wp-includes/ ainsi que les fichiers à la racine, sauf wp-config.php et le dossier wp-content/. Ces deux-là contiennent votre configuration et vos contenus, on n'y touche pas. Le reste ne contient aucune personnalisation, vous pouvez l'écraser sans risque.
.htaccess casséSi votre serveur tourne sous Apache, un fichier .htaccess corrompu peut provoquer une erreur 500 qui ressemble à une erreur critique.
Comment ça arrive : un plugin de cache ou de sécurité a écrit des règles invalides, ou une modification manuelle a introduit une erreur de syntaxe.
La solution : via FTP, renommez le .htaccess à la racine en .htaccess-old. Rechargez votre site. S'il revient, le fichier était bien le problème. Régénérez-en un propre depuis l'admin WordPress : allez dans Réglages > Permaliens et cliquez simplement sur « Enregistrer ». WordPress recrée un .htaccess correct.
Si vous ne savez pas par où commencer, suivez cette logique. Elle va du plus simple au plus technique, et elle résout la grande majorité des cas.
WP_DEBUG_LOG et lisez wp-content/debug.log pour avoir le message d'erreur exact.plugins).L'idée, c'est de changer une seule chose à la fois et de recharger après chaque étape. C'est ce qui vous permet d'isoler la cause au lieu de tout casser un peu plus.
Une erreur critique qui apparaît sans que vous ayez rien touché (pas de mise à jour, pas de nouveau plugin) doit vous mettre la puce à l'oreille. Du code malveillant injecté dans vos fichiers peut provoquer des erreurs fatales, notamment quand un script de piratage est mal écrit ou entre en conflit avec une mise à jour.
Si vous trouvez dans vos logs des erreurs pointant vers des fichiers que vous ne reconnaissez pas, ou du code contenant eval( et base64_decode(, ce n'est plus un simple bug. Dans ce cas, suivez notre guide complet sur un site WordPress piraté pour nettoyer et sécuriser votre installation.
Une erreur critique est rarement un coup de malchance. C'est presque toujours le signe qu'il manque un garde-fou quelque part.
Le réflexe le plus efficace, c'est de tester les mises à jour ailleurs qu'en production. Un environnement de préproduction (staging) vous permet d'appliquer les mises à jour de plugins, de thème et de WordPress sur une copie de votre site avant de les passer en ligne. Si quelque chose casse, ça casse sur la copie, pas sur le site que voient vos clients.
Gardez aussi vos sauvegardes automatiques à jour. Quand une mise à jour fait planter le site, restaurer la dernière sauvegarde est parfois plus rapide que de chercher la cause. C'est un filet de sécurité qui change tout dans ces moments-là.
Le reste tient à la régularité : mettre à jour ses composants au bon rythme, supprimer les plugins inutilisés, surveiller la version de PHP. C'est précisément ce que couvre une bonne maintenance de site WordPress. Un site suivi tombe beaucoup moins souvent en erreur critique, et quand ça arrive, on le remet debout en quelques minutes parce qu'on sait où regarder.
Enfin, la qualité de l'hébergement joue plus qu'on ne le croit : limites mémoire correctes, version de PHP récente, logs accessibles, sauvegardes intégrées. Ça vaut le coup de bien choisir son hébergement plutôt que de découvrir au pire moment que vous n'avez accès à rien.
Votre site affiche une erreur critique et vous n'arrivez pas à en sortir ? On voit ça avec vous. Contactez-nous pour un diagnostic rapide, ou découvrez notre offre de maintenance WordPress pour ne plus jamais avoir à gérer ce genre de surprise seul.
Que vous ayez besoin d'un nouveau site, d'une reprise de l'existant ou d'une maintenance experte, nous aidons vos équipes marketing et communication à s'appuyer sur un WordPress fiable, performant et simple à administrer.
Discutons de votre projet →Découvrez nos autres conseils WordPress
Votre site WordPress a été piraté ? Redirections suspectes, pages injectées, alertes Google... Voici un plan d'action concret pour nettoyer votre site, identifier la faille et empêcher que ça se reproduise.
Découvrez les meilleures méthodes pour dupliquer votre site WordPress : plugins Duplicator, All-in-One WP Migration, UpdraftPlus, Migrate Guru, ou méthode manuelle. Guide étape par étape pour cloner votre site en toute sécurité.
Selon l’Organisation Mondiale de la Santé (OMS), environ 1,3 milliard de personnes dans le monde sont atteintes d’un handicap important ce qui concerne plus d’une personne sur six. D’après OKEENEA 17% de la population mondiale souffre d’une déficience visuelle, 6% d’un handicap auditif et 2,6% handicap intellectuel. Ainsi en France en 2021 c’est **6,8 millions de [...]
Une des phases préliminaires d’un projet de site web est de déterminer son hébergement. Quel est le meilleur hébergement pour le client, pour son type de projet ? Il est donc de notre ressort de proposer une ou plusieurs solutions qui répondent à ces diverses exigences. Ces exigences regroupent le pays où les données vont être [...]
