PHP 8.2 fin de vie : checklist de migration

Chaque version de PHP suit un cycle de vie en deux phases : deux ans de support actif (correctifs de bugs et de sécurité), puis deux ans de support de sécurité seul — soit quatre ans au total par version. PHP 8.2, sorti en novembre 2022, a terminé son support actif le 31 décembre 2024. Depuis le 1er janvier 2025, seuls les correctifs de sécurité critiques sont encore publiés. Le 31 décembre 2026, même cette couverture s'arrête. Les vulnérabilités découvertes après cette date dans le moteur PHP 8.2 ne recevront aucun patch officiel. Vos serveurs continueront à exécuter le code, mais sans aucun filet de sécurité. Les CVE publiées après l'EOL resteront exploitables indéfiniment sur les installations non migrées. C'est la différence entre un runtime maintenu et un runtime abandonné — et cette différence ne se voit pas dans les logs tant qu'une attaque n'a pas eu lieu.

La première difficulté pour une agence n'est pas technique, c'est cartographique. Avant toute migration, vous devez savoir 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 l'EOL. Sur chaque VPS, exécutez php -v par virtual host ou consultez le fichier phpinfo.php déployé temporairement — supprimez-le immédiatement après consultation. Sur les serveurs cPanel ou Plesk, l'interface d'administration expose la version PHP par domaine. Listez chaque site dans un tableur avec les colonnes suivantes : domaine, version PHP active, CMS ou framework, version du CMS, date de dernière mise à jour des dépendances, et niveau de criticité (e-commerce, vitrine, intranet). Cette cartographie est le prérequis à toute planification : sans elle, vous ne pouvez pas prioriser ni estimer la charge de migration.

Migrer sans tester en amont est la principale cause d'incidents en production. Deux outils complémentaires couvrent l'essentiel de l'analyse statique. PHPCompatibility est un ensemble de règles pour PHP_CodeSniffer : il analyse votre code source et signale les appels de fonctions supprimées, les paramètres dépréciés et les changements de comportement entre versions. Installez-le via Composer (composer require --dev phpcompatibility/php-compatibility) et lancez-le avec la cible --runtime-version=8.3. PHPStan, de son côté, effectue une analyse de types statique : configuré avec le niveau 5 ou supérieur, il détecte les propriétés dynamiques (dépréciées depuis PHP 8.2 et fatales en 8.4), les incompatibilités de types et les signatures de méthodes incorrectes. L'approche recommandée est de lancer PHPStan d'abord sur la base de code actuelle pour établir une ligne de base, puis de passer le niveau de PHP cible à 8.3 ou 8.4 dans votre phpstan.neon pour identifier les écarts. Ces deux passes statiques ne remplacent pas les tests fonctionnels, mais elles permettent de prioriser les fichiers à corriger avant même d'ouvrir un environnement de staging.

Connaître le calendrier de vos frameworks est essentiel pour anticiper les contraintes de migration. Laravel 12, sorti le 24 février 2025, supporte PHP 8.2 à 8.5 et reçoit des correctifs de sécurité jusqu'au 24 février 2027 — il n'y a donc pas d'urgence à monter de version framework. En revanche, Laravel 13 (sorti en Q1 2026) exige PHP 8.3 minimum : toute application qui voudra migrer vers Laravel 13 devra d'abord passer PHP 8.3. Symfony 7.x (toutes versions de 7.0 à 7.4) exige PHP 8.2 minimum ; la version LTS Symfony 7.4, sortie en novembre 2025, est supportée jusqu'en novembre 2029 — elle est compatible PHP 8.3 et 8.4. Symfony 8.x, lui, exige PHP 8.4 minimum. WordPress recommande PHP 8.3 comme version minimale en 2026, et les plugins premium conditionnent progressivement leur support à PHP 8.3 ou supérieur. Ces jalons doivent figurer dans votre planning de migration : une contrainte de framework peut déclencher une montée de PHP plus tôt que prévu.

