L'écran blanc de la mort de WordPress, expliqué
L'écran blanc de la mort est une erreur critique PHP que vous ne pouvez pas voir. WordPress a rencontré une erreur irrécupérable en plein rendu, PHP s'est arrêté, et comme l'affichage des erreurs
Publié
L’écran blanc de la mort est une erreur critique PHP que vous ne pouvez pas voir. WordPress a rencontré une erreur irrécupérable en plein rendu, PHP s’est arrêté, et comme l’affichage des erreurs est désactivé sur les serveurs de production, la page est revenue vide au lieu d’afficher la raison. La solution ne relève presque jamais du hasard : activez le journal de débogage, ouvrez wp-content/debug.log, et lisez la dernière ligne fatale. Elle nomme le fichier exact — presque toujours un plugin ou un thème — et cette seule ligne constitue toute la réparation.
Pourquoi l’écran est vide
PHP possède un réglage appelé display_errors. Sur une machine de développement, il est généralement activé, si bien qu’une erreur critique affiche une trace d’appels à l’écran. Sur un véritable hébergement, il est désactivé par défaut, car divulguer des chemins de fichiers et des erreurs aux visiteurs pose un problème de sécurité. Ainsi, lorsque quelque chose déclenche une erreur critique — l’appel à une fonction qui n’existe plus, une classe qui n’est pas chargée, une erreur de syntaxe dans la mise à jour d’un plugin — PHP meurt et n’envoie rien. Votre navigateur affiche un document vide. C’est l’« écran blanc ».
Depuis WordPress 5.2, il existe un gestionnaire d’erreurs critiques (WP_Fatal_Error_Handler) qui tente de les intercepter. Quand il fonctionne, vous n’obtenez pas une page vide — vous obtenez « Il y a eu une erreur critique sur ce site », plus un e-mail envoyé à l’adresse de l’administrateur qui contient souvent l’erreur réelle et un lien vers le mode de récupération. Un écran vraiment vide signifie généralement que l’erreur s’est déclenchée avant que ce gestionnaire n’ait pu s’exécuter : une erreur d’analyse/de syntaxe (interceptée à la compilation), un must-use plugin cassé, ou une erreur critique dans le functions.php du thème actif. Dans tous les cas, la cause est consignée quelque part. Il vous suffit d’activer la consignation.
La corriger, dans l’ordre
1. Activez le journal. Modifiez wp-config.php en SFTP et ajoutez ceci au-dessus de la ligne /* That's all, stop editing! */ :
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
WP_DEBUG_DISPLAY à false empêche les erreurs d’apparaître sur la page publique tandis que WP_DEBUG_LOG les écrit dans wp-content/debug.log. Rechargez une fois la page cassée pour générer une nouvelle entrée.
2. Lisez la dernière erreur fatale. Ouvrez wp-content/debug.log et regardez tout en bas :
tail -n 30 wp-content/debug.log
Vous cherchez une ligne de ce type :
[14-Jul-2026 09:12:44 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88
Le chemin nomme le coupable : plugins/some-addon. Voilà votre réponse. Si la trace est longue ou si le message est cryptique (Allowed memory size exhausted, Cannot redeclare, un nom de classe que vous ne reconnaissez pas), collez-le dans notre décodeur de journal d’erreurs — il élimine le bruit, vous indique quel plugin ou thème le chemin désigne, et explique ce que signifie ce type d’erreur précis.
3. Désactivez le composant nommé. Vous ne pouvez pas accéder à /wp-admin, alors faites-le en SFTP. Renommez le dossier du plugin fautif, par exemple some-addon → some-addon.off. WordPress ne peut pas charger un dossier qu’il ne trouve pas, il désactive donc le plugin et le site revient. Si le journal désigne votre thème, basculez sur un thème par défaut en renommant le dossier du thème actif — WordPress se rabat sur un twentytwentysomething fourni.
4. Si le journal ne s’écrit pas, c’est que wp-content n’est pas accessible en écriture, ou que l’erreur se situe au niveau du serveur. Consultez plutôt le journal des erreurs PHP de l’hébergeur :
find . -name "error_log" -newermt "-1 hour"
La même information, dans un fichier différent. Les stacks cPanel/Apache déposent souvent un error_log à la racine du site ou dans le répertoire défaillant.
Ce qu’il ne faut pas faire
N’augmentez pas simplement la limite de mémoire. Le conseil le plus répété en ligne consiste à faire passer WP_MEMORY_LIMIT à 256M ou 512M. Cela ne corrige l’écran blanc que si le journal indique réellement Allowed memory size of N bytes exhausted. Si l’erreur est Call to undefined function, plus de mémoire ne change rien — vous avez modifié un réglage au hasard et l’écran est toujours blanc. Lisez le journal d’abord, puis n’augmentez la mémoire que si la mémoire est le problème énoncé.
Ne videz pas votre cache en croyant avoir posé un diagnostic. L’écran blanc, c’est PHP qui meurt sur le serveur avant qu’aucun HTML n’existe. Une ressource mise en cache et périmée ne peut pas provoquer un document vide. (Un plugin de cache cassé, si — mais le journal le nommera, ce qui est tout l’intérêt.)
Ne modifiez pas et ne réinstallez pas le cœur de WordPress. L’erreur critique n’est presque jamais dans wp-includes ou wp-admin ; elle est dans le plugin ou le thème que le journal désigne. Réinstaller le cœur est lent, risqué, et traite un symptôme que vous n’avez pas confirmé.
Ne désactivez pas tous les plugins pour les réactiver un par un à l’aveugle. La dichotomie fonctionne, mais c’est la voie lente. Le journal vous indique le dossier exact en une seule étape. Ne recourez à la méthode « on éteint tout » que lorsqu’il n’y a aucune erreur lisible du tout.
Ne laissez pas display_errors activé en production. Une fois le site rétabli, supprimez les define de débogage (ou remettez WP_DEBUG à false). Les erreurs affichées aux visiteurs exposent vos chemins.
Toujours bloqué ?
Si le journal nomme un plugin mais que le désactiver n’efface pas l’écran, c’est qu’il y a une seconde erreur critique sous la première — réactivez le journal et lisez la nouvelle dernière ligne ; les erreurs critiques s’empilent. Si le message lui-même est le mur, déposez-le dans le décodeur de journal d’erreurs et laissez-le traduire pour vous le type d’erreur et le chemin du fichier. L’écran blanc ne reste un mystère que tant que le journal est désactivé.