Mise à niveau de PHP sur un site autonome : compatibilité, extensions et performances
1. Pourquoi la version de PHP influe sur les performances d’un site autonome
WordPress est écrit en PHP : chaque requête de page fait d’abord tourner l’interpréteur PHP, qui traduit le code en instructions exécutables par la machine. Plus la version de PHP est récente, plus cette traduction est rapide. PHP 8.x embarque de nombreuses optimisations de bas niveau par rapport à 7.4, notamment un OPcache amélioré, la compilation JIT et une meilleure gestion de la mémoire : le même code tourne environ 2 fois plus vite sur 8.2 que sur 7.4.
Ce gain de performance se ressent directement sur un site autonome. Un site dont le LCP est de 3,5 s sous PHP 7.4 passe à environ 2 s après la mise à niveau vers 8.2 avec OPcache activé, et ses Core Web Vitals virent du rouge au vert. Sans changer de thème, sans changer d’extension, sans ajouter de cache : il suffit de changer de version de PHP. C’est pourquoi les équipes d’exploitation recommandent de mettre à niveau PHP au moins une fois tous les deux ans.
| Version de PHP | Date de sortie | Fin du support de sécurité | Performances par rapport à 7.4 | Recommandation pour un site autonome |
|---|---|---|---|---|
| PHP 5.6 et antérieures | Avant 2014 | Arrêté depuis longtemps | En dessous de la référence | À proscrire absolument |
| PHP 7.0 à 7.3 | 2015 à 2018 | Arrêté | Environ 0,8 fois | À mettre à niveau au plus vite |
| PHP 7.4 | 2019 | Arrêté en 2022 | Référence 1,0 | Version de transition, à mettre à niveau au plus vite |
| PHP 8.0 | 2020 | Arrêté en 2023 | Environ 1,5 fois | Utilisable, mais pas recommandé sur la durée |
| PHP 8.1 | 2021 | Fin 2025 | Environ 1,8 fois | Recommandé, stable |
| PHP 8.2 | 2022 | Fin 2026 | Environ 2,0 fois | Recommandé, dernière version stable |
Beaucoup de sites autonomes tournent encore sous PHP 7.4, voire 7.3, parce que « ça marche très bien, on n’ose pas y toucher ». Or 7.4 ne reçoit plus de correctif de sécurité depuis novembre 2022 : même si une nouvelle faille est découverte, personne ne la corrige. Pour un site tourné vers l’international, fonctionner sur une version de PHP sans mises à jour de sécurité fait grimper le risque de piratage avec le temps. Voir la procédure de nettoyage après un piratage dans Que faire après un piratage de son site, et le renforcement de la sécurité et les sauvegardes dans Sauvegarde et restauration : s’entraîner à réagir.
2. Vérifications de compatibilité : les trois choses à faire avant de mettre à jour
Le plus grand risque d’une mise à jour de PHP n’est pas la performance, c’est la compatibilité. PHP 8.x a introduit des changements de syntaxe cassants — par exemple, certaines anciennes fonctions ont été dépréciées, la rigueur des types a changé, et certains comportements historiques ont évolué. Si votre thème ou vos extensions utilisent ces écritures obsolètes, votre site affichera un écran blanc après la mise à jour, et vous ne pourrez même plus accéder à l’administration.
Trois choses à faire avant la mise à jour : premièrement, mettez à jour toutes vos extensions et tous vos thèmes vers la dernière version — les anciennes versions sont souvent incompatibles avec les nouvelles versions de PHP, tandis que les nouvelles ont généralement déjà corrigé le problème ; deuxièmement, utilisez une extension comme PHP Compatibility Checker pour scanner tout le code de votre site et repérer les fichiers qui utilisent des écritures incompatibles ; troisièmement, basculez la version de PHP dans un environnement de staging et testez toutes les fonctionnalités principales.
| Point de contrôle | Méthode de vérification | Critère de validation | En cas d’échec |
|---|---|---|---|
| Compatibilité des extensions | Scan avec PHP Compatibility Checker | Aucune erreur fatale dans les extensions | Trouver une extension alternative ou contacter l’auteur |
| Compatibilité du thème | Idem, scanner le répertoire du thème | Aucun appel à une fonction dépréciée dans le thème | Changer de thème ou attendre une mise à jour de l’auteur |
| Version du cœur de WordPress | Vérifier la version de WP dans l’administration | WP 6.0 ou supérieur est requis pour PHP 8.2 | Mettre à jour le cœur de WP d’abord |
| Extensions de base de données | Vérifier la présence de mysqli avec phpinfo | mysqli est activé | Installer l’extension mysqli |
| Code personnalisé | Scanner le thème enfant et les extensions personnalisées | Aucune fonction dépréciée | Modifier le code manuellement |
Exemple concret : un site B2B utilise une ancienne extension de formulaire datant de 2019, qui génère des erreurs sous PHP 8.1. Avant la mise à jour, un scan avec Compatibility Checker révèle que cette extension utilise la série de fonctions mysql_* (dépréciée depuis PHP 7.0). Dans ce cas, ne forcez pas la mise à jour de PHP : trouvez d’abord une extension de formulaire alternative (comme WPForms ou Fluent Forms), migrez vos formulaires, puis mettez à jour PHP. Pour découvrir comment crater gère la compatibilité des extensions sur les sites d’exportation, consultez La stack technique de crater et ses quatre extensions maison.
Jugement contre-intuitif : les alertes de compatibilité PHP affichées dans « Santé du site » de l’administration WordPress sont souvent inexactes. Elles ne vérifient que la version actuellement installée de l’extension ; si vous avez la dernière version d’une extension mais que son auteur n’a pas mis à jour les tests de compatibilité, l’administration continuera d’afficher qu’elle est compatible. La bonne méthode est de lancer vous-même un scan avec un outil, puis de tester réellement dans un environnement de staging, sans vous fier uniquement aux indications de l’administration.
3. Choix de la version PHP : 8.1 ou 8.2
La version vers laquelle migrer dépend de deux facteurs : la durée du support de sécurité et la compatibilité de votre écosystème d’extensions. PHP 8.1 bénéficie du support de sécurité jusqu’à fin 2025, PHP 8.2 jusqu’à fin 2026. Pour la plupart des sites indépendants, 8.2 est le choix le plus sûr — meilleures performances et support de sécurité le plus long. Mais si une extension essentielle indique explicitement ne supporter que 8.1, migrez d’abord vers 8.1, puis passez à 8.2 une fois l’extension mise à jour.
Ne sautez pas d’étape. Passer directement de 7.4 à 8.2, c’est enjamber deux versions majeures : les fonctions obsolètes et les changements de syntaxe s’accumulent, et le risque de casse augmente fortement par rapport à une montée progressive. Le bon chemin est 7.4 → 8.0 → 8.1 → 8.2 : à chaque version, on teste en staging, et on passe à la suivante seulement si tout est bon.
| Situation | Version recommandée | Raison | Points d’attention |
|---|---|---|---|
| Site tout juste créé | PHP 8.2 | Dernière version stable, meilleures performances | Vérifiez que toutes les extensions prennent en charge 8.2 |
| Site existant sous 7.4 | D’abord 8.1, puis 8.2 | Montez version par version pour réduire les risques | Testez chaque version en staging |
| Écosystème d’extensions ancien | PHP 8.0 ou 8.1 | Meilleure compatibilité | Attendez la mise à jour des extensions |
| Site e-commerce | PHP 8.1 | Écosystème le plus mature | Certaines extensions de paiement ne sont pas compatibles avec 8.2 |
| Site de blog uniquement | PHP 8.2 | Peu d’extensions, bonne compatibilité | Passez directement à 8.2 |
Exemple concret : un site de contenu n’utilise que 5 extensions (Yoast, WP Rocket, WPForms, UpdraftPlus, Wordfence), et ces extensions courantes prennent toutes en charge PHP 8.2. Dans ce cas, montez directement en 8.2 sur le staging, testez, et si tout va bien, déployez en production. Mais pour un site qui utilise WooCommerce et une dizaine d’extensions e-commerce, mieux vaut rester d’abord en 8.1, car à la sortie de 8.2, beaucoup d’extensions de paiement et de logistique n’étaient pas encore adaptées.
4. Installer les extensions : OPcache et les extensions essentielles
Si vous montez la version de PHP sans installer OPcache, vous ne récupérez que la moitié des gains de performance. OPcache stocke en mémoire le bytecode compilé par PHP : au prochain appel, le même code est lu directement en mémoire, sans recompilation. Avec OPcache activé, le temps d’exécution de PHP peut chuter de plus de 50 %, soit un gain supérieur à celui d’une montée de 7.4 à 8.0.
Outre OPcache, un site indépendant a besoin de quelques extensions de base : mysqli (connexion à la base de données, indispensable à WordPress), gd ou imagick (traitement des images, nécessaire à la médiathèque), intl (multilingue et localisation), mbstring (gestion des chaînes multi-octets, nécessaire aux sites en chinois). La plupart des hébergeurs les installent par défaut, mais sur un hébergement mutualisé, il faut parfois les activer manuellement.
| Extension | Rôle | Obligatoire ? | Configuration conseillée |
|---|---|---|---|
| OPcache | Cache de bytecode PHP | Indispensable, performances doublées | memory=256MB, revalidate_freq=60 |
| mysqli | Connexion à la base MySQL | Indispensable, dépendance du cœur de WP | Valeur par défaut |
| gd / imagick | Traitement des images | Indispensable à la médiathèque | imagick est plus rapide que gd |
| intl | Localisation et multilingue | Obligatoire pour un site multilingue | Valeur par défaut |
| mbstring | Chaînes multi-octets | Indispensable aux sites en chinois | Valeur par défaut |
| curl | Requêtes HTTP externes | Indispensable, dépendance de la REST API | Valeur par défaut |
| xml | Analyse XML | Indispensable, RSS et sitemap | Valeur par défaut |
Les points clés de la configuration d’OPcache : réglez opcache.memory_consumption sur 256 (MB) et opcache.revalidate_freq sur 60 (secondes), ce qui signifie que le code est revérifié 60 secondes après une modification. En environnement de développement, mettez revalidate_freq à 0 pour recompiler à chaque requête ; en production, mettez 60 secondes pour équilibrer performance et fraîcheur des mises à jour. Pour la limite de mémoire PHP (memory_limit), prévoyez au moins 256M, et 512M sur les sites qui installent beaucoup d’extensions.
OPcache et le cache de page sont deux couches distinctes, ne les confondez pas. Le cache de page stocke le HTML dans des fichiers, OPcache garde le bytecode PHP en mémoire : c’est en combinant les deux que vous descendez le LCP au minimum. Pour configurer le cache par couches, voir Stratégie de cache à trois niveaux pour un site indépendant, et pour les seuils de performance à atteindre, voir Optimiser les Core Web Vitals.
5. Étapes de mise à niveau et plan de retour arrière
Pour mettre à niveau PHP en production, choisissez impérativement une plage de faible trafic (entre 2 h et 4 h du matin, heure de Pékin) et préparez le retour arrière à l’avance. Si un problème survient pendant la mise à niveau, vous devez pouvoir revenir à l’ancienne version en 5 minutes. Ne mettez jamais à niveau en pleine journée : en cas de problème, les visiteurs n’accèdent plus au site et les demandes de devis sont perdues.
| Étape | Actions | Durée | Méthode de retour arrière |
|---|---|---|---|
| 1. Sauvegarder tout le site | Sauvegarde complète des fichiers et de la base de données | 10 à 30 minutes | Conserver les fichiers de sauvegarde au moins 7 jours |
| 2. Choisir une plage de faible trafic | Entre 2 h et 4 h du matin, heure de Pékin | — | À déterminer en consultant les logs de visite |
| 3. Basculer la version de PHP | Bascule via le panneau de l’hébergeur ou en SSH | 1 à 5 minutes | Retour à l’ancienne version en un clic |
| 4. Tester les parcours essentiels | Page d’accueil, pages produit, envoi de formulaire | 10 minutes | En cas de page blanche, revenir à l’ancienne version |
| 5. Observer pendant 30 minutes | Consulter les logs d’erreur et le trafic | 30 minutes | En cas d’erreur, revenir en arrière immédiatement |
| 6. Vider OPcache | Redémarrer PHP-FPM ou le serveur web | 1 minute | — |
Exemple concret : vous passez PHP de 7.4 à 8.1 dans le panneau BaoTa ou cPanel, vous rechargez la page d’accueil et vous tombez sur une page blanche. Pas de panique : la première chose à faire est de revenir à 7.4 — sur la plupart des panneaux d’hébergeur, changer la version de PHP se fait en un clic, soit 10 secondes pour revenir. Ensuite, consultez les logs d’erreur pour identifier l’extension qui plante, corrigez-la, puis réessayez. Ne restez pas à tester en boucle sur une page blanche : vos visiteurs verraient une page d’erreur tout ce temps.
Après la mise à niveau, observez pendant une semaine. Surveillez deux indicateurs : la présence de PHP Fatal Error dans les logs d’erreur et l’évolution du score Lighthouse. Si les logs d’erreur sont propres et que le LCP passe de 3,5 secondes à moins de 2 secondes, la mise à niveau est réussie. Si de nouveaux avertissements PHP apparaissent, vérifiez d’abord s’il s’agit d’un message deprecated d’une extension : ce type d’avertissement n’affecte pas le fonctionnement, mais notez-le pour le traiter lors de la prochaine mise à jour de l’extension. Dans la maintenance courante, la vérification de la version de PHP est un point fixe, voir Les six tâches mensuelles de la maintenance d’un site. Pour la supervision et les alertes, voir Surveillance et alertes du site.
FAQ — Questions fréquentes
Quelle version de PHP choisir pour un site WordPress indépendant ?
Que faire si le site affiche une page blanche après la mise à niveau de PHP ?
Qu’est-ce qu’OPcache, et faut-il l’activer ?
Peut-on sauter des versions de PHP lors de la mise à jour ?
Faut-il sauvegarder avant de mettre à jour PHP ?
Est-il normal que le LCP ne change pas après une mise à jour de PHP ?
Pour conclure
Dans la mise à jour de PHP, le plus grand obstacle n’est pas technique, il est psychologique : la peur de toucher à quelque chose. Beaucoup d’équipes font tourner leur site sur 7.4 depuis trois ans, en se disant que tout va bien, jusqu’au jour où une mise à jour d’extension provoque un écran blanc, ou où le site se fait pirater, et où l’on pense enfin à migrer. En réalité, la mise à jour de PHP est l’optimisation de performance qui demande le moins d’efforts pour le plus grand gain : aucun code métier à modifier, il suffit de changer de version d’un clic dans le panneau d’hébergement, puis de consacrer une heure à tester les fonctions essentielles.
Trois étapes pour migrer : d’abord, sauvegardez tout le site et la base de données, puis passez les extensions et le thème au crible avec Compatibility Checker ; ensuite, mettez à niveau version par version en staging (7.4 → 8.0 → 8.1 → 8.2) en testant les parcours clés à chaque fois ; enfin, déployez en production aux heures creuses, surveillez pendant 30 minutes et revenez en arrière immédiatement en cas de problème. Une fois ces trois étapes terminées, votre site sera deux fois plus rapide et vos correctifs de sécurité seront à jour.
Une phrase à retenir : passer à une version récente de PHP est l’optimisation la plus rentable pour un site e-commerce — de 7.4 à 8.2, le site va deux fois plus vite, à condition d’avoir d’abord tout testé : une seule extension obsolète suffit à afficher un écran blanc.