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

Cela signifie que PHP a rencontré une erreur fatale pendant la construction de la page et que WordPress l'a interceptée avant l'apparition de la page blanche. Le message reste volontairement vague pour que les visiteurs ne voient ni chemins de fichiers ni code. La vraie erreur, avec le fichier et le numéro de ligne, est écrite dans un journal sur le serveur.

Où se trouve le journal d'erreur critique de WordPress ?

Si vous passez WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php, WordPress écrit dans wp-content/debug.log. Si ces constantes sont désactivées, l'erreur part quand même dans le journal d'erreurs PHP de votre hébergeur, généralement accessible depuis le panneau d'administration à la rubrique journaux ou logs. Vérifiez les deux avant de conclure que rien n'a été enregistré.

Pourquoi n'ai-je pas reçu l'e-mail du mode de récupération WordPress ?

L'e-mail part vers l'adresse d'administration définie dans les réglages, pas vers votre adresse de connexion, et il est envoyé par le même PHP qui vient de planter : l'envoi échoue souvent. Les hébergements mutualisés bloquent aussi le courrier sortant sans SMTP. Regardez dans les indésirables, puis oubliez l'e-mail et désactivez les extensions en SFTP.

Comment réparer une erreur critique si je ne peux plus me connecter à wp-admin ?

Connectez-vous en SFTP ou via le gestionnaire de fichiers de votre hébergeur et renommez le dossier wp-content/plugins en plugins-off. Cela désactive toutes les extensions d'un coup et restaure presque toujours l'accès à l'administration. Remettez le nom d'origine, puis réactivez les extensions une par une jusqu'au retour de l'erreur : vous tenez la coupable.

Une mise à jour de PHP peut-elle provoquer une erreur critique dans WordPress ?

Oui, et c'est l'une des causes les plus fréquentes. Les hébergeurs mettent PHP à jour automatiquement, et du code d'extension ou de thème utilisant une syntaxe supprimée plante immédiatement. La ligne de journal désigne en général un fichier précis dans wp-content. Revenir à la version PHP précédente depuis le panneau d'hébergement confirme le diagnostic, mais reste une rustine temporaire.

Le message d'erreur critique veut-il dire que mon site a été piraté ?

En général non. L'immense majorité des cas vient d'une extension ou d'un thème incompatible avec votre version de PHP, ou d'un dépassement de mémoire. Un malware peut aussi provoquer une erreur fatale, mais la ligne de journal pointera alors vers un fichier inconnu ou du code obfusqué. Lisez le journal avant de conclure à une compromission.

Il y a eu une erreur critique sur ce site web : ce que ça veut dire et comment le réparer

Ce message signifie que PHP a rencontré une erreur fatale pendant la construction de votre page, et que WordPress l’a interceptée avant qu’elle ne devienne une page blanche. L’erreur est réelle, précise et enregistrée quelque part — WordPress refuse simplement de l’afficher dans le navigateur, car une trace d’exécution sur une page publique expose vos chemins de fichiers et votre code à n’importe quel visiteur.

Le dépannage ne se fait donc jamais au hasard. La méthode est : lire l’erreur réelle, puis agir sur ce qu’elle dit.

Ce qui se passe réellement

Depuis WordPress 5.2, le cœur embarque un gestionnaire d’erreurs fatales. Quand PHP meurt en cours de requête, ce gestionnaire prend le relais, remplace la sortie du plantage par la phrase générique polie et — s’il parvient à déterminer quelle extension ou quel thème est en cause — tente d’envoyer à l’administrateur du site un lien vers le mode de récupération.

C’est pour cela que vous voyez ce message au lieu de l’ancien écran blanc de la mort. C’est un progrès, mais cela veut aussi dire que l’information de diagnostic est masquée par défaut. Le message existe en trois variantes :

Ce que vous voyez	Où	Ce que ça vous apprend
« Il y a eu une erreur critique sur ce site web. »	Front-office, déconnecté	Une erreur fatale s’est produite, aucun détail exposé
La même phrase suivie de « En apprendre plus sur le dépannage de WordPress »	Front-office ou wp-admin	Même erreur, WordPress vous propose la page de documentation
« …Veuillez consulter la boîte de réception de l’e-mail d’administration du site pour les instructions. »	Front-office	Le gestionnaire pense avoir envoyé un e-mail de récupération

La troisième variante est la plus utile. Elle indique que WordPress a attribué le plantage à une extension ou un thème précis et a tenté de vous fournir une porte d’entrée.

Étape 1 : vérifier l’e-mail du mode de récupération

WordPress envoie le lien de récupération à l’adresse e-mail d’administration du site — celle qui figure dans Réglages, Général — qui n’est souvent pas l’adresse avec laquelle vous vous connectez. Consultez cette boîte, et regardez aussi les indésirables.

L’e-mail contient un long lien se terminant par quelque chose comme ?action=enter_recovery_mode. En l’ouvrant, vous entrez dans wp-admin en mode de récupération : l’extension ou le thème fautif y est mis en pause et signalé dans un bandeau rouge en haut de l’écran. De là, vous pouvez le désactiver normalement.

Deux réserves honnêtes. D’abord, cet e-mail est généré par le processus PHP qui vient précisément de planter, sur un hébergement qui n’a peut-être aucun transport de courrier fonctionnel : la non-réception est fréquente et ne vous apprend rien sur l’erreur. Ensuite, le lien de récupération expire (environ une journée par défaut), donc un vieil e-mail dans votre boîte peut tout simplement ne plus fonctionner ; provoquez un nouveau plantage en rechargeant le site et attendez le message suivant.

