PHP 8.5 et WordPress : votre hébergement est-il prêt ?

PHP 8.5 fait partie des versions récentes du langage utilisé par WordPress côté serveur. Son arrivée progressive dans les panneaux d’administration des hébergeurs est une bonne occasion de vérifier la santé technique de votre site. Mais une mise à niveau de PHP ne doit pas être traitée comme un simple bouton à activer : elle concerne le noyau WordPress, le thème, les extensions, les tâches planifiées et parfois des scripts personnalisés oubliés depuis longtemps.

Pour un propriétaire de site, la bonne question n’est donc pas uniquement « mon hébergeur propose-t-il PHP 8.5 ? ». Il faut aussi se demander si cette version est disponible sur l’offre souscrite, si elle peut être choisie par site, si le serveur l’exécute réellement via PHP-FPM, et si l’ensemble de la pile WordPress est prêt. Ce guide propose une méthode concrète pour préparer la transition sans confondre mise à jour du runtime et gain automatique de performance.

PHP 8.5 : ce qui change concrètement pour un site WordPress

PHP est le langage qui exécute WordPress. À chaque requête non servie depuis un cache, le serveur PHP traite le code du noyau, des extensions et du thème avant d’envoyer une réponse au navigateur. La version de PHP disponible sur l’hébergement joue donc un rôle important dans la compatibilité, la sécurité et, dans certains cas, les performances.

PHP 8.5 apporte des évolutions au langage destinées principalement aux développeurs. Un site WordPress standard ne se met pas soudainement à profiter de toutes ces nouveautés après le changement de version : les gains dépendent du code effectivement exécuté, de la configuration du serveur, de l’activation d’OPcache, du cache de page, de la base de données et du volume de trafic.

En pratique, la valeur la plus immédiate d’une version récente de PHP est souvent liée à son cycle de maintenance. Le projet PHP publie les périodes de support de chaque branche sur sa page officielle Supported Versions. Utiliser une version encore maintenue permet de recevoir des correctifs de sécurité du langage, à condition que l’hébergeur applique bien les mises à jour de sa distribution.

Pour WordPress, PHP 8.5 ne modifie pas l’administration, l’éditeur ou l’apparence du site par magie. Le changement intervient surtout dans la manière dont le code est interprété. Un code ancien qui s’appuyait sur un comportement obsolète peut déclencher :

• des avertissements ou messages de dépréciation dans les journaux PHP ;
• des erreurs fatales sur certaines pages ou actions d’administration ;
• des incompatibilités avec une extension abandonnée ;
• des dysfonctionnements discrets, par exemple un formulaire qui n’envoie plus d’e-mail ou une tâche cron qui ne se lance plus.

La prudence est particulièrement nécessaire pour les boutiques WooCommerce, les sites multilingues, les formulaires connectés à un CRM, les espaces membres et les installations utilisant des extensions sur mesure. Dans ces cas, une page d’accueil qui s’affiche correctement ne suffit pas à valider la migration.

Mettre à jour PHP est une opération d’infrastructure. Elle améliore la pérennité de la plateforme, mais elle ne remplace ni l’optimisation WordPress, ni un cache bien configuré, ni le nettoyage des extensions inutiles.

Disponibilité de PHP 8.5 : ce que votre hébergeur doit réellement proposer

La mention « PHP 8.5 disponible » dans une offre commerciale ne donne pas tous les éléments nécessaires. Les hébergeurs déploient les nouvelles branches progressivement, selon leurs datacenters, leurs gammes mutualisées, leurs VPS, leurs environnements managés et leurs contraintes de support. Une même entreprise peut proposer PHP 8.5 sur un serveur récent, sans l’avoir encore ouvert sur toutes ses offres.

Commencez par consulter le panneau de contrôle de votre hébergement. Selon les prestataires, le sélecteur de version peut se trouver dans cPanel, Plesk, hPanel chez Hostinger, l’espace client o2switch ou une console propriétaire. Cherchez une rubrique telle que « PHP », « Configuration PHP », « MultiPHP Manager », « PHP Selector » ou « Paramètres du site ».

Vérifiez ensuite quatre points précis :

• La version est-elle proposée pour votre domaine ? Certains panneaux permettent une sélection globale, d’autres une sélection par site ou par sous-domaine.
• Le changement est-il immédiat ou planifié ? Un redémarrage du processus PHP-FPM peut être nécessaire, ce qui explique parfois une courte indisponibilité technique.
• Quel gestionnaire PHP est utilisé ? PHP-FPM est courant dans les configurations modernes, mais les détails varient selon l’hébergeur.
• Quels paramètres sont personnalisables ? Limite de mémoire, taille maximale d’envoi, durée maximale d’exécution, extensions PHP actives et OPcache peuvent influencer le fonctionnement de WordPress.

Un hébergement WordPress bien administré doit également fournir l’accès à des journaux d’erreurs, à des sauvegardes et, idéalement, à un environnement de préproduction. Ces outils comptent davantage que la seule présence d’un numéro de version PHP dans une fiche produit. Retrouvez les critères à examiner dans notre guide des vérifications à effectuer avant de choisir un hébergement WordPress.

