Cache vidé, site en erreur 500 : le vrai diagnostic

Le cache masque une panne, il ne la cause pas

Vider le cache WordPress fait apparaître une erreur 500 quand PHP est déjà cassé en coulisses (plugin incompatible, mise à jour ratée, fonction obsolète) : tant que le cache sert du HTML statique, PHP ne s’exécute jamais et la panne reste invisible. Vider le cache oblige WordPress à régénérer la page, PHP s’exécute enfin, et l’erreur fatale surgit.

Ce n’est pas une mauvaise nouvelle sur le cache. C’est même plutôt rassurant une fois qu’on comprend le mécanisme : le problème existait déjà, il était juste caché par un rideau HTML. Le travail consiste à vérifier PHP avant d’agir, lire l’erreur exacte, isoler le coupable, corriger, puis remettre le cache en confiance.

Pourquoi ça arrive

Un site qui tombe pile au moment où on vide le cache a presque toujours une cause qui remonte à plusieurs jours ou semaines :

• Une mise à jour de plugin ou de thème a introduit un appel de fonction incompatible avec la version de PHP installée, sans que personne ne s’en aperçoive parce que les visiteurs recevaient encore des pages en cache.
• Une montée de version PHP côté hébergeur (migration automatique vers PHP 8.x) a rendu obsolète une syntaxe qui fonctionnait sous une version antérieure.
• Le cache de page sert la dernière version HTML générée avec succès, sans jamais redéclencher le moteur PHP pour les visiteurs anonymes. Un cache de page est un mécanisme qui stocke le résultat HTML final d’une requête pour le resservir tel quel, sans repasser par PHP ni par la base de données.
• Personne ne vérifie l’état de PHP avant de toucher au cache, alors que c’est le seul moyen de savoir si on va révéler une panne ou simplement rafraîchir un visuel.
• Le module d’intégration tierce d’un plugin (API externe, service CDN, passerelle de paiement) contient du code qui casse silencieusement avec une nouvelle version de PHP, bien avant que qui que ce soit vide le cache.

1. Vérifie que PHP est vivant avant de toucher au cache

C’est l’étape que la plupart des gens sautent, et c’est celle qui évite la panne surprise. Avant toute action sur le cache (vidage, changement de réglage, migration), lance une commande WP-CLI en lecture seule qui n’écrit rien et ne déclenche aucune régénération de page :

wp core version

Si PHP est cassé, cette commande renvoie une erreur fatale directement dans le terminal, sans toucher au site public. Si elle répond proprement avec un numéro de version, PHP est sain et tu peux vider le cache sans crainte.

Le 28 août 2026, sur un site vitrine hébergé sur un serveur Plesk que nous gérons chez Peechy, vider le cache WP Rocket pour faire apparaître un pied de page modifié a provoqué une erreur 500 immédiate. La cause n’était pas la modification du pied de page : dans son module Cloudflare, WP Rocket appelait substr() avec un entier en argument, ce que PHP 8 refuse. L’erreur existait déjà, silencieuse, et le cache la masquait depuis un moment. Depuis cet incident, avant toute intervention sur ce type de site, on lance wp core version en lecture seule via le binaire PHP de Plesk (/opt/plesk/php/8.3/bin/php), et on n’agit sur le cache que si la commande répond sans erreur fatale. WP Rocket est resté désactivé sur ce site en attendant un contournement propre du module Cloudflare.

2. Active le débogage pour lire l’erreur exacte

Une fois qu’on sait que PHP est cassé, il faut lire le message précis plutôt que deviner. Dans wp-config.php, à la racine de l’installation (sous httpdocs sur un hébergement Plesk classique), ajoute ou modifie ces trois lignes avant la ligne That's all, stop editing! :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

WP_DEBUG_LOG permet d’écrire chaque erreur dans un fichier journal via la fonction PHP error_log(), sauvegardé par défaut dans wp-content/debug.log source : WordPress.org, Debugging in WordPress. WP_DEBUG_DISPLAY contrôle si les messages d’erreur s’affichent en clair dans le HTML de la page ; le mettre à false évite d’exposer des détails techniques aux visiteurs tout en gardant tout consultable dans le fichier de log source : WordPress.org, Debugging in WordPress.

