WordPress 7.2 et PHP 8.6 : quelle configuration d’hébergement anticiper en 2027 ?

Les prérequis définitifs de WordPress 7.2 ne sont pas encore connus. Préparez surtout un hébergement qui permet de tester des versions récentes de PHP, une base de données maintenue, un environnement de préproduction et des sauvegardes restaurables.

Ne mettez pas à niveau PHP ou WordPress directement en production. La compatibilité dépendra aussi du thème, des extensions et de la configuration de l’hébergeur.

Vérifier la capacité de test

Une mise à jour majeure peut révéler un plugin abandonné, une fonction PHP obsolète dans un thème ou une extension serveur indisponible. Le problème vient souvent des dépendances propres au site, pas du seul cœur de WordPress.

Votre offre doit permettre de cloner le site dans un environnement isolé, de modifier la version PHP sur ce clone et de restaurer rapidement une sauvegarde. Sans ces possibilités, une montée de version devient un dépannage en production.

Consultez les prérequis WordPress officiels au moment de l’opération. Ils peuvent évoluer avant la publication de WordPress 7.2.

Contrôler PHP et la base de données

Traitez PHP 8.6 comme une cible de test tant que WordPress, votre thème et vos extensions critiques ne documentent pas sa prise en charge. Vérifiez quelles versions PHP sont disponibles, si le changement est réversible et si les journaux d’erreurs sont accessibles.

Évitez une offre limitée à une branche PHP ancienne ou non maintenue. La page php.net indique quelles branches reçoivent encore des correctifs.

WordPress recommande actuellement MySQL 8.0 ou supérieur, ou MariaDB 10.6 ou supérieur. Contrôlez la version réellement utilisée dans « Santé du site », via phpMyAdmin ou auprès du support, en particulier sur un ancien serveur mutualisé.

Conservez UTF-8/utf8mb4 pour les caractères internationaux et les emoji.
Vérifiez qu’un export de la base et une restauration sont possibles sans attente importante.
Assurez-vous de pouvoir dupliquer la base pour l’environnement de préproduction.

Un site sur MySQL 5.7 ou une ancienne branche MariaDB ne cessera pas automatiquement de fonctionner, mais nécessite un plan de migration. La compatibilité applicative ne garantit pas le maintien des correctifs de sécurité par l’éditeur.

Auditer les caches

Vérifiez d’abord qu’OPcache est actif. Il conserve du bytecode PHP compilé en mémoire et évite de recompiler les fichiers à chaque requête.

Demandez aussi comment OPcache est réinitialisé lors des déploiements ou des changements de version PHP. Un cache mal purgé peut compliquer le diagnostic après une mise à jour.

Le cache objet, souvent fondé sur Redis ou Valkey, n’est pas un prérequis de WordPress. Il est surtout utile pour une boutique WooCommerce, un espace membre ou une administration sollicitée, car il réduit certaines lectures répétées en base.

Un CDN ne remplace ni OPcache ni le cache objet : il distribue surtout les fichiers statiques et peut, selon sa configuration, mettre en cache des pages publiques. Les pages personnalisées, le panier et l’administration doivent rester exclus.

Consultez aussi notre guide sur Valkey ou Redis pour le cache objet WordPress et notre analyse du CDN natif chez les hébergeurs.

Tester avant le déploiement

Testez les usages réels du site, pas seulement la page d’accueil. Vérifiez notamment les paiements et e-mails transactionnels d’une boutique, ou les formulaires, redirections, recherche et administration d’un site éditorial.

Créez une sauvegarde complète des fichiers et de la base, puis vérifiez sa restauration.
Clonez le site sur un sous-domaine ou un environnement de staging protégé de l’indexation.
Mettez à jour WordPress, le thème et les extensions sur le clone, puis basculez-le vers la version PHP cible disponible.
Consultez les journaux PHP et WordPress, testez les parcours métier et les tâches planifiées.

En cas d’erreur, identifiez l’extension ou le thème responsable en le désactivant temporairement sur le clone. Ne masquez pas durablement les erreurs : corrigez, remplacez ou maintenez l’élément concerné avant la mise en production.