PHP 8.5 et WordPress : préparer la mise à jour sans stress

Passer à une version récente de PHP est une étape normale dans la vie d’un site WordPress. Ce n’est pas une refonte, ni une opération réservée aux développeurs. En revanche, ce n’est pas non plus un bouton à cliquer sans vérification, surtout lorsqu’un hébergeur annonce la fin prochaine d’une version PHP plus ancienne.

PHP 8.5 peut devenir un sujet concret de deux façons : votre hébergeur vous propose cette version dans son panneau de gestion, ou il vous demande de quitter une branche PHP qui approche de sa fin de support. Dans les deux cas, l’objectif n’est pas de courir après la toute dernière version disponible. Il consiste à choisir une version maintenue, compatible avec votre site, puis à la tester dans des conditions maîtrisées.

Pour une petite structure, la bonne méthode tient en quelques principes : faire un état des lieux, mettre à jour ce qui doit l’être, tester sur une copie du site et prévoir un retour arrière simple. Cette approche évite les indisponibilités, les erreurs visibles par les visiteurs et les interventions urgentes souvent plus coûteuses.

Pourquoi PHP 8.5 devient un sujet concret pour les sites WordPress

PHP est le langage sur lequel WordPress fonctionne côté serveur. Lorsqu’un visiteur ouvre une page, WordPress, votre thème et vos extensions exécutent du code PHP pour générer le contenu, traiter un formulaire, afficher une réservation ou envoyer une notification.

Les versions de PHP ne sont pas maintenues indéfiniment. Le projet PHP applique une période de support actif, puis une période de correctifs de sécurité. À terme, une version arrive en fin de vie. Continuer à l’utiliser expose le serveur à l’absence de correctifs de sécurité publiés par le projet PHP.

Les hébergeurs font donc évoluer leurs offres. Certains affichent des alertes dans leur interface ; d’autres planifient une migration automatique si le client ne choisit pas de version. Ce mécanisme est compréhensible du point de vue de la sécurité, mais il peut être mal vécu si le site n’a pas été préparé.

Le risque ne vient pas de WordPress seul. Un site peut fonctionner correctement avec le cœur de WordPress à jour, mais contenir :

un thème ancien qui utilise des fonctions PHP dépréciées ;
une extension abandonnée depuis plusieurs années ;
un module de paiement, de réservation ou de formulaire qui n’a jamais été retesté ;
du code ajouté dans un thème enfant, via Code Snippets ou dans un plugin spécifique ;
des tâches automatisées, comme l’envoi d’e-mails ou une synchronisation avec un agenda, qui ne se déclenchent pas lors d’une simple visite du site.

La mise à jour de PHP est donc un sujet de maintenance globale. Elle s’inscrit dans la même logique que les mises à jour du cœur WordPress, des extensions et du thème. Si votre site utilise une version récente de WordPress et des composants activement maintenus, le passage sera généralement plus simple. Mais « généralement » ne remplace pas un test.

Il est également utile de distinguer deux décisions : mettre à jour vers une branche PHP encore largement éprouvée dans votre environnement, ou passer directement à PHP 8.5. La réponse dépend de la compatibilité annoncée par les éditeurs de vos extensions et de la version de WordPress utilisée. Les exigences et recommandations évoluent : la référence reste la page des prérequis techniques de WordPress, complétée par la documentation de votre hébergeur.

Ne pas confondre mise à jour WordPress et changement de version PHP

Dans l’administration WordPress, vous pouvez mettre à jour le cœur, les extensions et les thèmes. Le choix de la version PHP se fait presque toujours chez l’hébergeur, depuis cPanel, Plesk, un espace client propriétaire ou une console d’administration.

Cette séparation explique une situation fréquente : le tableau de bord WordPress semble parfaitement à jour, mais le site utilise encore une version PHP ancienne. À l’inverse, passer PHP 8.5 chez l’hébergeur ne met pas automatiquement WordPress ni les extensions à jour.

Avant toute action, relevez la version actuellement utilisée. WordPress l’indique dans Outils > Santé du site > Informations > Serveur. Cette même page fournit d’autres indications utiles, comme les limites mémoire PHP ou les extensions serveur chargées.

Vous pouvez aussi vérifier la version directement dans le panneau de votre hébergeur. Les deux informations doivent correspondre. Si elles diffèrent juste après un changement, videz les caches disponibles et attendez la propagation éventuelle de la configuration côté hébergement avant de conclure à une anomalie.

