WordPress 7.1 est sorti le 19 août. Peu après, certains sites utilisant WP Rocket ont rencontré une erreur fatale.
Le problème n’a pas été découvert le jour de la sortie. Il avait été signalé publiquement le 6 juillet, alors que WordPress 7.1 était encore en version alpha.
Le signalement comprenait les étapes de reproduction, identifiait l’origine de l’erreur et proposait une correction d’une seule ligne. Puis… plus de six semaines se sont écoulées.
Le délai de 45 jours
6 juillet 2026
L’erreur fatale a été signalée publiquement, avec les étapes de reproduction, l’origine du problème et une correction proposée d’une seule ligne.
15 juillet 2026
WordPress 7.1 Beta 1 est sorti, marquant le début de la période de bêta publique.
5 août 2026
WordPress 7.1 est entré en phase de test des versions candidates. Le problème de compatibilité n’était toujours pas résolu.
19 août 2026
WordPress 7.1 est sorti. Les sites utilisant des configurations WP Rocket concernées ont commencé à rencontrer l’erreur fatale.
20 août 2026
WP Rocket 3.23.2.2 a fourni la correction, 45 jours après le signalement initial.
Au cours de cette période, WordPress 7.1 a connu quatre versions bêta et quatre versions candidates, conformément au calendrier des sorties. WP Rocket a également publié quatre mises à jour de l’extension avant l’arrivée de la correction de compatibilité.
Ce calendrier soulève une question légitime sur ce que les propriétaires de sites WordPress doivent attendre des extensions dont ils dépendent.
La compatibilité fait partie des performances
Les bugs surviennent dans tous les projets logiciels, y compris le nôtre. Les signalements concernant une version alpha peuvent être incomplets, limités à un seul environnement ou affectés par des changements intervenus avant la version finale. Les responsables des extensions doivent les examiner et les hiérarchiser avec soin.
Ce signalement était particulièrement précis. Il identifiait la fonction exacte qui recevait le mauvais type de données, fournissait les étapes pour reproduire l’erreur fatale et incluait une correction proposée.
Il y avait également le temps de le tester. le cycle de sortie publique de WordPress 7.1 comprenait des versions bêta à partir du 15 juillet et des versions candidates à partir du 5 août.
Les extensions de performance interviennent au cœur de WordPress. Elles modifient la manière dont les pages sont mises en cache, dont les scripts sont chargés, dont CSS est distribué et dont les ressources sont diffusées. La compatibilité revêt donc une importance particulière.
Un site plus rapide n’est pas d’une grande utilité si une mise à jour normale de WordPress peut le mettre hors ligne.
Il ne s’agissait pas d’une vulnérabilité de sécurité divulguée. C’était un problème de compatibilité qui affectait la disponibilité du site dans certaines configurations. Cette distinction est importante sur le plan technique, mais le résultat restait grave pour le propriétaire d’un site concerné.
Comment Jetpack traite les signalements de sécurité graves
Le problème de WP Rocket n’a pas été signalé comme une vulnérabilité de sécurité ; il ne serait donc pas exact de le comparer directement à un exploit. Nos politiques de sécurité restent toutefois un bon exemple du niveau d’exigence que nous avons fixé pour traiter les signalements graves.
Jetpack dispose d’une politique de sécurité publique et participe au programme d’Automattic de récompenses pour la découverte de bogues HackerOne. En interne, notre processus couvre les signalements reçus via HackerOne, GitHub et nos propres équipes internes d’Automattic.
- Examinez le signalement. Nous évaluons si le problème peut être exploité, quelles versions sont concernées, combien de sites pourraient être exposés et si WordPress.com est concerné.
- Faites intervenir les équipes compétentes. Jetpack Engineering se coordonne avec l’équipe de sécurité d’Automattic, ainsi qu’avec les équipes d’assistance, de communication et juridiques, les partenaires d’hébergement ou WordPress.org lorsque la situation l’exige.
- Adaptez la sortie à la gravité. Les vulnérabilités critiques nécessitent un correctif urgent et des rétroportages vers les versions concernées. Les problèmes de gravité élevée font l’objet d’une mise à jour intermédiaire. Les problèmes présentant un risque moindre se voient malgré tout attribuer une voie de publication claire.
- Examinez la correction. Les correctifs de sécurité font l’objet d’un examen de sécurité. Les tests peuvent être accélérés lorsque le risque est urgent, mais ils ne sont pas ignorés.
- Communiquez et tirez les leçons. Les incidents graves ont des responsables clairement désignés pour l’ingénierie, la communication avec les utilisateurs et l’assistance. Ensuite, nous examinons ce qui s’est passé et ce qui devrait changer.
Aucune politique ne rend une équipe logicielle parfaite. Elle clarifie toutefois les attentes. Un signalement crédible nécessite un responsable, une évaluation de la gravité, une voie de publication et un suivi.
C’est le bon moment pour revoir votre configuration de performances
Les configurations de performances de WordPress ont tendance à se complexifier avec le temps. On commence par ajouter une extension de mise en cache. Puis viennent l’optimisation des images, un CDN, le report des scripts, le Critical CSS et un autre outil pour mesurer les résultats.
À terme, plusieurs extensions peuvent modifier les mêmes parties d’un site.
Si vous utilisez principalement WP Rocket pour la mise en cache et l’optimisation front-end, Jetpack Boost couvre bon nombre de ces mêmes fonctions :
- Mise en cache des pages
- Critical CSS
- Report du JavaScript non essentiel
- Regroupement et minification de CSS et de JavaScript
- Optimisation des images grâce au Jetpack CDN mondial
- Scores de performance intégrés
Ces fonctionnalités peuvent être activées individuellement, ce qui facilite la compréhension de l’effet de chaque modification. La version gratuite comprend la mise en cache des pages, la génération manuelle du CSS critique, le chargement différé de JavaScript, le CDN d’images et la concaténation de CSS et de JavaScript.
Vous ne voulez pas tout ce que Jetpack a à offrir ? Aucun problème. Jetpack Boost est également une extension distincte. Vous n’avez pas besoin d’installer l’extension principale Jetpack pour l’utiliser.
Comment passer de WP Rocket à Jetpack Boost
Avant de modifier vos extensions de performance, sauvegardez votre site ou testez la modification sur un site de préproduction.
Si votre site est déjà affecté par l’erreur fatale de WordPress 7.1, mettez d’abord WP Rocket à jour vers la version 3.23.2.2. Une fois le site à nouveau opérationnel :
- Notez vos résultats de performance actuels afin de disposer d’une référence.
- Désactivez WP Rocket et videz les caches restants du serveur ou du CDN.
- Installez et activez Jetpack Boost.
- Activez les modules de performance un par un.
- Testez votre page d’accueil, vos articles, vos formulaires, la recherche, la connexion, le paiement et les autres parcours importants après chaque modification.
- Comparez les résultats avec votre référence initiale.
Évitez d’activer la même optimisation dans plusieurs extensions. Deux outils qui tentent de reporter le même JavaScript ou de gérer le même cache peuvent créer de nouveaux problèmes de compatibilité.
Chaque site WordPress est différent ; mesurez donc le résultat au lieu de supposer que chaque optimisation sera bénéfique.
Les mises à jour d’extensions requièrent votre confiance
Les propriétaires de sites comptent sur les équipes responsables des extensions pour suivre le développement de WordPress, tester les prochaines versions et examiner les signalements crédibles de problèmes de compatibilité avant leur mise en production.
Le problème de WP Rocket ne consiste pas à exiger qu’un logiciel soit exempt de bogues. Il s’agit de ce qui se passe après qu’un problème grave a été signalé et que le correctif proposé est connu.
Si cet incident vous fait reconsidérer WP Rocket, Jetpack Boost vous offre un moyen concret de simplifier votre configuration des performances tout en conservant les optimisations dont votre site a besoin.
Jetpack 