Ubuntu LTS ou version intermédiaire pour un serveur ?

Ubuntu LTS ou versions intermédiaires : réponse courte

Choisir entre une LTS Ubuntu et une version intermédiaire pour un serveur revient à considérer un seul élément : la durée pendant laquelle cette version reçoit des mises à jour de sécurité. Une LTS bénéficie de cinq ans de maintenance de sécurité standard. Une version intermédiaire en bénéficie pendant neuf mois, puis les mises à jour s’arrêtent : vous devez alors effectuer une mise à niveau ou reconstruire le serveur. Utilisez une LTS pour tout service dont dépendent d’autres personnes. Utilisez une version intermédiaire uniquement lorsque vous pouvez reconstruire le serveur sans devoir demander l’autorisation de qui que ce soit.

LTS signifie « support à long terme ». Canonical publie une LTS tous les deux ans, en avril des années paires, et une version intermédiaire tous les six mois entre deux LTS. La version 26.04 LTS est sortie le 23 avril 2026 et sa maintenance de sécurité standard se poursuit jusqu’en 2031. La version 26.10 est prévue pour le 15 octobre 2026. Il s’agit d’une version intermédiaire : sa période de support s’achève donc en juillet 2027.

Durée de prise en charge de chaque version d’Ubuntu

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Ces chiffres correspondent à la politique publiée par Canonical en août 2026, et non à des mesures effectuées sur un serveur de test. Une version LTS bénéficie de 60 mois de maintenance de sécurité standard, ce qui représente 1 mise à niveau planifiée vers une nouvelle version en cinq ans. Une version intermédiaire bénéficie de 9 mois. Rester sur le cycle des versions intermédiaires pendant ces cinq mêmes années implique 10 mises à niveau, car vous ne pouvez pas ignorer une version et cinq ans en couvrent dix.

Un abonnement Ubuntu Pro porte la prise en charge d’une version LTS à 120 mois, soit dix ans, et étend la couverture du composant main à l’ensemble de l’archive. En août 2026, Pro est gratuit pour un usage personnel sur cinq machines au maximum, ce qui couvre la plupart des petits parcs de VPS. Il n’existe pas d’équivalent pour une version intermédiaire. Neuf mois constituent toute la durée proposée, et aucun abonnement ne la prolonge.

Ce que coûtent neuf mois sur un vrai serveur

Prenons 26.10 comme exemple. Cette version sort le 15 octobre 2026 et sa maintenance de sécurité prend fin en juillet 2027, selon le même cycle de neuf mois que celui qui a pris fin pour 25.10 en juillet 2026. Vu dans un calendrier, cela ressemble à une fenêtre de maintenance tous les trois trimestres. Cette interprétation est fausse, et elle est fausse dans le sens le plus coûteux.

Une mise à niveau de version remplace le système d’exploitation sur place. do-release-upgrade réécrit les sources apt, désactive les dépôts tiers, modifie la version de presque tous les paquets installés, vous demande quoi faire des fichiers de configuration que vous avez modifiés, puis redémarre à la fin. C’est pourquoi il s’agit d’une fenêtre planifiée et non d’une tâche exécutée en arrière-plan.

Exécutez-la via ssh : l’outil vous protège contre la perte de votre propre connexion. Il démarre sa propre session screen et ouvre un second sshd, en vous en informant d’abord :

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Laissez-le faire. Si votre firewall ou le firewall réseau distinct de votre fournisseur bloque le port 1022, ce mécanisme de secours n’est pas disponible. Une connexion interrompue laisse alors un ensemble de paquets partiellement mis à niveau. Exécuter vous-même la mise à niveau dans tmux ou screen offre la même protection sur n’importe quelle machine.

Les invites concernant les fichiers de configuration sont ce qui transforme une mise à niveau de quinze minutes en une opération d’une heure :

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Conserver votre fichier signifie que vous ne bénéficiez pas des modifications apportées aux valeurs par défaut dans la nouvelle version. Prendre le fichier du mainteneur signifie que votre hardening disparaît jusqu’à ce que vous le réappliquiez. Aucune de ces réponses n’est sûre sans savoir ce qui a changé dans cette version. C’est pourquoi la lecture des release notes fait partie de la fenêtre de maintenance et ne constitue pas un travail facultatif à faire avant.

