Le site fonctionnait il y a une seconde, vous étiez en train de terminer un article ou de configurer WooCommerce, et soudain plus rien. Un écran blanc à la place du panneau d'administration. Ou la page d'accueil a disparu, alors que le tableau de bord s'ouvre encore. Cela vous semble familier? Bienvenue au club, vous avez rencontré le White Screen of Death, aussi appelé WSOD, ou «écran blanc de la mort» WordPress.

La panique est ici le premier ennemi. Un WSOD ne signifie presque jamais que le site est définitivement mort. La cause est le plus souvent banale: un conflit de plugin après une mise à jour, du code mal inséré dans functions.php, ou un simple manque de mémoire pour le processus PHP. Dans ce guide, quatre méthodes éprouvées pour ramener le site à la vie et une cinquième, intégrée au cœur de WordPress, que même les utilisateurs expérimentés oublient.

💡 Aperçu rapide:

• Désactiver le plugin problématique via FTP (renommer le dossier) ou en masse en renommant le répertoire plugins
• Désactiver le thème en conflit avec la même méthode: dossier themes → renommer le répertoire du thème actif
• Augmenter la limite de mémoire PHP avec la ligne WP_MEMORY_LIMIT dans wp-config.php à 128M ou 256M
• Activer WP_DEBUG et WP_DEBUG_LOG pour le diagnostic, connaître la cause exacte de l'erreur grâce au fichier debug.log
• Utiliser le mode de récupération (WordPress 5.2+), un mécanisme intégré qui envoie un lien pour accéder au panneau d'administration même en cas d'erreur fatale
• Restaurer le site à partir d'une sauvegarde si les autres méthodes n'ont pas fonctionné

1. Désactiver le plugin problématique

Les plugins sont la cause la plus fréquente de WSOD. Vous venez de mettre à jour votre plugin de cache préféré, l'écran est devenu noir. Vous avez installé un nouveau slider, le site ne s'ouvre plus. Le mécanisme est simple: le code PHP du plugin provoque une erreur fatale, et WordPress arrête de charger la page entière.

Le problème, c'est que vous ne pouvez pas vous connecter au panneau d'administration et cliquer sur «Désactiver», le panneau d'administration affiche lui aussi un écran blanc. La solution: désactiver le plugin directement via le système de fichiers.

Comment désactiver un plugin via FTP:

• Connectez-vous au serveur via FTP (FileZilla, WinSCP) ou via le gestionnaire de fichiers de l'hébergement (cPanel → Gestionnaire de fichiers).
• Allez dans le répertoire racine de WordPress.
• Ouvrez wp-content/plugins.
• Trouvez le dossier du plugin problématique, le nom correspond au titre (par exemple, akismet, woocommerce ou elementor).
• Renommez le dossier: ajoutez un tiret bas ou un suffixe, _akismet ou akismet_disabled. WordPress interprétera le changement de nom comme l'absence du plugin et le désactivera.

Immédiatement après avoir renommé, ouvrez le site dans votre navigateur. S'il fonctionne, le coupable est trouvé. Vous pouvez maintenant restaurer le nom d'origine du dossier et, après vous être connecté au panneau d'administration, soit mettre à jour le plugin vers une version compatible, soit le supprimer et trouver une alternative.

Désactivation en masse de tous les plugins d'un coup. Si vous ne savez pas quel plugin exact a causé la panne, désactivez tout en bloc. Renommez le dossier wp-content/plugins lui-même en plugins_old et créez un nouveau répertoire plugins vide à côté. Tous les plugins sont désactivés. Ensuite, ramenez-les un par un: déplacez le dossier du plugin de plugins_old vers plugins, connectez-vous au panneau d'administration, activez-le et vérifiez le site. Répétez jusqu'à trouver le coupable.

Alternative pour ceux qui ont WP-CLI. Une commande dans le terminal remplace la danse FTP:

1
wp plugin deactivate --all

Et ensuite activez un par un: wp plugin activate <slug>. Rapide, propre, sans gestionnaire de fichiers.

2. Désactiver le thème en conflit

Le deuxième coupable le plus fréquent est le thème. Les scénarios sont les mêmes: vous avez mis à jour le thème vers une nouvelle version majeure, installé un thème avec un functions.php mal écrit, ou un plugin est entré en conflit avec le thème actuel après une mise à jour de WordPress.

Le mécanisme de correction est presque identique à celui des plugins:

• Connectez-vous via FTP à wp-content/themes.
• Trouvez le dossier du thème actif (celui actuellement installé sur le site).
• Renommez-le, par exemple, ajoutez _disabled à la fin du nom.