Cette vérification simple permet de documenter le point de départ. Notez notamment :

la version de WordPress ;
la version de PHP active ;
le nom et la version du thème actif, ainsi que du thème enfant s’il existe ;
la liste des extensions actives ;
les services externes importants : paiement, prise de rendez-vous, formulaires, newsletter, outil métier ou agenda.

Cette liste peut sembler élémentaire. Pourtant, elle accélère considérablement le diagnostic si une erreur apparaît. Elle permet aussi de repérer les composants oubliés, notamment les extensions installées par un ancien prestataire.

Les vérifications à faire avant de changer de version PHP

La première vérification concerne le cœur de WordPress. Installez la dernière version stable compatible avec votre contexte avant de changer PHP, sauf contrainte documentée ou procédure de maintenance particulière. Les versions récentes corrigent régulièrement des problèmes de compatibilité et de sécurité.

Ensuite, mettez à jour les extensions et le thème. Faites-le de façon raisonnée : une sauvegarde doit précéder les mises à jour, et il est préférable de vérifier le site après un petit groupe de changements plutôt que d’empiler toutes les opérations sans contrôle. Pour une méthode plus large, consultez aussi notre guide pour faire le tri dans les extensions WordPress.

Examiner les extensions réellement actives

Une extension inactive ne s’exécute pas sur le site, mais elle reste présente sur le serveur. Si elle n’est plus utile, supprimez-la après sauvegarde. Garder des modules inutilisés ne simplifie ni la sécurité ni la maintenance.

Pour chaque extension active, consultez sa page officielle sur le répertoire WordPress ou le site de son éditeur. Recherchez en priorité :

une mention de compatibilité avec votre version de WordPress ;
la date de la dernière mise à jour ;
la réactivité du support, lorsque l’extension est critique ;
les éventuelles notes de version relatives à PHP 8.x ;
la disponibilité d’une mise à jour avant le passage à PHP 8.5.

Il n’existe pas de label universel garantissant qu’une extension fonctionnera avec PHP 8.5 dans tous les contextes. Une mention de compatibilité est rassurante, mais le test sur votre propre copie de site reste nécessaire. Les interactions entre une extension de cache, un constructeur de pages, un thème et un outil métier peuvent produire un problème qui n’apparaît pas sur une installation vierge.

Contrôler le thème et le code personnalisé

Le thème actif mérite la même attention que les extensions. Un thème acheté sur une place de marché, un thème enfant ou un thème développé sur mesure peut contenir du code ancien. Vérifiez sa version, son historique de mises à jour et l’existence d’un support.

Le code personnalisé est souvent le point aveugle. Il peut se trouver dans le fichier functions.php d’un thème enfant, dans une extension maison, dans un plugin tel que Code Snippets, ou dans des fichiers ajoutés par une agence. Ne supprimez pas ce code au hasard. Identifiez son rôle : modification d’un formulaire, ajout de champs, connexion à une API, redirection, calcul de tarif ou automatisation.

Si vous avez accès à un prestataire technique, demandez-lui une revue ciblée de ce code pour la version PHP envisagée. L’outil PHPCompatibilityWP peut aider les développeurs à repérer des incompatibilités potentielles dans un code WordPress, mais il ne remplace pas les tests fonctionnels.

Prévoir une sauvegarde qui peut vraiment être restaurée

Une sauvegarde utile contient les fichiers du site et la base de données. Elle doit être identifiable, récente et stockée dans un emplacement accessible. Les sauvegardes proposées par l’hébergeur sont précieuses, mais vérifiez leur fréquence, leur durée de conservation et la procédure de restauration.

Un export ponctuel via une extension comme UpdraftPlus, ou une sauvegarde créée depuis le panneau d’hébergement, peut compléter ce dispositif. Le plus important est de ne pas découvrir, après une erreur, que la sauvegarde ne contient pas la base de données ou qu’elle est impossible à restaurer sans assistance.

Une mise à jour PHP sereine commence par une question très concrète : si le site affiche une erreur, puis-je revenir à l’état précédent rapidement et sans perdre de contenus récents ?

Tester PHP 8.5 sans mettre le site en danger

La solution la plus sûre est de tester sur un environnement de préproduction, souvent appelé staging. Il s’agit d’une copie du site, hébergée sur une adresse distincte, sur laquelle vous pouvez changer de version PHP sans impacter les visiteurs.

