Symfony 6.4 : fin des correctifs en novembre 2026, vers quelle version migrer

Symfony 6.4 ne reçoit plus de correctifs de bugs après novembre 2026 ; seules les failles de sécurité seront encore corrigées, jusqu’en novembre 2027. Ce guide donne les dates officielles, ce que la fin des correctifs change, la version vers laquelle migrer, la version de PHP qui va avec et la méthode de migration.

Il s’adresse aux dirigeants techniques, aux DSI et aux responsables d’applications PHP construites sur Symfony 6.4. La mise à jour des applications web fait partie de notre offre de développement web et de la maintenance applicative.

Quand le support de Symfony 6.4 s’arrête-t-il ?

Le support de Symfony 6.4 s’arrête en deux temps : les correctifs de bugs prennent fin en novembre 2026, les correctifs de sécurité en novembre 2027. Symfony publie ces échéances au mois près, sans jour précis.

Symfony 6.4 est sortie en novembre 2023. C’est une version à support long terme (LTS), comme la dernière version mineure de chaque branche (5.4, 6.4, 7.4) : selon le processus de publication de Symfony, une LTS reçoit des correctifs de bugs pendant trois ans et des correctifs de sécurité pendant quatre ans. Les autres versions, dites standard, ne sont maintenues que huit mois. Symfony 6.4 demande PHP 8.1 au moins ; sa dernière version publiée à ce jour est la 6.4.50.

Les versions standard Symfony 7.3 et 8.0 ne sont déjà plus maintenues : une application restée sur l’une d’elles ne reçoit plus aucun correctif.

Que change la fin des correctifs de bugs en novembre 2026 ?

Après novembre 2026, une application Symfony 6.4 fonctionne exactement comme avant, mais les versions correctives de la branche 6.4 ne contiennent plus que des correctifs de sécurité. Un bug découvert ensuite dans un composant de Symfony 6.4 reste dans le framework : c’est à l’application de le contourner.

• Les bugs. Un défaut du framework signalé après novembre 2026 n’est corrigé que dans les versions maintenues, 7.4 et 8.x.
• La sécurité, encore un an. Les failles restent corrigées jusqu’en novembre 2027. Après cette date, plus aucune version 6.4 ne paraît, et une faille découverte ensuite reste ouverte.
• PHP. Une application en Symfony 6.4 tourne souvent sur PHP 8.1 ou 8.2. PHP 8.1 n’est plus supporté depuis le 31 décembre 2025, et PHP 8.2 ne reçoit plus que des correctifs de sécurité, jusqu’au 31 décembre 2026.
• Les dépendances. Les bundles et les bibliothèques suivent les versions maintenues de Symfony : une application restée en 6.4 se retrouve peu à peu bloquée sur d’anciennes versions de ses dépendances.

L’année de sécurité seule est une marge pour planifier, pas une raison d’attendre : une migration lancée fin 2027 se fait sous la contrainte de la date. Une fois la maintenance terminée, Symfony renvoie vers le support professionnel de SensioLabs, la société à l’origine du framework ; ce support achète du temps, la migration reste à faire. La démarche est la même que pour un langage en fin de vie, décrite dans notre article sur la fin du support de PHP 8.2.

Symfony 7.4 ou Symfony 8 : vers quelle version migrer ?

Pour quitter Symfony 6.4, la cible à privilégier est Symfony 7.4 : c’est la version LTS en cours, sortie en novembre 2025, avec des correctifs de bugs jusqu’en novembre 2028 et des correctifs de sécurité jusqu’en novembre 2029.

• Symfony 7.4, le choix par défaut. Trois ans de correctifs devant elle, PHP 8.2 au minimum, et le chemin le plus court depuis 6.4 : une seule version majeure à franchir.
• Symfony 8, pour les équipes qui suivent chaque version. Symfony 8.1 est la version stable actuelle, mais c’est une version standard : maintenue jusqu’en janvier 2027, puis remplacée par 8.2, et ainsi de suite tous les six mois. Elle demande PHP 8.4 et impose de passer d’abord par 7.4.
• Attendre la prochaine LTS ? Au rythme publié par Symfony, une version mineure en mai et une en novembre, la prochaine LTS, Symfony 8.4, est attendue en novembre 2027 : au moment même où Symfony 6.4 perd ses correctifs de sécurité. L’attendre, c’est migrer sans marge.

Quelle version de PHP choisir avec Symfony 7.4 ?

Avec Symfony 7.4, visez PHP 8.4 ou PHP 8.5. Symfony 7.4 accepte PHP 8.2, mais PHP 8.2 ne reçoit plus que des correctifs de sécurité et s’arrête le 31 décembre 2026 : migrer le framework sans changer de PHP laisserait l’application sur un langage sans support quelques semaines plus tard.

PHP 8.4 est aussi la version minimale de Symfony 8 : la choisir dès maintenant ne ferme aucune porte. Le changement de version de PHP se prépare comme celui du framework et se livre séparément ; notre article sur la fin du support de PHP 8.2 en détaille les étapes.

