Page blanche ou erreur critique : ce ne sont pas les mêmes pannes

Tout le monde appelle ça « la page blanche ». Le terme est resté des années 2010, quand un plugin cassé laissait effectivement un écran vide. Aujourd'hui, dans l'immense majorité des cas, votre écran n'est pas blanc : il porte une phrase. Et cette différence décide de l'endroit où chercher.

Ce que vous voyez presque toujours

WordPress 6.7 après une erreur fatale dans une extension. Capture réelle, provoquée en conteneur.

Depuis WordPress 5.2, le cœur installe un gestionnaire d'erreur fatale. Quand une extension ou un thème plante, il intercepte le crash et affiche ce message au lieu de laisser une page vide.

C'est une bonne nouvelle : cela signifie que WordPress a démarré, qu'il a lu wp-config.php, qu'il s'est connecté à la base, et qu'il est allé assez loin pour installer ses propres protections. Le problème est donc dans une extension ou dans le thème, et il est localisable.

Où est écrite la réponse

Dans wp-content/debug.log, à condition de l'avoir activé. Voici ce que le laboratoire a relevé sur la panne ci-dessus :

[22-Aug-2026 07:19 UTC] PHP Fatal error:  Uncaught Error:
Call to undefined function creebs_lab_fonction_supprimee_par_une_maj()
in /var/www/html/wp-content/mu-plugins/lab-fatal.php:3
Stack trace:
#0 /var/www/html/wp-settings.php(451): include_once()
#1 /var/www/html/wp-config.php(139): require_once('/var/www/html/w...')
#2 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...')
#3 /var/www/html/wp-blog-header.php(13): require_once('/var/www/html/w...')
#4 /var/www/html/index.php(17): require('/var/www/html/w...')
  thrown in /var/www/html/wp-content/mu-plugins/lab-fatal.php on line 3

La première ligne suffit : le fichier fautif et le numéro de ligne. Vous n'avez pas à désactiver vos extensions une par une, le journal vous donne le coupable directement.

Ce que vous voyez rarement, et qui veut dire autre chose

Une page réellement blanche, sans une lettre, existe encore. Elle a une signification précise : l'erreur est survenue avant que WordPress ait pu installer son gestionnaire. Autrement dit, avant même que WordPress existe.

Trois cas produisent cela :

• une erreur de syntaxe dans wp-config.php, ou dans un fichier chargé avant lui ;
• la constante WP_DISABLE_FATAL_ERROR_HANDLER positionnée à true ;
• une mémoire PHP épuisée au point que le gestionnaire lui-même ne peut plus s'exécuter.

Le premier cas est de loin le plus fréquent, et il suit presque toujours une modification manuelle : ajout d'une constante de cache, saisie d'identifiants SMTP, ou copier-coller d'un extrait trouvé sur un forum.

Le piège du diagnostic

Sur une vraie page blanche, inutile de chercher dans wp-content. Aucun debug.log ne sera écrit, pour une raison simple : WordPress n'a jamais démarré, donc il n'a jamais pu configurer où écrire.

La réponse est dans le journal d'erreurs PHP de l'hébergeur. Voici ce que le laboratoire a relevé sur une page rigoureusement vide :

[Sat Aug 22 07:19:53 2026] [php:error] [pid 20] PHP Parse error:
syntax error, unexpected token ";" in /var/www/html/wp-config.php on line 143

Côté visiteur : rien, pas un pixel. Côté serveur : le fichier et la ligne exacts. C'est tout le paradoxe de cette panne, elle paraît opaque et elle est en réalité la mieux documentée des trois.

Le tableau qui résume

Ce qu'il faut retenir

La couleur de l'écran n'est pas un détail cosmétique, c'est un élément de diagnostic. Un message affiché veut dire que WordPress vit encore et sait vous parler. Un écran vide veut dire qu'il n'a jamais eu la parole, et qu'il faut monter d'un cran, vers PHP et le serveur.

Si votre journal est introuvable ou si l'erreur qu'il affiche ne vous dit rien, décrivez-moi ce que vous voyez : le diagnostic est gratuit.

Article publié à l'origine sur creebs.fr. Creebs dépanne les sites WordPress et PrestaShop en panne, chaque solution testée en labo avant d'être écrite.