Mise à jour WP Rocket 3.23 : pourquoi votre site WordPress peut afficher une « erreur critique » du jour au lendemain

Un matin, le site ne répond plus. À la place, ce message laconique :

Pas de page d’accueil, pas d’accès au tableau de bord. Pour un cabinet d’avocats ou une étude notariale dont le site est le premier point de contact des clients, c’est une journée de visibilité perdue — et souvent une soirée à chercher qui appeler.

Dans la grande majorité des cas observés ces dernières semaines, la cause est la même : la mise à jour automatique de WP Rocket vers la version 3.23, sur un hébergement resté sur une version de PHP obsolète.

Voici ce qui se passe exactement, comment rétablir le site en quelques minutes, et surtout comment faire en sorte que cela ne se reproduise plus.

Ce que change réellement WP Rocket 3.23

Nous avons ouvert et analysé le paquet officiel de la version 3.23.2.2. Le fichier principal du plugin est explicite :

Version: 3.23.2.2
Requires at least: 5.8
Requires PHP: 7.4

Le seuil est donc PHP 7.4. Précisons-le tout de suite, car beaucoup d’articles circulent avec de fausses informations :

Si votre hébergement est en PHP 7.4 ou supérieur, vous n’êtes pas concerné. Inutile de toucher à quoi que ce soit.

Ce durcissement n’est pas une lubie de l’éditeur. Il accompagne une décision du cœur de WordPress : depuis WordPress 7.0, sorti en avril 2026, le support de PHP 7.2 et 7.3 a été abandonné, et le minimum requis est passé à PHP 7.4. WP Rocket s’aligne, comme le feront progressivement tous les autres plugins majeurs. Autrement dit : si votre site est concerné aujourd’hui par WP Rocket, il le sera demain par un autre plugin, puis par un autre.

Pourquoi une erreur critique, et pas un simple avertissement ?

C’est le point qui surprend le plus, y compris des développeurs expérimentés. WP Rocket intègre pourtant un garde-fou. À l’ouverture du plugin, une classe de vérification (WP_Rocket_Requirements_Check) compare la version de PHP du serveur au minimum requis. Si elle est trop basse, le plugin est censé ne pas se charger, afficher un bandeau rouge dans l’administration et proposer un bouton de retour à la version précédente (la 3.22.1).

En théorie, donc : un message, pas une panne.

En pratique, l’erreur fatale survient malgré tout, pour trois raisons.

1. Le contrôle de plateforme des dépendances

WP Rocket embarque des bibliothèques tierces chargées via un autoloader Composer. Celui-ci exécute son propre contrôle et, en cas d’échec, ne se contente pas d’un avertissement : il lève une exception non rattrapée. Le journal d’erreurs affiche alors une ligne caractéristique, que l’on retrouve dans presque tous les dossiers que nous traitons :

PHP Fatal error: Composer detected issues in your platform:
Your Composer dependencies require a PHP version ">= 7.4.0". You are running 7.3.33.

2. Les hébergements multi-versions

De nombreux hébergeurs mutualisés exécutent plusieurs versions de PHP en parallèle : une pour le web, une autre pour les tâches planifiées ou la ligne de commande. Le garde-fou lit une version, le serveur en exécute une autre. Le contrôle passe, le chargement casse.

3. Le fichier de cache anticipé

WP Rocket installe un fichier advanced-cache.php à la racine de wp-content. Ce fichier est chargé par WordPress avant les plugins, très tôt dans le cycle. Sur les versions récentes il est correctement protégé, mais sur les installations anciennes, mal mises à jour ou dont le dossier du plugin a été déplacé manuellement, il continue de pointer vers des fichiers qui n’existent plus — et l’écran blanc persiste même après désactivation du plugin. C’est la raison pour laquelle un simple renommage du dossier ne suffit pas toujours.

Symptômes : comment reconnaître ce cas précis