Ouvre ensuite wp-content/debug.log et cherche la ligne la plus récente contenant PHP Fatal error. Elle indique le fichier exact, la ligne, et la fonction qui a échoué.

3. Comprendre ce que dit l’erreur fatale

Une erreur fatale PHP est une erreur qui interrompt totalement l’exécution du script en cours, contrairement à un simple avertissement (warning) qui laisse le script continuer. Une ligne type ressemble à ceci :

PHP Fatal error: Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in .../wp-content/plugins/wp-rocket/inc/...

Trois informations comptent : le nom du plugin ou du thème dans le chemin (wp-content/plugins/... ou wp-content/themes/...), la fonction PHP qui a levé l’erreur, et le type de désaccord (ici, un entier passé là où une chaîne était attendue, un cas typique de code qui n’a pas été mis à jour pour les vérifications de type plus strictes de PHP 8). Le HTTP 500 est une réponse générique du serveur signalant une condition inattendue qui l’empêche de traiter la requête ; le détail réel se trouve toujours dans les logs, jamais dans le code HTTP lui-même source : MDN, 500 Internal Server Error.

4. Isole le plugin fautif sans passer par l’admin HTTP

Si le site est cassé, l’interface d’administration l’est probablement aussi. WP-CLI permet d’agir directement en base de données, sans dépendre du front HTTP :

wp plugin deactivate --all

Puis réactive un par un, en testant wp core version (toujours en lecture seule pour vérifier l’état) après chaque réactivation :

wp plugin activate nom-du-plugin

Le plugin dont la réactivation fait réapparaître l’erreur fatale dans debug.log est le coupable source : WordPress.org, wp plugin deactivate. Cette méthode évite de tâtonner dans l’admin, où chaque clic peut relancer une régénération de page et retomber sur l’écran blanc ou l’erreur 500.

5. Corrige la cause, pas le symptôme

Désactiver le plugin fautif fait revenir le site, mais ce n’est pas une correction : c’est une mise en pause. Trois options concrètes, du plus rapide au plus durable :

• Mettre à jour le plugin si une version compatible avec la version de PHP existe déjà.
• Revenir temporairement à une version antérieure de PHP compatible, le temps qu’un correctif sorte (solution de repli, pas une stratégie).
• Désactiver uniquement le module fautif si le plugin le permet, plutôt que le plugin entier : c’est ce que nous avons fait avec WP Rocket, en gardant le plugin désactivé le temps qu’un contournement propre du module Cloudflare soit disponible.

6. Ne remets le cache en place qu’une fois PHP confirmé sain

Relance wp core version après la correction. Si la réponse est propre, vide le cache une dernière fois en observant le site en navigation privée. Si debug.log reste silencieux pendant quelques minutes de navigation normale, le cache peut être remis en pleine capacité.

7. Mets en place une vérification systématique avant chaque intervention

C’est la leçon durable de cet incident : ne jamais toucher au cache, à une mise à jour ou à un réglage sans avoir vérifié l’état de PHP en amont, en lecture seule. Un contrôle de trente secondes en WP-CLI évite de découvrir une panne au pire moment, devant un client ou un visiteur.

FAQ

Quand passer la main à un pro

Un wp core version qui répond proprement et un debug.log sans erreur fatale : tu peux gérer ça seul. Si le fichier de log reste illisible, si la commande WP-CLI elle-même échoue, ou si tu ne sais pas quel module d’un plugin isoler sans tout casser, c’est le moment de passer la main. Une maintenance par abonnement inclut justement ce type de vérification systématique avant chaque intervention, ce qui évite de découvrir une panne au pire moment. Si le site reste inaccessible malgré ces étapes, la checklist complète sur les erreurs 500 WordPress et la méthode pour identifier un conflit de plugins prennent le relais là où cet article s’arrête.