Erreur critique WordPress : causes et solutions

Votre site affiche « Il y a eu une erreur critique sur ce site. » et plus rien d’autre. Ce message n’est pas une panne mystérieuse : c’est WordPress qui vous dit qu’un morceau de code PHP s’est arrêté net, et qu’il a préféré afficher une phrase plutôt qu’une page blanche. La cause est presque toujours écrite quelque part, dans un e-mail ou dans un journal. Ce guide vous montre où la trouver, comment la lire et comment remettre le site en ligne sans tout casser une seconde fois.

Que signifie « Il y a eu une erreur critique sur ce site » ?

Le message apparaît quand PHP rencontre une erreur fatale : une instruction impossible à exécuter, qui arrête le chargement de la page. Avant WordPress 5.2, ce type d’erreur produisait le plus souvent une page vide, le fameux écran blanc de la mort. Depuis la version 5.2, sortie en 2019, WordPress intercepte l’erreur, affiche un message et, quand il le peut, déclenche le mode de récupération.

Le texte exact change selon la personne qui regarde et selon ce que WordPress a réussi à faire. Voici les variantes de la traduction française officielle, relevées dans le code de WordPress 7.1 :

Dans tous les cas, le site n’est pas détruit. Une erreur fatale arrête l’exécution du code, elle n’efface ni vos articles, ni vos commandes, ni votre base de données. Le travail consiste à trouver la ligne qui bloque.

Les causes les plus fréquentes d’une erreur critique

Six familles de causes couvrent l’essentiel des cas. Le journal d’erreurs dit laquelle est en jeu, mais le contexte donne souvent la piste avant même de l’ouvrir : qu’est-ce qui a changé juste avant ?

• Une extension mise à jour ou installée. C’est la cause la plus courante. La nouvelle version appelle une fonction qui n’existe pas chez vous, ou entre en conflit avec une autre extension.
• Le thème, ou son fichier functions.php. Un bout de code collé depuis un tutoriel, une accolade oubliée, un thème parent mis à jour qui ne reconnaît plus son thème enfant.
• Un changement de version de PHP. L’hébergeur a fait monter la version, ou vous l’avez fait vous-même. Du code écrit pour une ancienne version ne passe plus. La fiche compatibilité PHP détaille le mécanisme.
• La mémoire allouée à PHP est épuisée. Une extension gourmande, un import volumineux, une page de constructeur trop lourde : PHP atteint sa limite et s’arrête.
• Une mise à jour interrompue. Un fichier manquant ou à moitié copié, souvent après une mise à jour du cœur de WordPress coupée en route.
• Du code malveillant. Plus rare, mais à ne jamais écarter : un fichier injecté par un pirate peut planter le site. On y revient plus bas.

Étape 1 : récupérer le message d’erreur exact

Ne désactivez rien au hasard tant que vous n’avez pas lu le message. Il nomme le fichier et la ligne en cause, ce qui transforme une heure de tâtonnements en deux minutes de lecture.

L’e-mail « Votre site connaît un problème technique »

Quand l’erreur vient d’une extension ou d’un thème, WordPress envoie un e-mail à l’adresse d’administration du site, avec pour objet « [Nom du site] Votre site connaît un problème technique ». Il contient trois choses utiles :

1. le nom de l’extension ou du thème qui a provoqué l’erreur ;
2. le détail technique de l’erreur, avec le fichier et la ligne ;
3. un lien vers le mode de récupération, qui ouvre une administration où le coupable est mis en pause.

Deux limites à connaître. Par défaut, WordPress n’envoie pas plus d’un e-mail par jour pour ces erreurs, et le lien n’est valable qu’un jour. Si vous avez manqué le premier, le suivant n’arrivera pas tout de suite. Ensuite, l’e-mail part vers l’adresse d’administration réglée dans Réglages > Général : si elle est périmée, ou si votre hébergeur envoie mal les e-mails, vous ne recevrez rien. Pour forcer une autre adresse, ajoutez cette ligne dans wp-config.php :

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

Le journal de débogage de WordPress

Pas d’e-mail ? Le journal prend le relais. Ouvrez wp-config.php par FTP ou par le gestionnaire de fichiers de votre hébergeur, et placez ces trois lignes au-dessus de la ligne « C’est tout, ne touchez pas à ce qui suit ! » :

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

