Fin de vie d'Ubuntu 22.04 : dates clés, risques et prochaines étapes

Principaux enseignements

• La prise en charge standard de la sécurité d'Ubuntu 22.04 LTS (Jammy Jellyfish) par Canonical prendra fin en mai 2027.
• Les systèmes restés sous la version 22.04 continuent de fonctionner, mais les correctifs de sécurité gratuits ne sont plus fournis.
• La mise à niveau vers Ubuntu 24.04, puis vers la version 26.04 LTS, constitue la solution définitive à long terme.
• Si cette manœuvre ne peut pas aboutir à temps, le support à vie de TuxCare continue de fournir des correctifs.

Vos serveurs sous Ubuntu 22.04 continuent de démarrer. Ils continuent de traiter le trafic. Ils passent toujours tous les contrôles d’intégrité. Et c’est justement là que réside le problème. La fin de vie d’Ubuntu 22.04 ne se traduit pas par une interruption de service. La maintenance de sécurité standard prendra fin en mai 2027, et les serveurs continueront de tourner sans encombre tandis que les correctifs gratuits cesseront discrètement d’arriver.

Cet article aborde les dates précises du cycle de vie, ce qui cesse effectivement de fonctionner à la fin du support (et ce qui continue de fonctionner), les raisons pour lesquelles la migration prend généralement plus de temps que prévu, ainsi que les options concrètes permettant de continuer à bénéficier des correctifs après la date limite.

Dates à retenir concernant le cycle de vie du support d'Ubuntu 22.04

Ubuntu 22.04 LTS (Jammy Jellyfish) a été lancé le 21 avril 2022. Comme toutes les versions LTS, elle bénéficie de cinq ans de maintenance de sécurité standard pour les paquets du dépôt « main », avec des extensions payantes optionnelles en complément. Voici un aperçu complet du calendrier.

Phase	Date	Ce que cela signifie
Disponibilité générale	Avril 21, 2022	Première version LTS
Fin de la maintenance de sécurité standard	Mai 2027	Correctifs CVE gratuits pour Main Stop
Fin de la prise en charge d'Ubuntu Pro ESM	Mai 2032	L'ESM payant couvre les indices « Main » et « Universe »
Fin de la couverture de l'extension « Legacy »	Mai 2037	Dernière prolongation rémunérée, soit 15 ans au total

La date la plus importante est mai 2027. Jusqu’à cette date, la commande « apt upgrade » tire gratuitement les correctifs de sécurité depuis les archives d'Ubuntu. Passé ce délai, les paquets du dépôt « main » ne bénéficieront plus de ces correctifs, à moins que vous ne passiez à une couverture étendue telle qu’Ubuntu Pro. Le système continue de fonctionner. Il cesse simplement de bénéficier de correctifs gratuits.

Que se passera-t-il lorsque Ubuntu 22.04 arrivera en fin de vie ?

La fin de vie n'est pas une échéance souple que l'on peut discrètement ignorer. Dès qu'elle survient, le profil de risque de chaque système 22.04 encore en production change. Même matériel, même charge de travail, mais surface d'exposition aux menaces différente. Ces risques s'accumulent et s'aggravent chaque mois où vous ne faites rien.

1. Les CVE pour lesquelles aucun correctif n'a été publié deviennent permanentes

Les vulnérabilités divulguées après mai 2027 ne bénéficieront plus de correctifs dans le cadre de la maintenance de sécurité standard de la version 22.04. Sans une extension de couverture quelconque, elles resteront non corrigées indéfiniment, y compris après la publication publique du code d’exploitation. Pour se faire une idée du volume en jeu, LinuxCVETracker avait répertorié plus de 4 800 CVE du noyau Linux pour l’année 2026 fin août, dont 359 classées « critiques » et 1 896 classées « élevées ».

L'une d'entre elles est déjà passée de la théorie à la pratique. La vulnérabilité CVE-2026-31431, surnommée « Copy Fail », a été ajoutée au catalogue des vulnérabilités connues pour être exploitées (KEV) de la CISA le 1er mai 2026. Il s’agit d’une faille d’élévation de privilèges locale introduite par une modification du noyau en 2017, qui permet à un utilisateur local non privilégié d’accéder directement au compte root ; elle présente un score CVSS de 7,8 (ÉLEVÉ).

