TECHNOLOGIES / Fin de support

Fin de support d'une version : ce qui s'arrête vraiment, et quand

Chaque version de PHP, de Symfony, de Node.js ou de MySQL naît avec sa date de fin. Elle est publiée le jour de la sortie, elle ne bouge presque jamais, et personne ne vous la rappellera. Cette page explique ce qu'elle arrête, en trois temps, et pourquoi les éditeurs procèdent ainsi.

Toutes les dates affichées sortent de notre référentiel de versions, confronté automatiquement aux calendriers officiels. Elles ne sont pas recopiées à la main : quand une échéance passe, la page change.

En résumé, pour extraire l'essentiel

  • « Fin de support » cache deux dates : la première arrête les corrections de bugs, la seconde, un ou deux ans plus tard, arrête les correctifs de sécurité. Entre les deux, le logiciel s'exploite sans risque nouveau : c'est la fenêtre où l'on décide.
  • Ce n'est pas une panne : la date est publiée le jour de la sortie, parfois des années à l'avance, parce que la capacité d'un éditeur à maintenir plusieurs branches est finie. Le calendrier est une promesse dans les deux sens.
  • Notre ligne : nous ne vendons pas l'urgence, une version en phase de sécurité seule n'est pas un incendie. Nous vendons la lecture juste du calendrier, celle qui transforme une contrainte subie en une décision prise à temps.

Le modèle

Trois phases, et ce que chacune autorise

La plupart des éditeurs sérieux suivent le même schéma, avec des durées différentes. Le vocabulaire varie (maintenance, Premier Support, bug fixes), le mécanisme est le même.

1

Support actif

