Fin de support Symfony : quelle version reçoit encore des correctifs

La réponse courte, au 9 août 2026 : trois versions sont supportées, 6.4, 7.4 et 8.1, et une quatrième, 5.4, ne reçoit plus que des correctifs de sécurité. Toutes les autres branches sont arrêtées. Cette page sert à situer la vôtre et à identifier la marche suivante la plus courte, pas à vous convaincre de partir.

Ce que « fin de vie » veut dire, et ce que cela ne veut pas dire

Une version en fin de vie ne tombe pas en panne. Votre application continue de fonctionner exactement comme la veille. Ce qui s'arrête, c'est le flux de correctifs : une faille publiée après cette date ne sera jamais corrigée sur cette branche. Le risque ne se manifeste donc pas le jour de la fin de support, il se constitue lentement, à mesure que des vulnérabilités sont divulguées et restent ouvertes chez vous.

Une distinction se perd souvent, et elle change la lecture du calendrier. Le processus de publication du projet sépare la fin des corrections de bugs et la fin des correctifs de sécurité. Pour une version à support long terme, un an sépare les deux : trois ans de corrections, quatre ans de sécurité. Pour une version standard, les deux tombent le même jour, au bout de huit mois. Il n'y a donc pas de période de grâce sur une version standard, contrairement à ce que l'habitude des LTS laisse croire.

Où vous êtes, et quelle est la marche suivante

Sources : la liste des versions et le fichier de statut publié par symfony.com, qui déclare 6.4, 7.4 et 8.1 supportées, 5.4 en sécurité seule, et nomme 8.2 comme prochaine version. Les dates de la branche 6.4 figurent sur sa page de version. Les planchers PHP par version viennent du même fichier de statut.

Deux lignes de ce tableau méritent une remarque. Une application en 7.4 n'a rien à faire côté Symfony pendant trois ans, ce qui est confortable mais déplace le sujet vers PHP et vers les dépendances. Une application en 8.1 est à jour aujourd'hui et sortira du support en janvier prochain : c'est la situation qui demande le plus d'attention, précisément parce qu'elle ne ressemble pas à un problème.

Le coût de chaque montée repoussée

Repousser une montée ne fait pas que reporter le travail, cela en change la nature. Le mécanisme de dépréciation de Symfony ne fonctionne que d'une majeure à la suivante : la dernière mineure d'une branche signale ce que la majeure d'après supprimera. Franchir deux majeures d'un coup revient à perdre ce signal pour la première d'entre elles, et à traiter les deux vagues de ruptures ensemble, sans savoir laquelle a causé quoi. Un retard de deux ans ne coûte pas deux fois un an, il coûte plus.

L'autre effet est extérieur à votre code. Les bundles tiers alignent leurs contraintes de version sur les branches vivantes ; plus vous restez sur une branche morte, plus la probabilité augmente qu'une dépendance dont vous avez besoin ne propose plus de version compatible. Vous vous retrouvez alors à devoir remplacer une bibliothèque au milieu d'une montée de version, ce qui est le pire moment pour le faire.

Surveiller le calendrier sans y penser

Le statut de chaque branche est publié dans un format lisible par machine : rien n'empêche de comparer, dans votre intégration continue, la version verrouillée par Composer à la liste des versions supportées, et de faire échouer la vérification quand vous en sortez. Le projet propose aussi des notifications par courriel à la publication d'une version et à l'arrivée en fin de vie d'une branche. Un contrôle automatique vaut mieux qu'une note dans un calendrier partagé, parce qu'il survit aux départs.

Questions fréquentes