Ça fait un an, et ce n'est que le noyau. Le rapport 2026 de TuxCare sur le paysage de l’open source a révélé que parmi les organisations ayant signalé un incident de cybersécurité, 61,4 % ont indiqué que l'incident s'était produit alors qu'un correctif était déjà disponible, mais qu'il n'avait tout simplement pas été appliqué. Sans couverture étendue, le correctif n'arrive pas en retard. Il se peut même qu'aucun correctif ne soit diffusé via le canal standard.

2. Les audits de conformité sont de plus en plus difficiles à réussir

PCI DSS, HIPAA, SOC 2et RGPD exigent toutes que vous gériez les vulnérabilités connues et que vous mettiez en place des contrôles de sécurité appropriés ; un système d’exploitation en fin de vie rend cette tâche bien plus difficile à mener à bien. La norme PCI DSS est la plus explicite à ce sujet. Un logiciel qui n’est plus pris en charge peut rendre les exigences en matière de correctifs inatteignables, et bien qu’un contrôle compensatoire correctement conçu soit parfois accepté, vous devez documenter cette contrainte et démontrer que le contrôle répond réellement au risque. Cela représente une charge de conformité bien plus lourde que de maintenir le système à jour.

Le coût en aval n'est pas non plus théorique. Le rapport IBM de 2026 sur le coût des fuites de données estime le coût moyen d’une violation de données à l’échelle mondiale à un montant record de 4,99 millions de dollars, soit une hausse de 12 % par rapport à l’année précédente.

3. L'écosystème logiciel vous laisse à la traîne

Ce problème s'installe progressivement, ce qui explique pourquoi on a tendance à le sous-estimer. Les agents de surveillance cessent de prendre en charge les anciennes versions. Les nouveaux moteurs d'exécution des langages ne peuvent plus être compilés avec des bibliothèques système obsolètes. À terme, même les équipes d'assistance des éditeurs cessent de traiter les tickets de dépannage concernant les systèmes en fin de vie, et à ce stade, vous avancez déjà à l'aveuglette.

Pourquoi la migration n'est pas toujours simple

Sur le papier, la mise à niveau ressemble à une simple commande. Dans la pratique, il s'agit d'un véritable projet, et lorsqu'on en définit la portée, on se rend toujours compte qu'il ne s'agit pas seulement d'un simple changement de version. Cela met en évidence toutes les hypothèses que votre pile technologique a discrètement formulées concernant le système d'exploitation sous-jacent. Voici les trois points de friction qui transforment systématiquement une « mise à niveau rapide » en un trimestre de planification.

Les mises à jour LTS s'effectuent de manière séquentielle

Il n'est pas possible de passer directement de la version 22.04 à la dernière version LTS. Le parcours de mise à jour d'Ubuntu se fait version par version ; ainsi, pour passer de la version 22.04 à la version 26.04, il faut d'abord passer par la version 24.04. Les notes de mise à jour de la version 26.04 publiées par Canonical le précisent clairement.

sudo do-release-upgrade

Chaque étape constitue un cycle de test et de validation à part entière, et chacune peut révéler ses propres dysfonctionnements. Si vous optez pour la mise à niveau sur place jusqu’à la version 26.04, prévoyez deux opérations de mise à niveau plutôt qu’une seule. Pour un parc informatique plus important, l’approche la plus propre consiste souvent à effectuer une nouvelle installation de la version LTS cible sur une nouvelle infrastructure, puis à procéder à un redéploiement via la gestion des configurations, ce qui permet d’éviter complètement la chaîne de mise à niveau sur place.

Conseil de pro : Vérifiez que Prompt=lts est défini dans /etc/update-manager/release-upgrades si vous souhaitez que la machine suive les versions LTS, ce qui est le comportement par défaut sur une installation LTS. Gardez à l'esprit que le chemin de mise à jour d'une version LTS vers une autre ne s'ouvre qu'une fois que la version cible a atteint sa première version mineure. Exécutez do-release-upgrade -c pour vérifier si la version suivante est effectivement disponible sans lancer la mise à niveau.

Les applications ne fonctionnent plus sur la nouvelle base

La mise à jour du système d'exploitation en elle-même pose rarement problème. C'est plutôt l'application qui tourne dessus. Le passage de la version 22.04 à la version 24.04 entraîne des Python, OpenSSLet des dizaines de bibliothèques système de plusieurs versions à la fois, et le code qui s’appuyait sur un comportement antérieur peut présenter des défaillances qui n’apparaissent qu’au moment de l’exécution.