Comment migrer de Symfony 6.4 vers Symfony 7.4 ?

La méthode officielle de Symfony tient en une règle : une application sans aucune dépréciation en 6.4 fonctionne en Symfony 7, car Symfony 7.0 contient les mêmes fonctionnalités que 6.4, moins celles qui étaient dépréciées. Les étapes, dans l’ordre :

• Faire l’inventaire. Versions exactes de Symfony et de PHP, bundles et bibliothèques et leur compatibilité avec Symfony 7, couverture de tests, chaîne de déploiement. Un audit de l’existant répond à ces questions.
• Supprimer les dépréciations en 6.4. En développement, la barre de débogage et le profiler listent les appels dépréciés. Avec le PHPUnit Bridge (composer require --dev symfony/phpunit-bridge), les tests affichent le nombre de dépréciations restantes, à ramener à zéro. Rector, un outil tiers cité par la documentation de Symfony, automatise une partie des réécritures.
• Mettre PHP à niveau, vers 8.4 ou 8.5, et le livrer à part, sur Symfony 6.4 encore en place.
• Changer de version. Dans composer.json, passer les contraintes symfony/* de 6.4.* à 7.4.* (les paquets symfony/polyfill-*, symfony/ux-* et les bundles qui ont leur propre numérotation ne changent pas), lancer composer update "symfony/*", puis vider le cache en supprimant le contenu de var/cache.
• Mettre à jour les recettes. composer recipes:update aligne les fichiers de configuration installés par Symfony Flex ; les conflits se règlent comme des conflits Git.
• Lire le guide UPGRADE-7.0. Ce fichier du dépôt Symfony liste les ruptures, dont des valeurs par défaut qui changent (voir la section suivante).
• Tester et livrer. Les parcours critiques, les formulaires, l’authentification, les tâches en arrière-plan. Une campagne de tests préparée avant la migration sert de référence, et la mise en production se fait avec un retour arrière prêt.

Viser directement 7.4 plutôt que 7.0 est possible : la promesse de compatibilité de Symfony permet de passer d’une version mineure à la suivante sans rupture, et les dépréciations ajoutées entre 7.1 et 7.4 n’empêchent rien de fonctionner ; elles préparent Symfony 8.

Qu’est-ce qui change entre Symfony 6.4 et Symfony 7 ?

Entre Symfony 6.4 et Symfony 7, l’essentiel des changements est annoncé par des dépréciations dès la 6.4 : une application qui n’en a plus est prête. Les points qui demandent le plus de travail, d’après le guide UPGRADE-7.0 de Symfony :

• Les annotations laissent la place aux attributs PHP. Les annotations Doctrine ne sont plus lues pour les routes, la validation et la sérialisation : @Route devient #[Route], et ainsi de suite.
• Les commandes et les gestionnaires de messages. Command::$defaultName est retiré au profit de l’attribut #[AsCommand], MessageHandlerInterface au profit de #[AsMessageHandler].
• L’injection de dépendances. ContainerAwareInterface et ContainerAwareTrait sont retirés : un service se reçoit par injection, il ne se cherche plus dans le conteneur.
• Des composants retirés. Le composant Templating est supprimé au profit de Twig ; Twig 2 et Monolog avant la version 3 ne sont plus pris en charge.
• La sécurité. L’option enable_authenticator_manager disparaît, et activer SecurityBundle sans configurer au moins un pare-feu n’est plus permis.
• Des valeurs par défaut qui changent. http_method_override passe à false, le cookie de session passe en secure « auto » et SameSite « lax », les UUID générés passent en version 7, la validation des e-mails passe en mode html5. Ces changements se vérifient un par un sur l’application.
• Des types plus stricts. Symfony 7 ajoute des types de retour natifs : les classes de l’application qui étendent celles du framework doivent les déclarer. ParameterBag::getInt() et getBool() lèvent désormais une erreur au lieu de renvoyer 0 ou false.

Une application qui a pris du retard sur ses versions cache souvent d’autres retards, dans le code comme dans l’infrastructure : c’est une part de la dette technique, et son rattrapage relève de la maintenance évolutive.

Questions fréquentes

Symfony 6.4 : fixez maintenant la date de la migration

Novembre 2026 ne casse rien, mais il ouvre la dernière année de Symfony 6.4, et cette année ne couvre plus que la sécurité. La décision tient en trois points : la version cible (Symfony 7.4, avec PHP 8.4 ou 8.5), l’ordre des livraisons (dépréciations, PHP, framework), et une date pour chacune, fixée après l’inventaire des dépendances.

L’équipe iones met à jour des applications Symfony, de l’inventaire à la mise en production, dans le cadre de son offre de développement web, et les tient à jour dans la durée avec la maintenance applicative. Pour faire le point sur vos applications, écrivez-nous.