La WordPress erreur critique s’affiche quand une extension ou le thème actif génère une erreur PHP fatale. Solution immédiate : accéder au dossier wp-content/plugins/ via FTP ou le gestionnaire de fichiers cPanel, renommer le dossier de la dernière extension installée ou mise à jour, puis recharger le site. Si l’accès FTP n’est pas disponible, WordPress 5.2 et supérieur envoie automatiquement un email à l’adresse admin avec un lien de récupération. En activant le mode debug dans wp-config.php, le journal des erreurs identifie la ligne PHP exacte en cause. Dans plus de 90 % des cas, le coupable est une extension incompatible avec la version PHP active ou avec la version de WordPress.

Qu’est-ce que l’erreur critique WordPress ?

Depuis WordPress 5.2 (mai 2019), le traditionnel « écran blanc de la mort » (WSOD) a été remplacé par un message plus explicite : « Une erreur critique est survenue sur votre site. En savoir plus sur le débogage de WordPress. » Ce message correspond à une PHP Fatal Error, c’est-à-dire une erreur que l’interpréteur PHP ne peut pas dépasser et qui interrompt l’exécution du code.

Deux variantes existent en pratique :

  • Écran blanc total (WSOD) : PHP plante avant l’affichage de quoi que ce soit, souvent sur des installations WordPress très anciennes.
  • Message d’erreur critique visible : WordPress intercepte la fatal error et affiche le message standardisé, introduit dans WP 5.2.

Selon les données de WordPress.org, plus de 60 000 extensions sont disponibles dans le dépôt officiel. La qualité du code varie énormément d’un développeur à l’autre, ce qui explique pourquoi les erreurs critiques surviennent le plus souvent après l’installation ou la mise à jour d’une extension tierce.

Les 5 causes les plus fréquentes de l’erreur critique WordPress

Avant d’intervenir, identifier la cause évite de perdre du temps. Voici les scénarios classiques, par ordre de fréquence :

  1. Extension incompatible avec la version PHP : une extension utilise des fonctions PHP supprimées (ex. split() supprimé en PHP 7, create_function() en PHP 8). Fréquent après que l’hébergeur a mis à jour PHP automatiquement.
  2. Conflit entre extensions : deux extensions redéfinissent la même fonction ou classe, ce qui déclenche un Fatal error: Cannot redeclare function.
  3. Thème actif avec erreur PHP : une mise à jour du thème ou un thème enfant mal codé contenant une syntaxe PHP invalide.
  4. Limite mémoire PHP dépassée : erreur Fatal error: Allowed memory size of X bytes exhausted (traité en détail plus bas).
  5. Mise à jour WordPress elle-même : rare, mais une mise à jour majeure peut exposer des incompatibilités avec des extensions anciens non maintenus.

Résoudre via le mode récupération WordPress (wp-admin accessible)

Si l’erreur critique n’affecte que le front-end et que wp-admin reste accessible, WordPress propose un mode récupération intégré depuis la version 5.2. Ce mécanisme désactive automatiquement l’extension ou le thème responsable de l’erreur et envoie un email à l’administrateur du site.

Procédure via le tableau de bord :

  1. Aller dans Extensions > Extensions installées.
  2. Désactiver l’extension récemment installée ou mise à jour.
  3. Recharger le front-end pour confirmer la résolution.
  4. Si le problème persiste, désactiver toutes les extensions, puis les réactiver une par une pour isoler le coupable.

Si wp-admin est lui aussi affecté, le lien de récupération dans l’email admin permet d’accéder à une interface de débogage simplifiée. Ce lien contient un token temporaire valable 1 heure.

Résoudre via FTP ou cPanel quand wp-admin est inaccessible

C’est le scénario le plus stressant : le site est blanc, l’admin aussi. La solution passe par un accès direct aux fichiers du serveur.

Méthode 1 : désactiver toutes les extensions via FTP

  1. Se connecter via FTP (FileZilla, WinSCP) ou via le gestionnaire de fichiers cPanel.
  2. Naviguer vers wp-content/plugins/.
  3. Renommer le dossier plugins en plugins-disabled. WordPress ne peut plus charger aucune extension et utilise son comportement de base.
  4. Recharger le site : si la page d’accueil s’affiche, une extension était responsable.
  5. Renommer le dossier en plugins, puis entrer dans wp-admin (accessible maintenant), et réactiver les extensions une par une.
