Migration Symfony 6.4 vers 7.4 : étapes, risques et stratégie de mise à niveau

Symfony 6.4 et Symfony 7.4 sont toutes deux des versions LTS. La première ne recevra plus de correctifs de bugs après le 30 novembre 2026 et plus de correctifs de sécurité après le 30 novembre 2027 ; la seconde est maintenue jusqu'au 30 novembre 2028 (bugs) et 30 novembre 2029 (sécurité). Pour une application qui doit vivre encore plusieurs années, la question n'est donc pas si mais quand et comment migrer. Voici la méthode que nous appliquons.

1. Ce qui change entre 6.4 et 7.4

La règle de Symfony est stable depuis la 3.x : une version majeure (7.0) n'ajoute aucune fonctionnalité par rapport à la dernière mineure précédente (6.4), elle retire uniquement les couches de dépréciation. Les versions 7.1 à 7.4 ajoutent ensuite des fonctionnalités et, à leur tour, déprécient. La même règle vaut pour 8.0, qui « égale 7.4 moins les dépréciations », selon la formulation de l'équipe Symfony.

Trois conséquences pratiques :

Le prérequis PHP monte : Symfony 6.4 fonctionne sur PHP 8.1 ou plus, Symfony 7.x exige PHP 8.2 ou plus, Symfony 8.0 exige PHP 8.4. Côté PHP, 8.2 et 8.3 ne reçoivent plus que des correctifs de sécurité (jusqu'au 31 décembre 2026 et 2027 respectivement) ; 8.4 et 8.5 sont en support actif. Viser PHP 8.4 au moment de la migration évite une seconde opération dans un an.
Tout ce qui est déprécié en 6.4 disparaît en 7.0 : signatures de méthodes, options de configuration, services, annotations au profit des attributs PHP.
Les dépendances tierces doivent suivre : un bundle qui déclare symfony/framework-bundle: ^6.0 bloque l'installation de la 7.x.

2. Préparer le terrain sur la 6.4

La mise à niveau se gagne avant de changer le numéro de version.

Vider le journal de dépréciations. La commande recommandée par Symfony est simple :
```
php bin/phpunit --display-deprecations
```
Les dépréciations directes viennent de votre code et se corrigent chez vous ; les dépréciations indirectes viennent de vendor/ et se signalent (ou se contournent par une mise à jour) chez le projet concerné. Sans suite de tests, des smoke tests sur les URL principales suffisent déjà à faire remonter l'essentiel.
Inventorier les dépendances. composer outdated --direct et composer why-not symfony/symfony 7.4.* disent immédiatement quels paquets bloquent. Chaque bloqueur devient une tâche : mise à jour, remplacement ou, rarement, fork temporaire.
Passer à PHP 8.2 minimum, idéalement 8.4, sur la 6.4. Cette étape isole les problèmes liés à PHP (typage plus strict, dépréciations de fonctions) de ceux liés à Symfony.
Automatiser ce qui peut l'être. Rector dispose de jeux de règles qui suivent la version Symfony installée :
```
// rector.php
use Rector\Config\RectorConfig;

return RectorConfig::configure()
    ->withPaths([__DIR__ . '/src', __DIR__ . '/tests'])
    ->withPhpSets()
    ->withComposerBased(symfony: true, doctrine: true, phpunit: true);
```
vendor/bin/rector --dry-run montre les changements avant de les appliquer. Rector traite bien les changements mécaniques (signatures, attributs, renommages) ; il ne décide pas à votre place des changements de comportement.

3. Le saut de version

Une fois le journal de dépréciations vide et les dépendances alignées :

// composer.json (application Symfony Flex)
"extra": { "symfony": { "require": "7.4.*" } }

composer update "symfony/*" --with-all-dependencies

C'est la procédure documentée par Symfony (guide « Upgrading a Major Version ») : la contrainte extra.symfony.require fixe la version cible, puis composer update l'applique à tous les paquets symfony/*. En pratique on procède par paquets (symfony/framework-bundle, puis les composants utilisés), et on relance la suite de tests après chaque groupe. Les points qui demandent le plus d'attention dans nos migrations récentes :

la configuration des sérialiseurs et validateurs (attributs, normaliseurs par défaut) ;
les écouteurs d'événements déclarés par convention, dont certains noms ont changé ;
le composant Security : les anciennes classes d'authentification retirées depuis 6.0 ne sont plus tolérées ;
les recipes Flex, à resynchroniser (composer recipes:update) pour récupérer les fichiers de configuration à jour.

4. Plan de tests

Le risque d'une migration n'est pas qu'elle échoue bruyamment — c'est qu'elle réussisse silencieusement avec un comportement différent. D'où un plan de tests en trois couches :

| Couche | Ce qu'elle protège | Quand | | --- | --- | --- | | Tests de caractérisation | Le comportement actuel, défauts compris, sur les parcours critiques | Écrits avant la migration | | Tests d'intégration | API, base de données, files de messages, sur un environnement proche de la production | À chaque lot | | Analyse statique (PHPStan) | Les erreurs introduites par les changements de signature | Niveau augmenté d'un cran après la migration |

Quand la couverture existante est faible, on ne vise pas un pourcentage : on couvre les parcours qui rapportent ou qui engagent (facturation, authentification, exports), puis on élargit.

5. Et Symfony 8 ?

Symfony 8.0 (novembre 2025) et 8.1 (mai 2026) sont des versions à cycle court (huit mois). Pour une application métier, la 7.4 LTS est la cible raisonnable ; la 8.x devient accessible dès que le journal de dépréciations de la 7.4 est vide, exactement comme pour le passage 6.4 → 7.0. La mise à niveau vers 7.4 n'est donc pas un détour : c'est le chemin obligé vers la 8.

Ce qu'il faut retenir

La 6.4 n'aura plus de correctifs de sécurité après novembre 2027 ; planifiez la 7.4 dès maintenant.
La migration se prépare sur la 6.4 : dépréciations à zéro, dépendances alignées, PHP 8.2 ou plus.
Rector et PHPStan accélèrent le travail mécanique ; les tests de caractérisation protègent le comportement.
Chaque étape se livre en production, par lots ; pas de « grand soir ».

Vous avez une application Symfony 6.4 (ou plus ancienne) à mettre à niveau ? Notre offre de modernisation PHP & Symfony commence par un diagnostic préliminaire, sans engagement.

Sources : calendrier des versions Symfony (symfony.com/releases ; endoflife.date/symfony), billet « Preparing for Symfony 7.4 and Symfony 8.0 » (symfony.com/blog), versions PHP supportées (php.net/supported-versions), prérequis PHP par version Symfony (zend.com/blog/symfony-php-requirements), documentation Rector (getrector.com). Dates vérifiées le 28 octobre 2026.