Multipliez ensuite par le nombre de machines. Un VPS sur le cycle intermédiaire représente dix fenêtres de mise à niveau en cinq ans. Cinq VPS représentent cinquante fenêtres, sauf si chaque machine est jetable et reconstruite depuis une image. Cinq machines sur le cycle LTS représentent cinq mises à niveau sur la même période, et vous choisissez le mois où chacune a lieu.

Pourquoi vous ne pouvez pas ignorer une version d’Ubuntu

Les chemins de mise à niveau sont fixes. Une version intermédiaire passe à la version suivante, quelle qu’elle soit. Une version LTS passe directement à la LTS suivante, ou à la version intermédiaire suivante si vous le demandez. Aucune mise à niveau ne franchit deux étapes en une seule fois. Pour passer de 26.10 à 28.04 LTS, vous devez passer par 27.04 et 27.10, ou réinstaller la machine.

Il est utile de connaître le fonctionnement, car il montre que cette règle ne peut pas être contournée. do-release-upgrade récupère un fichier meta-release sur changelogs.ubuntu.com, puis télécharge un outil de mise à niveau conçu pour une transition précise. Canonical construit et teste une transition à la fois. Un saut qui ignore une version ne dispose donc d’aucun outil ni d’aucun test associé. L’outil de mise à niveau ne refuse pas par prudence. Il n’a simplement rien à proposer.

La version proposée dépend d’une ligne de configuration :

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts propose uniquement la LTS suivante. Prompt=normal propose la version suivante, qu’elle soit LTS ou non. Prompt=never ne propose rien. Cela permet d’empêcher un collègue bien intentionné de lancer une mise à niveau que vous n’aviez pas planifiée. Sur une version qui n’est pas LTS, lts se comporte exactement comme normal, car la version qui suit 26.10 est 27.04 dans les deux cas. La vérification affiche Checking for a new Ubuntu release, puis soit une ligne New release ... available., soit No new release found.

Une autre règle de planification surprend souvent. Une mise à niveau d’une LTS vers une autre LTS n’est pas proposée le jour de la sortie de la nouvelle LTS. Elle devient disponible avec la première mise à jour intermédiaire, et la sortie de 26.04.1 est prévue le 27 août 2026. Une machine sous 24.04 avec Prompt=lts, qui répondait No new release found. pendant l’été 2026, ne présentait aucun problème. Elle appliquait la politique prévue. Lorsque le chemin sera ouvert, la mise à niveau de 24.04 vers 26.04 LTS sera l’opération à planifier et à répéter.

Quand une version intermédiaire est le bon choix

Voici quatre cas où elle est réellement avantageuse :

• Vous avez besoin d’une version du kernel ou de l’espace utilisateur absente des dépôts LTS, sur cette machine et dès maintenant.
• La machine est un build host, un CI runner ou une machine de test que vous recréez à partir d’une image. La mise à niveau devient alors le déploiement d’une nouvelle instance, et non une maintenance planifiée.
• Une fonctionnalité matérielle ou d’hyperviseur est apparue après le gel de la LTS, et aucun backport n’existe.
• Vous vérifiez ce que contiendra la prochaine LTS. 28.04 est construite à partir de 26.10, 27.04 et 27.10. Détecter une breaking change sur un VPS de secours coûte moins cher que de la découvrir sur la machine importante.

La plupart des personnes qui choisissent une version intermédiaire veulent un package plus récent, pas une distribution plus récente. Deux solutions moins coûteuses existent. La pile hardware enablement apporte à une LTS des kernels issus de versions ultérieures : sur 24.04, il s’agit de sudo apt install linux-generic-hwe-24.04, et elle évolue à chaque point release, à partir de la deuxième. Pour une seule application, une container image ou le dépôt du fournisseur permet de mettre à jour un composant au lieu de tout le système d’exploitation.

Quand une version intermédiaire est le mauvais choix

