Fin du support de PHP 8.2 : migrer vers PHP 8.4 ou 8.5 avant 2027

La fin du support de PHP 8.2 tombe le 31 décembre 2026 : à partir de cette date, plus aucune faille ne sera corrigée par le projet PHP. Si vos applications Symfony, Laravel, WordPress, Drupal ou PrestaShop tournent encore en 8.2, voici la version à viser, les points de compatibilité à vérifier, les outils à utiliser et une méthode de migration testée, avec l’option FrankenPHP.

PHP 8.2 : ce qui se passe le 31 décembre 2026

Chaque branche de PHP bénéficie de deux ans de support actif, puis de deux ans de correctifs de sécurité seuls. Pour PHP 8.2, sortie le 8 décembre 2022, le support actif s’est terminé le 31 décembre 2024 et les correctifs de sécurité s’arrêtent le 31 décembre 2026, selon php.net. Au 19 septembre 2026, la dernière version publiée est la 8.2.33, du 30 juillet 2026.

Le calendrier de PHP 8.6 prévoit quatre versions candidates entre le 24 septembre et le 5 novembre 2026. À la date de publication, 8.6 n’est donc pas encore stable.

Pourquoi rester sur une version en fin de vie est un risque

Sécurité. Une faille découverte en 2027 dans le moteur PHP ou une extension standard ne sera pas corrigée en 8.2. L’exposition dépend de votre code, mais vous perdez le levier le plus simple : appliquer un correctif.

Dépendances. Les frameworks et bibliothèques abandonnent les versions de PHP en fin de vie. Rester en 8.2, c’est se condamner à terme à des versions de dépendances qui ne reçoivent plus elles-mêmes de correctifs.

Conformité. Le Cyber Resilience Act (règlement (UE) 2024/2847) impose aux fabricants de produits comportant des éléments numériques de traiter les vulnérabilités de leurs composants, y compris open source, pendant toute la période de support. Ses obligations de signalement s’appliquent depuis le 11 septembre 2026, le reste au 11 décembre 2027 (Commission européenne). Un éditeur qui livre un logiciel reposant sur un runtime sans correctifs aura du mal à tenir ces engagements ; nous détaillons ces obligations dans notre article sur le Cyber Resilience Act. Pour un site ou une application sur mesure, c’est surtout l’obligation générale de sécurité des données personnelles (article 32 du RGPD) qui s’applique.

Contrats. Si vous êtes prestataire, vérifiez vos contrats de maintenance applicative (TMA) : un engagement de « maintien en conditions de sécurité » est difficile à honorer sur une plateforme que plus personne ne corrige. Mieux vaut planifier la montée de version que la découvrir lors d’un audit client.

Quelle version viser : 8.4 ou 8.5 ?

Notre règle : viser la version la plus récente que toutes vos dépendances supportent officiellement. Sauter directement de 8.2 à 8.4 ou 8.5 se fait très bien ; il n’est pas nécessaire de passer par chaque version intermédiaire en production.

Compatibilité des frameworks et CMS

Sources : Symfony, Laravel, WordPress, Drupal, PrestaShop.

Deux cas méritent une attention particulière. Laravel 11 cumule deux fins de vie : celle du framework et bientôt celle de PHP 8.2. Drupal 10 atteint sa fin de vie le 9 décembre 2026, trois semaines avant PHP 8.2 : la migration vers Drupal 11 et PHP 8.3 minimum est un seul et même projet. Pour WordPress, le cœur suit ; ce sont les extensions et thèmes qui décident.

Ce qui casse en pratique

Vers 8.3 : peu de ruptures. Les nouveautés (constantes de classe typées, json_validate()) sont optionnelles.

Vers 8.4 (liste officielle) :

• les paramètres implicitement nullables (string $x = null) sont dépréciés : écrivez ?string $x = null ;
• exit() et die() se comportent comme des fonctions et lèvent une TypeError sur un type invalide ;
• la constante E_STRICT est dépréciée ;
• les extensions IMAP, OCI8, PDO_OCI et pspell ne sont plus livrées avec PHP et passent sur PECL : un point bloquant pour les applications qui lisent des boîtes mail en IMAP ;
• de nombreuses fonctions lèvent désormais ValueError ou TypeError sur des arguments invalides.