Une cartographie manuelle vieillit vite : les clients ajoutent des plugins, changent de prestataire de déploiement, ou installent de nouvelles applications sans notification. Automatiser la surveillance de version permet de rester informé sans effort quotidien. Plusieurs approches sont complémentaires. Un script cron simple peut interroger php -v via SSH sur chaque serveur et écrire le résultat dans un fichier de rapport centralisé — un outil comme Ansible ou Fabric permet de paralléliser cette collecte sur des dizaines d'hôtes. Des outils de monitoring de serveur (Netdata, Munin, ou des agents spécialisés) exposent la version PHP dans leurs métriques et peuvent déclencher des alertes si une version non autorisée apparaît. Pour les parcs hébergés sur des VPS ServOrbit, un endpoint d'inventaire par VPS permet d'interroger la version PHP active sur chaque pool FPM depuis un tableau de bord centralisé. L'objectif est que la découverte d'un site encore en PHP 8.2 après le 31 décembre 2026 déclenche une alerte automatique — pas un audit annuel.

Les migrations PHP 8.2 → 8.3/8.4 suivent des patterns d'échec récurrents. Premièrement, les propriétés dynamiques : depuis PHP 8.2, ajouter une propriété non déclarée à une classe est déprécié ; en PHP 8.4, c'est une erreur fatale. Le symptôme est un Warning Creation of dynamic property suivi d'un comportement inattendu. Le correctif : déclarer toutes les propriétés dans la classe ou ajouter l'attribut #[\AllowDynamicProperties] pour les classes héritées. Deuxièmement, les extensions PECL manquantes : PHP 8.3 et 8.4 ne compilent pas les mêmes extensions par défaut selon les distributions ; des extensions comme imagick, redis ou swoole doivent être réinstallées explicitement pour la nouvelle version. Vérifiez avec php8.3 -m | grep redis. Troisièmement, les conflits de versions Composer : un paquet qui déclare "php": "^8.2" peut lever une incompatibilité avec un autre paquet qui déclare "php": "^8.3" si votre composer.lock n'a pas été régénéré — toujours relancer composer update depuis zéro dans l'environnement de staging. Quatrièmement, les directives ini dépréciées : certaines directives comme mbstring.func_overload ont été supprimées ; un php.ini non nettoyé peut provoquer des warnings au démarrage de PHP-FPM et masquer des erreurs applicatives réelles.

Pour une agence qui gère des dizaines de sites, la migration PHP est un projet plurisite à piloter plusieurs mois à l'avance. Établissez un planning par priorité décroissante : les sites e-commerce et les applications de gestion critique en premier, les sites vitrines 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, expliquant les implications de sécurité et de conformité, suffit généralement à débloquer l'accord et la budgétisation nécessaires. Intégrez la montée de version PHP dans vos contrats de maintenance annuels : une ligne dédiée évite de renégocier chaque migration. Pour les projets qui utilisent Docker depuis le début, la migration se réduit à changer une image de base dans le Dockerfile et à relancer les tests — la migration est une demi-journée de travail plutôt qu'une intervention sur serveur.

Sur un VPS ServOrbit, plusieurs versions PHP-FPM coexistent sur la même machine et chaque virtual host pointe vers la version de son choix. La montée de version se fait en modifiant une seule ligne de configuration nginx et en rechargeant PHP-FPM — sans redémarrage de serveur, sans interruption des autres sites hébergés. Pour les parcs agence, un VPS dédié par client ou un VPS mutualisé avec isolation PHP-FPM par pool offre la flexibilité nécessaire pour migrer site par site selon votre calendrier, sans dépendre du planning d'un hébergeur manag é. La gestion centralisée des pools FPM depuis le panneau ServOrbit permet de visualiser en un coup d'oeil quelle version PHP est active sur chaque domaine — un prérequis pour maintenir l'inventaire à jour et anticiper les prochaines échéances de cycle de vie.