Symfony et PHP 8.4 : moderniser sans tout réécrire

Symfony et PHP 8.4 en 2026 : moderniser une application sans tout réécrire

Passer un projet Symfony à PHP 8.4, ce n’est pas simplement remplacer une version dans composer.json, lancer un composer update et croiser les doigts.

Sur une application qui tourne depuis plusieurs années, le vrai sujet est ailleurs : savoir ce que l’on peut moderniser, ce qu’il vaut mieux conserver et comment avancer sans transformer une mise à jour technique en chantier interminable.

Parce que dans la vraie vie, on ne repart pas de zéro tous les six mois.

Il y a des clients à servir, des données à préserver, des fonctionnalités qui fonctionnent déjà et une équipe qui doit continuer à livrer pendant la migration.

Et c’est justement là que le duo Symfony et PHP 8.4 devient intéressant.

PHP 8.4 n’est pas dépassé parce que PHP 8.5 existe

PHP 8.5 est sorti fin 2025, mais cela ne transforme pas PHP 8.4 en vieille version bonne à jeter.

PHP 8.4 bénéficie encore d’un support actif jusqu’à la fin de l’année 2026, puis de correctifs de sécurité jusqu’au 31 décembre 2028. Pour une entreprise qui privilégie la stabilité et ne souhaite pas courir après chaque nouvelle version dès sa sortie, cela reste donc une base tout à fait sérieuse.

Consulter le calendrier officiel des versions de PHP

Côté Symfony, PHP 8.4 est même devenu la version minimale requise par Symfony 8. La branche stable Symfony 8.1 demande actuellement PHP 8.4 ou une version plus récente.

Consulter les informations sur Symfony 8.1

Autrement dit, PHP 8.4 n’est pas seulement une étape de transition. C’est le socle sur lequel Symfony construit désormais ses versions modernes.

Des nouveautés utiles, pas seulement décoratives

PHP 8.4 apporte plusieurs changements importants : les hooks sur les propriétés, la visibilité asymétrique, les objets initialisés à la demande, l’attribut #[Deprecated], une nouvelle API DOM compatible avec HTML5, ainsi que différentes améliorations de performances et de cohérence du langage.

Découvrir les nouveautés de PHP 8.4

Évidemment, personne n’a besoin de réécrire tout son projet pour utiliser chaque nouveauté dès le lundi matin.

Mais certaines d’entre elles permettent de simplifier du code que l’on écrit depuis des années.

Les hooks sur les propriétés

Jusqu’ici, dès que l’on voulait contrôler la lecture ou la modification d’une propriété, on finissait souvent avec un getter, un setter et plusieurs lignes de code pour une opération assez simple.

PHP 8.4 permet maintenant d’associer directement un comportement à une propriété :

final class Product
{
    public float $price {
        set {
            if ($value < 0) {
                throw new InvalidArgumentException(
                    'Le prix ne peut pas être négatif.'
                );
            }

            $this->price = round($value, 2);
        }
    }
}

La validation et la normalisation restent proches de la donnée concernée, sans avoir besoin de multiplier les méthodes uniquement pour lire ou modifier une valeur.

C’est pratique, mais ce n’est pas une invitation à déplacer toute la logique métier dans les propriétés.

Comme souvent avec PHP, la fonctionnalité est intéressante lorsqu’elle simplifie le code. Elle le devient beaucoup moins lorsqu’on l’utilise partout simplement parce qu’elle vient de sortir.

Une propriété publique, mais pas modifiable par tout le monde

La visibilité asymétrique permet de distinguer les droits de lecture et d’écriture.

Une propriété peut, par exemple, être accessible publiquement tout en restant modifiable uniquement depuis la classe :

final class Order
{
    public private(set) OrderStatus $status = OrderStatus::Pending;

    public function markAsPaid(): void
    {
        $this->status = OrderStatus::Paid;
    }
}

Le reste de l’application peut consulter l’état de la commande, mais il ne peut pas décider arbitrairement qu’elle est payée.

Ce genre de détail rend les objets plus explicites et évite de laisser des modifications sensibles se promener un peu partout dans le projet.

La visibilité séparée pour la lecture et l’écriture fait partie des nouveautés centrales de PHP 8.4.

Consulter les nouvelles fonctionnalités de PHP 8.4

Les lazy objects : la nouveauté qui intéresse directement Symfony

Les lazy objects sont des objets qui ne sont initialisés que lorsqu’ils deviennent réellement nécessaires.

Le principe existait déjà dans Symfony et Doctrine, notamment pour charger certains services ou certaines relations uniquement au moment où l’application en a besoin.

Le problème, c’est que les frameworks devaient jusqu’ici construire leurs propres systèmes de proxies et générer du code pour obtenir ce comportement.

PHP 8.4 intègre désormais ce mécanisme directement dans le langage grâce à son API de réflexion.

Depuis Symfony 7.3, les services configurés en chargement différé peuvent utiliser automatiquement les lazy objects natifs lorsque l’application tourne sous PHP 8.4 ou une version plus récente.

Il n’y a rien de particulier à réécrire dans le projet : Symfony détecte la version de PHP et utilise directement le mécanisme natif.

Découvrir l’intégration dans Symfony 7.3

Ce n’est probablement pas la fonctionnalité que l’on montrera en premier dans une démonstration commerciale.