WordPress, ne trouvant pas le thème actif, basculera automatiquement sur le thème par défaut Twenty Twenty-Five (ou Twenty Twenty-Four, selon la version de WP). Le site se chargera avec le design par défaut, mais tout votre contenu restera en place. Important: ne supprimez pas le thème par défaut, sinon il n'y aura rien vers quoi basculer, et vous aurez un nouveau tour de WSOD.

Thèmes mal codés et mises à jour de WordPress. Après une version majeure de WordPress, les anciens thèmes utilisant des fonctions ou des hooks obsolètes peuvent casser. Les thèmes de qualité provenant de développeurs vérifiés sont mis à jour dans les jours qui suivent la sortie de la version principale. Si votre thème n'a pas été mis à jour depuis six mois ou plus, c'est un signal d'alarme: passez à un thème activement maintenu.

Modification de functions.php et d'autres fichiers de thème. Une faute de frappe dans functions.php, une parenthèse en trop, un appel de hook incorrect, et le site tombe. Si vous avez modifié des fichiers de thème juste avant l'apparition du WSOD, remplacez le fichier modifié par la version originale provenant d'une sauvegarde ou de la distribution du thème. Sans sauvegarde, téléchargez à nouveau le thème depuis la source et uploadez le fichier propre.

3. Dépassement de la limite de mémoire PHP

Le site a grandi, les plugins se sont multipliés, le trafic a augmenté, et soudain WSOD. Un symptôme classique que le processus PHP est à court de RAM. Particulièrement pertinent sur les hébergements bon marché, où un serveur fait tourner des centaines de sites, et la limite par client est réduite au minimum.

WordPress recommande officiellement un minimum de 64 Mo de mémoire, mais cette recommandation date de l'ère PHP 5.6 et de cinq plugins par site. En 2026, un minimum réaliste pour un site fonctionnel est de 128 Mo, et pour les configurations avec Elementor, WooCommerce et plusieurs dizaines de plugins, 256 Mo.

Comment augmenter la limite de mémoire:

