Critical error sur WordPress - Causes & solutions

Symptômes : comment confirmer le diagnostic

Avant toute manipulation, identifie précisément ton scénario. La nature exacte de l'affichage oriente directement la procédure de réparation, et c'est ce tri que les guides génériques zappent.

Le message officiel depuis WordPress 5.2 est, en français :

• Front affiche le message d'erreur + back-office accessible : exception sur une page/route spécifique. Le moins grave — connecte-toi à /wp-admin et regarde Outils » Santé du site.
• Front ET back-office affichent le message : exception globale (souvent un plugin actif partout ou functions.php). Vise l'email de récupération ou le FTP.
• Écran totalement blanc (WSOD), aucun texte : le gestionnaire d'erreurs WordPress n'a même pas pu s'exécuter — erreur très précoce (wp-config.php cassé, fatal dans un mu-plugin, ou WP_DEBUG masqué). Passe directement au debug.log.
• Message visible côté front mais admin inaccessible : c'est le cas le plus fréquent post-mise à jour ou post-installation de plugin. Le mode récupération est ton meilleur réflexe.

1. Note l'horodatage exact de l'apparition de l'erreur.
2. Rappelle-toi ta dernière action : mise à jour de plugin/thème/core, installation, ou édition de code ? 90 % des erreurs critiques surviennent dans les minutes qui suivent l'une de ces actions.
3. Vérifie si l'écran change selon l'URL (front d'accueil vs /wp-admin vs une page produit) : un comportement différent par route confirme un conflit ciblé plutôt qu'une panne serveur.

Une erreur critique est survenue sur ce site. Veuillez consulter la boîte de réception de l'e-mail d'administration de votre site pour plus d'informations.

Impact business immédiat

Une erreur critique sur une boutique n'est pas un simple bug cosmétique : elle coupe le tunnel d'achat et les signaux que tu envoies aux moteurs.

Concrètement, tant que l'écran reste affiché :

• Toutes les commandes et demandes entrantes sont interrompues — chaque visiteur tombe sur l'erreur au lieu de la fiche produit ou du panier.
• Perte de crédibilité immédiate : un visiteur qui voit « erreur critique » ne revient généralement pas, et peut le signaler sur tes réseaux.
• Risque SEO réel si la panne dure : Googlebot qui crawle pendant l'incident reçoit un HTTP 500. Quelques heures sont tolérables, mais une panne de plusieurs jours peut faire désindexer des URLs.
• Les emails transactionnels (confirmation de commande, reset mot de passe) peuvent aussi tomber si le fatal se déclenche sur des hooks d'envoi.

Causes classées par probabilité

Depuis la version 5.2, l'erreur critique remplace la page blanche de la mort (WSOD) : elle attrape une exception PHP fatale via le gestionnaire d'erreurs intégré. La cause se range presque toujours dans cette liste, par ordre de fréquence réelle observée en intervention :

• Plugin incompatible (le plus fréquent) : un plugin actif appelle une fonction qui n'existe pas/plus, souvent après une mise à jour. Typique sur PHP 8.2+ avec des plugins non maintenus utilisant des fonctions dépréciées (each(), create_function()).
• Thème cassé après update : functions.php du thème déclenche un fatal, ou le thème actif a été supprimé/déplacé.
• Version PHP non compatible : passage à PHP 8.x qui casse du code écrit pour PHP 7.x. À l'inverse, un plugin récent peut exiger PHP 8.1+ sur un hébergement resté en 7.4.
• Code personnalisé : un snippet ajouté dans functions.php ou via un plugin de snippets (WPCode) avec une erreur de syntaxe — la cause la plus brutale car elle peut tuer le site instantanément à l'enregistrement.
• Mémoire PHP dépassée : « Allowed memory size exhausted ». Attention, c'est souvent un symptôme (un plugin qui boucle) plus qu'une vraie cause — voir la nuance plus bas.
• Fichier core corrompu : upload FTP interrompu, transfert partiel de /wp-admin ou /wp-includes. Plus rare.
• Conflit réseau : wp_remote_get qui échoue sur un hébergement mutualisé avec cURL désactivé, sur WordPress 6.4+.

Diagnostic : les commandes à lancer

Ne devine pas le plugin fautif : lis-le. La différence entre une réparation de 5 minutes et 2 heures de tâtonnement, c'est le debug.log. Active d'abord le débogage en éditant wp-config.php via FTP (FileZilla) ou SSH, juste au-dessus de la ligne /* That's all, stop editing! Happy blogging. */ :

• Allowed memory size of X bytes exhausted → limite mémoire (souvent un plugin qui boucle).
• Call to undefined function ... → plugin ou version PHP incompatible.
• Maximum execution time of 30 seconds exceeded → timeout, ajuster max_execution_time / process lourd.
• syntax error, unexpected ... → édition récente de functions.php ou d'un snippet.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );    // écrit dans wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // NE PAS afficher à l'écran en prod
define( 'SCRIPT_DEBUG', true );

Beaucoup de tutoriels mettent WP_DEBUG_DISPLAY à true. C'est une erreur en production :
afficher les erreurs expose les chemins absolus de ton serveur (/home/user/...) et
des détails exploitables par un attaquant. On LOGGE l'erreur, on ne l'AFFICHE pas.

# Les 30 dernières lignes du journal WordPress
tail -n 30 wp-content/debug.log

# Filtrer uniquement les erreurs fatales
grep -i "PHP Fatal error" wp-content/debug.log | tail -n 5

# Si pas d'accès SSH : ouvre wp-content/debug.log via FTP
# et regarde aussi le log serveur (hors WordPress) :
tail -n 50 error_log
tail -n 50 ~/.logs/error_log_tondomaine.com

PHP Fatal error:  Uncaught Error: Call to undefined function wpcf7_init()
  in /home/user/public_html/wp-content/plugins/contact-form-7/wp-contact-form-7.php on line 312

>> Le chemin .../plugins/contact-form-7/... NOMME le plugin fautif : contact-form-7.
>> 'Call to undefined function' = fonction manquante = plugin/PHP incompatible.
>> La ligne 312 te dit où, mais tu n'as pas besoin de toucher au code : désactive le plugin.

# Vérifier la version PHP du serveur
php -v

# Lister les plugins actifs (souvent où se cache le coupable)
wp plugin list --status=active

# Vérifier l'intégrité des fichiers core (détecte un fichier corrompu)
wp core verify-checksums

# Activer le debug sans éditer le fichier à la main
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw

Solutions pas-à-pas

Procède de la correction la plus ciblée (qui garde le site partiellement en ligne) à la plus radicale (restauration). Une fois la cause lue dans le debug.log, tu sais souvent quelle étape attaquer directement.

1. Méthode email / mode récupération (résout environ la moitié des cas). WordPress envoie automatiquement à l'admin un email intitulé « Your Site is Experiencing a Technical Issue ». Il contient un lien valable 24h vers /wp-login.php?action=enter_recovery_mode&rm_token=XXX. Clique, connecte-toi : WordPress te montre quel plugin/thème déclenche le fatal et te laisse le désactiver en un clic, sans FTP.
2. Pas reçu l'email ? Vérifie tes spams, confirme l'adresse dans Réglages » Général (option admin_email), et sache que certains hébergeurs mutualisés bloquent l'envoi PHP mail(). Si rien n'arrive, passe au FTP — l'email n'est pas indispensable.
3. Désactivation chirurgicale d'UN plugin par FTP. Si le log nomme un plugin précis, va dans wp-content/plugins et renomme SON dossier uniquement (ex. contact-form-7 → contact-form-7.off). WordPress le désactive et le reste du site reste en ligne — bien plus fin que tout couper.
4. Désactivation de masse si tu ne sais pas lequel. Renomme le dossier wp-content/plugins en plugins.deactivated : tout est désactivé d'un coup. Si le site revient, remets le nom d'origine puis réactive les plugins un par un dans /wp-admin jusqu'à reproduire l'erreur. En SSH : wp plugin deactivate --all.
5. Tester le thème. Si désactiver les plugins ne suffit pas, renomme le dossier du thème actif dans wp-content/themes : WordPress bascule automatiquement sur le thème par défaut (Twenty Twenty-Four/Five). Si le site repart, le problème vient du thème ou de son functions.php.
6. Annuler une mise à jour récente (rollback). Si l'erreur est apparue juste après un update, c'est presque toujours la cause. Réinstalle la version stable précédente du plugin/thème (le plugin WP Rollback ou un upload manuel de l'ancienne version par FTP).
7. Mémoire PHP, avec nuance. Si le log dit « memory exhausted », ajoute dans wp-config.php : define( 'WP_MEMORY_LIMIT', '256M' ); puis '512M' si besoin. Ne monte PAS à 1536M comme le suggèrent certains hébergeurs : au-delà de 512M, le manque de mémoire est le symptôme d'un plugin qui dérape, pas la cause — tu masquerais le vrai problème.
8. Mettre PHP à niveau (ou rétrograder). Vérifie ta version via Outils » Santé du site » Info » Serveur. Passe sur PHP 8.2 ou 8.3 si tu es sur une 7.4 obsolète, OU reste/reviens à une version supportée par ton plugin. Change la version dans le panneau de ton hébergeur.
9. Réinstaller le core si verify-checksums signale des fichiers corrompus. Télécharge WordPress depuis fr.wordpress.org, et remplace UNIQUEMENT les dossiers /wp-admin et /wp-includes par FTP (ne touche jamais à wp-content ni wp-config.php).
10. Restaurer une sauvegarde en dernier recours, seulement si elle est récente, vérifiée, et plus rapide qu'un rollback ciblé. Une restauration écrase aussi les commandes passées depuis le backup — à éviter sur une boutique active si une correction chirurgicale est possible.
11. Remise en production (l'étape oubliée). Une fois réparé : repasse WP_DEBUG à false dans wp-config.php, supprime ou archive wp-content/debug.log, vide le cache (plugin de cache + CDN/hébergeur) et purge OPcache. Sans ça, tes visiteurs peuvent encore voir une version en cache de l'erreur.

Spécificités par version

Le comportement face à l'erreur critique dépend de ta version de WordPress et de PHP.

• Avant WordPress 5.2 : pas de gestionnaire d'erreurs ni de mode récupération — tu obtenais une page blanche (WSOD) muette. La seule voie était le FTP + debug.log. Si tu vois encore un écran totalement blanc sur une install récente, c'est que l'erreur survient AVANT le chargement du gestionnaire (wp-config, mu-plugin).
• WordPress 5.2 (mai 2019) et + : introduction du recovery mode, de l'email automatique et du fichier de gestion fatal-error-handler. C'est ce qui rend l'URL /wp-login.php?action=enter_recovery_mode possible. Le lien stocké côté serveur (option recovery_keys) expire après 24h.
• WordPress 6.4+ : durcissement de certains appels réseau ; un conflit wp_remote_get sur hébergement mutualisé avec cURL désactivé peut déclencher un fatal sur des plugins qui font des appels externes.
• PHP 7.4 : minimum techniquement supporté mais en fin de vie — beaucoup de plugins récents le refusent.
• PHP 8.0–8.1 : suppression de fonctions historiques (each(), create_function()) → casse les plugins/thèmes anciens. C'est la source n°1 d'erreurs critiques après une montée de version PHP.
• PHP 8.2–8.3 : propriétés dynamiques dépréciées ; du code ancien peut générer des warnings devenus bloquants. Recommandé pour les installs à jour, à condition que tous tes plugins suivent.

Quand appeler un expert

Tu peux résoudre seul la grande majorité des erreurs critiques avec la méthode ci-dessus. Certaines situations justifient pourtant un renfort, surtout sur une boutique qui prend des commandes en continu.

Fais appel à un expert si : le debug.log pointe un fatal dans le core ou la base de données et non un plugin ; la désactivation de tous les plugins ne corrige rien (suspicion de fichier core ou de table SQL corrompue) ; tu n'as ni FTP ni SSH ni accès au panneau hébergeur ; ou si l'erreur est apparue avec des signes de compromission (fichiers inconnus, modifications de wp-config). Dans ces cas, une mauvaise manipulation peut transformer une panne réversible en perte de données.

Si tu veux une remise en ligne rapide et une correction sécurisée plutôt qu'un correctif à l'aveugle, BugRescue (Soulaimane Aattar) diagnostique la stack trace, isole le coupable et sécurise la remise en prod — sans écraser tes commandes récentes par une restauration brutale.

FAQ