« Une erreur critique est survenue sur ce site » ? Commencez par la boîte mail de l’administrateur : depuis WordPress 5.2, un e-mail automatique vous y attend, avec un lien de connexion en mode dépannage et, la plupart du temps, le nom de l’extension responsable. Si cet e-mail n’arrive pas, la marche à suivre tient en trois étapes : lire le journal d’erreurs, neutraliser les extensions, puis le thème.
Ce que « erreur critique » signifie exactement
Derrière ce message se cache une erreur fatale PHP : un bout de code a demandé quelque chose d’impossible et l’exécution s’est arrêtée net. WordPress affiche alors une page neutre plutôt que de laisser apparaître un message technique, qui révélerait des chemins de fichiers à d’éventuels attaquants.
Ce message est donc volontairement vague. Il ne dit rien de la cause, et c’est normal : l’information réelle se trouve ailleurs, dans l’e-mail de récupération et dans les journaux d’erreurs. Tout l’enjeu consiste à aller la chercher plutôt qu’à tâtonner.
Bonne nouvelle au passage : depuis la version 5.2, WordPress dispose d’un gestionnaire d’erreurs fatales qui met automatiquement en pause l’extension ou le thème fautif quand il parvient à l’identifier. Il arrive donc que le site se rétablisse partiellement tout seul.
Étape 1 — L’e-mail de récupération
WordPress envoie un e-mail à l’adresse d’administration du site, celle renseignée dans Réglages > Général. Son objet ressemble à « Votre site rencontre un problème technique ». Vérifiez les indésirables, il y atterrit souvent.
Cet e-mail contient trois choses précieuses :
- le nom de l’extension ou du thème en cause, quand WordPress a pu le déterminer ;
- le détail technique de l’erreur, avec le fichier et la ligne concernés ;
- un lien vers le mode dépannage, du type
/wp-login.php?action=enter_recovery_mode&rm_token=…, qui vous permet de vous connecter à l’administration malgré la panne.
Ce lien expire au bout d’un jour. Ce n’est pas grave : si l’erreur se reproduit après expiration, WordPress en envoie un nouveau. Une fois connecté en mode dépannage, vous arrivez directement sur la page des extensions ou des thèmes, avec un bandeau indiquant lequel est en pause. Désactivez-le, corrigez, puis quittez le mode dépannage via le bouton prévu en haut de l’écran.
Si l’e-mail n’arrive jamais, deux explications : l’adresse d’administration n’est plus relevée par personne — vérifiez-la, c’est fréquent sur les sites repris à un ancien prestataire — ou votre hébergement n’envoie pas correctement les e-mails PHP. Passez à l’étape 2.
Étape 2 — Lire le journal d’erreurs
C’est l’étape que la plupart des gens sautent, et c’est celle qui donne la réponse. Ouvrez wp-config.php par FTP et ajoutez ces lignes avant la ligne « Nous avons fini, bonne publication ! » :
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );Ce réglage enregistre les erreurs sans les afficher aux visiteurs. Rechargez la page qui plante, puis ouvrez wp-content/debug.log. La dernière ligne Fatal error mentionne le fichier fautif : son chemin vous indique immédiatement s’il s’agit d’une extension, du thème ou du cœur.
Si le fichier reste vide, le site plante peut-être avant même d’atteindre ce réglage. Cherchez alors le journal d’erreurs du serveur, accessible depuis votre panneau d’hébergement, souvent nommé error_log et situé à la racine du site.
À ne pas oublier : une fois le problème réglé, repassez WP_DEBUG à false et supprimez debug.log. Ce fichier est accessible publiquement et expose des chemins serveur.
Étape 3 — Neutraliser les extensions
Les extensions sont responsables de la grande majorité des erreurs critiques. Sans accès à l’administration, la manipulation se fait par FTP : renommez le dossier wp-content/plugins en plugins-off pour toutes les désactiver d’un coup.
Si le site revient, vous avez confirmé la piste. Remettez le nom d’origine, puis réactivez les extensions par moitiés successives pour isoler la coupable en quelques tests. La procédure complète, y compris pour les sites sans accès FTP, est détaillée dans notre guide sur la désactivation d’une extension en FTP.
Étape 4 — Écarter le thème
Si le site plante encore avec toutes les extensions désactivées, le thème devient le suspect principal. Renommez son dossier dans wp-content/themes/ : WordPress bascule automatiquement sur un thème par défaut, à condition qu’un thème Twenty soit encore présent. Si aucun ne l’est, téléversez-en un avant de renommer le vôtre, sans quoi le site restera cassé.
Quand le thème est en cause, l’origine est très souvent un extrait de code ajouté dans functions.php. Si vous avez collé un bout de code trouvé en ligne dans les minutes précédant la panne, c’est là qu’il faut regarder : retirez-le et rechargez.
La cause n°1 aujourd’hui : une version de PHP incompatible
Un scénario devenu classique : votre hébergeur fait passer le serveur d’une ancienne version de PHP à une plus récente, et une extension ancienne, écrite pour PHP 7, cesse de fonctionner du jour au lendemain. Le site tournait parfaitement la veille, personne n’a rien touché, et pourtant il plante.
Le signe qui ne trompe pas : le journal d’erreurs affiche une Uncaught Error ou une Parse error mentionnant une fonction supprimée du langage. La solution immédiate consiste à revenir temporairement à la version de PHP précédente depuis votre panneau d’hébergement, puis à mettre à jour ou remplacer l’extension concernée. Le retour en arrière n’est qu’un pansement : ne restez pas sur une version de PHP obsolète, qui n’est plus corrigée en cas de faille.
Les autres causes fréquentes
- Mémoire insuffisante. Le journal mentionne
Allowed memory size exhausted. Ajoutezdefine( 'WP_MEMORY_LIMIT', '256M' );danswp-config.php. Si cela ne suffit pas, la limite est fixée côté serveur et seul l’hébergeur peut la relever. - Fichiers du cœur corrompus. Après une mise à jour interrompue, retéléchargez WordPress depuis le site officiel et remplacez par FTP les dossiers
wp-adminetwp-includes. Ne touchez ni àwp-content, ni àwp-config.php. - Deux extensions qui se marchent dessus. Deux caches, deux extensions SEO, deux constructeurs de pages : le conflit est prévisible. N’en gardez qu’une par fonction.
- Une mise à jour restée en plan. Si le message parlait de maintenance avant de devenir une erreur critique, commencez par débloquer le mode maintenance.
Si la panne se répète
Une erreur critique isolée est un accident. Une erreur critique tous les quinze jours est un symptôme. Regardez alors du côté des fondations plutôt que des extensions : version de PHP figée par l’hébergeur, mémoire trop juste, disque saturé, ou serveur mutualisé qui coupe les processus trop longs aux heures de pointe. Demandez à votre hébergeur de relever memory_limit et max_execution_time — c’est gratuit et souvent suffisant. Si sa réponse est qu’aucun réglage n’est possible sur votre formule, le problème n’est plus votre site.
Questions fréquentes
Ai-je perdu mon contenu ?
Non. Une erreur critique est une interruption de l’exécution du code PHP, pas une perte de données. Vos articles, pages, médias et réglages restent dans la base de données et dans le dossier wp-content, intacts. Le site est inaccessible, il n’est pas effacé. Une fois la cause écartée, tout réapparaît tel quel, sans manipulation de restauration.
Je ne reçois pas l’e-mail de récupération, pourquoi ?
Trois causes possibles. L’adresse d’administration dans Réglages > Général n’est plus relevée, cas fréquent sur un site repris à un prestataire. L’e-mail est parti dans les indésirables. Ou votre hébergement n’envoie pas correctement les messages PHP, problème courant sur les offres mutualisées. Dans ce dernier cas, le passage par un service SMTP règle durablement la question, au-delà de ce seul e-mail.
Comment accéder au mode dépannage sans l’e-mail ?
Le mode dépannage repose sur un jeton envoyé par e-mail : il n’est pas déclenchable manuellement depuis le navigateur. Sans cet e-mail, passez directement par les fichiers, qui donnent le même résultat : renommez le dossier des extensions, puis celui du thème. C’est plus manuel, mais cela fonctionne dans tous les cas, y compris quand WordPress est trop cassé pour envoyer quoi que ce soit.
Faut-il restaurer une sauvegarde immédiatement ?
Pas en premier réflexe. Une restauration remet le site dans un état antérieur, mais efface aussi le travail fait depuis, et surtout elle ne vous apprend rien : si la cause était une incompatibilité PHP, la panne reviendra. Cherchez d’abord la cause dans le journal d’erreurs. La restauration se justifie si le site reste cassé après avoir écarté extensions et thème, ou si l’urgence commerciale ne laisse pas le temps du diagnostic.
L’erreur critique affecte-t-elle mon référencement ?
Quelques heures d’indisponibilité n’ont pas d’effet durable : Google repasse et reprend l’exploration. Le risque apparaît si la panne dure plusieurs jours, car les pages concernées peuvent finir par sortir de l’index. Surveillez le rapport de couverture dans la Search Console dans les jours qui suivent, et corrigez en priorité les pages qui vous apportent du trafic.
Peut-on éviter les erreurs critiques ?
On peut fortement les raréfier. Mettez à jour une extension à la fois plutôt qu’en lot, sauvegardez avant chaque mise à jour majeure, limitez le nombre d’extensions installées, écartez celles qui ne sont plus maintenues, et testez les changements sensibles sur une copie de préproduction. Enfin, surveillez les annonces de votre hébergeur sur les changements de version de PHP : ce sont elles qui déclenchent les pannes les plus inattendues.