Identifier la version PHP réellement exécutée par WordPress

Le choix affiché dans l’interface de l’hébergeur et la version utilisée par votre site peuvent différer. Cela arrive notamment lorsqu’un domaine pointe vers un autre répertoire, lorsqu’un sous-domaine possède sa propre configuration ou lorsqu’un cache applicatif masque temporairement un changement récent.

Depuis l’administration WordPress, allez dans Outils > Santé du site > Informations > Serveur. WordPress y affiche normalement la version de PHP détectée, ainsi que plusieurs informations sur l’environnement. Cette section est la première vérification à faire après toute modification chez l’hébergeur.

La page Outils > Santé du site > État peut aussi signaler une version de PHP obsolète ou des recommandations générales. Elle ne remplace pas un test fonctionnel, mais elle fournit un point de départ utile.

Évitez de laisser publiquement accessible un fichier phpinfo.php. Ce type de fichier affiche de nombreux détails sur la configuration du serveur et les modules installés. Il peut être utile temporairement pour un diagnostic demandé par le support, mais il doit être supprimé dès la vérification terminée. La Santé du site WordPress ou les informations fournies par le support de l’hébergeur sont généralement préférables.

Pour les utilisateurs de WP-CLI, la commande wp --info permet également d’obtenir des détails sur l’environnement en ligne de commande. Attention : la version PHP du terminal peut ne pas être la même que celle utilisée par les requêtes web. Si votre hébergeur donne accès au SSH, demandez-lui explicitement si le binaire CLI et PHP-FPM utilisent la même branche.

Préparer WordPress avant le test de compatibilité

Avant de tester PHP 8.5, mettez votre installation en ordre. Cette phase réduit autant les risques que le test lui-même. Un WordPress ancien, avec de nombreuses extensions non mises à jour, est difficile à diagnostiquer : une erreur peut venir du noyau, d’un thème, d’un plugin ou d’un code personnalisé.

Commencez par mettre à jour WordPress vers la dernière version stable compatible avec votre environnement. Consultez les recommandations officielles sur la page Requirements de WordPress, ainsi que les notes de version de votre installation. Mettez aussi à jour les extensions et le thème actif, après avoir réalisé une sauvegarde complète.

Faites un inventaire des composants actifs :

• le thème parent, le thème enfant et les éventuelles modifications dans le fichier functions.php ;
• les extensions actives et inactives ;
• les extensions premium dont les mises à jour nécessitent une licence valide ;
• les snippets ajoutés via une extension de code ou un mu-plugin ;
• les scripts externes appelés par cron, webhooks ou formulaires ;
• les connecteurs métiers : paiement, livraison, ERP, CRM, e-mail transactionnel ou API sur mesure.

Supprimez les extensions et thèmes inutilisés lorsque cela est possible. Conserver du code désactivé n’aide pas à la stabilité, et un thème inactif très ancien peut devenir un risque si une faille y est découverte. En revanche, gardez un thème WordPress par défaut récent comme solution de diagnostic temporaire.

Le débogage de WordPress peut faciliter l’identification d’avertissements. Sur une préproduction uniquement, les constantes WP_DEBUG et WP_DEBUG_LOG peuvent enregistrer des messages dans un fichier de journal. Il est préférable de ne pas afficher les erreurs aux visiteurs : WP_DEBUG_DISPLAY doit rester désactivé sur un site public. Les erreurs visibles peuvent révéler des chemins internes ou gêner la navigation.

Tester extensions, thème et parcours utilisateurs sur une préproduction

La méthode la plus sûre consiste à cloner le site dans un environnement de préproduction. De nombreux hébergeurs managés proposent une fonction de staging ; sur d’autres offres, il faut créer un sous-domaine protégé, une base de données de test et une copie des fichiers. L’objectif est d’obtenir une version représentative du site, sans envoyer de vrais e-mails ni créer de vraies commandes.

Sur cette préproduction, passez PHP à la version 8.5, puis videz les caches pertinents : cache de page, cache objet si vous utilisez Redis ou Memcached, cache de l’extension et éventuellement CDN. Cloudflare, par exemple, peut conserver des pages en cache ; ne confondez pas une page servie par le CDN avec le résultat réel d’une exécution PHP réussie.

Testez ensuite des scénarios complets, et non uniquement quelques URL :

• connexion et déconnexion d’un compte administrateur ;
• création, modification et publication d’un article ;
• téléversement d’une image et génération des tailles d’images ;
• envoi d’un formulaire de contact ;
• recherche interne, pagination, commentaires et pages 404 ;
• envoi d’un e-mail de réinitialisation de mot de passe ;
• tâches cron WordPress et sauvegardes planifiées ;
• pour WooCommerce : ajout au panier, code promotionnel, création de compte, passage de commande en mode de paiement de test, e-mails et espace client.

Consultez les journaux PHP et le fichier de débogage après ces tests. Une erreur fatale doit être corrigée avant la mise en production. Un avertissement de dépréciation n’empêche pas toujours le site de fonctionner aujourd’hui, mais il mérite d’être transmis à l’éditeur de l’extension ou au développeur concerné. Le repousser sans suivi peut compliquer la prochaine évolution de PHP.

