Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

« Erreur critique » sur votre site WordPress

Le message « Une erreur critique s’est produite sur ce site » ne donne aucun détail par défaut : c’est volontaire, WordPress masque l’erreur réelle pour ne pas exposer d’informations sensibles. Il faut aller la chercher dans les logs pour savoir quoi corriger.

Décrire mon problème Écrire un message

Comment je procède

  1. Activation du débogage

    Je passe WP_DEBUG et WP_DEBUG_LOG à true dans wp-config.php pour faire apparaître l’erreur réelle dans wp-content/debug.log au lieu du message générique.

  2. Lecture de l’erreur PHP

    Je lis la trace complète : fichier, ligne, fonction en cause. La plupart du temps, c’est une fonction dépréciée ou un fichier manquant dans un plugin ou le thème.

  3. Isolation par renommage

    Je renomme le dossier du plugin suspect (ou tout wp-content/plugins) pour désactiver sans passer par l’interface d’administration, souvent inaccessible dans ce cas.

  4. Vérification de compatibilité

    Je vérifie la version de PHP du serveur : beaucoup d’erreurs critiques apparaissent après une montée de version PHP automatique chez l’hébergeur, incompatible avec un vieux plugin.

  5. Correction et remise en ligne

    Je corrige, mets à jour ou remplace l’élément fautif, je vide les caches actifs (plugin de cache, cache serveur) et je repasse WP_DEBUG sur false.

Lire debug.log : ce que dit la dernière ligne

Selon la version de WordPress, l’écran affiche « Il y a eu une erreur critique sur ce site » ou une formulation voisine ; derrière, la ligne utile du journal commence par PHP Fatal error. Le chemin qu’elle cite désigne le coupable : wp-content/plugins/nom-de-l-extension/ pour une extension, wp-content/themes/nom-du-theme/ pour le thème. Les messages que je rencontre le plus :

  • Uncaught Error: Call to undefined function : l’extension appelle une fonction qui n’existe plus dans la version de PHP du serveur, ou qui appartient à une extension dont elle dépend et qui est désactivée — un module complémentaire de WooCommerce quand WooCommerce lui-même est désactivé, par exemple.
  • Allowed memory size of … bytes exhausted : la limite mémoire est atteinte. Relever WP_MEMORY_LIMIT débloque, mais il reste à trouver ce qui consomme autant.
  • Cannot redeclare : deux extensions, ou une extension installée en double, déclarent la même fonction.
  • Failed opening required : un fichier manque, signe typique d’une mise à jour interrompue. Réinstaller la même version de l’extension suffit souvent.
  • syntax error, unexpected : un fichier a été modifié à la main, le plus souvent le functions.php du thème via l’éditeur de fichiers de l’administration.

Sans accès FTP : le mode de récupération, et ses limites

Depuis la version 5.2, quand une extension ou le thème provoque une erreur fatale, WordPress envoie à l’adresse e-mail d’administration un message contenant un lien de connexion en mode de récupération. Ce lien ouvre l’administration en mettant en pause l’élément fautif, ce qui permet de le désactiver sans FTP. Il est temporaire, et il n’arrive pas si l’adresse d’administration est obsolète ou si le site n’envoie pas d’e-mails. Dans ce cas, renommer le dossier de l’extension par FTP ou depuis le gestionnaire de fichiers de l’hébergeur reste la voie la plus sûre.

Si l’erreur critique n’apparaît que sur le panier ou la page de commande, le coupable est presque toujours la passerelle de paiement ou une extension de livraison, appelées seulement à cette étape : voir problème de paiement WooCommerce. Et si le même symptôme touche une autre plateforme, le mécanisme est détaillé dans d’où vient une erreur 500.

Ce que je traite régulièrement

  • Message « Une erreur critique s’est produite sur ce site WordPress »
  • Écran blanc total, site public ou administration
  • Erreur apparue juste après une mise à jour automatique de plugin ou de WordPress
  • Site fonctionnel puis cassé sans action apparente, souvent après une mise à jour PHP silencieuse de l’hébergeur
  • Impossible d’accéder à wp-admin pour désactiver le plugin en cause

Les causes les plus fréquentes

Sur un site WordPress, l’erreur critique vient dans l’immense majorité des cas d’un conflit entre plugins, ou d’une incompatibilité entre un plugin/thème et la version de PHP du serveur. Une fonction appelée par un vieux plugin peut avoir été supprimée dans une version récente de PHP, ce qui provoque une erreur fatale immédiate.

Le deuxième cas fréquent est une mise à jour interrompue : coupure réseau ou timeout pendant une mise à jour automatique de plugin, laissant des fichiers à moitié écrits. WordPress détecte parfois ce cas et active un mode maintenance qui reste bloqué (fichier .maintenance à la racine).

Enfin, un dépassement de la limite mémoire PHP (WP_MEMORY_LIMIT) peut aussi provoquer ce type d’erreur, en particulier sur des sites avec beaucoup de plugins actifs simultanément ou des imports de données volumineux.

wp-config.php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Pages liées

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quelle est l’ampleur du problème ?
Quel type de message s’affiche ?
Qu’est-ce qui a changé juste avant ?

Neuf fois sur dix, une extension ou un thème récemment mis à jour est en cause.

WP_DEBUG est-il activé dans wp-config.php ? (facultatif)

Cette option révèle le fichier et la ligne exacts en cause, au lieu du message générique affiché aux visiteurs.

De quels accès disposez-vous ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Est-ce que je risque de perdre mes articles ou mes commandes ?
Non. L’erreur critique empêche l’affichage des pages, elle n’altère pas la base de données. Vos contenus, commandes et clients restent intacts.
Pourquoi je n’avais rien touché et le site s’est cassé tout seul ?
C’est fréquent : une mise à jour automatique de plugin, ou une montée de version PHP décidée par l’hébergeur sans prévenir, suffit à casser un site resté stable depuis des mois.
Quels accès dois-je vous fournir ?
Un accès FTP ou SSH pour lire les fichiers et les logs, et un accès à la base de données. Si wp-admin est accessible, ses identifiants aident aussi mais ne sont pas indispensables.
Combien de temps pour remettre le site en ligne ?
Dans la majorité des cas, l’identification du plugin ou du fichier fautif se fait en moins d’une heure une fois les accès obtenus. La correction elle-même dépend de ce qui est cassé.
Comment éviter que ça se reproduise ?
Je peux limiter les mises à jour automatiques de plugins sensibles et mettre en place un environnement de test pour valider les mises à jour avant de les appliquer en production.
Que faire si je ne reçois pas l’e-mail du mode de récupération ?
Vérifiez d’abord les indésirables de l’adresse d’administration, celle des réglages généraux de WordPress, souvent obsolète. Si rien n’arrive, passez par le FTP ou le gestionnaire de fichiers de l’hébergeur : renommer le dossier de l’extension fautive dans wp-content/plugins la désactive immédiatement, et ses réglages restent en base.