LTS ou version standard : vous choisissez une cadence, pas une version
Mise à jour le 9 août 2026
La question se pose presque toujours à l'envers. On demande « quelle version installer », alors que la décision porte sur autre chose : à quelle fréquence votre équipe accepte de refaire l'opération. Une version standard et une version à support long terme n'offrent pas la même durée de tranquillité, et l'écart n'est pas marginal.
Ce que chaque cadence vous engage à faire
| Cadence | Corrections de bugs | Correctifs de sécurité | Ce que cela impose |
|---|---|---|---|
| Version standard | 8 mois | 8 mois | Une montée de mineure environ tous les six mois, indéfiniment |
| Version LTS | 3 ans | 4 ans | Une montée de majeure tous les deux ans, avec un an de marge |
Ces durées viennent du processus de publication du projet, qui les documente explicitement et assume les deux publics : les équipes qui veulent les nouveautés prennent la version standard et disposent de deux mois pour remonter à chaque cycle ; les entreprises qui cherchent la stabilité prennent la LTS, publiée tous les deux ans, avec un an pour effectuer la transition. Ce sont deux régimes de fonctionnement, pas deux niveaux de qualité.
Un point de vocabulaire qui évite une erreur de lecture : la LTS n'est pas une version à part, développée séparément. C'est la dernière mineure d'une branche, 5.4, 6.4, 7.4, qui reçoit un support prolongé parce qu'elle est le point de passage vers la majeure suivante. Choisir une LTS, ce n'est donc pas choisir une version en retrait, c'est s'arrêter sur la dernière marche avant le saut.
Le piège : prendre une version standard sans la cadence qui va avec
Le scénario est mécanique. Une équipe installe la dernière version disponible parce qu'elle a besoin d'une fonctionnalité récente, ou simplement parce que c'est ce que propose l'installeur. Huit mois passent. Rien ne casse, rien ne prévient, aucune alerte ne se déclenche : une version en fin de vie fonctionne exactement comme avant. L'application est sortie du support et personne ne l'a remarqué, précisément parce qu'il n'y avait rien à remarquer.
Un réglage courant renforce cet effet sans le vouloir. Le guide de montée majeure recommande de contraindre l'ensemble des paquets `symfony/` à une version unique via `extra.symfony.require` dans `composer.json`, ce qui simplifie la gestion des dépendances. Ce réglage fait exactement ce qu'il annonce : tant que vous ne changez pas sa valeur, aucune mise à jour ne vous fera changer de version. La même page signale d'ailleurs que certains outils de mise à jour automatique peuvent l'ignorer et faire bouger les dépendances Symfony malgré lui. Le verrou et l'automate peuvent donc se contredire.
Quatre critères pour trancher
- Personne n'est nommément responsable des montées de version : prenez une LTS. Une cadence semestrielle sans propriétaire désigné ne tient pas deux cycles.
- Vous livrez déjà en continu, avec une suite de tests qui tourne à chaque fusion : la cadence standard est finançable, et elle vous évite les grosses marches.
- L'application est déployée chez des clients dont vous ne maîtrisez pas le calendrier de mise à jour : LTS, sans hésiter. Vous ne pourrez pas imposer deux montées par an à leur planning.
- Vous avez besoin d'une fonctionnalité qui n'existe que dans une version standard : prenez-la, mais inscrivez la date de fin de support dans le même ticket que celui qui autorise la mise en production.
La LTS n'est pas un abri définitif
Quatre ans passent, et une branche LTS finit par s'arrêter comme les autres. Surtout, elle ne vous protège que du côté du framework. Le plancher PHP d'une LTS est fixé à sa sortie et vieillit avec elle : celui de Symfony 6.4 est PHP 8.1.0, une version de PHP qui n'est plus supportée depuis fin 2025. Rester sur une LTS jusqu'au bout de ses quatre ans, sans jamais toucher à l'interpréteur, revient donc à échanger un problème de framework contre un problème de langage.
Il existe une troisième posture, moins confortable à énoncer mais parfois juste : rester sur une version non supportée, en connaissance de cause. Une application interne, sans exposition publique, sans données personnelles et dont le remplacement est déjà planifié à dix-huit mois, ne présente pas la même urgence qu'un service ouvert sur Internet. Ce n'est défendable que si la décision est prise volontairement, datée et écrite, plutôt que subie par oubli.
Questions fréquentes
Une LTS est-elle moins performante ou moins sûre ?
Non. Une LTS est la dernière mineure d'une branche, elle contient donc toutes les fonctionnalités développées pendant ce cycle. La seule différence documentée avec la majeure suivante tient aux éléments dépréciés, que la LTS conserve et que la majeure supprime. Ce qu'une LTS n'a pas, ce sont les nouveautés arrivées après elle, ce qui est une contrainte fonctionnelle, pas un défaut de sécurité.
Peut-on passer de la cadence standard à la cadence LTS ?
Oui, et le chemin est court dans un sens : depuis une version standard, la LTS de la même branche est sa dernière mineure, donc une montée sans rupture. Une application en Symfony 8.1 rejoindra ainsi la LTS de la branche 8 en montant de mineure en mineure, sans jamais franchir de majeure. L'inverse, quitter une LTS pour la cadence standard, suppose de franchir une majeure d'abord, et surtout d'avoir mis en place la discipline de montée qui va avec.
Que se passe-t-il si on saute une LTS entière ?
Vous vous retrouvez à franchir deux versions majeures en une fois. Le mécanisme de dépréciation, qui ne signale que ce que la majeure immédiatement suivante supprimera, ne couvre alors plus la première marche : vous traitez deux vagues de ruptures cumulées sans le diagnostic qui va avec. C'est faisable, mais cela relève d'un chantier de reprise plutôt que d'une montée de version.
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.