← Blog

WordPress & CMS

Écran blanc WordPress (WSOD) : le diagnostic dans l'ordre

Par l’équipe technique HelpApp Pro5 août 20264 min de lecture
Partager
Illustration : Écran blanc WordPress (WSOD) : le diagnostic dans l'ordre

Le White Screen of Death n'est presque jamais une fatalité. Voici comment isoler la cause réelle en quelques minutes — du plus probable au plus rare — sans aggraver la panne.

Un matin, la page d'accueil est blanche. Pas d'erreur, pas de logo, rien. Réponse directe : l'écran blanc WordPress (WSOD) est presque toujours une erreur PHP fatale que WordPress masque, causée dans 9 cas sur 10 par un plugin, sinon par le thème ou une limite mémoire. La première étape n'est donc pas de bricoler, mais de rendre l'erreur visible — ensuite, la cause tombe en quelques minutes. Voici la procédure exacte, dans l'ordre.

Comment voir l'erreur que WordPress cache ?

Par défaut, WordPress masque les erreurs PHP en production : c'est ce masquage qui produit le blanc. Rendez l'erreur visible en modifiant wp-config.php (juste avant la ligne /* That's all, stop editing! */) :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Rechargez la page, puis ouvrez wp-content/debug.log. La dernière ligne ressemble à ceci, et elle nomme le fichier et la ligne exacts du plantage :

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_init()
in /var/www/wp-content/plugins/mon-plugin/mon-plugin.php:42

Vous venez de transformer un mystère en une adresse précise. Remettez WP_DEBUG à false une fois réglé — laisser les logs actifs en production expose des chemins serveur.

Pourquoi un plugin est-il le suspect n°1 ?

Si l'erreur pointe vers wp-content/plugins/, vous tenez le coupable. Le réflexe destructeur — tout désactiver d'un coup depuis phpMyAdmin — vous fait perdre l'information sur *quel* plugin est en cause.

À la place, renommez le dossier de l'extension suspecte via FTP (ou le gestionnaire de fichiers de l'hébergeur) : woocommerce → woocommerce_off. WordPress la désactive au rechargement. Si le site revient, la cause est isolée sans toucher aux autres extensions. En WP-CLI, c'est encore plus rapide :

wp plugin deactivate mon-plugin

Et si ce n'est pas un plugin : thème ou mémoire ?

Si le renommage des plugins ne change rien, l'arbre de décision continue :

  1. Thème : renommez le dossier du thème actif dans wp-content/themes/. WordPress bascule sur un thème par défaut. Site de retour ? Le coupable est le thème — souvent son functions.php modifié à la main ou cassé par une mise à jour.
  2. Mémoire PHP : un blanc sans erreur claire sur une page lourde (admin, page builder) sent la limite mémoire. Ajoutez define( 'WP_MEMORY_LIMIT', '256M' );. Si ça débloque, c'est un pansement : une extension consomme trop, à identifier ensuite.
  3. Cœur WordPress : si l'erreur pointe vers wp-includes/, ne modifiez jamais ces fichiers à la main — c'est le signal d'un fichier corrompu ou d'un piratage.

Checklist express

  • [ ] WP_DEBUG_LOG activé, debug.log lu (le fichier + la ligne du plantage)
  • [ ] Plugin suspect renommé/désactivé → site revient ?
  • [ ] Thème actif renommé → site revient ?
  • [ ] WP_MEMORY_LIMIT augmenté → site revient ?
  • [ ] Erreur qui pointe vers wp-includes/ → stop, ne pas bricoler
  • [ ] WP_DEBUG remis à false après résolution

Questions fréquentes

Comment réparer un écran blanc WordPress sans accès à l'admin ?

Passez par le FTP ou le gestionnaire de fichiers de l'hébergeur : activez WP_DEBUG_LOG dans wp-config.php, lisez wp-content/debug.log, puis renommez le dossier du plugin ou du thème fautif. WordPress désactive automatiquement une extension dont le dossier a été renommé — vous récupérez l'accès sans passer par le back-office.

L'écran blanc peut-il venir d'une mise à jour PHP ?

Oui. Si l'hébergeur a basculé sur une version PHP plus récente, une extension utilisant une fonction supprimée provoque une erreur fatale. Le debug.log le confirme (« Call to undefined function » ou « expects parameter »). La solution est de mettre à jour l'extension ou, en dépannage, de redescendre temporairement la version PHP.

Pourquoi je ne vois toujours rien après avoir activé WP_DEBUG ?

Parce que WP_DEBUG_DISPLAY est à false (recommandé en production) : l'erreur ne s'affiche pas à l'écran mais est écrite dans wp-content/debug.log. C'est ce fichier qu'il faut ouvrir. Si le fichier n'existe pas, vérifiez les droits d'écriture sur wp-content/.

Faut-il restaurer une sauvegarde ?

Seulement si le diagnostic échoue ou si un piratage est suspecté. Dans la majorité des cas (plugin/thème/mémoire), on corrige la cause sans restauration. Gardez néanmoins une sauvegarde à jour avant toute manipulation, par sécurité.

Quand faire appel à HelpApp Pro

Trois signaux disent qu'il faut passer la main : l'erreur pointe vers le cœur de WordPress, un piratage est suspecté, ou le checkout est cassé et chaque heure coûte des ventes. HelpApp Pro intervient sur ce type de blocage sans refonte : on lit le debug.log avec vous, on corrige la cause réelle, et on vérifie que rien d'autre ne casse. Décrivez le symptôme via le devis en ligne, ou passez en urgence si le site est à l'arrêt.

Cet article vous a été utile ?

Partager

Besoin d'une intervention ciblée ?

Décrivez le blocage — devis sans engagement, ou rappel sous 2 h ouvrées. Supplément urgence possible.

À lire aussi