Le « White Screen of Death » reste l'une des pannes les plus déstabilisantes sous WordPress : aucun message, aucune indication, juste une page totalement blanche. Ce silence n'est pourtant pas un mystère technique : il cache presque toujours une erreur fatale PHP que le serveur a simplement choisi de ne pas afficher, par mesure de sécurité en production.
Étape 1 : révéler l'erreur cachée
La première chose à faire est de forcer l'affichage de l'erreur réelle. Dans wp-config.php, activez temporairement le mode debug avec les lignes suivantes, qui enregistrent l'erreur dans un fichier journal sans l'afficher publiquement aux visiteurs :
- define('WP_DEBUG', true);
- define('WP_DEBUG_LOG', true);
- define('WP_DEBUG_DISPLAY', false);
L'erreur apparaît alors dans le fichier wp-content/debug.log, avec le nom exact du fichier et la ligne en cause. Si l'hébergement dispose d'un journal d'erreurs PHP global, accessible depuis le panneau de contrôle, il contient généralement la même information sans même avoir à modifier wp-config.php.
Étape 2 : identifier la cause la plus probable
Les causes les plus fréquentes d'une page blanche, dans l'ordre de probabilité, sont :
- Une mise à jour récente d'un plugin ou d'un thème qui introduit une incompatibilité avec la version de PHP active.
- Une limite de mémoire PHP dépassée (le message correspondant apparaît alors clairement dans le journal).
- Une erreur de syntaxe introduite par une modification manuelle d'un fichier (functions.php notamment).
- Un conflit entre deux extensions qui déclarent la même fonction ou la même classe.
Étape 3 : isoler le coupable par élimination
Si le message d'erreur ne suffit pas à identifier directement le fichier en cause, la méthode d'élimination reste la plus fiable :
- Via FTP ou le gestionnaire de fichiers, renommez le dossier wp-content/plugins en plugins-test. WordPress désactive alors automatiquement toutes les extensions sans perdre leur configuration, et renommer le dossier à son nom d'origine les réactive toutes d'un coup.
- Si le site revient, le problème vient d'un plugin. Renommez le dossier à son nom d'origine, puis réactivez les extensions une par une depuis l'administration jusqu'à reproduire l'erreur et identifier la coupable.
- Si le site reste blanc même sans aucune extension, répétez l'opération en renommant le dossier du thème actif, ce qui force WordPress à basculer sur un thème par défaut.
Étape 4 : restaurer si rien ne fonctionne
Si aucune de ces étapes ne résout le problème, ou si l'erreur provient d'une corruption plus profonde (base de données, fichiers core modifiés), la restauration d'une sauvegarde récente reste la solution la plus rapide et la plus sûre, à condition de disposer d'un point de restauration fiable.
Prévenir plutôt que diagnostiquer dans l'urgence
La meilleure façon de gérer une page blanche reste de ne jamais avoir à la diagnostiquer en production. Quelques habitudes simples réduisent nettement ce risque :
- Tester toute mise à jour de thème ou de plugin sur une copie du site avant de l'appliquer en production, surtout pour les extensions qui touchent profondément au fonctionnement du site (constructeur de page, cache, sécurité).
- Conserver une sauvegarde récente et facilement restaurable avant toute mise à jour, pour transformer un incident potentiellement long en une simple restauration de quelques minutes.
- Activer une alerte de disponibilité qui vous notifie immédiatement si le site devient inaccessible, plutôt que de découvrir la panne par un appel client mécontent.
En complément du journal propre à WordPress, le journal d'erreurs du serveur web lui-même (error.log sous Apache ou Nginx, accessible depuis le panneau d'hébergement) mérite aussi d'être consulté : certaines erreurs surviennent avant même que WordPress n'ait eu la main, par exemple une mauvaise configuration PHP-FPM ou une extension PHP manquante, des cas où le journal applicatif de WordPress reste muet alors que le journal serveur contient l'information clé.
Pourquoi WordPress n'affiche-t-il pas directement l'erreur ?
Par mesure de sécurité, un site en production masque les messages d'erreur détaillés aux visiteurs, car ils peuvent révéler des informations sensibles (chemins de fichiers, structure du code) exploitables par un attaquant. L'activation de WP_DEBUG_LOG permet de consulter l'erreur sans l'exposer publiquement.
Faut-il laisser WP_DEBUG actif en permanence ?
Non, uniquement le temps du diagnostic. Le mode debug ajoute une charge de traitement et peut exposer des informations sensibles s'il est mal configuré ; il doit être désactivé une fois le problème résolu.
Disposer d'une sauvegarde récente change complètement la donne face à ce type de panne : la restauration en un clic proposée par CodeGuard permet de revenir à une version fonctionnelle en quelques minutes plutôt que de chercher l'erreur dans l'urgence. Nos offres d'hébergement WordPress incluent l'accès aux journaux d'erreurs nécessaires à ce diagnostic.