• Tout serveur utilisé par des utilisateurs payants ou couvert par une astreinte. Vous accepteriez une mise à niveau obligatoire deux fois par an en échange de versions de paquets dont vous n’aurez peut-être jamais besoin.
• Tout serveur sur lequel unattended-upgrades applique automatiquement les correctifs de sécurité. Cette automatisation dépend entièrement du dépôt de sécurité qu’elle utilise.
• Un parc que vous mettez à niveau manuellement, car le coût réel correspond à une fenêtre de maintenance multipliée par le nombre de serveurs.
• Tout système que vous installez sans le consulter ensuite pendant un an. Une version intermédiaire oubliée devient un serveur exposé à Internet et non corrigé neuf mois plus tard.

Ce dernier problème est silencieux, ce qui le rend dangereux. Lorsqu’une version arrive en fin de vie, ses paquets sont déplacés vers old-releases.ubuntu.com. sudo apt update échoue alors contre archive.ubuntu.com avec des erreurs 404. Les listes de paquets stockées sur le disque deviennent obsolètes. unattended-upgrades continue de s’exécuter selon sa planification et continue d’écrire des lignes comme celle-ci dans /var/log/unattended-upgrades/unattended-upgrades.log :

No packages found that can be upgraded unattended and no pending auto-removals

Cette ligne est identique sur un serveur entièrement corrigé et sur un serveur dont la version est arrivée en fin de vie il y a quatre mois. Sauf si quelqu’un lit les erreurs apt ou suit la date de fin de vie, rien sur la machine ne permet de savoir lequel des deux vous consultez.

Le type de changement qui arrive d’abord dans une version intermédiaire

En mars 2026, un ingénieur de Canonical a proposé, sur le forum Ubuntu Discourse, de retirer du chargeur de démarrage GRUB signé fourni pour le secure boot dans 26.10. Cette proposition supprime les pilotes de système de fichiers pour btrfs, hfsplus, xfs et zfs, les parseurs d’images JPEG et PNG, les tables de partitions Apple, /boot sur LVM, le RAID logiciel autre que RAID 1, ainsi qu’un /boot chiffré avec LUKS. La raison avancée est que les parseurs intégrés à un chargeur de démarrage sont régulièrement à l’origine de failles de sécurité et que la logique de stockage et de chiffrement doit se trouver dans l’initramfs, le petit système de fichiers initial en RAM que le noyau monte avant le vrai système de fichiers root. En août 2026, il s’agit d’une proposition en discussion, pas d’un changement déjà publié.

Pour la plupart des instances VPS, cela ne changerait rien, car elles démarrent sans secure boot depuis un /boot ext4 classique sur une table de partitions GPT. Vérifiez votre configuration au lieu de partir du principe qu’elle est identique. Si votre système de fichiers root est ZFS, ou si /boot se trouve sur btrfs ou dans LUKS, vous êtes précisément concerné par cette classe de changements qui vous atteint d’abord dans la version intermédiaire. Dans ce cas, le fil de discussion recommande lui-même aux utilisateurs concernés de rester sur une LTS. Cette recommandation résume tout en une phrase. Les versions intermédiaires servent à tester les changements. Une LTS les reçoit après que deux années de versions intermédiaires ont permis d’identifier ce qu’ils cassent.

Le même schéma se retrouve sous des formes plus limitées à chaque version intermédiaire. Les versions par défaut de la base de données, du runtime du langage et de la configuration init évoluent. Des fichiers de configuration qui fonctionnaient peuvent donc cesser de fonctionner. Faire évoluer les valeurs par défaut est précisément le rôle d’une version intermédiaire. Lire les notes de version avant chacune de ces dix mises à niveau fait donc partie du prix à payer.

Choisir le canal lors de l’installation du serveur

Choisissez le canal au moment de l’installation, car le modifier ensuite implique une réinstallation ou une suite de mises à niveau. Sur un serveur neuf, quatre commandes indiquent où vous en êtes :

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a doit indiquer la release que vous aviez prévu d’installer. Sur une version LTS, la ligne de description se termine par LTS. La ligne Prompt doit correspondre au canal choisi, et non à celui fourni par l’image du provider. Sur une LTS actuelle, do-release-upgrade -c doit renvoyer No new release found.. Si la commande propose plutôt une interim release, Prompt vaut normal. Il faut alors vérifier que ce choix était volontaire. pro security-status indique combien de packages installés sont couverts par chaque flux de mises à jour. La commande précise également quand la machine n’est associée à aucun abonnement.