De nombreux hébergeurs proposent une fonction de staging, mais les modalités varient. Vérifiez notamment si la copie inclut les fichiers et la base de données, comment elle est protégée de l’indexation et comment les e-mails ou paiements sont gérés. Une préproduction ne doit pas envoyer de vraies confirmations de commande ni déclencher de véritables rendez-vous.

Si votre offre ne propose pas de staging, plusieurs alternatives existent :

demander à l’hébergeur la création d’un sous-domaine ou d’un espace de test ;
créer une copie sur un hébergement distinct, avec un accès protégé par mot de passe ;
utiliser un environnement local avec Local ou DevKinsta, si vous êtes à l’aise avec cette méthode ou accompagné par un professionnel.

Une copie locale est pratique pour un développeur, mais elle n’est pas toujours la plus simple pour une équipe non technique. Dans un contexte de petite structure, un staging chez l’hébergeur est souvent le meilleur compromis : il reproduit plus fidèlement le serveur réel et rend les vérifications accessibles depuis un navigateur.

Ordre de test conseillé

Sur la préproduction, commencez par appliquer les mises à jour WordPress, thème et extensions prévues. Vérifiez que la copie fonctionne encore avec la version PHP actuelle. Ensuite seulement, sélectionnez PHP 8.5 dans le panneau de l’environnement de test.

Après le basculement, ne vous contentez pas de vérifier la page d’accueil. Testez les parcours qui comptent réellement pour votre activité :

navigation sur les principales pages et affichage sur mobile ;
formulaire de contact avec réception effective de l’e-mail ;
prise de rendez-vous, si elle est intégrée au site ;
connexion à l’administration WordPress ;
création ou modification d’un article et affichage du contenu ;
recherche interne, si elle est utilisée ;
panier, paiement et e-mails transactionnels pour un site WooCommerce ;
espaces membres, téléchargements ou contenus protégés lorsqu’ils existent.

Sur un site de cabinet ou de praticien, le formulaire et la prise de rendez-vous méritent une attention particulière. Le choix entre une extension WordPress et une solution externe a d’ailleurs des conséquences sur cette phase de test : notre article rendez-vous en ligne : plugin WordPress ou outil externe détaille les points à comparer.

Utilisez une fenêtre de navigation privée pour contrôler le site sans être trompé par vos cookies ou votre session administrateur. Videz aussi le cache de WordPress, de votre extension de cache, de l’hébergeur et, le cas échéant, de votre CDN. Un cache peut masquer une erreur, mais aussi donner l’impression qu’un problème persiste alors qu’il est corrigé.

Surveiller les signaux techniques utiles, sans multiplier les outils

Une erreur visible peut prendre différentes formes : page blanche, message « Une erreur critique est survenue », erreur 500, formulaire qui ne s’envoie plus ou zone d’administration inaccessible. Mais certains avertissements PHP ne sont pas immédiatement visibles par les visiteurs.

Le premier réflexe consiste à consulter les journaux d’erreurs PHP proposés par l’hébergeur. Selon l’interface, ils peuvent être nommés error log, logs ou journal des erreurs. Cherchez les lignes correspondant à l’heure précise de votre test.

Dans WordPress, le mode de débogage peut écrire des informations dans un fichier de journal, mais il ne doit pas être activé ni affiché sans précaution sur un site public. Les détails techniques peuvent révéler des chemins de fichiers ou des informations inutiles aux visiteurs. Sur une préproduction, un prestataire peut l’activer temporairement pour analyser une erreur, puis le désactiver.

L’extension Query Monitor est également utile en environnement de test pour observer certaines erreurs PHP, requêtes ou appels WordPress. Elle s’adresse surtout à des utilisateurs ayant quelques repères techniques. Inutile de l’installer durablement sur un petit site de production si personne ne consulte ses informations.

Enfin, utilisez Santé du site de WordPress comme tableau de contrôle complémentaire, non comme verdict absolu. Ses recommandations peuvent mettre en évidence une version PHP vieillissante, l’absence de modules nécessaires ou des tâches planifiées problématiques. Elles doivent toutefois être interprétées dans le contexte de votre hébergement.

Que faire en cas d’erreur après le basculement

Une erreur après le passage à PHP 8.5 ne signifie pas que tout est perdu. Le plus important est de réagir dans le bon ordre : préserver l’accès, identifier le composant concerné, puis corriger ou reporter la migration.

Revenir immédiatement à la version PHP précédente si le site est bloqué

Si le site public ou l’administration deviennent inaccessibles, utilisez le panneau de l’hébergeur pour remettre la version PHP qui fonctionnait auparavant. C’est précisément pour cette réversibilité qu’il faut noter la version de départ avant toute manipulation.