Mais sous le capot, c’est typiquement le genre d’évolution qui compte : moins de code généré, moins de contournements propres au framework et une fonctionnalité importante désormais gérée par PHP lui-même.

Une migration progressive reste possible

Adopter PHP 8.4 ne signifie pas obligatoirement passer immédiatement à la dernière version majeure de Symfony.

Symfony 6.4 accepte PHP 8.1 ou une version supérieure et bénéficie encore de correctifs de sécurité jusqu’en novembre 2027.

Symfony 7.4, l’actuelle version LTS, fonctionne à partir de PHP 8.2 et restera couverte par les correctifs de sécurité jusqu’en novembre 2029.

Consulter les informations sur Symfony 7.4

Une équipe peut donc commencer par mettre à niveau PHP, stabiliser l’application, vérifier les dépendances et traiter les alertes avant d’envisager une migration plus importante du framework.

C’est souvent plus raisonnable que de vouloir changer en même temps :

• La version de PHP

• La version majeure de Symfony

• Doctrine

• Le système d’authentification

• L’infrastructure

• La moitié de l’architecture

Changer dix choses en même temps donne peut-être l’impression d’avancer vite.

En revanche, lorsqu’un problème apparaît en production, retrouver précisément ce qui l’a provoqué devient beaucoup moins amusant.

Non, changer la version dans composer.json ne suffit pas

Avant de migrer, je commence généralement par vérifier quelles dépendances bloquent encore PHP 8.4 :

composer why-not php 8.4

Puis je contrôle les prérequis réellement installés sur la machine ou dans le conteneur :

composer check-platform-reqs

Ensuite viennent les étapes moins spectaculaires, mais beaucoup plus importantes :

• Mettre à jour les dépendances compatibles

• Lancer les tests automatisés

• Repérer les dépréciations

• Vérifier les extensions PHP utilisées

• Analyser le code avec PHPStan ou Psalm

• Tester les commandes, les workers et les tâches planifiées

• Générer le cache de production

• Contrôler les logs après le déploiement

PHP 8.4 contient quelques incompatibilités et de nouvelles erreurs sur des usages auparavant tolérés.

Le guide officiel recommande donc explicitement de tester l’application avant de changer la version utilisée en production.

Consulter le guide de migration vers PHP 8.4

Pour une migration Symfony majeure, la documentation recommande également de supprimer les dépréciations avant de modifier les contraintes de version, puis d’effectuer la mise à jour avec Composer et l’ensemble des dépendances nécessaires.

Consulter le guide de migration majeure de Symfony

Ce travail paraît moins vendeur qu’une réécriture complète.

Pourtant, c’est souvent lui qui fait la différence entre une migration maîtrisée et trois jours passés à réparer la production.

Profiter de la migration pour nettoyer, sans chercher à tout refaire

Une mise à niveau vers PHP 8.4 peut devenir une bonne occasion de revenir sur certaines parties du projet :

• Préciser les types qui sont encore trop vagues

• Remplacer quelques constructions devenues inutiles

• Supprimer les dépendances abandonnées

• Corriger les dépréciations accumulées

• Renforcer les tests autour des fonctionnalités sensibles

• Simplifier du code qui s’est complexifié au fil des années

Mais il faut aussi savoir s’arrêter.

Un ancien service un peu verbeux, correctement testé et parfaitement stable n’a pas forcément besoin d’être entièrement réécrit avec les dernières fonctionnalités du langage.

À l’inverse, un composant fragile, difficile à comprendre et rempli d’effets de bord mérite peut-être davantage qu’un simple changement de version.

L’expérience consiste justement à faire la différence entre les deux.

Symfony reste intéressant pour les projets qui doivent durer

Ce que j’apprécie avec Symfony, ce n’est pas seulement le nombre de composants disponibles ou la richesse de sa documentation.

C’est surtout la possibilité de faire évoluer une application par étapes.

On peut moderniser l’environnement PHP sans réécrire immédiatement le métier.

On peut traiter progressivement les dépréciations.

On peut mettre à jour les dépendances une par une, renforcer les tests et préparer la prochaine version majeure sans immobiliser tout le projet pendant plusieurs mois.

Le framework ne garantit évidemment pas à lui seul un code propre.

Une mauvaise architecture reste une mauvaise architecture, même avec la dernière version de Symfony et tous les attributs à la mode.

La maintenabilité dépend toujours des choix techniques, des tests, de la compréhension du métier et de la manière dont l’équipe travaille ensemble.

Mais Symfony fournit un cadre suffisamment stable pour accompagner cette évolution sans imposer de repartir de zéro à chaque nouvelle version.

Mon avis

En 2026, PHP 8.4 reste un très bon choix pour une application Symfony.

La version est suffisamment récente pour profiter des évolutions modernes du langage, suffisamment installée pour ne plus être une nouveauté expérimentale et compatible avec plusieurs branches Symfony encore maintenues.

Faut-il migrer uniquement pour pouvoir écrire PHP 8.4 dans la documentation du projet ?

Non.

En revanche, si l’application tourne encore sur une ancienne version de PHP, que les dépendances commencent à bloquer ou que la dette technique complique chaque évolution, la migration peut devenir un excellent point de départ.

Pas besoin de tout jeter.

On commence par auditer, tester et sécuriser. Puis on modernise ce qui apporte une vraie valeur, étape par étape.

C’est moins spectaculaire qu’une réécriture complète.

Mais dans beaucoup de projets, c’est aussi beaucoup plus utile.