Ubuntu LTS ou version intermédiaire pour un serveur ?

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

Le choix entre une version Ubuntu LTS et une version intermédiaire sur un serveur dépend d’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 mettre à niveau le système ou le reconstruire. Utilisez une LTS pour tout ce dont dépendent d’autres personnes. Utilisez une version intermédiaire uniquement lorsque vous pouvez reconstruire le système 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 doit sortir le 15 octobre 2026. Il s’agit d’une version intermédiaire : ses mises à jour s’arrêtent 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 mêmes cinq ans nécessite 10 mises à niveau, car il est impossible d’ignorer une version et que cinq ans en comprennent dix.

Un abonnement Ubuntu Pro porte la durée de prise en charge d’une 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 de 25.10, arrivé à son terme en juillet 2026. Sur un calendrier, cela semble correspondre à une fenêtre de maintenance tous les trois trimestres. Cette lecture du calendrier est fausse, et elle vous coûte cher.

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.

Effectuez-la via ssh et l’outil vous protège contre la rupture de votre propre connexion. Il démarre sa propre session screen et ouvre un deuxième sshd, après vous en avoir informé :

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 pare-feu ou le pare-feu réseau distinct de votre fournisseur bloque 1022, ce mécanisme de secours n’existe pas. Une rupture de connexion laisse alors un ensemble de paquets partiellement mis à niveau. Exécuter vous-même la mise à niveau dans tmux ou screen fournit la même protection sur n’importe quel serveur.

Les invites concernant les fichiers de configuration sont ce qui transforme une mise à niveau de quinze minutes en 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 à la nouvelle configuration par défaut. Utiliser le fichier du mainteneur signifie que votre durcissement 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 notes de version fait partie de la fenêtre de maintenance et ne constitue pas un travail facultatif à effectuer en dehors de celle-ci.

Multipliez ensuite par le nombre de serveurs. 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 serveur est jetable et reconstruit depuis une image. Cinq serveurs 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 LTS passe directement à la LTS suivante, ou à la version intermédiaire suivante si vous le demandez. Aucune mise à niveau ne franchit deux étapes d’un coup. 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 depuis 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. 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. C’est ainsi que vous empêchez un collègue bien intentionné de lancer une mise à niveau que vous n’aviez pas planifiée. Sur une version qui n’est pas une 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 calendrier est souvent oubliée. La 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 point release, et 26.04.1 est prévue pour le 27 août 2026. Une point release n’est pas une nouvelle version d’Ubuntu, mais la même version avec quatre mois de correctifs cumulés intégrés dans de nouveaux supports d’installation, et cette attente permet de tester le chemin de mise à niveau pendant ces quatre mois avant de le proposer. Une machine sous 24.04 avec Prompt=lts qui répondait No new release found. pendant l’été 2026 n’était pas en panne. 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.

Dans quels cas choisir une version intermédiaire

Quatre cas où elle est réellement pertinente :

• Vous avez besoin maintenant, sur cette machine, d’une version du kernel ou de l’espace utilisateur que l’archive LTS ne fournit pas.
• 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 une nouvelle instance plutôt qu’une fenêtre de maintenance.
• 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 un changement incompatible sur un VPS de secours coûte moins cher que le 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 d’activation matérielle apporte dans 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 image de conteneur ou le dépôt fourni par l’éditeur permet de mettre à jour un composant sans remplacer tout le système d’exploitation.

Quand une version intermédiaire est le mauvais choix

• Tout système utilisé par des clients payants ou couvert par une rotation d’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 n’est jamais meilleure que le dépôt de sécurité depuis lequel elle récupère les paquets.
• Une flotte 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 ce que vous installez sans le consulter 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 commence alors à échouer contre archive.ubuntu.com avec des erreurs 404. Les listes de paquets présentes 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 quatre mois plus tôt. À moins que quelqu’un ne consulte les erreurs d’apt ou ne suive la date de fin de vie, rien sur la machine ne permet de savoir lequel des deux cas se présente.

Le type de changement qui arrive d’abord sur la version intermédiaire

