En bref : chez un hébergeur, vous changez la version de PHP le plus souvent dans l'espace client, sous un point tel que « Paramètres PHP » ou « Version de PHP », souvent séparément pour chaque domaine. Au préalable, il vous faut une sauvegarde et la configuration requise de votre CMS, ensuite un test de fonctionnement. Important après PHP2Shell : le choix ne détermine que la branche PHP. Que cette branche soit corrigée, l'hébergeur doit vous le confirmer.
Pourquoi tant de gens changent la version de PHP en ce moment
Depuis PHP2Shell, de nombreux exploitants de sites regardent pour la première fois depuis des années leurs paramètres d'hébergement. Ils y trouvent souvent PHP 7.4 ou 8.1, parce que le site a été configuré ainsi un jour et que personne n'a plus regardé. Le projet PHP ne fournit plus de versions pour ces branches ; contre PHP2Shell, il n'a publié que des corrections minimales dans le code source pour 7.4, 8.0 et 8.1.
Chez la plupart des hébergeurs, le changement se fait en un clic. C'est précisément ce qui le rend risqué : un site plus ancien, dont le code n'a pas été écrit pour les versions plus récentes de PHP, n'affiche peut-être ensuite plus qu'un message d'erreur. Un peu de préparation permet de l'éviter. Ce que l'hébergeur prend en charge dans le cadre de PHP2Shell et ce qui vous incombe est décrit sur la page Hébergement mutualisé : ce que fait l'hébergeur.
Le choix dans le panneau n'est pas le correctif
Un malentendu fréquent : qui passe dans l'espace client de 8.2 à 8.3 n'a pas fermé PHP2Shell automatiquement. Vous choisissez une branche que l'hébergeur met à disposition. Que cette branche contienne les corrections, c'est-à-dire qu'elle soit en 8.3.36 ou ait un rétroportage confirmé, c'est entre les mains de l'hébergeur.
Inversement : si votre branche actuelle 8.2 est corrigée chez l'hébergeur, vous êtes protégé contre PHP2Shell, même sans changement. Le passage à une version plus récente reste judicieux, car PHP 8.2 atteint la fin du support le 31 décembre 2026. Faites-vous confirmer le niveau de correctif par écrit ; un modèle figure dans le guide Demander à l'hébergeur l'état des correctifs.
Changer la version de PHP chez l'hébergeur : pas à pas
Les noms de menus diffèrent selon le fournisseur. Cherchez dans l'espace client des termes comme paramètres PHP, version de PHP, configuration PHP ou langages de script. Chez de nombreux fournisseurs, le choix se trouve dans la gestion de chaque domaine.
- Noter l'état actuel : quelle version de PHP tourne pour chaque domaine et sous-domaine ? Une capture d'écran des paramètres aide pour le retour arrière.
- Créer une sauvegarde : fichiers et base de données, si possible via la fonction de sauvegarde de l'hébergeur et en plus en téléchargement.
- Vérifier la configuration requise : quelles versions de PHP votre CMS ou boutique prend-il en charge dans la version installée ? Cela figure dans la configuration requise de l'éditeur, par exemple sur wordpress.org, shopware.com ou typo3.org.
- Mettre à jour extensions et thèmes : les extensions obsolètes sont la cause la plus fréquente d'erreurs après un changement de PHP. Mettez-les à jour avant le changement.
- Utiliser un environnement de test s'il existe : de nombreux hébergeurs proposent du staging ou une copie sur un sous-domaine. Changez-y d'abord.
- Changer : choisir la nouvelle version, enregistrer, attendre quelques minutes. Certains hébergeurs ne prennent pas la modification en compte immédiatement.
- Tester : ouvrir la page d'accueil, le formulaire de contact, la connexion, la recherche, le panier et le paiement, se connecter dans l'espace d'administration et enregistrer.
- Lire le journal d'erreurs : dans l'espace client, il existe le plus souvent un journal d'erreurs PHP. Les avertissements après le changement montrent où des adaptations sont nécessaires.
Changez en dehors des heures d'activité principales et veillez à ce qu'une personne qui connaît le site soit joignable dans l'heure qui suit. Les erreurs ne se remarquent souvent que sur des fonctions rarement utilisées.
Quelle est la bonne version ?
Choisissez la version la plus récente que votre application prend officiellement en charge. La raison est simple : chaque branche PHP ne reçoit des mises à jour de sécurité que pendant une durée limitée. Plus la branche est récente, plus vous avez de tranquillité. Les durées actuelles sont indiquées par php.net sur la page des versions prises en charge ; le fonctionnement du cycle est expliqué sur la page Versions de PHP et cycle de publication.
| Branche | Version corrigée (PHP2Shell) | Classement |
|---|---|---|
| PHP 8.5 | 8.5.12 | actuellement prise en charge |
| PHP 8.4 | 8.4.27 | actuellement prise en charge |
| PHP 8.3 | 8.3.36 | actuellement prise en charge |
| PHP 8.2 | 8.2.35 | fin du support le 31 décembre 2026 |
| PHP 8.1 et plus ancien | aucune version officielle | seulement rétroportages du code source ou du fournisseur |
Si votre application ne prend en charge aucune version à partir de 8.2, le changement seul n'est pas possible. Il faut alors d'abord mettre à jour ou remplacer l'application. Cette voie est décrite par notre prestation Migration depuis PHP 8.1 et plus ancien.
Pièges typiques après le changement
Une page blanche ou une erreur 500 indique le plus souvent une extension ou un thème qui ne supporte pas la nouvelle version. Le journal d'erreurs indique en règle générale le fichier et la ligne. Désactivez le fautif ou revenez temporairement en arrière.
Les paramètres PHP personnalisés se perdent parfois lors du changement. Qui avait par exemple défini une limite d'envoi plus élevée ou une durée d'exécution plus longue des scripts devrait vérifier si ces valeurs s'appliquent encore pour la nouvelle version. Veillez à ne pas écraser des mesures transitoires de l'hébergeur contre PHP2Shell.
Si le site affiche après le changement d'anciens contenus ou d'étranges erreurs, un cache peut en être la cause. Videz le cache du CMS et d'éventuelles extensions de cache. Si le problème persiste, demandez à l'hébergeur si des caches côté serveur doivent être reconstruits.
N'oubliez pas les sous-domaines, installations de test et anciens répertoires. Une copie oubliée depuis longtemps du site sous PHP 7.4 est tout aussi attaquable que le site principal. La manière de se débarrasser de tels héritages est décrite dans l'article Désactiver les anciennes versions de PHP.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons les versions de PHP qui tournent sur vos domaines et sous-domaines et clarifions le niveau de correctif avec l'hébergeur.
- Nous vérifions la compatibilité de votre application et changeons d'abord dans un environnement de test.
- Nous accompagnons le changement, analysons le journal d'erreurs et corrigeons les erreurs ou revenons en arrière de façon contrôlée.
- Là où l'application ne supporte aucune version prise en charge, nous planifions la migration et sécurisons la période transitoire.
Questions fréquentes
Passer à une version de PHP plus récente ferme-t-il PHP2Shell ?
Seulement si l'hébergeur a lui-même corrigé la version choisie. Dans l'espace client, vous ne choisissez le plus souvent que la branche, par exemple 8.3. Que cette branche soit en 8.3.36 ou à un rétroportage confirmé, c'est l'hébergeur qui en décide.
Quelle version de PHP dois-je choisir ?
La version la plus récente que votre CMS ou boutique prend en charge selon la configuration requise de l'éditeur. PHP 8.2 atteint la fin du support le 31 décembre 2026 ; 8.3 ou plus récent est donc le meilleur choix si votre application le permet.
Que se passe-t-il si le site ne fonctionne plus après le changement ?
Rétablissez la version précédente dans l'espace client. Notez le message d'erreur du journal d'erreurs et faites corriger la cause avant de réessayer. Ne restez pas durablement sur une version sans mises à jour de sécurité.
Puis-je définir des versions de PHP différentes pour différents domaines ?
Chez de nombreux hébergeurs oui, par domaine, sous-domaine ou répertoire. C'est pratique pour les tests, mais comporte le risque qu'une ancienne version continue de tourner sur un sous-domaine oublié.