# Via SSH (si disponible sur l'hébergeur)
cd /home/username/public_html/wp-content/
mv plugins plugins-disabled
# Vérifier le site, puis :
mv plugins-disabled plugins

Méthode 2 : désactiver le thème actif

Si la désactivation des extensions ne résout pas l’erreur, le thème est suspect. Ajouter cette ligne dans wp-config.php force WordPress à utiliser le thème par défaut :

// Forcer le thème Twenty Twenty-Four le temps du diagnostic
define('WP_DEFAULT_THEME', 'twentytwentyfour');

Retirer cette ligne une fois le diagnostic terminé.

Activer le mode debug WordPress pour identifier la ligne exacte

Le mode debug est l’outil le plus précis pour localiser une erreur critique. Il force WordPress à écrire les erreurs PHP dans un fichier journal au lieu de les cacher.

// Dans wp-config.php, avant la ligne "/* That's all, stop editing! */"

// Activer le debug
define('WP_DEBUG', true);

// Écrire les erreurs dans un fichier (ne pas les afficher en front-end)
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

// Masquer les erreurs pour les visiteurs
@ini_set('display_errors', 0);

Le journal des erreurs est écrit dans wp-content/debug.log. Consulter ce fichier révèle la ligne exacte de code PHP qui a planté :

# Lire les dernières erreurs via SSH
tail -50 /home/username/public_html/wp-content/debug.log

# Ou via FTP : télécharger wp-content/debug.log et l'ouvrir dans un éditeur

Le fichier contiendra des lignes comme :

[07-Jul-2026 06:00:01 UTC] PHP Fatal error:
  Uncaught Error: Call to undefined function some_function()
  in /home/username/public_html/wp-content/plugins/bad-plugin/bad-plugin.php:142

La ligne 142 du fichier bad-plugin.php est la coupable. Désactiver cette extension règle immédiatement le problème.

Pour renforcer la sécurité globale du site après un incident de ce type, consultez notre guide sur la sécurisation WordPress avec WAF, headers et CSP : il couvre les vecteurs d’attaque qui exploitent justement les extensions mal maintenus.

Corriger l’erreur « Allowed memory size exhausted » WordPress

Si le fichier debug.log affiche Fatal error: Allowed memory size of X bytes exhausted, la limite mémoire PHP est trop basse. WordPress nécessite au minimum 64 Mo, mais les installations avec beaucoup d’extensions demandent souvent 256 Mo ou plus.

Trois façons d’augmenter cette limite, par ordre de préférence :

Option 1 : via wp-config.php (solution la plus portable)

define('WP_MEMORY_LIMIT', '256M');
// Pour wp-admin spécifiquement :
define('WP_MAX_MEMORY_LIMIT', '512M');

Option 2 : via le fichier php.ini (si l’hébergeur autorise sa modification)

memory_limit = 256M

Option 3 : via .htaccess (hébergements Apache)

php_value memory_limit 256M

Après la modification, vérifier la valeur active avec un fichier phpinfo.php temporaire :

<?php phpinfo(); ?>

Supprimer ce fichier immédiatement après vérification (il expose des informations serveur sensibles). Notre générateur .htaccess WordPress peut aussi vous aider à configurer les directives PHP directement depuis le navigateur.

Prévenir les erreurs critiques WordPress à l’avenir

Une erreur critique survient rarement sans avertissement préalable. Quelques pratiques permettent de les éviter ou de les détecter avant qu’elles affectent le site en production :

  • Tester les mises à jour sur un site de staging : la majorité des hébergeurs modernes (o2switch, WP Engine, Kinsta) proposent un environnement de staging en un clic.
  • Installer l’extension Health Check & Troubleshooting : elle permet d’activer le mode de dépannage sans désactiver les extensions pour les autres visiteurs. Vous voyez l’erreur, eux voient le site normal.
  • Mettre en place des sauvegardes automatiques : en cas d’erreur critique après une mise à jour importante, une restauration en 2 minutes est toujours préférable à 2 heures de débogage.
  • Surveiller les journaux PHP côté serveur : les hébergeurs cPanel exposent les erreurs PHP dans le menu Métriques > Erreurs. Une extension qui génère des warnings répétés deviendra tôt ou tard une fatal error.
  • Vérifier la compatibilité PHP avant toute mise à jour : l’extension PHP Compatibility Checker analyse tous les fichiers PHP installés et signale les incompatibilités avec la version PHP cible.

