Mettre à niveau PHP sur les sites WordPress de vos clients sans les casser

La mise à jour de sécurité de PHP d’octobre 2026 a été un rappel utile : certains correctifs ne viennent pas d’une mise à jour WordPress. Quand la faille se trouve dans PHP lui-même, le correctif est une version plus récente de PHP sur le serveur, et les sites sur une branche qui ne reçoit plus de correctifs de sécurité n’en reçoivent aucun. Ce guide est une routine que vous pouvez appliquer à chaque site client pour le passer à une version de PHP prise en charge sans mauvaise surprise.

Pourquoi la version de PHP compte plus qu’il n’y paraît

Chaque branche de PHP reçoit des correctifs de sécurité pendant une durée limitée. Ensuite, toute nouvelle faille reste ouverte, même si vous mettez soigneusement à jour WordPress, les plugins et les thèmes. PHP 8.1 et les versions antérieures ne reçoivent plus de correctifs de sécurité officiels. Consultez php.net/supported-versions pour les dates actuelles de chaque branche.

Il y a une deuxième raison. Les auteurs de plugins et de thèmes abandonnent avec le temps la prise en charge des anciennes versions de PHP. Un site qui reste sur une ancienne branche perd peu à peu l’accès aux mises à jour des plugins, et avec elles aux correctifs de sécurité des plugins eux-mêmes.

Étape 1 : relever la version de PHP de chaque site

Dans WordPress, vous la trouvez sous Outils → Santé du site → Informations → Serveur. Votre panneau d’hébergement l’affiche aussi. Pour chaque site, notez la version de PHP, la version de WordPress, le thème, le constructeur de pages, si WooCommerce est utilisé, et s’il y a du code sur mesure dans un thème enfant ou un plugin must-use.

Triez ensuite la liste. Commencez par les versions de PHP les plus anciennes, et parmi elles par les sites qui génèrent du chiffre d’affaires ou des demandes : boutiques, sites de réservation et sites avec des formulaires importants.

Étape 2 : trouver ce qui bloquera la migration

La plupart des mises à niveau de PHP échouent à cause d’un vieux plugin, d’un thème abandonné ou d’un bout de code sur mesure. Cherchez-les avant de basculer :

• Les plugins et thèmes qui n’ont pas été mis à jour depuis deux ans ou plus. Vérifiez les lignes « Requires PHP » et « Tested up to » sur leur page de plugin.
• Les anciennes versions de constructeurs de pages et de plugins premium dont la licence a expiré, si bien que le site n’a jamais reçu les versions compatibles avec un PHP plus récent.
• Le code sur mesure dans functions.php ou les plugins must-use. Des fonctions comme each() et create_function() ont été supprimées en PHP 8.0, et PHP 8.2 avertit au sujet des propriétés dynamiques.
• Les outils d’analyse de compatibilité peuvent aider, mais ils signalent de faux positifs. Prenez leurs résultats comme une liste de départ, pas comme un verdict.

Mettez d’abord à jour WordPress, les plugins et les thèmes, pendant que le site tourne encore sur la version actuelle de PHP. Les versions récentes des plugins prennent généralement en charge un PHP plus récent. Faites les mises à jour et le changement de PHP des jours différents, pour savoir quel changement a causé un problème.

Étape 3 : tester d’abord sur une copie

Faites une copie de préproduction du site et passez-la à la version de PHP cible. La plupart des hébergeurs permettent de choisir la version de PHP par site. Activez WP_DEBUG_LOG sur la copie pour que les erreurs aillent dans un fichier journal plutôt qu’à l’écran.

Parcourez ensuite ce qui compte pour ce client :

• La page d’accueil et les deux ou trois pages les plus visitées, sur ordinateur et sur mobile.
• Chaque formulaire important : envoyez-le et vérifiez que l’e-mail arrive.
• Sur une boutique : ajout au panier, paiement avec une commande test, la page du compte.
• Dans l’administration : l’éditeur et le constructeur de pages s’ouvrent, l’envoi de médias fonctionne, les pages de réglages se chargent.

Lisez ensuite wp-content/debug.log. Les erreurs fatales doivent être corrigées avant la mise en ligne. Les avis de dépréciation sont des avertissements pour la prochaine mise à niveau ; notez-les, ils peuvent attendre. Comparer des captures d’écran des pages clés avant et après révèle les problèmes qui ne produisent pas d’erreur, comme un slider ou un menu qui ne s’affiche plus.

Étape 4 : basculer le site en ligne à un moment calme

Choisissez un moment de faible trafic. Faites une sauvegarde fraîche des fichiers et de la base de données juste avant le changement, et notez la version actuelle de PHP. Changez PHP dans le panneau d’hébergement, videz le cache de pages et un éventuel cache d’objets, et refaites les mêmes vérifications que sur la copie. Laissez la journalisation des erreurs dans un fichier activée un jour ou deux, pour repérer la page que personne n’a visitée pendant votre contrôle.

Expliquez au client en une ou deux phrases ce que vous avez fait et pourquoi. Une mise à niveau de PHP est invisible quand tout se passe bien, et c’est un bon travail de maintenance qu’il mérite de connaître.

Étape 5 : connaître le chemin du retour

Revenir en arrière après une mise à niveau de PHP est généralement simple : remettez l’ancienne version dans le panneau d’hébergement. C’est pour cela que vous l’avez notée. Si un plugin s’avère être le problème, vous avez trois options : le mettre à jour, le remplacer, ou rester peu de temps sur la branche prise en charge précédente le temps de régler la question. Ne restez jamais plus longtemps que nécessaire sur une branche non prise en charge.

En cas d’urgence : une mise à jour de sécurité de PHP lui-même

Quand une faille est publiée dans PHP, une mise à jour WordPress ne la corrige pas. Demandez à votre hébergeur si la version corrective de votre branche a été appliquée. Un correctif au sein de la même branche, par exemple d’une version 8.3 à la suivante, casse rarement quelque chose. Le geste risqué, c’est le passage à une nouvelle branche, et c’est exactement ce à quoi ce guide vous prépare. Les sites sur une branche sans correctifs de sécurité sont ceux à planifier en premier.

Mise à jour du 23 octobre 2026 : un second problème PHP, moins risqué. Deux jours après la version critique, PHP a publié un avis informatif sur la CVE-2026-115560 dans session upload progress (php.net). PHP juge une exploitation peu probable : elle nécessite plusieurs réglages et un code bien précis en même temps. Il n’y a pas encore de correctif ; il arrivera avec la prochaine version régulière de PHP. D’ici là, terminez d’abord les mises à jour du 21 octobre, puis demandez à votre hébergeur de passer session.upload_progress.enabled à off dans php.ini ou dans le pool PHP-FPM et de redémarrer PHP. Le régler depuis WordPress ou un fichier .user.ini peut intervenir trop tard avec PHP-FPM.

Comment Verploy gère les mises à niveau de PHP

Sur les sites avec une ancienne version de PHP, la vérification de mise à niveau PHP de Verploy montre ce qui bloque la migration et dans quel ordre le corriger. Chaque mise à jour est vérifiée, et les plus risquées sont d’abord testées sur une copie. Voyez comment cela s’intègre dans une routine de maintenance complète sur maintenance WordPress pour agences.