Les dépôts tiers, tels que les PPA, sont généralement désactivés lors de la mise à niveau vers une nouvelle version. Les options de configuration obsolètes sont ignorées sans avertissement. C'est précisément au niveau de ce service interne hérité, que personne n'a touché depuis trois ans, que les choses tournent mal. La mesure corrective est incontournable : recompilez dans un environnement de préproduction qui reflète l'environnement de production, exécutez l'intégralité de votre suite de tests et corrigez les dysfonctionnements à ce stade. Pas à 2 heures du matin, pendant la bascule.

Coordination des temps d'arrêt au sein d'une flotte

Un serveur, c'est une fenêtre de maintenance. Trois cents serveurs, c'est un problème logistique. Les gel des changements, les validations de conformité, l'ordre des dépendances entre les services et le fait que tous les serveurs ne peuvent pas redémarrer en même temps contribuent tous à allonger le délai.

Les équipes qui ont franchi la fin de vie d’Ubuntu 16.04 en savent quelque chose. La solution consiste en un déploiement progressif : d’abord les environnements hors production, puis les environnements de production à faible risque, et enfin les systèmes critiques, en utilisant des images de référence et une infrastructure codifiée afin que chaque étape soit reproductible. Si le calendrier ne permet vraiment pas de respecter l’échéance avant mai 2027, c’est là que la couverture prolongée des correctifs prend tout son sens.

Comment vérifier l'état de votre prise en charge Ubuntu en 2 minutes

Vous n'avez pas besoin de deviner où en est chaque boîte. Deux commandes vous indiquent la version et l'état de la prise en charge active, tandis que les dates du cycle de vie vous indiquent le temps qu'il reste avant la fin de la prise en charge. Exécutez-les dans l'ordre sur tout hôte pour lequel vous avez des doutes.

Commencez par vérifier la version exacte de votre logiciel.

Commencez par vérifier la date de sortie et le nom de code.

lsb_release -a

À ne pas manquer Version : 22.04 et Nom de code : jammy. Si vous souhaitez obtenir le code source brut, cat /etc/os-release vous donnera les mêmes informations, ainsi que la chaîne de version complète. Tout ce qui mentionne « jammy » correspond à la version 22.04, et les versions mineures telles que 22.04.5 ne modifient pas cette date.

Vérifiez ensuite l'état du service d'assistance en direct

C'est l'étape que la plupart des gens négligent. Le client Ubuntu Pro indique quelle couverture de sécurité s'applique actuellement aux paquets d'un système.

pro état de sécurité

Le résultat vous indique le nombre de paquets concernés, si des mises à jour de sécurité standard ou ESM sont disponibles, et quels paquets ne relèvent pas de ces canaux de mise à jour de sécurité. Si la liste mentionne des paquets « ne recevant plus de mises à jour de sécurité », cela signifie que ces paquets ont quitté ce canal de mise à jour, et que le risque potentiel augmente à mesure que de nouvelles vulnérabilités les affectant sont révélées. TuxCare’s présentation de TuxCare sur la fin de vie d’Ubuntu explique en détail ce que cela signifie concrètement.

Enfin, mettez en correspondance vos conclusions avec le cycle de vie

Vérifier en vous référant au tableau des dates ci-dessus ou endoflife.date, puis évaluez votre marge de manœuvre. Le 22 avril, sans abonnement Pro, la maintenance de sécurité standard prend fin en mai 2027. Avec un abonnement Pro ou ESM actif, la couverture s'étend jusqu'en mai 2032, ce qui vous fait gagner du temps mais ne supprime pas la migration de votre feuille de route.

Notez la date. « À un moment donné en 2027 » ne constitue pas un plan de migration. « Nous effectuerons la bascule au premier trimestre 2027, en utilisant ELS comme solution de secours en cas de retard », voilà ce qu’est un plan de migration.

Que faire si votre version d'Ubuntu arrive en fin de vie ?

La fin de vie (EOL) de la version 22.04 n'est pas une impasse. Il existe trois voies possibles, et le choix de la bonne dépend de votre capacité à migrer et du moment où vous pouvez le faire. Faites votre choix en fonction de vos contraintes réelles, et non pas en optant pour l'option qui semble la plus simple dans un document.

Utiliser le support étendu