Ouvrez le fichier wp-config.php (situé à la racine de l'installation WordPress) et ajoutez une ligne avant le commentaire /* That's all, stop editing! */:

1
define('WP_MEMORY_LIMIT', '256M');

Si le fournisseur limite strictement la mémoire PHP au niveau du serveur, cette directive ne fonctionnera pas, alors il n'y a qu'une seule issue: changer de formule ou d'hébergement. Les hébergements WordPress managés (SiteGround, WP Engine, Kinsta) configurent les limites de manière adéquate par défaut, et le problème de mémoire n'y est pratiquement jamais rencontré.

4. Diagnostic via WP_DEBUG

Parfois, ni les plugins, ni le thème, ni la mémoire ne sont en cause, la cause du WSOD échappe à l'analyse. Il faut alors faire en sorte que WordPress vous dise exactement ce qui a mal tourné.

WordPress embarque depuis des décennies un débogueur intégré WP_DEBUG. Par défaut, il est désactivé (écran blanc au lieu des erreurs, l'idée étant de ne pas exposer les rouages internes du site aux visiteurs). Mais pour l'administrateur, ce mode est inestimable.

Ajoutez à wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Ce qui se passe:

• WP_DEBUG active le mode débogage;
• WP_DEBUG_LOG écrit les erreurs dans le fichier wp-content/debug.log, pratique à lire sans les montrer aux visiteurs;
• WP_DEBUG_DISPLAY avec la valeur false masque les erreurs à l'écran (vous voyez un écran blanc, mais les logs sont écrits).

Après activation, ouvrez le site, reproduisez le problème et regardez dans wp-content/debug.log. Il y aura une ligne avec le fichier, le numéro de ligne et le type d'erreur, par exemple, Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. C'est l'adresse exacte du problème.

Important: ne laissez pas WP_DEBUG activé en production après le diagnostic, les logs grossissent rapidement et peuvent saturer l'espace disque.

5. Mode de récupération, le sauveur intégré de WordPress 5.2+

Depuis la version 5.2, WordPress peut détecter lui-même les erreurs fatales et proposer un chemin de repli. Le mode de récupération (Recovery Mode) est une fonctionnalité que de nombreux administrateurs n'utilisent toujours pas, simplement parce qu'ils ne la connaissent pas.

Comment cela fonctionne. Lorsque le code PHP d'un plugin ou d'un thème provoque une erreur fatale, WordPress l'intercepte, arrête l'extension problématique et envoie un email à l'adresse email de l'administrateur. L'email contient un lien qui ouvre l'accès au panneau d'administration en contournant le code problématique. Vous vous connectez, voyez le plugin planté marqué «a causé une erreur», le désactivez, et le site est de nouveau vivant. Pas de FTP, pas de renommage de dossier.

Limites du mode de récupération:

• Le lien est valable pour une durée limitée (environ un jour) et est lié à une adresse IP;
• Nécessite un envoi de mail configuré depuis le site (plugin SMTP ou messagerie de l'hébergement);
• Ne sauve pas des erreurs au niveau du serveur (manque de mémoire, .htaccess cassé).

Et pourtant, si l'email est arrivé, vous économisez une dizaine de minutes de stress et de manipulations FTP.

Regardez un court guide sur la correction du WSOD, toutes les méthodes décrites avec une démonstration en direct:

⁉️🤔 Questions fréquemment posées

Pourquoi l'écran blanc apparaît-il uniquement dans le panneau d'administration, mais le site s'ouvre normalement?

L'erreur est localisée dans du code qui s'exécute uniquement dans le panneau de contrôle: une metabox de plugin, une page de réglages de thème, un widget d'administration personnalisé. Désactivez les plugins récemment installés un par un, le coupable sera trouvé rapidement. Si cela n'aide pas, activez WP_DEBUG_LOG et vérifiez le log après avoir tenté de vous connecter au panneau d'administration.

Écran blanc uniquement sur un article ou une page d'entrée, qu'est-ce que c'est?

Très probablement, le problème se situe dans le contenu de l'entrée spécifique: un shortcode d'un plugin inexistant, du HTML cassé dans le texte, un conflit avec des champs personnalisés. Ouvrez l'entrée via Modification rapide dans le panneau d'administration et changez temporairement le statut en «Brouillon». La page se charge-t-elle? Alors cherchez à l'intérieur du contenu.

Peut-on éviter complètement le WSOD à l'avenir?

L'éliminer complètement, non, mais minimiser le risque est réaliste. Trois règles: (1) testez toujours les mises à jour de plugins et de thèmes sur une copie de staging du site avant de déployer en production; (2) conservez des sauvegardes quotidiennes des fichiers et de la base de données; (3) n'installez pas de plugins et de thèmes provenant de sources douteuses, en particulier les versions nulled.

Le mode de récupération n'a pas envoyé d'email, que faire?

L'envoi de mail depuis un site WordPress sans plugin SMTP configuré fonctionne de manière instable. Configurez SMTP (Post SMTP, FluentSMTP ou WP Mail SMTP) à titre préventif. Si l'email n'est déjà pas arrivé, revenez à la méthode FTP de la section 1, elle fonctionne toujours.

Combien de temps dure le lien du mode de récupération?

Le lien est valable 24 heures (plus précisément, jusqu'à l'expiration du jeton nonce). Après cela, vous devez reproduire l'erreur à nouveau, WordPress renverra l'email.

Que faire si rien n'a aidé?

Si les quatre méthodes ci-dessus et le mode de récupération n'ont pas ramené le site, le problème est plus profond. Peut-être que le fichier .htaccess est endommagé (renommez-le et connectez-vous au panneau d'administration, WordPress en créera un nouveau via «Réglages → Permaliens → Enregistrer»). Ou une incompatibilité de version PHP: WordPress moderne nécessite PHP 7.4+, mais l'hébergeur pourrait encore avoir PHP 5.6.

Un autre outil de diagnostic est le plugin Health Check & Troubleshooting de l'équipe WordPress.org. Il peut lancer une session en mode sans échec: désactive tous les plugins et bascule vers le thème par défaut, mais uniquement pour votre navigateur (les visiteurs voient le site normal). Avec lui, vous pouvez activer les plugins un par un en toute sécurité et attraper le coupable sans toucher à la production.

Pas le temps d'enquêter, mais le site doit être en ligne tout de suite? Restaurez la sauvegarde. S'il n'y a pas de sauvegarde, une leçon pour l'avenir: les sauvegardes automatiques quotidiennes coûtent quelques euros par mois et sont rentabilisées dès le premier jour d'un sinistre. Pratiquement tous les hébergements proposent cette fonctionnalité dans le panneau de contrôle.

Et le plus important, ne craignez pas le WSOD. C'est désagréable, mais soluble. Vous avez maintenant un algorithme d'actions étape par étape, pas de panique ni d'écran vide.