Ce que signifie la fin de vie d'une version PHP
Chaque version de PHP suit un cycle de vie structuré : deux ans de support actif avec correctifs de bugs et de sécurité, puis une année de support de sécurité seul. À l'issue de ce cycle, la version entre en état End of Life (EOL). Pour PHP 8.2, cette date est fixée au 31 décembre 2026. Une fois cette date passée, les vulnérabilités découvertes dans PHP 8.2 ne recevront plus aucun patch officiel. Vos serveurs continueront à faire tourner le code, mais ils le feront sans filet de sécurité. Les CVE publiées après le 31 décembre 2026 resteront exploitables indéfiniment sur les installations non migrées.
Les risques concrets après le 31 décembre 2026
- **Failles zero-day sans correctif** — les vulnérabilités découvertes dans PHP 8.2 après l'EOL ne seront plus patchées officiellement, exposant vos applications à des attaques exploitables dès leur publication.
- **Incompatibilité croissante des frameworks** — Laravel 12 recommande PHP 8.3 minimum ; WordPress 6.7 et les extensions premium commencent à abandonner le support PHP 8.2.
- **Retrait par les hébergeurs** — certains hébergeurs et panneaux de contrôle suppriment PHP 8.2 de leurs environnements managés, forçant une migration d'urgence non planifiée.
- **Risque lors des audits de conformité** — les référentiels ISO 27001, PCI-DSS et SOC 2 signalent l'usage de runtimes EOL comme un risque non accepté.
- **Perte de support Composer** — les paquets Composer cessent progressivement de déclarer la compatibilité avec PHP 8.2, générant des conflits lors des mises à jour de dépendances.
Inventorier votre parc : repérer tous les sites en PHP 8.2
La première difficulté pour une agence n'est pas technique, c'est cartographique. Avant toute migration, vous devez savoir exactement combien de sites tournent sur PHP 8.2 et sous quelle configuration serveur. Un inventaire incomplet débouche sur des sites oubliés qui restent exposés après la date limite. Sur chaque VPS ou serveur mutualisé, exécutez php -v par virtual host ou consultez le fichier phpinfo.php déployé temporairement, et listez toutes les versions actives dans un tableur partagé avec le contexte (CMS, framework, dépendances critiques).
Checklist de migration vers PHP 8.3 ou 8.4
Tester la compatibilité sur un environnement de staging
Avant toute modification en production, dupliquez le site sur une instance de test avec PHP 8.3 ou 8.4 activé. Repérez les avertissements de dépréciation, les erreurs fatales et les incompatibilités d'extensions.
Mettre à jour les dépendances
Lancez composer update en environnement de staging et résolvez les conflits de version. Vérifiez que chaque paquet déclare explicitement la compatibilité avec la version PHP cible dans son composer.json.
Valider avec la suite de tests
Exécutez PHPUnit, Pest ou les tests end-to-end existants sur la version PHP cible. Si le projet ne dispose pas encore de tests, priorisez les parcours critiques (authentification, panier, formulaires de contact) avec des tests manuels documentés.
Basculer la version en production
Une fois la validation complète, changez la version PHP active dans la configuration du virtual host (PHP-FPM pool ou directive de l'hébergeur), puis surveillez les logs d'erreur pendant 24 à 48 heures.
Isoler les projets difficiles avec Docker
Quand les projets ont des exigences très différentes en extensions ou en configuration ini, Docker offre une isolation complète : chaque application dispose de son propre runtime PHP et de ses propres extensions, sans interférence avec les autres conteneurs.
Sur un VPS, PHP-FPM permet d'exécuter plusieurs versions en parallèle : chaque virtual host nginx pointe vers un pool FPM distinct (par exemple php82-fpm.sock, php83-fpm.sock). Cela vous permet de migrer site par site sans affecter les autres projets hébergés sur la même machine. Commencez par les sites les moins critiques pour roder votre processus.
Anticiper pour gérer votre parc client en douceur
Pour une agence qui gère des dizaines de sites, la migration PHP est un projet plurisite à piloter plusieurs mois à l'avance. Etablissez un planning par priorité décroissante : sites critiques e-commerce en premier, sites vitrine en dernier. Communiquez à vos clients les risques de rester sur PHP 8.2 après le 31 décembre 2026 — une note de service datée peut suffire à déclencher l'accord et la budgetisation nécessaires. Pour les projets qui utilisent Docker depuis le début, la migration se réduit à changer une image de base dans le Dockerfile : voir notre guide demarrer-avec-docker-vps pour la mise en place pas à pas.