Rechargez la page qui plante, puis ouvrez le fichier wp-content/debug.log. La troisième ligne est importante : elle écrit les erreurs dans le fichier sans les afficher aux visiteurs. Afficher les erreurs sur un site public expose des chemins de fichiers et des détails de configuration à tout le monde.

Le journal d’erreurs de l’hébergeur

Si wp-config.php lui-même est en cause, ou si vous ne pouvez pas le modifier, le journal d’erreurs PHP de l’hébergeur contient la même information. Sur un panneau cPanel, il se trouve généralement dans la rubrique des journaux ou dans un fichier error_log à la racine du site.

Étape 2 : lire la ligne d’erreur fatale

Une ligne du journal ressemble à ceci :

PHP Fatal error:  Uncaught Error: Call to undefined function ma_fonction()
in /home/compte/public_html/wp-content/plugins/nom-extension/fichier.php:42

Deux informations comptent. Le chemin d’abord : wp-content/plugins/nom-extension/ désigne une extension, wp-content/themes/nom-theme/ un thème, wp-includes/ ou wp-admin/ le cœur de WordPress. Le type d’erreur ensuite, qui oriente vers la cause :

Lisez toujours la première erreur fatale de la série. Les suivantes sont souvent des conséquences de la première.

Étape 3 : neutraliser le coupable

Une fois la cause identifiée, il s’agit de la mettre hors circuit pour remettre le site en ligne. Choisissez la méthode selon les accès dont vous disposez.

Avec le lien du mode de récupération

Le lien reçu par e-mail ouvre l’administration avec l’extension ou le thème fautif mis en pause, pour vous seul. Les visiteurs, eux, voient toujours l’erreur. Rendez-vous dans Extensions : l’extension en cause y est signalée. Désactivez-la, ou mettez-la à jour si une version corrigée existe, puis cliquez sur « Quitter le mode de récupération » et vérifiez le site dans une fenêtre de navigation privée.

Par FTP ou le gestionnaire de fichiers

Sans accès à l’administration, renommez le dossier de l’extension en cause, par exemple wp-content/plugins/nom-extension en nom-extension-off. WordPress ne la trouve plus et la désactive. Si le journal ne désigne rien de précis, renommez le dossier plugins entier en plugins-off : si le site revient, remettez le nom d’origine, puis renommez les extensions une par une jusqu’à retrouver la fautive.

Pour un thème, renommez son dossier dans wp-content/themes/. WordPress bascule sur un thème par défaut s’il en trouve un installé : vérifiez qu’il en reste au moins un, comme Twenty Twenty-Five.

En ligne de commande avec WP-CLI

Si votre hébergeur donne un accès SSH, WP-CLI est le plus rapide. L’option --skip-plugins empêche le chargement des extensions, ce qui permet de lancer des commandes même quand le site plante :

# lister les extensions actives sans les charger
wp plugin list --status=active --skip-plugins --skip-themes

# désactiver l'extension en cause
wp plugin deactivate nom-extension --skip-plugins --skip-themes

# basculer sur un thème par défaut
wp theme activate twentytwentyfive --skip-plugins --skip-themes

# vérifier que les fichiers du cœur sont intacts
wp core verify-checksums

Les cas particuliers

• Mémoire épuisée. Ajoutez define( 'WP_MEMORY_LIMIT', '256M' ); dans wp-config.php. Si l’hébergeur plafonne plus bas, la limite se règle dans son panneau. C’est un pansement : une extension qui dévore la mémoire continuera de le faire.
• Version de PHP changée. Revenez à la version précédente dans le panneau de l’hébergeur, le temps de mettre à jour l’extension ou le thème en cause. Ne restez pas sur une version ancienne : une version de PHP en fin de vie ne reçoit plus de correctifs de sécurité.
• Fichiers du cœur endommagés. Réinstallez WordPress depuis Tableau de bord > Mises à jour, ou avec wp core download --force --skip-content. Vos contenus, extensions et thèmes ne sont pas touchés.

Étape 4 : vérifier, puis refermer le débogage

Le site s’affiche de nouveau ? Il reste trois gestes, souvent oubliés.