• →Le site affiche « Il y a eu une erreur critique sur ce site », en façade et en administration.
• →La panne est apparue sans intervention humaine, souvent la nuit (les mises à jour automatiques de WordPress s’exécutent via les tâches planifiées).
• →Un e-mail de WordPress a pu être reçu, intitulé « Votre site rencontre un problème technique », mentionnant le plugin WP Rocket.
• →Le fichier wp-content/debug.log ou les journaux de l’hébergeur contiennent une ligne Fatal error mentionnant wp-rocket ou Composer detected issues in your platform.

Si ces éléments sont réunis, le diagnostic est quasi certain.

Procédure de rétablissement d’urgence (accès FTP)

L’objectif de cette étape est simple : remettre le site en ligne. La correction de fond viendra ensuite.

Prérequis : les identifiants FTP ou SFTP de l’hébergement (hôte, identifiant, mot de passe, port) et le logiciel gratuit FileZilla.

Étape 1 — Sauvegarder avant toute chose

Si votre hébergeur propose une sauvegarde en un clic (OVH, o2switch, Infomaniak, Hostinger le proposent tous), déclenchez-la maintenant. À défaut, téléchargez au minimum le dossier wp-content et exportez la base de données. Aucune manipulation de fichiers ne doit se faire sans filet.

Étape 2 — Se connecter en FTP

Dans FileZilla, renseignez en haut de fenêtre :

• →Hôte : sftp://ftp.votredomaine.fr (privilégiez le SFTP, chiffré, plutôt que le FTP simple)
• →Identifiant et Mot de passe : ceux fournis par l’hébergeur
• →Port : 22 en SFTP, 21 en FTP

Cliquez sur « Connexion rapide ». Le volet de droite affiche les fichiers du serveur.

Étape 3 — Atteindre le dossier des extensions

Naviguez vers la racine de WordPress — selon l’hébergeur, elle se trouve dans www/, public_html/ ou htdocs/. Vous devez y voir les dossiers wp-admin, wp-includes et wp-content, ainsi que le fichier wp-config.php.

Ouvrez ensuite : wp-content → plugins

Étape 4 — Neutraliser le plugin

Repérez le dossier wp-rocket. Clic droit → Renommer → saisissez :

wp-rocket.old

WordPress ne reconnaît plus le dossier comme une extension valide et la désactive automatiquement. Aucune donnée n’est perdue : les réglages sont stockés en base de données, et le dossier reste sur le serveur si vous devez revenir en arrière.

Étape 5 — Recharger le site

Actualisez la page d’accueil. Dans la plupart des cas, le site revient immédiatement.

Étape 6 — Si l’écran blanc persiste

Deux vestiges de configuration peuvent maintenir la panne.

Le fichier de cache anticipé. Remontez dans wp-content et renommez advanced-cache.php en advanced-cache.php.old.

La constante de cache. Ouvrez wp-config.php (clic droit → Afficher/Éditer) et recherchez cette ligne :

define( 'WP_CACHE', true );

Remplacez true par false, ou commentez la ligne en la préfixant de //. Enregistrez, et confirmez le renvoi du fichier vers le serveur.

Les règles du serveur web. Si le site est sur Apache ou LiteSpeed, ouvrez le fichier .htaccess à la racine et supprimez le bloc compris entre # BEGIN WP Rocket et # END WP Rocket.

Le site doit désormais répondre.

La vraie correction : mettre l’hébergement à niveau

Le site est en ligne, mais sans cache : il est plus lent, consomme davantage de ressources serveur, et vos performances Core Web Vitals se dégradent — avec les conséquences que l’on sait sur le référencement. Ce n’est pas un état stable.

La solution durable tient en une opération : passer l’hébergement en PHP 8.2 ou 8.3.

Trois erreurs à ne pas commettre

Cet article s’appuie sur l’analyse technique du paquet officiel WP Rocket 3.23.2.2 et sur les annonces de compatibilité PHP publiées par le projet WordPress.