Monter une application Symfony vers une version encore supportée
Mise à jour le 9 août 2026
Symfony va bien, et la question n'est pas là. Elle est de savoir si la version que vous faites tourner reçoit encore des correctifs de sécurité, et si le PHP qui l'exécute en reçoit lui aussi. Au 9 août 2026, le projet ne déclare que trois versions supportées : 6.4, 7.4 et 8.1. Tout le reste est sorti du cadre, y compris des versions publiées il y a moins d'un an. Cette page part de ce constat, pas d'une opinion sur le framework.
Le contresens : récent ne veut pas dire supporté
Symfony publie une version mineure tous les six mois, en mai et en novembre, et une version majeure tous les deux ans. La dernière mineure d'une branche, 5.4, 6.4, 7.4, est une version à support long terme ; les autres sont des versions standard. L'écart de couverture entre les deux catégories est considérable, et il est écrit noir sur blanc dans le processus de publication du projet : huit mois de corrections de bugs et huit mois de correctifs de sécurité pour une version standard, contre trois ans et quatre ans pour une LTS.
La conséquence est contre-intuitive. Une équipe passée en Symfony 8.0 à sa sortie, en novembre 2025, était alors sur la version la plus récente disponible, celle qu'on installe quand on veut bien faire. Neuf mois plus tard, elle est sur une branche qui ne reçoit plus rien. Une équipe restée en 6.4 est couverte en sécurité jusqu'en novembre 2027. Être à jour et être supporté sont deux propriétés distinctes, et seule la seconde vous protège.
Où en est votre version, au 9 août 2026
| Version | Type | Fin des corrections de bugs | Fin des correctifs de sécurité | Statut |
|---|---|---|---|---|
| Symfony 5.4 | LTS | Terminée | En cours | Sécurité seule, plus aucune correction de bug |
| Symfony 6.4 | LTS | 30 novembre 2026 | 30 novembre 2027 | Maintenue |
| Symfony 7.3 | Standard | 31 janvier 2026 | 31 janvier 2026 | Fin de vie, aucun correctif |
| Symfony 7.4 | LTS | 30 novembre 2028 | 30 novembre 2029 | Maintenue, LTS courante |
| Symfony 8.0 | Standard | 31 juillet 2026 | 31 juillet 2026 | Fin de vie, aucun correctif |
| Symfony 8.1 | Standard | 31 janvier 2027 | 31 janvier 2027 | Maintenue, stable courante |
Sources : la liste des versions publiée par symfony.com et son équivalent lisible par machine, qui au 9 août 2026 ne déclare supportées que 6.4, 7.4 et 8.1, et ne conserve 5.4 qu'en maintenance de sécurité. Les dates de la branche 6.4 sont celles de sa page de version. Les branches absentes du tableau, 6.0 à 6.3, 7.0 à 7.2, sont toutes des versions standard arrivées au bout de leurs huit mois : elles ne reçoivent plus rien depuis longtemps.
Le second calendrier, celui de PHP
La version de Symfony n'est pas la seule horloge, et les deux ne sont pas alignées. php.net place PHP 8.2 en correctifs de sécurité seuls jusqu'au 31 décembre 2026, PHP 8.3 jusqu'au 31 décembre 2027 et PHP 8.4 jusqu'au 31 décembre 2028 ; PHP 8.1 est sorti de support fin 2025. Or le plancher de Symfony 6.4 est PHP 8.1.0. Une application en 6.4 peut donc être parfaitement en règle côté framework et tourner sur un interpréteur qui ne reçoit plus aucun correctif. Ce genre de situation passe sous le radar, parce qu'on ne surveille qu'une des deux horloges.
Ce que la montée demande réellement
Une montée de version majeure n'est pas un saut, c'est une échelle. Le guide officiel est explicite sur l'ordre : rendre le code exempt de dépréciations sur la dernière mineure de la majeure courante, puis seulement changer de majeure. La raison est structurelle. Symfony développe en parallèle la dernière mineure d'une branche et la majeure suivante avec les mêmes fonctionnalités, la première conservant les éléments dépréciés que la seconde supprime. Passer par cette mineure vous donne donc, gratuitement, la liste exacte de ce qu'il faudra avoir corrigé.
Le reste du chantier s'organise autour de cette contrainte : faire remonter les dépréciations, les traiter, mettre à jour les dépendances, vérifier. Une partie du travail s'automatise, une autre non, et c'est la frontière entre les deux qui détermine la durée réelle, bien plus que le nombre de versions à franchir. Une application couverte par des tests et une application sans filet ne posent pas le même problème, même si elles affichent le même numéro de version.
Ce qui casse en dehors de Symfony
La promesse de rétrocompatibilité du projet est stricte, mais elle ne couvre que Symfony. Doctrine est un projet distinct, avec ses propres versions majeures et ses propres ruptures ; les bundles tiers suivent chacun leur rythme et n'ont aucune obligation d'être prêts le jour de la sortie. Sur une application de gestion, la couche de persistance est aussi la plus couplée au code métier : c'est fréquemment elle, et non le framework, qui fixe le calendrier réel de la montée.
Questions fréquentes
Faut-il viser une LTS ou la dernière version stable ?
Cela dépend de la fréquence à laquelle vous acceptez de remonter. [Le processus de publication](https://symfony.com/doc/current/contributing/code/releases.html) donne huit mois de couverture à une version standard, ce qui impose une montée environ tous les six mois ; une LTS en donne trois ans pour les bugs et quatre pour la sécurité. Le choix n'est pas technique, il est organisationnel : combien de fois par an votre équipe peut absorber une montée sans repousser tout le reste.
Je suis en Symfony 8.0, est-ce grave ?
8.0 ne figure plus parmi les [versions supportées déclarées par le projet](https://symfony.com/releases.json) depuis le 31 juillet 2026 : les failles publiées après cette date ne recevront pas de correctif officiel sur cette branche. La sortie immédiate est courte, puisque 8.1 est la mineure suivante de la même majeure et qu'[une version mineure n'introduit aucune rupture](https://symfony.com/doc/current/contributing/code/releases.html). Mais 8.1 s'arrête elle-même fin janvier 2027 : la vraie question est de savoir si vous voulez recommencer tous les huit mois.
Combien de temps me reste-t-il en Symfony 6.4 ?
Les corrections de bugs s'arrêtent le 30 novembre 2026 et les correctifs de sécurité le 30 novembre 2027, d'après [la page de version du projet](https://symfony.com/releases/6.4). Vous disposez donc de plus d'un an de couverture sécurité, ce qui laisse le temps d'instruire la décision sans la prendre dans l'urgence. Le point de vigilance est ailleurs : le plancher PHP de cette branche est 8.1.0, une version qui n'est plus supportée depuis fin 2025.
Peut-on sauter directement de 6.4 à 8.1 ?
Composer ne l'interdit pas, mais le chemin décrit par [le guide de montée majeure](https://symfony.com/doc/current/setup/upgrade_major.html) passe par la dernière mineure de chaque majeure, parce que c'est elle qui affiche les dépréciations à corriger avant de franchir la marche suivante. Sauter les étapes revient à découvrir d'un coup les ruptures de deux majeures cumulées, sans le filet des messages de dépréciation, et avec un changement de plancher PHP au passage.
Faire auditer votre application Symfony
Réponse humaine sous 24 h ouvrées. Prendre contact ne vous engage à rien.
Symfony, Doctrine, Rector, Composer et PHP sont des projets et des marques appartenant à leurs détenteurs respectifs. Smartshift n'est ni affiliée, ni partenaire, ni mandatée par aucun d'eux. Les dates de fin de support citées proviennent des calendriers publics de ces projets, relevées le 9 août 2026 ; vérifiez-les avant toute décision engageante, elles peuvent évoluer.