Les extensions populaires ne sont pas automatiquement compatibles dans toutes les configurations. Il faut vérifier la documentation et le journal des modifications de chaque éditeur, en particulier pour les extensions de cache, de sécurité, de paiement ou de génération de pages. Si une extension n’est plus maintenue, recherchez une alternative avant de modifier la version PHP de production.

Performance : pourquoi PHP 8.5 ne suffit pas à accélérer WordPress

Une branche PHP plus récente peut offrir une meilleure efficacité d’exécution dans certains contextes, mais il n’existe pas de pourcentage de gain universel pour un site WordPress. Un blog fortement mis en cache, une boutique avec de nombreuses requêtes dynamiques et un espace membre ne sollicitent pas PHP de la même manière.

Le résultat dépend notamment du serveur web, de PHP-FPM, d’OPcache, des ressources réellement allouées au compte, de la version de MariaDB ou MySQL, de la qualité des requêtes SQL, du thème et des extensions. Un site lent à cause d’images trop lourdes ou de scripts JavaScript tiers ne sera pas transformé par la seule migration de PHP.

Mesurez avant et après sur des pages identiques. Vous pouvez suivre le temps de réponse initial dans les outils de développement du navigateur, utiliser WebPageTest ou consulter les métriques de votre outil de supervision. Pour les pages non mises en cache, comparez plusieurs mesures et regardez également l’utilisation CPU et mémoire dans le panneau de l’hébergeur si ces données sont disponibles.

Une fois PHP 8.5 validé, l’optimisation reste un travail distinct : cache de page, compression des images, réduction des extensions superflues, optimisation de la base et choix d’une infrastructure adaptée. Notre article optimiser WordPress sur votre hébergement détaille les leviers à prioriser sans attribuer tous les problèmes de vitesse à PHP.

Établir un plan de migration avec un retour arrière sécurisé

Quand la préproduction est validée, planifiez la bascule de production à un moment où le trafic et les transactions sont limités. Pour une boutique, évitez les périodes de soldes, une campagne e-mail en cours ou un lancement de produit. Prévenez les personnes qui administrent le site afin qu’elles évitent les modifications de contenu pendant l’opération.

Votre plan doit inclure une sauvegarde vérifiable. Une sauvegarde utile comprend au minimum les fichiers WordPress, la base de données et, si nécessaire, les éléments hors répertoire standard tels que des règles serveur ou des configurations spécifiques. Vérifiez où elle est stockée, sa date et la procédure de restauration. Une sauvegarde non testée n’est pas une garantie de reprise.

Voici une séquence raisonnable :

• noter la version PHP actuelle et les paramètres importants ;
• réaliser une sauvegarde complète avant la bascule ;
• activer PHP 8.5 pour le site concerné depuis le panneau d’hébergement ;
• purger les caches applicatifs et CDN si nécessaire ;
• contrôler immédiatement la page d’accueil, la connexion à l’administration et les parcours critiques ;
• surveiller les logs PHP, les e-mails transactionnels et les alertes pendant les heures suivantes ;
• revenir à la version PHP précédente en cas d’erreur critique, puis restaurer uniquement si le retour de version ne suffit pas.

Documentez la version précédente avant de changer quoi que ce soit. Sur certains hébergements, le retour arrière est aussi simple qu’un nouveau choix dans le sélecteur PHP ; sur d’autres, il demande une intervention du support. Connaître cette procédure à l’avance évite une décision précipitée pendant une indisponibilité.

Si vous prévoyez également de changer d’hébergement, séparez autant que possible les opérations. Migrer les fichiers, modifier les DNS, changer de PHP et remplacer une extension de cache au même moment rend le diagnostic beaucoup plus complexe. Consultez notre méthode pour migrer WordPress sans interruption de service avant de cumuler ces changements.

Quand attendre avant de passer à PHP 8.5 ?

Il est raisonnable d’attendre si votre hébergeur ne propose pas encore PHP 8.5 sur votre formule, si vous ne disposez d’aucun environnement de test, ou si une extension indispensable est explicitement incompatible. Attendre ne signifie pas ignorer le sujet : profitez de ce délai pour mettre à jour le noyau, renouveler les licences, remplacer les composants abandonnés et préparer les sauvegardes.

En revanche, rester durablement sur une branche PHP sortie de maintenance augmente le risque de sécurité et réduit les options lors d’une future migration. L’enjeu consiste à avancer avec méthode, pas à activer la toute dernière version dès son apparition dans le panneau client.

PHP 8.5 est avant tout une étape de maintenance de votre environnement WordPress. Vérifiez sa disponibilité réelle, testez votre site sur une copie, mesurez les résultats et conservez un chemin de retour clair. Cette approche protège la continuité de service tout en préparant votre hébergement aux prochaines évolutions. Si votre offre ne permet ni préproduction, ni sauvegarde fiable, ni sélection PHP maîtrisée, c’est peut-être le bon moment de réévaluer votre hébergement WordPress.