Si la migration ne peut véritablement pas avoir lieu avant mai 2027, que ce soit en raison d’un gel réglementaire, de matériel en fin de vie ou d’une pile d’applications qui ne peut pas être migrée sans heurts, le service « Endless Lifecycle Support » de TuxCare assure la mise à jour des systèmes sans imposer de mise à niveau. Vous continuez à recevoir les correctifs CVE pour les paquets que vous utilisez réellement, tout en planifiant la migration à un rythme qui vous convient.

L'intérêt n'est pas de « ne jamais effectuer de mise à jour », mais de laisser une marge de manœuvre suffisante pour que la migration soit effectuée correctement, sans précipitation. TuxCare ELS couvre Ubuntu 16.04, Ubuntu 18.04et Ubuntu 20.04 aujourd'hui, et couvrira la version 22.04 lorsque le support standard prendra fin.

Le support prolongé est un filet de sécurité, pas un plan visant à maintenir la version 22.04 en service jusque dans les années 2030. Utilisez-le pour vous accorder une période de migration en toute sérénité, puis profitez pleinement de cette période. Le rapport 2026 de TuxCare sur le paysage de l’open source a révélé que 50,2 % des organisations gérant des composants en fin de vie (EOL) en production se tournent vers le support de cycle de vie prolongé ou les correctifs fournis par les éditeurs, devant la migration (43,9 %) et les mises à niveau (41,0 %). Cela ne signifie pas pour autant qu’elles ont renoncé à la migration. Le support prolongé leur offre une fenêtre de temps maîtrisée pour la mener à bien.

Passez à une version LTS prise en charge

La meilleure solution à long terme consiste à passer à une version LTS actuelle. En 2026, il s'agira de Ubuntu 24.04 LTS, dont la maintenance de sécurité standard s'étend jusqu'en mai 2029, ou la version 26.04 LTS (Resolute Raccoon, sortie le 23 avril 2026), dont la maintenance s'étend jusqu'en mai 2031.

N’oubliez pas qu’à partir de la version 22.04, vous passez d’abord à la 24.04, puis à la 26.04. Avant d’évaluer l’ampleur du travail, notez que la version 26.04 rend la session de bureau Ubuntu exclusivement compatible avec Wayland, puisque GNOME Shell ne peut plus fonctionner sous une session X.org, et qu’elle fait passer le noyau de la version 6.8 à la version 7.0. Les applications X.org continuent de fonctionner via XWayland et les autres sessions de bureau peuvent toujours utiliser X.org, mais tout ce qui présente des dépendances liées au bureau ou aux pilotes du noyau mérite un examen plus approfondi. Cette voie vous offre une nouvelle période de plusieurs années de support standard. C’est également celle qui nécessite le plus de travail en amont ; prévoyez donc un budget pour les tests et les scénarios de défaillance évoqués ci-dessus.

Activer Canonical Ubuntu Pro avec ESM

Si vous souhaitez bénéficier d'une couverture étendue directement auprès du fournisseur, Ubuntu Pro active l'ESM pour la version 22.04 jusqu'en mai 2032, avec une couverture de sécurité pour les paquets des dépôts « main » et « universe ». Ce service est gratuit pour un usage personnel sur un maximum de cinq machines ; des formules payantes sont disponibles pour les déploiements en entreprise.

La solution « Pro » est la plus simple si vous utilisez déjà exclusivement les outils de Canonical. Pour les parcs informatiques de grande envergure, cependant, le coût par machine grimpe rapidement ; c’est pourquoi il vaut la peine de comparer des options tierces telles que TuxCare ELS avant de vous engager.

Assurez votre sécurité après la fin de vie d'Ubuntu 22.04 grâce à TuxCare

Le mois de mai 2027 approche plus vite qu’il n’y paraît, et les serveurs ne vous préviendront pas lorsque cette date arrivera. Ils cesseront simplement de recevoir des correctifs. Que vous migriez vers la version 24.04, que vous effectuiez un nouveau déploiement sur la version 26.04 ou que vous deviez conserver la version 22.04 plus longtemps que prévu, ce que vous ne pouvez pas repousser, c’est la décision concernant la faille de sécurité entre aujourd’hui et votre date de basculement.

Si cette migration ne peut pas être effectuée dans les délais, le service « Endless Lifecycle Support » proposé par TuxCare garantit que vos systèmes 22.04 restent à jour face aux nouvelles vulnérabilités (CVE), sans migration précipitée ni interruption de service imprévue. La fin de vie (EOL) devient alors une étape clé de votre feuille de route, et non plus une situation d’urgence.

FAQ