Vers 8.5 (dépréciations) : opérateur backtick, noms de cast non canoniques ((integer), (boolean)), case terminé par un point-virgule, null comme clé de tableau, __sleep() et __wakeup(), curl_close() et imagedestroy(), entre autres. Des dépréciations, pas des erreurs : elles casseront en PHP 9, pas maintenant.

Les outils de la migration

Pour simuler la résolution des dépendances sur la version cible sans changer de machine, déclarez la plateforme dans une branche dédiée :

composer config platform.php 8.4.0
composer update --dry-run
composer why-not php 8.4

Chaque paquet signalé doit être mis à jour, remplacé ou, en dernier recours, forké. C’est souvent là que se cache le vrai coût de la migration.

Configuration Rector minimale :

<?php
// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets(php84: true);

Lancez d’abord vendor/bin/rector process --dry-run, relisez le diff, puis appliquez par lots. Côté PHPStan :

parameters:
    level: 6
    paths: [src, tests]
    phpVersion: 80400

Méthode de migration pas à pas

• Inventorier. Versions de PHP par environnement, extensions chargées (php -m), dépendances Composer, modules et extensions de CMS, tâches planifiées, workers. C’est la première étape d’un audit de migration.
• Choisir la cible avec le tableau de compatibilité, dépendance par dépendance.
• Ajouter la cible à la CI sans bloquer : une matrice qui teste la version actuelle et la cible.

strategy:
  matrix:
    php: ['8.2', '8.4']
steps:
  - uses: actions/checkout@v4
  - uses: shivammathur/setup-php@v2
    with:
      php-version: ${{ matrix.php }}
  - run: composer install --no-progress
  - run: vendor/bin/phpunit

• Journaliser les dépréciations en préproduction (error_reporting = E_ALL, canal dédié : LOG_DEPRECATIONS_CHANNEL sous Laravel, canal deprecation de Monolog sous Symfony).
• Mettre à jour les dépendances bloquantes, puis passer Rector et PHPStan.
• Tester selon le plan ci-dessous.
• Basculer progressivement : une instance ou un site d’abord, observation des erreurs et des performances, puis généralisation. Gardez l’ancienne image prête pour un retour arrière rapide.
• Nettoyer : retirer 8.2 de la CI, mettre à jour la documentation et le contrat de maintenance.

FrankenPHP : changer de runtime pendant la migration ?

FrankenPHP est un serveur d’applications PHP écrit en Go, bâti sur Caddy ; son dépôt est hébergé dans l’organisation GitHub du projet PHP. Son mode worker charge l’application une fois et la garde en mémoire entre les requêtes.

Dans la fiche EXP-02 du iones lab, nous avons développé la même API de commandes (6 endpoints, 2 millions de lignes PostgreSQL, 4 vCPU) dans quatre langages. Résultats utiles pour décider :

Lecture honnête : le gain du mode worker est réel quand le démarrage de l’application pèse lourd ; il disparaît quand la base de données est le goulot. Notre décision après EXP-02 : FrankenPHP pour les nouveaux projets PHP et les migrations depuis PHP-FPM.

Mise en œuvre avec Symfony 7.4 ou plus, qui prend en charge nativement le mode worker :

docker run -e FRANKENPHP_CONFIG="worker ./public/index.php" \
  -v $PWD:/app -p 80:80 -p 443:443 -p 443:443/udp dunglas/frankenphp

Avec Laravel, via Octane : composer require laravel/octane, puis php artisan octane:install --server=frankenphp. Octane redémarre chaque worker après 500 requêtes par défaut, réglable avec --max-requests.

Deux pièges : l’état partagé (propriétés statiques, singletons qui gardent la requête ou l’utilisateur précédent) et les fuites mémoire, jusque-là masquées par PHP-FPM. Faites la migration de version d’abord, le changement de runtime ensuite : deux changements à la fois compliquent le diagnostic.

Plan de test

Questions fréquentes

PHP 8.2 en fin de vie : planifiez la migration dès maintenant

Il reste moins de trois mois avant la fin du support de PHP 8.2. Le chemin est connu : inventaire, choix de la cible selon vos dépendances, CI sur deux versions, Rector et PHPStan, tests des parcours critiques, bascule progressive. Profitez-en pour évaluer FrankenPHP, une fois la migration stabilisée.

Vous gérez un parc d’applications PHP, en direct ou pour vos clients d’agence ? Notre équipe réalise l’audit, la migration et la maintenance, y compris en marque blanche. Parlons de votre plan de migration : réponse sous 48 à 72 heures.