SYMFONY / Fin de support Symfony
Votre version de Symfony s'arrête : monter, rester, ou refondre ?
Symfony 6.4 LTS cesse de recevoir des corrections en nov. 2026, puis des correctifs de sécurité en nov. 2027. Ce n'est pas une panne annoncée, c'est une date connue depuis sa sortie. Ce que vous en faites dépend du logiciel, pas du calendrier.
Cette page ne vend pas une migration. Elle pose les trois options réelles, dit dans quels cas chacune est la bonne, y compris celle de ne rien faire, et donne une grille pour trancher. La méthode technique est ailleurs, sur la page migration.
OÙ EN EST VOTRE VERSION
Les LTS Symfony encore couvertes, et jusqu'à quand
Symfony publie une majeure tous les deux ans et fait de sa dernière mineure une LTS : trois ans de corrections, puis un an de correctifs de sécurité seuls. Les dates ci-dessous sont dérivées du calendrier officiel. Si votre version n'y figure pas, elle est déjà en fin de vie.
Symfony 7.4 LTS
Sortie nov. 2025, support actif jusqu'en nov. 2028, puis correctifs de sécurité jusqu'en nov. 2029. La cible naturelle de qui monte de version aujourd'hui : quatre ans de couverture devant elle, et une seule majeure d'écart avec la précédente.
Symfony 6.4 LTS
Sortie nov. 2023, support actif jusqu'en nov. 2026, puis correctifs de sécurité jusqu'en nov. 2027. La LTS la plus déployée du parc français. Sa fin de support actif puis de sécurité sont les deux échéances qui motivent le plus de décisions en ce moment, et c'est le cas que cette page prend pour exemple.
Symfony 5.4 LTS
Sortie nov. 2021, correctifs de sécurité jusqu'en févr. 2029. Son support de sécurité a été prolongé bien au-delà de la règle, parce qu'un éditeur (Ibexa) l'a financé. C'est la preuve qu'une LTS ancienne peut être mieux couverte qu'une majeure récente. Ce n'est pas une cible : deux majeures la séparent de la LTS courante.
Le modèle en trois phases, et ce que chacune autorise, est expliqué sur la page fin de support, commune à toutes les technologies.
Chez nos clients
La montée vers Symfony 7.4 est déjà en cours
Pour un client sous contrat de maintenance SmartBooster, la question de cette page ne se pose pas : la montée de version fait partie du contrat, elle est planifiée à la sortie de chaque LTS, et elle est menée sans interruption de service.
En cours depuis mai 2026
La montée vers Symfony 7.4 LTS est engagée sur l'ensemble des projets que nous exploitons dans le cadre d'un contrat de maintenance. Nos clients n'ont rien eu à demander : c'est prévu au contrat.
3 à 7 jours par projet
Selon la taille du projet, la montée d'une majeure prend entre trois et sept jours, recette et mise en production comprises. C'est très en dessous de ce qu'on lit ailleurs, et ce n'est pas un hasard.
Pourquoi ça tient
Nous connaissons ces projets, nous les avons développés selon nos pratiques, et chacun a ses tests automatisés : ce qui casse à la montée de version se voit en minutes, pas en production.
Sur une base moins saine, une remise à niveau d'abord
Un projet sans tests ou développé autrement demande une étape préalable, chiffrée à part après audit. Ce n'est pas la montée de version qui coûte, c'est ce qui manque pour la faire vite.
Ces délais sont ceux que nous tenons sur les projets que nous maîtrisons. Sur un projet repris, l'audit dit d'abord ce qui manque pour les tenir.
Comment nous migrons Le contrat de maintenance L'audit avant repriseNotre position
Une fin de support n'oblige à rien, elle oblige à décider
Trois réponses possibles, aucune n'est la bonne partout.
La réponse réflexe est « il faut migrer ». Elle est souvent juste, et c'est notre métier de le faire. Mais elle est fausse pour un logiciel qui sera éteint l'an prochain, prématurée pour un projet que personne ne sait déployer, et insuffisante pour celui qui en est à sa troisième migration douloureuse en dix ans.
Une page qui concluait toujours par la migration ne vous servirait à rien : vous sauriez ce qu'elle vend avant de l'avoir lue. Celle-ci décrit les trois options avec les cas où chacune est la bonne, et ce que chacune coûte. La décision reste la vôtre.
LES TROIS OPTIONS
Monter, rester, ou refondre : trois réponses réelles
Pour chacune : les situations où elle est la bonne, ce qu'elle coûte et ce qu'elle achète. Aucune n'est la bonne partout, et c'est ce qui fait de cette page un arbitrage plutôt qu'une offre.
Monter de version, vers la LTS courante
De Symfony 6.4 vers la 7.4 LTS : une seule majeure d'écart, et une couverture jusqu'en nov. 2029. C'est la réponse par défaut pour un logiciel qui a de l'avenir, et celle qui coûte le moins quand elle est prise pendant la phase de support actif plutôt qu'à la fin de la phase de sécurité. Comment nous migrons, et à quoi ressemble le travail sur une montée de majeure.
C'est la bonne réponse quand
Le logiciel a encore des années devant lui
Il porte une activité qui continue, on lui demande encore des évolutions, et personne n'envisage de le remplacer. Chaque mois de retard renchérit la montée de version qui finira par s'imposer.
Il est exposé
Accessible depuis internet, avec des comptes clients, des données personnelles ou des paiements. Une faille non corrigée sur un logiciel exposé n'est pas un risque théorique, c'est une question de temps.
Les dépendances commencent à bloquer
Une librairie que vous voulez ajouter exige déjà la version suivante, ou un bundle que vous utilisez a cessé de publier pour la vôtre. Le blocage arrive rarement par Symfony lui-même.
Ce que ça engage
Ce que ça coûte
Un chantier technique borné, dont le prix dépend surtout de l'état du projet (tests, bundles abandonnés, écart de majeures), très peu de Symfony lui-même.
Ce que ça achète
Quatre ans de tranquillité, des dépendances qui suivent, et une équipe qu'on peut encore recruter.
Rester, et assumer en connaissance de cause
Rester sur une version en phase de sécurité seule n'est pas une faute. Rester par oubli en est une. La différence tient à une décision datée : jusqu'à quand, pour quelle raison, et ce qui la remettra en cause. Commencez par situer vos versions.
C'est la bonne réponse quand
Le logiciel a une fin programmée
Il sera remplacé, fusionné ou éteint dans les dix-huit mois, et la décision est prise. Migrer un logiciel condamné est de l'argent dépensé deux fois. On sécurise l'existant et on tient la date.
Il n'est pas exposé
Un outil interne, derrière un VPN, sans compte externe ni donnée sensible, tourne des années sur une version en phase de sécurité seule sans incident. Le risque existe, il est mesurable, et il peut être assumé en connaissance de cause.
Le budget est arbitré ailleurs, cette année
Une refonte métier, un autre chantier prioritaire, une trésorerie tendue. Rester douze mois de plus en phase de sécurité est un choix défendable, à condition de le dater : ce qui ne l'est pas, c'est de rester par oubli.
Ce que ça engage
Ce que ça coûte
Appliquer chaque correctif de sécurité publié, renoncer aux librairies qui exigent la version suivante, et accepter qu'un bug rencontré ne sera plus corrigé par l'éditeur.
Au-delà de la fin des correctifs
Un support étendu payant existe (SensioLabs pour Symfony, à vérifier version par version) : c'est un sursis, utile pour tenir une date, pas une destination.
Ne pas rejouer le même coup dans quatre ans
Quand la fin de support revient comme une crise à chaque cycle, la version n'est pas le problème. Le problème est ce qui rend chaque migration douloureuse : un projet sans tests, une équipe qui ne suit plus, ou un socle qui n'est plus vraiment Symfony. Deux chemins selon la cause : reprendre le projet avec une autre équipe, ou reconstruire sur un socle sain.
C'est la bonne réponse quand
C'est la troisième fois que la question se pose
Le logiciel a déjà été migré deux fois, à chaque fois dans la douleur, et rien n'a changé entre les deux : pas de tests, pas de documentation, une seule personne qui sait. La prochaine migration coûtera autant. La question n'est plus la version, c'est la façon dont le logiciel est tenu.
L'équipe n'est plus la bonne
Le prestataire ne suit plus, ne répond plus, ou a disparu. Migrer avec lui n'est pas possible, et migrer sans lui suppose d'abord de reprendre le projet. La montée de version vient après, jamais avant.
Le socle lui-même est en cause
Le code n'est pas vraiment sur Symfony : un framework maison greffé dessus, une version 1 jamais montée, ou une architecture qui rend chaque évolution plus chère que la précédente. Là, monter de version ne règle rien, et reconstruire brique par brique est le vrai chemin.
Ce que ça engage
Ce que ça coûte, et ce que ça achète
Plus qu'une montée de version, cette fois. En échange, la suivante sera un chantier ordinaire.
La quatrième issue, qu'il faut oser nommer
Décider que ce logiciel ne mérite plus d'investissement, et planifier sa fin proprement.
LA GRILLE POUR TRANCHER
Quatre questions, et ce que chaque réponse implique
Aucune ne suffit seule. Un logiciel exposé et condamné dans un an se sécurise et s'éteint ; un outil interne qui doit vivre dix ans migre sans urgence mais migre. La grille sert à formuler la décision, pas à la prendre à votre place.
Première question
Combien de temps le logiciel doit-il encore vivre ?
C'est la question qui commande les autres, et celle qu'on oublie de poser. Une montée de version s'amortit sur des années : sur un logiciel qui n'en a plus qu'une devant lui, elle ne s'amortit pas.
La réponse n'a pas besoin d'être précise. Elle a besoin d'exister, et d'avoir un propriétaire.
Moins de deux ans, décision prise
Rester et sécuriser. Une migration ne se rentabilise pas sur un logiciel condamné.
Plus de deux ans, ou indéfiniment
Monter de version, vers la LTS courante, avant la fin des correctifs de sécurité.
On ne sait pas
C'est la réponse la plus fréquente, et c'est déjà une information : le logiciel n'a pas de propriétaire qui décide. Commencer par là.
Deuxième question
À quoi est-il exposé ?
Une faille non corrigée n'a pas la même portée sur un back-office derrière un VPN et sur un espace client ouvert sur internet. C'est l'exposition qui transforme une fin de support en risque, pas la date.
Elle se mesure : qui peut atteindre le logiciel, avec quelles données derrière, et qui vous le demande.
Internet, comptes clients, données personnelles
Le report n'est pas une option raisonnable après la fin des correctifs de sécurité.
Interne, VPN, utilisateurs connus
La phase de sécurité seule peut se prolonger, à condition d'appliquer chaque correctif publié.
Un assureur ou un client le demande
Les questionnaires cyber exigent une politique de mise à jour écrite. Une version datée et une décision datée y répondent, une version oubliée non.
Troisième question
Combien de majeures le séparent de la LTS courante ?
On ne saute pas de majeure : chaque palier se franchit l'un après l'autre, avec ses propres changements incompatibles. L'écart de versions est donc la première variable du coût, avant la taille du projet.
Il dit aussi combien de temps il reste : plus l'écart est grand, plus la phase de sécurité de la version actuelle est la seule marge.
Une seule
Un chantier borné, qui se planifie sur un trimestre. C'est le moment où il coûte le moins.
Deux ou plus
Chaque majeure sautée s'ajoute à la facture, et la phase de sécurité de la version actuelle est votre seule marge. Décider maintenant, pas à l'échéance.
Le code n'est pas vraiment sur une version
Framework maison, Symfony 1, fork figé : ce n'est plus une montée de version, c'est une reprise.
Quatrième question
Dans quel état est le projet ?
Une montée de version révèle ce qui casse. Sans tests, on ne le saura qu'en production ; sans déploiement reproductible, on ne saura pas revenir en arrière. L'état du projet décide de l'ordre des opérations, pas seulement du prix.
C'est aussi la question qui sépare l'option 1 de l'option 3 : un projet qu'on ne sait pas tenir reviendra à la même case dans quatre ans.
Tests, documentation, déploiement reproductible
La migration est un chantier technique ordinaire. Elle peut attendre la bonne fenêtre.
Aucun des trois
Migrer d'abord est une erreur : on ne saura pas ce qui a cassé. Stabiliser, tester, puis monter. C'est plus long, et c'est la seule façon de ne pas le refaire dans quatre ans.
Une seule personne sait
Le risque n'est pas la version, c'est cette personne. La reprise passe avant la migration.
Vous hésitez entre les trois ?
Décrivez-nous le logiciel, pas la version
Ce qu'il fait tourner, qui l'utilise, combien de temps il doit encore vivre, et qui s'en occupe aujourd'hui. Nicolas vous dit laquelle des trois options tient, y compris quand la réponse est de ne pas migrer. Premier échange gratuit, sans engagement.
Appel de 30 min → Lecture des versions → Recommandation écrite
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Sortie nov. 2023, support actif jusqu'en nov. 2026, puis correctifs de sécurité seuls jusqu'en nov. 2027. Ces dates sortent du calendrier officiel de Symfony, que nous confrontons automatiquement à notre référentiel. Après la fin des correctifs de sécurité, chaque faille découverte reste ouverte : le logiciel fonctionne, mais plus personne ne le protège.
Rien de visible. Le logiciel démarre, les utilisateurs se connectent, les commandes passent. Ce qui change est invisible : la prochaine faille découverte dans Symfony ne sera pas corrigée pour votre version, et elle sera publiée dans la base CVE avec sa description. Les librairies cesseront une à une de supporter votre version. Les développeurs qui la connaissent se raréfieront. Aucun de ces effets n'a de date, ils s'accumulent.
La documentation officielle indique qu'après la fin de la maintenance d'une version, un support professionnel peut être obtenu auprès de SensioLabs, la société qui sponsorise le framework. Les conditions et les versions couvertes ne sont pas publiées : elles se demandent, version par version. C'est un sursis payant, utile pour tenir une date de remplacement ou traverser une année contrainte, pas une alternative durable à la montée de version.
À la fin du support actif, pas à la fin des correctifs de sécurité. La phase de sécurité seule est la fenêtre de décision : elle dure un an sur une LTS Symfony, et c'est le temps qu'il faut pour cadrer, budgéter et mener une montée de version d'une majeure sans presser personne. Décider à la fin de la phase de sécurité, c'est décider en urgence, et l'urgence coûte.
Vers la 7.4 LTS, couverte jusqu'en nov. 2029. Attendre une LTS qui n'est pas encore publiée, c'est prolonger le séjour sur une version qui s'éteint, pour une cible dont personne ne connaît encore les changements. On ne saute pas de majeure : le chemin passe de toute façon par la LTS courante, et c'est la page migration qui détaille comment.
On ne migre pas avec un prestataire qui ne suit plus, et on ne migre pas non plus sans avoir repris le projet. L'ordre est : reprendre, stabiliser, puis monter de version. La reprise commence par un audit qui dit ce qui presse et ce qui peut attendre, versions comprises.
« Nous collaborons avec l'équipe Smartbooster depuis 3 ans sur un projet stratégique pour notre activité.
Nous avons largement dépassé la relation « client/prestataire », l'équipe Smartbooster nous accompagne au quotidien dans le développement de nos outils digitaux.
Une équipe experte, réactive et à l'écoute… Je recommande évidemment ! »
« Tout au long de notre collaboration, Nicolas a toujours su être un professionnel exemplaire. En tant que project manager, il sait prendre tous les sujets à bras-le-corps et les prioriser avec intelligence.
Il sait aussi donner la visibilité suffisante et rassurante sur les avancées de ses équipes. Nicolas se révèle être un interlocuteur crédible et efficace autant sur le plan technique que sur le plan de la gestion projet. »
Pour aller plus loin
Approfondir votre réflexion
Ce qui s'arrête à chaque phase, pourquoi les éditeurs procèdent ainsi, et les politiques de six technologies avec toutes leurs dates.
Si vous avez choisi l'option 1 : comment nous montons de version palier par palier, ce que Rector automatise, et ce que chaque majeure a changé.
Si l'équipe n'est plus la bonne : ce que nous lisons les deux premières semaines, et dans quel ordre nous stabilisons avant de monter de version.
Six versions à renseigner, et l'outil situe chacune dans son calendrier de support, PHP et Symfony compris.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.