Le critère qu'on vérifie trop tard : les versions de PHP
Ou : PHP a une date de péremption, et elle est imprimée sur le site du langage, pas sur l’offre.
La réponse courte : le 12 novembre 2026, quatre branches de PHP reçoivent encore des correctifs de sécurité, 8.2, 8.3, 8.4 et 8.5, d’après le calendrier officiel du projet PHP. La première les perd le 31 décembre 2026. Une offre d’hébergement sérieuse propose donc au moins PHP 8.4 et 8.5, et dit ce qu’elle fera des versions anciennes. La plupart des pages de vente se contentent d’écrire « PHP 8 », ce qui ne renseigne ni sur la version la plus récente ni sur la date à laquelle la vôtre deviendra un risque : c’est l’un des critères à vérifier avant de signer, au même titre que les autres points de ce que permet un mutualisé.
Un site resté sur une branche abandonnée continue de fonctionner. Le problème est ailleurs : les failles découvertes après la fin du support ne sont plus corrigées par le projet PHP, les extensions cessent peu à peu d’être testées sur cette version, et l’hébergeur peut un jour imposer la mise à niveau.
Pour qui : un site PHP, WordPress ou autre, qui veut disposer des versions 8.4 et 8.5 et des correctifs de sécurité déployés par l’hébergeur.
À partir de : 5,75 € HT par mois pour l’hébergement web Infomaniak, facturé à l’année par défaut, sans prix promotionnel affiché (relevé du 12 novembre 2026).
Pour démarrer : commander l’hébergement web Infomaniak, tester le site sur une copie avec PHP 8.4 ou 8.5, puis changer la version du site dans le Manager.
Version de PHP chez l’hébergeur : ce qui est proposé, ce qui est encore maintenu
| Branche | Fin du support actif | Fin des correctifs de sécurité |
|---|---|---|
| PHP 8.5 | 31 décembre 2027 | 31 décembre 2029 |
| PHP 8.4 | 31 décembre 2026 | 31 décembre 2028 |
| PHP 8.3 | 31 décembre 2025 | 31 décembre 2027 |
| PHP 8.2 | 31 décembre 2024 | 31 décembre 2026 |
| PHP 8.1 | terminé | 31 décembre 2025 |
| PHP 8.0 | terminé | 26 novembre 2023 |
| PHP 7.4 | terminé | 28 novembre 2022 |
Source : php.net, pages des versions supportées et des branches en fin de vie, lues le 12 novembre 2026. Le même jour, le site du projet annonçait PHP 8.6 au stade de la septième version candidate, ouverte aux tests. Sur les branches en fin de vie, le projet PHP recommande fortement de passer à une version actuelle, car les anciennes exposent à des failles et à des bogues corrigés depuis.
| Hébergeur | Versions proposées | Ce que l’hébergeur précise |
|---|---|---|
| Infomaniak | 7.4 à 8.5 | correctifs du 21 octobre 2026 déployés sur toutes ces versions ; après une mise à jour, retour impossible vers une version vulnérable (FAQ du 2 novembre 2026) |
| o2switch | 4.4 à 8.5 | version native, celle d’un hébergement qui ne choisit rien : PHP 8.1 |
| OVHcloud | 5.3 à 8.5 | sa propre fin de prise en charge : 30 juin 2029 pour 8.4, 30 juin 2030 pour 8.5 ; migration recommandée depuis 8.1 et les versions antérieures |
| Hostinger | 8.2 à 8.5 | 8.3 par défaut, versions antérieures à 8.2 plus sélectionnables (article du 29 octobre 2026) |
| PlanetHoster | 5.6 à 8.5 | page d’accueil |
| IONOS | 8.2, 8.3 et 8.4 | « prise en charge étendue » des versions à partir de 5.6 |
| LWS | 5.6 à 8.4 | tableau des offres |
Relevé du 12 novembre 2026 dans la documentation et sur les pages officielles, notamment la grille des versions d’OVHcloud (mise à jour le 27 octobre 2026) et la FAQ d’o2switch.
Deux politiques se dessinent. La première garde les anciennes versions pour que les vieux sites continuent de tourner : o2switch propose encore PHP 4.4, OVHcloud PHP 5.3, IONOS promet de veiller à la sécurité des sites qui n’utilisent pas la dernière version. La seconde ferme la porte : Hostinger ne laisse plus choisir que de 8.2 à 8.5, et Infomaniak interdit de revenir à une version vulnérable une fois qu’on l’a quittée. Aucune n’est mauvaise en soi ; la première protège votre site d’une panne, la seconde vous protège de vous-même.
Le cas d’o2switch mérite une ligne. Sa FAQ, mise à jour le 12 novembre 2026, indique que la version native de PHP, celle d’un hébergement qui n’a rien choisi, est PHP 8.1, et qu’elle évolue au rythme d’une fois par an ou tous les deux ans. Or PHP 8.1 ne reçoit plus de correctif officiel depuis le 31 décembre 2025. Un site installé sans réglage tourne donc, sur le papier, sur une branche en fin de vie ; il suffit de sélectionner une version récente, non native, dans le cPanel. WordPress, de son côté, recommande PHP 8.3 ou plus sur sa page de téléchargement.
Pour changer de version sans casse, l’ordre reste le même partout :
- Vérifier la compatibilité du CMS, du thème et des extensions avec la branche visée.
- Tester sur une copie du site, dans un sous-domaine, plutôt que sur la version en ligne.
- Afficher les erreurs PHP pendant le test, puis les masquer avant la mise en production.
- Changer la version, en sachant si un retour en arrière reste possible chez votre hébergeur.
L’outil qui porte le menu des versions
Selon le panneau, la version se choisit site par site ou pour tout le compte, et la différence compte dès que deux sites n’ont pas le même âge. La comparaison des panneaux, de cPanel aux consoles maison, est faite dans le panneau d’administration au quotidien.
La version oubliée des tâches planifiées
Une tâche cron qui lance un script PHP appelle souvent un binaire précis, comme /opt/alt/php81/usr/bin/php dans l’exemple de la documentation d’o2switch : changer la version du site ne change pas celle de la tâche. Ce piège et les autres sont décrits dans les tâches planifiées d’un mutualisé.
Quand une vieille version ralentit le site
Infomaniak cite une version de PHP compatible parmi les vérifications à faire devant un site lent, avec les extensions trop gourmandes et les requêtes SQL interminables. La méthode complète pour départager les causes est détaillée dans le diagnostic d’un site lent.