1. Tester les pages qui comptent : accueil, un article, le formulaire de contact, le panier si vous vendez en ligne, et l’administration. Une erreur peut ne toucher qu’un type de page.
2. Remettre WP_DEBUG à false dans wp-config.php.
3. Supprimer wp-content/debug.log. Ce fichier est placé dans un dossier public : sauf blocage côté serveur, n’importe qui peut le lire en tapant son adresse. Il contient des chemins et des noms de fichiers qui facilitent le travail d’un attaquant. Si vous devez garder un journal actif, indiquez à WP_DEBUG_LOG un chemin situé hors du dossier public plutôt que true.

Enfin, remplacez durablement ce qui a planté : version corrigée de l’extension, alternative mieux maintenue, ou correction du code. Une extension simplement désactivée laisse souvent une fonction du site en panne sans bruit.

Quand l’erreur critique cache un piratage

Une erreur critique n’est pas un signe de piratage en soi. Mais certains indices doivent vous arrêter avant de simplement « réparer » :

• le journal cite un fichier PHP dans wp-content/uploads/, un dossier qui ne devrait contenir que des médias ;
• wp core verify-checksums signale des fichiers modifiés ou ajoutés dans le cœur ;
• le chemin cité porte un nom sans rapport avec vos extensions et vos thèmes ;
• vous découvrez un compte administrateur que vous n’avez pas créé.

Dans ce cas, restaurer une sauvegarde ou désactiver une extension ne suffit pas : la porte dérobée reste en place et le problème revient. Il faut un nettoyage complet du site infecté. C’est le cœur de notre prestation site WordPress piraté.

Éviter la prochaine erreur critique

La plupart des erreurs critiques arrivent au moment d’une mise à jour. Quelques habitudes en éliminent la majorité :

• Sauvegarder avant toute mise à jour, fichiers et base de données, avec une sauvegarde que vous avez déjà restaurée au moins une fois pour vérifier qu’elle fonctionne.
• Tester sur une préproduction, une copie privée du site, avant de toucher au site en ligne.
• Mettre à jour une extension à la fois, et regarder le site entre deux. La fiche mise à jour majeure et mineure détaille l’ordre à suivre. Dix mises à jour d’un coup, c’est dix suspects au lieu d’un.
• Vérifier la compatibilité avec PHP avant de changer de version, en commençant par les extensions les moins maintenues.
• Garder une adresse d’administration valide et relevée, pour que l’e-mail de récupération arrive vraiment.
• Ne jamais modifier le thème principal directement : passer par un thème enfant ou une extension de bouts de code.

Si vous préférez ne plus vous en occuper, c’est exactement le rôle d’un contrat de maintenance WordPress. Sauvegardes vérifiées, mises à jour testées avant d’être appliquées, et une intervention rapide quand quelque chose casse malgré tout.

Questions fréquentes

Vais-je perdre mon contenu à cause d’une erreur critique ?

Non. L’erreur arrête l’exécution du code PHP, elle ne supprime rien dans la base de données. Vos pages, articles et réglages sont toujours là et réapparaissent dès que le code fautif est neutralisé.

Seule l’administration affiche l’erreur critique, le site fonctionne. Pourquoi ?

Le code qui plante n’est chargé que dans l’administration. C’est typique d’une extension dont seule la partie réglages est incompatible. La méthode est la même : lire le journal, puis désactiver l’extension citée.

Je n’ai jamais reçu l’e-mail de récupération. Que faire ?

Vérifiez les courriers indésirables, puis l’adresse réglée dans Réglages > Général. Souvenez-vous que WordPress n’envoie qu’un e-mail par jour pour ces erreurs. Sans e-mail, passez directement par le journal de débogage et le renommage de dossier par FTP.

Faut-il restaurer une sauvegarde ?

C’est souvent le moyen le plus rapide de remettre le site en ligne, mais il ne dit pas ce qui s’est passé. Lisez le journal avant de restaurer : sinon, la même mise à jour reproduira la même erreur la semaine suivante. Et si l’erreur trahit un piratage, une sauvegarde peut contenir le code malveillant elle aussi.

L’erreur critique a-t-elle un effet sur le référencement ?

Une page en erreur fatale renvoie en principe un code HTTP 500 aux robots. Une panne de quelques heures n’a généralement pas de conséquence durable, mais une erreur qui dure plusieurs jours peut conduire Google à espacer ses visites, puis à retirer des pages de son index. Corrigez vite, puis surveillez le rapport « Indexation des pages » de la Search Console.