Si vous voulez que cet e-mail arrive dans une boîte que vous consultez vraiment, définissez-la explicitement dans wp-config.php :

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

Étape 2 : lire la vraie erreur

C’est l’étape qui transforme un site cassé en réparation de cinq minutes. Ajoutez ces lignes dans wp-config.php, au-dessus de la ligne qui demande d’arrêter les modifications :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY à false a son importance : cela garde l’erreur hors du navigateur tout en l’écrivant sur le disque, ce qui vous évite d’exposer vos chemins serveur aux visiteurs pendant le débogage.

Rechargez une fois la page cassée, puis ouvrez wp-content/debug.log. La dernière entrée ressemblera à peu près à ceci :

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

Le chemin du fichier est la réponse. S’il pointe dans wp-content/plugins/, c’est cette extension la cause. S’il pointe dans wp-content/themes/, c’est le thème — très souvent un bout de code récemment collé dans functions.php.

Si debug.log n’apparaît pas, le répertoire n’est peut-être pas accessible en écriture, ou une extension de sécurité a déplacé la journalisation ailleurs. Repliez-vous sur le journal d’erreurs PHP de votre hébergeur : la plupart des panneaux d’administration ont une section « Journal d’erreurs » ou « Logs », et la même erreur fatale s’y trouvera avec un horodatage.

Collez l’entrée dans le décodeur de journal d’erreurs WordPress pour traduire la formulation PHP en ce qu’elle signifie concrètement et savoir quel fichier ouvrir en premier.

Supprimez ces lignes de débogage une fois terminé. Laisser WP_DEBUG actif en production remplit le disque et, si WP_DEBUG_DISPLAY repasse un jour à true, affiche publiquement vos chemins serveur.

Étape 3 : retrouver l’accès à wp-admin

Si wp-admin est mort lui aussi et qu’aucun e-mail de récupération n’est arrivé, désactivez toutes les extensions au niveau du système de fichiers. Connectez-vous en SFTP (ou via le gestionnaire de fichiers de votre hébergeur) et renommez un seul dossier :

mv wp-content/plugins wp-content/plugins-off

WordPress ne trouve plus les extensions, les désactive donc toutes, et l’accès à l’administration revient presque toujours. Ensuite :

Renommez le dossier en plugins. Tout reste désactivé — WordPress les a enregistrées comme inactives.
Réactivez les extensions une par une, en chargeant le front-office après chacune.
Celle qui fait revenir l’erreur est la coupable.

Si le site reste cassé avec toutes les extensions désactivées, le thème est le suspect. Renommez le dossier du thème actif dans wp-content/themes/ : WordPress bascule sur un thème par défaut s’il en existe un d’installé.

Les trois causes à connaître

Une mise à jour d’extension ou de thème qui plante. De loin la plus fréquente. Le journal nomme directement le fichier. Revenez à la version précédente de cette extension, ou laissez-la désactivée et contactez son auteur avec la ligne de journal.

Une incompatibilité de version PHP. Les hébergeurs mettent PHP à jour selon leur calendrier, parfois sans grand préavis. Du code écrit pour un PHP ancien peut cesser d’être interprété sur une version récente. L’indice : vous n’avez rien changé de votre côté et tout casse d’un coup. Revenir d’une version mineure de PHP dans votre panneau d’hébergement est un diagnostic valable — mais considérez cela comme du temps gagné, pas comme une solution. Les vieilles versions de PHP ne reçoivent plus de correctifs de sécurité.

Un dépassement de mémoire. Le journal indique « Allowed memory size of X bytes exhausted ». Relever la limite dans wp-config.php est raisonnable :

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

Soyons clairs sur ce que ça fait : cela repousse le plafond, cela ne corrige pas ce qui a consommé 256 Mo pour afficher une seule page. Si la limite doit sans cesse être augmentée, quelque chose — souvent un import, un constructeur de pages ou une requête mal écrite — est le vrai problème.

Les conseils que vous pouvez ignorer sans risque

« Augmentez simplement la limite de mémoire. » Pertinent uniquement si le journal indique effectivement un dépassement de mémoire. Sinon, cela ne change rien et masque le fait que vous n’avez jamais lu l’erreur.

« Réinstallez le cœur de WordPress. » Les fichiers du cœur sont rarement en cause, et les remplacer gaspille le temps que vous pourriez consacrer à lire une seule ligne de journal.

« Désactivez le gestionnaire d’erreurs fatales. » Une constante permet effectivement de le couper, et le résultat est que l’erreur brute s’affiche sur votre site public au lieu d’être interceptée. Cela expose vos chemins de fichiers aux visiteurs. Utilisez plutôt WP_DEBUG_LOG avec WP_DEBUG_DISPLAY désactivé : même information, aucune exposition.

« Videz votre cache. » Une erreur fatale survient dans PHP avant qu’une extension de cache puisse servir quoi que ce soit. Si une copie en cache de la page d’erreur est servie, vider le cache aide après avoir corrigé la cause — jamais à la place.

Toujours bloqué ?

Si le journal désigne un fichier du cœur plutôt qu’un fichier dans wp-content, l’explication la plus probable est une extension chargée plus tôt qui a cassé un état dont le cœur dépend, pas un cœur corrompu. Coupez tout avec le renommage de dossier, vérifiez que le site charge proprement, puis réintroduisez les extensions une par une : la dernière activée avant le retour de l’erreur est celle à signaler, ligne de journal à l’appui.