Les erreurs critiques sont souvent le symptôme d’une gestion des extensions trop permissive. Consulter régulièrement les rapports de vulnérabilités, comme notre article sur les vulnérabilités plugins WordPress King Addons et W3 Total Cache, permet d’anticiper les problèmes avant qu’ils deviennent critiques.

Cas particuliers : erreur critique après migration ou changement PHP

Deux scénarios méritent une attention particulière, car ils surprennent souvent les administrateurs WordPress expérimentés.

Après une migration de serveur : la version PHP du nouveau serveur peut différer de l’ancienne. Un site fonctionnel sous PHP 7.4 peut générer des erreurs critiques sous PHP 8.2 à cause des fonctions dépréciées ou supprimées. La liste des changements de rupture entre PHP 7 et 8 est documentée sur php.net.

# Vérifier la version PHP active via SSH
php -v

# Ou dans wp-config.php, ajouter temporairement :
if (version_compare(PHP_VERSION, '8.0.0', '<')) {
    error_log('Version PHP insuffisante : ' . PHP_VERSION);
}

Après une mise à jour PHP automatique de l’hébergeur : certains hébergeurs mutualisés mettent à jour PHP automatiquement. Le passage de PHP 7.4 à 8.1 ou 8.2 peut casser des extensions utilisant des fonctions obsolètes. Solution : vérifier dans cPanel la version PHP active et la rétrograder temporairement le temps de mettre à jour les extensions incompatibles.

Chez o2switch, la version PHP se modifie depuis cPanel > Logiciels > Sélectionner une version PHP. La modification est instantanée et sans redémarrage.

Sources

  1. WordPress.org : Debugging in WordPress
  2. WordPress Developer Docs : Debug WordPress
  3. Kinsta : Erreurs WordPress courantes et comment les corriger
  4. WPBeginner : How to Fix the Critical Error in WordPress
  5. WordPress Core Blog : Fatal Error Recovery Mode in 5.2
  6. PHP.net : Changements incompatibles PHP 8.0

FAQ : erreur critique WordPress

Qu’est-ce que l’erreur critique « Une erreur critique est survenue sur votre site » ?

C’est un message introduit dans WordPress 5.2 pour signaler une PHP Fatal Error : une erreur que l’interpréteur PHP ne peut pas ignorer et qui interrompt l’exécution du site. Dans 90 % des cas, la cause est une extension ou un thème générant une erreur PHP incompatible avec la version du serveur.

Comment corriger l’erreur critique WordPress sans accès wp-admin ?

Connectez-vous via FTP ou le gestionnaire de fichiers cPanel, et renommez le dossier wp-content/plugins/ en wp-content/plugins-disabled/. WordPress ne peut plus charger les extensions, le site redevient accessible. Connectez-vous ensuite à wp-admin, renommez le dossier à son nom d’origine, puis réactivez les extensions une par une pour identifier le coupable.

L’erreur critique WordPress peut-elle venir d’un problème de mémoire PHP ?

Oui. Le message Fatal error: Allowed memory size of X bytes exhausted est une erreur critique causée par une limite mémoire PHP trop basse. La solution consiste à ajouter define('WP_MEMORY_LIMIT', '256M'); dans wp-config.php ou à augmenter memory_limit dans le fichier php.ini de l’hébergeur.

Comment trouver quelle extension cause l’erreur critique WordPress ?

Activer le mode debug en ajoutant define('WP_DEBUG', true); et define('WP_DEBUG_LOG', true); dans wp-config.php. Le fichier wp-content/debug.log indique alors le nom du fichier PHP et le numéro de ligne exacts de l’erreur fatale. L’extension ou le thème correspondant est le coupable.

Comment éviter les erreurs critiques WordPress lors des mises à jour ?

Testez toujours les mises à jour sur un environnement de staging avant de les appliquer en production. Installez l’extension Health Check & Troubleshooting pour tester les mises à jour sans affecter les visiteurs. Maintenez des sauvegardes automatiques quotidiennes pour pouvoir restaurer le site en moins de 5 minutes si une erreur survient.

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.