Un retour arrière PHP ne remplace pas une sauvegarde, mais il règle souvent l’urgence. Il permet de remettre le site en ligne pendant que vous analysez le problème sur une préproduction. Évitez de modifier plusieurs éléments à la fois dans la précipitation : vous perdriez la trace de la cause.

Identifier l’extension ou le thème responsable

Les journaux d’erreurs indiquent souvent un chemin de fichier. S’il contient le dossier d’une extension, vous tenez une piste. S’il renvoie vers le thème actif ou le thème enfant, la correction doit être examinée de ce côté.

Sur la copie de test, désactivez temporairement l’extension suspecte, puis refaites le contrôle. Si l’erreur disparaît, cherchez une mise à jour, une note de compatibilité ou une alternative maintenue. Si le problème vient d’un thème, testez temporairement avec un thème par défaut de WordPress, sans toucher au site de production.

Pour un site WooCommerce, ne désactivez pas aveuglément un module de paiement ou de livraison sur la boutique en ligne. Effectuez cette recherche sur le staging, puis prévoyez une fenêtre de maintenance si une intervention en production est nécessaire.

Quand demander de l’aide

Contactez le support de l’extension, du thème ou votre prestataire avec des informations précises : version de WordPress, version PHP, version du composant, message d’erreur complet et étapes permettant de reproduire le problème. Un simple « mon site ne marche plus » ralentit le traitement.

Si l’erreur concerne l’hébergement, fournissez l’heure du test, l’URL touchée et une capture d’écran. Le support de l’hébergeur pourra alors consulter les journaux serveur plus efficacement.

Dans certains cas, la bonne décision est de différer PHP 8.5. Par exemple, si une extension métier essentielle n’est pas encore compatible et qu’aucune alternative raisonnable n’existe. Il vaut mieux rester provisoirement sur une version PHP encore maintenue et planifier le remplacement du composant que forcer une migration qui casse une fonction essentielle.

Préparer le basculement sur le site en production

Lorsque les tests sont concluants, choisissez un créneau calme. Pour un site vitrine, l’opération peut être rapide ; pour une boutique ou un site de prise de rendez-vous, évitez les périodes où vous recevez le plus de demandes.

Juste avant le changement, réalisez ou vérifiez une sauvegarde récente. Si du contenu a été ajouté depuis la création du staging, gardez à l’esprit que cette copie n’est plus parfaitement identique à la production. Le test valide surtout la compatibilité technique ; il ne doit pas conduire à écraser des données récentes lors d’un éventuel déploiement.

Après le basculement PHP dans le panneau de l’hébergeur :

videz les caches nécessaires ;
contrôlez la page d’accueil et quelques pages stratégiques ;
envoyez un formulaire de test ;
connectez-vous à l’administration ;
surveillez les journaux d’erreurs dans les heures qui suivent ;
vérifiez le lendemain les e-mails, commandes ou réservations selon votre activité.

Cette dernière vérification est importante : certaines tâches sont exécutées à intervalles réguliers par WordPress ou par le serveur. Un site peut paraître normal immédiatement après la migration, puis révéler un souci lors de l’envoi différé d’un e-mail ou d’une synchronisation planifiée.

Faire de PHP une routine de maintenance plutôt qu’une urgence

Le passage à PHP 8.5 est plus simple lorsqu’il s’inscrit dans un entretien régulier. Un site WordPress durable repose rarement sur une accumulation d’outils : il dépend surtout de composants bien choisis, mis à jour et réellement utilisés.

Conservez une liste courte de vos extensions essentielles, identifiez la personne qui gère l’hébergement et planifiez un contrôle périodique de la santé du site. Cela rejoint une logique plus générale : avant une évolution majeure de WordPress ou de son environnement serveur, il faut pouvoir tester et revenir en arrière. Notre article sur la préparation d’un site WordPress sans mise à jour risquée applique le même principe aux mises à jour du CMS.

PHP 8.5 ne doit donc pas être subi comme une alerte administrative de plus. En préparant les mises à jour, en testant une copie du site et en gardant une procédure de retour arrière, vous transformez une contrainte technique en opération de maintenance maîtrisée. Si votre site repose sur des extensions anciennes, du code sur mesure ou des fonctions métier importantes, faites-vous accompagner avant le basculement : quelques vérifications ciblées suffisent souvent à préserver la fiabilité du site.