Notez ensuite la date de fin de support à un endroit où vous la reverrez, avec le reste des notes d’installation de ce serveur. Cela fait partie des tâches à effectuer pendant les dix premières minutes sur un nouveau VPS, car une date de support conservée uniquement dans la mémoire de quelqu’un finit par expirer sans que personne ne s’en aperçoive. Si vous cherchez surtout à éviter complètement le cycle de six mois, le modèle de releases de FreeBSD comparé à Linux mérite une heure de lecture avant de choisir l’une ou l’autre solution pour un parc de serveurs.

FAQ

Faut-il exécuter une version intermédiaire d’Ubuntu sur un serveur de production ?

Dans presque tous les cas, non. Une version intermédiaire cesse de recevoir des mises à jour de sécurité neuf mois après sa publication. La production sur cette version impose donc une fenêtre de mise à niveau environ deux fois par an, indéfiniment. Les seules exceptions raisonnables concernent les machines que vous reconstruisez de toute façon depuis une image, comme les runners CI et les hôtes de build. Dans ce cas, une mise à niveau crée une nouvelle instance au lieu d’imposer une fenêtre d’intervention. Si de vrais utilisateurs dépendent de la machine, installez la LTS et consacrez le temps ainsi économisé à autre chose.

Pendant combien de temps une version intermédiaire d’Ubuntu est-elle prise en charge ?

Neuf mois. 26.10 sort le 15 October 2026 et sa maintenance de sécurité se termine en July 2027, comme pour 25.10, dont la prise en charge s’est terminée en July 2026. Chaque version intermédiaire suit le même calendrier : publication en April ou October, puis fin de prise en charge neuf mois plus tard. Une LTS bénéficie de cinq ans de maintenance de sécurité standard, portée à dix ans avec Ubuntu Pro, qui, en August 2026, est gratuit pour un usage personnel sur un maximum de cinq machines.

Puis-je ignorer des versions d’Ubuntu lors d’une mise à niveau ?

Non. do-release-upgrade avance une version à la fois : une version intermédiaire passe à la version suivante, tandis qu’une LTS peut passer directement à la LTS suivante. Pour passer de 26.10 à 28.04 LTS, vous devez d’abord effectuer la mise à niveau vers 27.04, puis vers 27.10, ou réinstaller la machine. Canonical développe et teste chaque transition séparément. Le programme de mise à niveau télécharge un outil prévu pour cette transition précise. Il n’existe donc aucun outil pour un saut de deux versions, qui n’est jamais proposé.

Que se passe-t-il lorsque ma version d’Ubuntu arrive en fin de vie ?

Ses paquets sont déplacés vers old-releases.ubuntu.com. sudo apt update commence alors à échouer contre archive.ubuntu.com avec des erreurs 404, et aucune nouvelle mise à jour de sécurité n’est publiée pour cette version. Rien sur la machine ne vous en informe. Le serveur continue de fonctionner et de servir le trafic, tandis que chaque nouvelle vulnérabilité publiée dans ses composants reste exploitable. La récupération consiste à effectuer une mise à niveau de version dans l’urgence ou à reconstruire la machine. Surveillez donc la date plutôt que les symptômes.

Le noyau LTS est-il trop ancien pour le matériel récent ?

En général, non, car une LTS ne conserve pas son noyau d’origine pendant cinq ans. La pile Hardware Enablement, HWE, apporte dans la LTS des noyaux issus de versions ultérieures lors des point releases. Une installation serveur peut l’activer avec un paquet tel que linux-generic-hwe-24.04. Vérifiez ce que vous utilisez avec uname -r avant de considérer le noyau comme responsable du problème. Si l’élément manquant concerne une version de l’espace utilisateur plutôt que le noyau, un conteneur ou un dépôt du fournisseur constitue une modification bien plus limitée que le passage de toute la machine à une version intermédiaire.