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

Creebs — Thu, 22 Oct 2026 08:00:02 +0000

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 que vous voyez	Ce que ça veut dire	Où chercher
« Il y a eu une erreur critique sur ce site »	WordPress a démarré, une extension ou le thème plante	`wp-content/debug.log`
Page entièrement vide	L'erreur précède le démarrage de WordPress	Journal PHP de l'hébergeur
« Erreur lors de la connexion à la base de données »	WordPress tourne, la base ne répond pas	Identifiants dans `wp-config.php`
Internal Server Error	Apache refuse avant même de passer la main à PHP	Journal d'erreurs du serveur, souvent `.htaccess`

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.

Site bloqué sur « Bientôt de retour » : le fichier que WordPress a oublié d'effacer

Creebs — Tue, 20 Oct 2026 07:39:48 +0000

Votre site affiche en boucle « Briefly unavailable for scheduled maintenance. Check back in a minute. » La minute dure depuis ce matin. Bonne nouvelle : la réparation prend quelques secondes, et vous pouvez très probablement la faire vous-même.

Ce que voient vos visiteurs. Capture réelle d'un WordPress 6.7 bloqué en maintenance, provoqué en conteneur pour cet article.

Ce qui s'est passé exactement

Avant chaque mise à jour, WordPress dépose un fichier nommé .maintenance à la racine du site. Tant que ce fichier existe, WordPress répond à tout le monde par ce message et un code 503, le temps que l'opération se termine. Puis il le supprime, et le site revient.

Si la mise à jour est interrompue en cours de route, le fichier n'est jamais supprimé. Les trois causes habituelles : le temps d'exécution PHP a expiré, l'onglet du navigateur a été fermé trop tôt, ou la connexion a lâché pendant le téléchargement.

Le détail qui prouve que le site n'est pas cassé

En montant cette panne en laboratoire, j'ai relevé le journal d'erreurs du serveur pendant que le message s'affichait. Il est entièrement vide.

C'est une information, pas une absence d'information. Un site réellement en panne écrit toujours quelque chose dans le journal du serveur. Ici, rien : WordPress fonctionne parfaitement, il a simplement trouvé un fichier qui lui dit de ne servir personne. Vos données sont intactes, votre base n'a rien perdu.

Vérifier en trente secondes

Connectez-vous en FTP, ou ouvrez le gestionnaire de fichiers de votre hébergeur.
Placez-vous à la racine du site, là où se trouvent wp-config.php et wp-content.
Activez l'affichage des fichiers cachés. C'est l'étape que tout le monde saute : un nom qui commence par un point est invisible par défaut, et beaucoup de gens concluent que le fichier n'existe pas alors qu'il est sous leurs yeux.
Si .maintenance est là, vous avez trouvé.

Le correctif

Supprimez le fichier. Rechargez le site : il revient immédiatement, sans vider de cache ni redémarrer quoi que ce soit.

Ne vous arrêtez pas là. Le site est revenu, mais la mise à jour qui a échoué, elle, est restée à moitié faite. Une base de données partiellement migrée ne se voit pas tout de suite : elle produit des erreurs bizarres deux semaines plus tard, quand plus personne ne fait le lien. Retournez dans Tableau de bord puis Mises à jour, et relancez proprement celle qui a échoué.

Si le message revient

Un .maintenance qui réapparaît à chaque tentative de mise à jour signale autre chose : un temps d'exécution PHP trop court pour votre hébergement, des droits d'écriture incorrects sur les dossiers, ou une extension qui bloque le processus. Là, supprimer le fichier ne suffira plus, il faut traiter la cause.

C'est mon quotidien. Diagnostic gratuit, et je vous dis franchement si c'est une chose que vous pouvez régler seul.

Pour aller plus loin

Si le site affiche « Il y a eu une erreur critique sur ce site » au lieu du message de maintenance, c'est une autre panne : voir Page blanche WordPress.
Si vous obtenez une erreur 500 après la mise à jour : voir Erreur 500 WordPress.