En mars 2026, un ingénieur de Canonical a proposé sur le forum Ubuntu de retirer le chargeur d’amorçage GRUB signé fourni pour le secure boot dans 26.10. La proposition supprime les pilotes de système de fichiers pour btrfs, hfsplus, xfs et zfs, les analyseurs d’images JPEG et PNG, les tables de partitions Apple, /boot sur LVM, les niveaux de RAID logiciel autres que RAID 1, ainsi qu’un /boot chiffré avec LUKS. La raison avancée est que les analyseurs intégrés à un chargeur d’amorçage 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 RAM initial que le noyau monte avant la véritable racine. En août 2026, il s’agit d’une proposition en discussion, et non d’une modification déjà publiée.

Pour la plupart des instances VPS, cela ne changerait rien, car elles démarrent sans secure boot depuis un simple /boot ext4 sur une table de partitions GPT. Vérifiez votre configuration au lieu de partir du principe qu’elle est identique. Si votre racine utilise ZFS, ou si /boot se trouve sur btrfs ou dans LUKS, c’est exactement le type de changement qui vous atteint d’abord sur la version intermédiaire. Dans ce cas, le conseil donné dans le fil aux utilisateurs concernés est de rester sur une LTS. Ce conseil 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 à plus petite échelle à chaque version intermédiaire. Les versions par défaut de la base de données, de l’environnement d’exécution 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 coût accepté.

Choisir la version lors de l’installation du serveur

Choisissez la version au moment de l’installation, car la modifier ensuite nécessite une réinstallation ou une succession de mises à niveau. Sur un nouveau serveur, 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 version que vous aviez prévu d’installer, et, sur une version LTS, la ligne de description se termine par LTS. La ligne Prompt doit correspondre à la version choisie, et non à celle fournie par l’image du prestataire. do-release-upgrade -c sur une LTS actuelle doit renvoyer No new release found.. S’il propose à la place une version intermédiaire, Prompt vaut normal et il faut déterminer si ce choix était volontaire. pro security-status indique combien de paquets installés sont couverts par chaque flux de mises à jour et précise clairement si la machine n’est associée à aucun abonnement.

Notez ensuite la date de fin de support à un endroit où vous la reverrez, avec les autres informations de déploiement 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 qui ne figure que dans la mémoire de quelqu’un finit par expirer sans que personne s’en aperçoive. Si vous cherchez surtout à éviter complètement le cycle de six mois, le modèle de versions de FreeBSD comparé à Linux mérite une heure de lecture avant de choisir une plateforme pour toute une flotte.

FAQ

Faut-il utiliser une version intérimaire d’Ubuntu sur un serveur de production ?

Dans presque tous les cas, non. Une version intérimaire ne reçoit plus de mises à jour de sécurité neuf mois après sa publication. Utiliser cette branche en production impose donc une fenêtre de mise à niveau environ deux fois par an, indéfiniment. Les seules exceptions raisonnables concernent les machines que vous recréez de toute façon depuis une image, comme les runners CI et les serveurs 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 cette machine, installez la LTS et consacrez le temps ainsi gagné à autre chose.

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

Neuf mois. 26.10 sort le 15 octobre 2026 et sa maintenance de sécurité se termine en juillet 2027, selon le même calendrier que 25.10, dont la prise en charge s’est terminée en juillet 2026. Chaque version intérimaire suit ce cycle : publication en avril ou en octobre, puis fin de prise en charge neuf mois plus tard. Une LTS bénéficie de cinq ans de maintenance de sécurité standard, durée portée à dix ans avec Ubuntu Pro, qui, en août 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 intérimaire 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, et l’outil de mise à niveau télécharge un outil spécifique à cette transition. Une mise à niveau en deux étapes ne dispose donc d’aucun outil correspondant et n’est jamais proposée.

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 donc à échouer sur 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 vulnérabilité nouvellement publiée reste exploitable. La récupération consiste à effectuer une mise à niveau de version dans l’urgence ou à recréer 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 ?

Généralement non, car une LTS ne conserve pas son noyau d’origine pendant cinq ans. La pile d’activation matérielle, HWE, intègre des noyaux de versions ultérieures dans la LTS 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 supposer que le noyau est le 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 à la branche intérimaire.