L'éditeur corrige tout : bugs, failles, compatibilité avec les versions récentes du langage et des librairies voisines. Ce que ça autorise : installer les mises à jour au fil de l'eau, ajouter des dépendances récentes, recruter sur une version que les développeurs connaissent. Ce que ça n'autorise pas : croire que ça durera. La date de fin est publiée dès la sortie.

    2

    Correctifs de sécurité seuls

    Les bugs ne sont plus corrigés, seules les failles le sont, souvent avec un délai plus long. Ce que ça autorise : exploiter le logiciel sans exposition nouvelle, à condition d'appliquer chaque correctif publié. Ce que ça interdit : attendre un correctif de bug, ou installer une librairie récente qui exige déjà la version suivante. C'est la phase où l'on décide, pas celle où l'on subit.

      3

      Fin de vie

      Plus rien n'est publié. Le logiciel continue de fonctionner exactement comme la veille. Ce que ça change : chaque faille découverte à partir de cette date reste ouverte, elle est documentée publiquement dans une base CVE, et des robots scannent le web à la recherche des versions qui la portent. L'exposition ne fait que grandir, sans qu'aucun symptôme ne le signale.

        POURQUOI LES ÉDITEURS PROCÈDENT AINSI

        Un calendrier n'est pas une contrainte, c'est un contrat

        Il est tentant de lire une fin de support comme une pression commerciale pour faire migrer. Pour les technologies de cette page, toutes open source, c'est l'inverse : la date protège la capacité de l'éditeur à corriger ce qu'il maintient encore.

        Notre calendrier de support reprend ce que chaque éditeur publie et le place sur un même axe du temps. C'est l'outil que nous ouvrons en premier sur tout projet repris.

        Maintenir une version a un coût, et quelqu'un le paie
        Chaque branche maintenue en parallèle exige de porter chaque correctif sur chacune d'elles, puis de le tester. Un éditeur qui promettait de tout maintenir ne tiendrait pas la promesse. Il promet une durée, et il la tient.
        La LTS est un compromis entre deux publics
        Ceux qui veulent les nouveautés tous les six mois et ceux qui veulent de la stabilité pendant des années ne peuvent pas être servis par la même version. Le double régime standard / LTS résout ce conflit en donnant à chacun son calendrier.
        Un calendrier publié est une promesse dans les deux sens
        L'éditeur s'engage sur ce qu'il corrigera et jusqu'à quand. En échange, il attend que ses utilisateurs aient migré à la date dite. Personne ne vous préviendra le jour venu : la date était connue à la sortie.
        Situer vos versions sur ce calendrier
        Calendrier de support SmartBooster : PHP, MySQL, Node.js, Symfony, Vue.js et Tailwind CSS placés sur un axe du temps, avec la date du jour et la fin de support de chaque version

        EN CE MOMENT

        Les échéances récentes et les cibles qui tiennent

        Les dernières versions sorties de support, puis les LTS encore couvertes vers lesquelles migrer. La liste est dérivée du référentiel : elle se met à jour toute seule.

        Une version marquée EOL ne reçoit plus aucun correctif : chaque faille découverte depuis sa date est ouverte. Une version marquée LTS est une cible de migration raisonnable, parce que sa propre date de fin est la plus lointaine de sa technologie.

        Ce résumé ne remplace pas le détail par éditeur ci-dessous, où chaque version apparaît avec ses deux dates. Il sert à répondre vite à la question que tout le monde pose en premier : est-ce que ça presse ?

        Pour Symfony, la question suivante (monter de version, rester, ou refondre) a sa propre page : fin de support Symfony, que décider.

        Dates EOL récentes et à venir

        Symfony 8.0
        31 juil. 2026 EOL
        Symfony 7.3
        31 janv. 2026 EOL
        PHP 8.1
        31 déc. 2025 EOL
        Vue.js 2.7
        31 déc. 2023 EOL
        PHP 8.0
        26 nov. 2023 EOL
        Vue.js 1.0
        31 déc. 2016 EOL
        Symfony 7.4
        30 nov. 2029 LTS
        Symfony 5.4
        28 févr. 2029 LTS
        Symfony 6.4
        30 nov. 2027 LTS

        Les politiques éditeur

        Six éditeurs, six façons de compter, et le piège de chacune

        Le modèle en trois phases est commun, les durées et les exceptions ne le sont pas. Pour chaque technologie : la logique de l'éditeur, l'erreur de lecture la plus fréquente, et les versions encore couvertes avec leurs deux dates, suivies des deux dernières sorties de support.

        Logo Symfony

        Symfony

        Source : calendrier officiel

        La logique

        Une mineure tous les six mois, en mai et en novembre, une majeure tous les deux ans. Deux régimes : une version standard reçoit huit mois de corrections, bugs et sécurité confondus, et s'éteint à la suivante. La dernière mineure de chaque majeure devient LTS et reçoit trois ans de corrections puis une année supplémentaire de correctifs de sécurité. Le projet documente aussi qu'après la fin de maintenance, un support professionnel s'achète auprès de SensioLabs, la société qui sponsorise le framework.

        Le piège

        La version la plus récente est la moins protégée. Une majeure fraîchement publiée vit huit mois, la LTS de la majeure précédente vit quatre ans. Pour un logiciel métier, viser le dernier numéro est une erreur de calendrier : c'est la LTS qui espace les migrations.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        Symfony 8.1 Mai 2026 Janv. 2027 Janv. 2027 Support actif janv. 2027
        Symfony 8.0 Nov. 2025 Juil. 2026 Juil. 2026 Obsolète depuis juil. 2026
        Symfony 7.4 LTS Nov. 2025 Nov. 2028 Nov. 2029 Recommandée
        Symfony 7.3 Mai 2025 Janv. 2026 Janv. 2026 Obsolète depuis janv. 2026
        Symfony 6.4 LTS Nov. 2023 Nov. 2026 Nov. 2027 Support actif nov. 2026
        Symfony 5.4 LTS Nov. 2021 Nov. 2024 Févr. 2029 Support sécurité févr. 2029
        Logo Vue.js

        Vue.js

        Source : calendrier officiel

        La logique

        Seule la dernière mineure d'une branche reçoit des correctifs. La date de fin de support d'une mineure est la date de sortie de la suivante : la branche, elle, reste vivante. Il n'y a ni LTS ni calendrier publié pour la branche courante. La branche 2 a atteint sa fin de vie en déc. 2023, avec un support étendu payant proposé par un tiers (HeroDevs) pour ceux qui ne peuvent pas la quitter.

        Le piège

        Confondre une mineure remplacée et une version abandonnée. Rester en 3.4 quand la 3.5 est sortie est une mise à jour à planifier, pas un risque : la branche 3 est couverte. Rester en Vue 2 est une tout autre situation, et la même colonne du tableau ne le dit pas.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        Vue.js 3.5 Sept. 2024 Non annoncée Non annoncée Recommandée
        Vue.js 2.7 Juil. 2022 Déc. 2023 Déc. 2023 Obsolète depuis déc. 2023
        Vue.js 1.0 Oct. 2015 Non annoncée Déc. 2016 Obsolète
        Logo PHP

        PHP

        Source : calendrier officiel

        La logique

        Chaque version mineure a son propre cycle, indépendant des autres : deux ans de support actif, puis deux ans de correctifs de sécurité seuls, quatre ans en tout. Les échéances sont alignées sur un 31 décembre, ce qui rend le calendrier lisible d'une année sur l'autre. Il n'existe pas de version LTS : toutes les mineures sont logées à la même enseigne.

        Le piège

        Un numéro qui sonne récent peut être hors support. Un 8.x n'est pas « la version 8 » : la 8.1 et la 8.4 sont deux versions distinctes, à quatre ans d'écart de calendrier. Le piège est de lire le premier chiffre et de croire que la branche entière est couverte.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        PHP 8.5 Nov. 2025 Déc. 2027 Déc. 2029 Recommandée
        PHP 8.4 Nov. 2024 Déc. 2026 Déc. 2028 Support actif déc. 2026
        PHP 8.3 Nov. 2023 Déc. 2025 Déc. 2027 Support sécurité déc. 2027
        PHP 8.2 Déc. 2022 Déc. 2024 Déc. 2026 Support sécurité déc. 2026
        PHP 8.1 Nov. 2021 Nov. 2023 Déc. 2025 Obsolète depuis déc. 2025
        PHP 8.0 Nov. 2020 Nov. 2022 Nov. 2023 Obsolète depuis nov. 2023
        Logo Tailwind CSS

        Tailwind CSS

        Source : calendrier officiel

        La logique

        Aucun calendrier de support formel. Le suivi se fait par branche majeure : la branche courante reçoit les correctifs, la précédente s'arrête quand l'éditeur cesse d'y publier. Il n'y a pas de canal sécurité distinct, ce qui est cohérent pour une librairie CSS dont la surface d'attaque est nulle.

        Le piège

        Mesurer l'écart en dates alors qu'il se mesure en coût. Une branche Tailwind ne devient pas dangereuse, elle devient chère à quitter : chaque majeure renomme des classes et change la configuration, et le retard s'accumule dans le code des templates, pas dans un calendrier.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        Tailwind CSS 4.x Janv. 2025 Non annoncée Non annoncée Recommandée
        Tailwind CSS 3.4 Déc. 2023 Févr. 2027 Pas de canal séparé Support actif févr. 2027
        Tailwind CSS 2.x Nov. 2020 Déc. 2021 Pas de canal séparé Obsolète
        Tailwind CSS 1.0 Mai 2019 Nov. 2020 Pas de canal séparé Obsolète
        Logo MySQL

        MySQL

        Source : calendrier officiel

        La logique

        Depuis la 8.4, Oracle alterne deux canaux. Les versions LTS, environ tous les deux ans, reçoivent cinq ans de support Premier puis trois ans de support Extended. Les versions Innovation, trimestrielles, ne sont couvertes que jusqu'à la suivante : elles servent à essayer les nouveautés, pas à durer.

        Le piège

        Une version Innovation ressemble à une version comme les autres, avec un numéro plus grand que la LTS du moment. Un hébergeur ou une image Docker qui la propose par défaut engage le projet sur un canal qui expire au trimestre suivant.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        MySQL 26.7 Juil. 2026 Non annoncée Non annoncée Support actif
        MySQL 9.7 LTS Avr. 2026 Avr. 2031 Avr. 2034 Recommandée
        MySQL 9.0 Juin 2024 Avr. 2026 Avr. 2026 Obsolète depuis avr. 2026
        MySQL 8.4 LTS Avr. 2024 Avr. 2029 Avr. 2032 Support actif avr. 2029
        MySQL 8.0 Avr. 2018 Avr. 2025 Avr. 2026 Obsolète depuis avr. 2026
        Logo Node.js

        Node.js

        Source : calendrier officiel

        La logique

        Jusqu'à Node 26, une majeure sur deux devient LTS : les paires, promues en octobre de leur année de sortie, sont maintenues trente mois en tout ; les impaires vivent six mois et n'ont jamais vocation à tourner en production. À partir de Node 27, le projet annonce un cycle annuel où chaque majeure passe en LTS après sa phase courante.

        Le piège

        Une majeure impaire installée par défaut sur un poste de développement finit en production sans que personne l'ait décidé. Et une LTS a beau s'appeler ainsi, elle s'arrête aussi : trente mois passent vite quand on ne les compte pas.

        Version Sortie Fin du support actif Fin des correctifs de sécurité État
        Node.js 26 Mai 2026 Oct. 2027 Avr. 2029 Support actif oct. 2027
        Node.js 25 Oct. 2025 Avr. 2026 Juin 2026 Obsolète depuis juin 2026
        Node.js 24 LTS Mai 2025 Oct. 2026 Avr. 2028 Recommandée
        Node.js 22 LTS Avr. 2024 Oct. 2025 Avr. 2027 Support sécurité avr. 2027
        Node.js 20 LTS Avr. 2023 Oct. 2024 Avr. 2026 Obsolète depuis avr. 2026

        Deux exemples qui montrent que le numéro ne dit rien

        Symfony 5.4, sortie en nov. 2021, reste couverte jusqu'en févr. 2029 : un éditeur (Ibexa) a financé l'extension de son support de sécurité. PHP 8.1, sortie en nov. 2021, ne reçoit plus rien depuis déc. 2025. Le numéro le plus récent n'est pas le mieux protégé, et le plus ancien n'est pas forcément abandonné.

        Et après

        Savoir où l'on en est, puis décider

        Cette page dit ce qui s'arrête et quand. Elle ne dit pas ce qu'il faut faire, parce que la bonne réponse dépend du logiciel, de son exposition et de ce qu'on attend encore de lui.

        Situer vos versions

        Six versions à renseigner, et l'outil place chacune dans la phase de ce calendrier. Sans rien installer, sans rien envoyer.

        Décider, pour Symfony

        Monter de version, rester et assumer, ou ne pas rejouer le même coup dans quatre ans : trois options réelles, avec les cas où la bonne réponse n'est pas de migrer.

        Comprendre le coût du report

        Pourquoi une migration repoussée coûte plus cher qu'une migration faite à temps, et comment nous les menons sans arrêter la production.

        EOL - définitive

        Une fin de support sans suite prévue par l'éditeur

        Une fin de support concerne une version, d'une technologie vivante dont la version suivante existe et vous attend : la montée de version est le chemin normal, et c'est le sujet de cette page.

        Une technologie entière peut aussi disparaître. Ce n'est pas une fin de support, c'est une obsolescence, et la réponse n'est pas une montée de version mais une reconstruction. Ce cas est traité sur la page reprise d'un logiciel sur technologie obsolète.

        1

        L'éditeur a fermé, ou le projet est abandonné

        Aucune version suivante n'existe ni n'existera. Il n'y a rien vers quoi monter : la question n'est plus « quand », c'est « par quoi remplacer ».

        2

        La communauté s'est dispersée

        Plus de correctifs tiers, plus de librairies compatibles, plus de réponses sur les forums. Le logiciel n'est pas seulement hors support, il est seul.

        3

        Plus personne ne recrute dessus

        Les développeurs qui connaissent la technologie partent à la retraite ou changent de métier. Chaque intervention dépend d'une personne, et son départ est le vrai risque.

        GLOSSAIRE

        Le vocabulaire d'une fin de support

        Quatre termes qui reviennent dans les calendriers des éditeurs et dans les échanges avec un prestataire. Chaque définition dit d'abord ce que ça change pour votre logiciel.

        EOL (End of Life)
        La date à partir de laquelle une version ne reçoit plus rien : ni correction de bug, ni correctif de sécurité. Le logiciel continue de fonctionner, mais chaque faille découverte après cette date reste ouverte. C'est la troisième phase du modèle, et la seule qui ne se rattrape pas.
        LTS (Long Term Support)
        Une version que l'éditeur s'engage à maintenir plus longtemps que les autres : quatre ans chez Symfony contre huit mois pour une version standard, trente mois chez Node.js contre six. Toutes les technologies n'en ont pas : PHP et Vue.js traitent toutes leurs versions de la même façon.
        BC break (Breaking Change)
        Un changement d'une version majeure qui rend du code existant incompatible : une méthode renommée, un argument supprimé, une signature modifiée. C'est ce qui fait qu'une montée de majeure est un chantier, là où une mineure s'installe sans toucher au code. Le sujet de la page migration, pas de celle-ci.
        CVE (Common Vulnerabilities and Exposures)
        Le registre public mondial des failles de sécurité : chaque faille reçoit un identifiant, une description et un score de criticité. Sur une version couverte, la faille est corrigée en quelques jours. Sur une version en fin de vie, elle reste documentée, ouverte, et trouvable par un scan.

        D'autres termes sont définis dans notre glossaire général.

        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 !

        La fin du support actif arrête les corrections de bugs et les améliorations : l'éditeur ne publie plus que des correctifs de failles. La fin du support sécurité arrête tout. Entre les deux, le logiciel est exploitable sans exposition nouvelle, à condition d'appliquer les correctifs publiés, mais un bug rencontré ne sera plus corrigé et les librairies récentes commencent à exiger la version suivante. C'est la fenêtre où l'on décide de la suite.

        Parce que leur date de fin est la plus lointaine de leur technologie, et qu'elle est connue le jour de la sortie. Chez Symfony, une LTS reçoit trois ans de corrections puis un an de correctifs de sécurité, contre huit mois pour une version standard : la 7.4 LTS est couverte jusqu'en nov. 2029. Pour un logiciel métier, viser les LTS espace les migrations obligatoires et donne une fenêtre de planification connue à l'avance. Toutes les technologies n'en ont pas : PHP et Vue.js traitent toutes leurs versions de la même façon.

        Chaque éditeur publie son calendrier, ils sont tous liés sur cette page. Si vous ne connaissez pas les versions installées, le fichier composer.json (PHP, Symfony) ou package.json (Vue.js, Node.js) les révèle en quelques minutes, et votre hébergeur connaît celles de PHP et de MySQL. Notre outil d'analyse de montée de version confronte ces six versions aux calendriers, sans rien installer.

        Situer mes versions

        Sur une version maintenue, une faille découverte est corrigée en quelques jours et il suffit d'appliquer la mise à jour. Sur une version en fin de vie, aucun correctif n'est publié : la faille reste ouverte indéfiniment. Et comme elle est documentée publiquement dans la base CVE, n'importe qui peut identifier votre version par un scan automatisé et tenter l'exploitation décrite. Le risque ne vient pas d'une attaque ciblée, il vient des robots qui parcourent des millions de serveurs en continu.

        Parfois, et jamais pour toutes les versions. Symfony documente qu'un support professionnel s'achète auprès de SensioLabs après la fin de la maintenance communautaire. Vue.js renvoie vers HeroDevs pour Vue 2. Oracle propose un support « Sustaining » pour MySQL, sans nouveaux correctifs. PHP n'a aucune offre officielle : ce sont les distributions Linux qui rétroportent certains correctifs sur leurs paquets. Dans tous les cas, c'est un sursis payant, pas une solution, et il se vérifie version par version.

        Non. Une fin de support concerne une version, d'une technologie vivante dont la version suivante existe et vous attend : la montée de version est le chemin normal. Une technologie obsolète n'a plus de version suivante : l'éditeur a fermé, la communauté s'est dispersée, plus personne ne recrute dessus. Là, il n'y a pas de migration possible, seulement une reconstruction. Cette page traite la première situation.

        Reprise sur technologie obsolète

        Il n'y en a aucun le jour même, et c'est ce qui rend la situation trompeuse. Rien ne tombe en panne : le code s'exécute comme la veille. Ce qui change est invisible et s'accumule. Les failles découvertes ne sont plus corrigées, les librairies cessent une à une de supporter votre version, les développeurs qui la connaissent se raréfient, et chaque mois de retard renchérit la migration qui finira par s'imposer. Le problème n'est pas une panne, c'est une pente.

        « 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 ! »

        Raphael Muller
        Raphael Muller
        Directeur Marketing - La Maison Saint-Gobain
        Voir la réalisation →

        « Les préconisations de Nicolas sur la mise en oeuvre d'une stack de développement Gitlab et sa parfaite connaissance du Framework Symfony m'ont fait gagner un temps précieux.

        Toujours pro et dynamique, c'est un plaisir de travailler avec Nicolas. »

        Vincent Depeyre
        Vincent Depeyre
        Directeur de projet | Gérant | Web | Data | Innovations

        Pour aller plus loin

        Approfondir votre réflexion

        Fin de support Symfony : que décider

        Votre LTS s'arrête. Monter de version, rester et assumer, ou refondre : la page qui arbitre, avec les cas où il ne faut pas migrer.

        Migration applicative

        Le coût du report, la différence entre migration et refonte, et notre méthode pour monter de version sans casser la production.

        Analyse de montée de version

        Six versions à renseigner, et chacune est placée dans la phase décrite sur cette page, avec le chemin de migration qui en découle.

        Votre logiciel est-il à jour ?

        L'article qui pose la question au dirigeant et au développeur, et ramène chaque version à l'un de quatre états, quelle que soit la technologie.

        Vous avez un projet ?

        Contactez-nous pour savoir comment nous pouvons vous aider.

        Contactez-nous