Ubuntu Server en 2026 : choisir entre les versions LTS (et migrer)

La réponse d'abord

• Nouveau serveur aujourd'hui ? Déployez 24.04 LTS ou 26.04 LTS : 26.04 si vous voulez le nouveau noyau et une horloge de support qui court jusqu'en 2031, 24.04 si un dépôt tiers dont vous dépendez n'a pas encore publié de paquets 26.04 (vérifiez avant de vous engager ; trois mois après la sortie, certains ne l'ont toujours pas fait).
• Vous êtes sur 24.04 ? Tout va bien : support standard jusqu'en 2029, et la mise à niveau sur place sanctionnée vers 26.04 ne s'ouvre qu'avec la révision mineure 26.04.1, attendue en août 2026. Aucune urgence ; migrez selon votre propre calendrier entre-temps et 2029.
• Vous êtes sur 22.04 ? Commencez à planifier dès maintenant. La maintenance de sécurité standard prend fin au printemps 2027, et votre chemin vers 26.04 compte deux étapes (22.04 → 24.04 → 26.04). Planifiez ces étapes, ou activez Ubuntu Pro pour gagner du temps jusqu'en 2032.
• Vous faites tourner une version intermédiaire (non-LTS) sur un serveur ? Passez à une LTS : les versions intermédiaires n'ont que neuf mois de support et existent pour les early adopters et les postes de bureau, pas pour les serveurs de production.

Le panorama

Dates selon le cycle de publication de Canonical ; la précision au mois près se décale à l'occasion, prévoyez donc en trimestres, pas en jours. Deux remarques structurelles : chaque LTS reçoit cinq années gratuites de maintenance de sécurité pour le dépôt main ; le dépôt universe, largement utilisé, reçoit une couverture systématique via l'ESM d'Ubuntu Pro (gratuite jusqu'à cinq machines, plus de détails plus bas sous « Ubuntu Pro »). Et en milieu de vie d'une LTS, la pile HWE (hardware enablement) propose des noyaux plus récents sur des versions plus anciennes : les révisions mineures de la 24.04 embarquent des noyaux bien au-delà de 6.8, ce qui couvre souvent tout ce qu'exige réellement « j'ai besoin de pilotes plus récents ».

Ce que change 26.04 pour les opérateurs de serveurs

Resolute Raccoon (sortie le 23 avril 2026) est un pas de plateforme plus important qu'une LTS classique. Les points qui comptent sur les serveurs :

• Linux 7.0. Une étape de numérotation de version plus qu'un tournant architectural : upstream a renuméroté après la 6.19, donc 7.0 est simplement le noyau suivant normal, pas une réécriture. Ce que vous obtenez réellement par rapport à la 6.8 de la 24.04 : deux années de hardware enablement supplémentaires, des améliorations d'io_uring et du réseau, et du travail sur l'ordonnanceur.
• systemd 259 supprime entièrement cgroup v1. L'outil de mise à niveau refuse de s'exécuter sur les systèmes encore en v1. Tout ce qui est moderne est déjà en v2 (mount | grep cgroup2 pour le confirmer) ; les victimes sont les moteurs Docker antiques et les anciennes installations LXC ; corrigez cela avant la mise à niveau de l'OS, pas pendant.
• OpenSSH 10.2 avec échange de clés post-quantique par défaut et DSA entièrement supprimé.
• APT 3.1 avec le nouveau solveur et une CLI plus propre.
• Espace utilisateur protégé en mémoire : sudo-rs et les coreutils Rust remplacent par défaut leurs ancêtres en C. La compatibilité est élevée, mais les scripts qui dépendent d'un comportement obscur des options de sudo/cp/date méritent un passage de test.
• Aspérités signalées jusqu'ici : Postfix ne tourne plus dans un chroot par défaut (vérifiez votre configuration lors de la mise à niveau), les montages de médias amovibles sont passés de /media à /run/media (cassant certains scripts), le noyau 7.0 abandonne de très anciennes séries de pilotes NVIDIA, et les notes de publication signalent une régression de performance PostgreSQL sous certaines configurations. Si vous faites tourner une machine à forte charge de base de données, lisez les problèmes connus actuels avant de planifier le déplacement.

Aucun de ces points n'est une raison d'éviter 26.04 ; ce sont tous des raisons de migrer de façon délibérée plutôt que désinvolte.

L'argument honnête pour rester sur 24.04 (pour l'instant)

• Les dépôts tiers sont à la traîne. Les PPA et les dépôts d'éditeurs (bases de données, PHP, agents de supervision) publient pour une nouvelle LTS selon leur propre calendrier. Si apt update sur 26.04 devait laisser une dépendance critique de côté, c'est décisif. Attendez.
• La règle du .1 existe pour une bonne raison. Canonical lui-même n'offre la mise à niveau aux utilisateurs LTS existants qu'à partir de 26.04.1 (attendue en août 2026) : la première révision mineure absorbe les correctifs de la fenêtre de lancement. Les parcs de production ne perdent presque jamais rien à respecter ce garde-fou.
• Votre horloge ne tourne pas. La 24.04 est prise en charge gratuitement jusqu'en 2029. Migrer fin 2026 ou courant 2027 est une position parfaitement à jour.

Le revers de la médaille : les nouvelles machines ne portent aucun risque de migration, donc déployer 26.04 en neuf dès aujourd'hui, là où vos dépendances le permettent, démarre la plus longue période de support possible.

Ubuntu Pro et ESM, en bref

Ubuntu Pro fait passer les cinq ans de chaque LTS à dix (plus un add-on « Legacy » qui va jusqu'à quinze), ajoute une couverture ESM pour le dépôt universe, Livepatch (correctifs de sécurité du noyau sans redémarrage), et l'outillage de durcissement USG (profils CIS/DISA-STIG). C'est gratuit jusqu'à cinq machines, et facturé au tarif catalogue de 500 $/serveur/an au-delà (les SLA de support coûtent plus cher ; les prix évoluent, vérifiez le tarif actuel).

Quand cela se justifie : pour les parcs qui ne peuvent pas suivre la cadence de mise à niveau (Pro change « doit quitter 22.04 avant 2027 » en « avant 2032 »), pour les régimes de conformité qui veulent des artefacts FIPS/CIS, et pour quiconque a ses paquets critiques dans universe. Quand ça ne se justifie pas : un petit parc bien entretenu qui migre à chaque cycle de LTS et puise surtout dans main. Le palier gratuit couvre de toute façon vos cinq premières machines.

Migrer sur place

Le chemin sanctionné est do-release-upgrade, de LTS à LTS, une étape à la fois : les machines en 22.04 passent par 24.04. La mécanique, condensée (la discipline plus complète pour serveur distant est la même que dans notre guide de mise à niveau Debian ; les précautions se transposent intégralement) :

apt update && apt full-upgrade        # be fully current first
# backups + snapshot; then, inside tmux:
do-release-upgrade                    # offers 26.04 once 26.04.1 is out

Avant de commencer : vérifiez cgroup v2 (mount | grep cgroup2), revérifiez que chaque dépôt tiers fournit déjà des paquets 26.04 (l'outil de mise à niveau les désactive pendant l'exécution ; vous les réactivez ensuite), et testez que l'accès console hors bande fonctionne. Sur un serveur dédié, KVM-over-IP fait toute la différence entre « incident amusant » et « reprovisionnement ». Ensuite : systemctl --failed, tests de fumée des services, et réactivez vos dépôts.

Questions fréquentes

Ubuntu 26.04 est-elle déjà assez stable pour la production ?

Pour les nouveaux déploiements, oui, avec la réserve habituelle : vérifiez la liste actuelle des problèmes connus au regard de votre charge de travail (la régression PostgreSQL en est l'exemple évident) et confirmez que vos dépôts tiers publient des paquets 26.04. Pour les mises à niveau sur place de machines existantes, le garde-fou de Canonical lui-même donne la réponse : l'outil de mise à niveau n'offre 26.04 aux utilisateurs LTS qu'à partir de 26.04.1 en août 2026, ce qui est une valeur par défaut sensée pour des parcs de production, pas de la bureaucratie.

Faut-il un jour faire tourner des versions intermédiaires (25.10, 26.10…) sur un serveur ?

Presque jamais. Les versions intermédiaires n'ont que neuf mois de support, ce qui sur un serveur signifie plus d'une migration d'OS par an juste pour rester à jour côté correctifs. Leur but est de donner un aperçu de ce que contiendra la prochaine LTS. La seule utilisation défendable sur un serveur est une machine de courte durée de vie qui a réellement besoin d'une fonctionnalité plusieurs mois avant la prochaine LTS, et même dans ce cas, un conteneur ou un noyau HWE sur la LTS actuelle y mène généralement avec moins de bouleversements.

J'ai besoin d'un noyau plus récent sur 24.04. Dois-je migrer vers 26.04 ?

Généralement non : installez la pile HWE (apt install linux-generic-hwe-24.04), qui suit des noyaux plus récents au fil des révisions mineures de la LTS. C'est la réponse prévue pour « du matériel neuf, un espace utilisateur stable ». Ne mettez à niveau l'OS que lorsque vous voulez la nouvelle plateforme (systemd, OpenSSL, piles de langage), pas seulement le noyau.

Ubuntu, ou tout autre chose ?

Si vous pesez des distributions plutôt que des versions, c'est un autre article : Ubuntu vs Debian couvre l'alternative la plus proche, et comment choisir une distribution Linux couvre tout le terrain, famille RHEL comprise. En bref : la cadence de publication LTS d'Ubuntu et les fenêtres Pro sont ses éléments distinctifs ; si cela n'a pas de valeur pour vous, le champ des possibles s'ouvre.

Déployer sur Serverside

Nous déployons vos serveurs dédiés Ubuntu avec la version LTS prise en charge de votre choix en moins d'une minute, sur notre réseau ASN 55285 avec mitigation DDoS permanente et pare-feu de périphérie en self-service. KVM-over-IP est inclus en standard, exactement le filet de sécurité hors bande que suppose la section sur la mise à niveau sur place, et quand vous préférez repartir propre sur 26.04 plutôt que migrer sur place, le reprovisionnement en moins d'une minute fait de l'installation neuve suivie d'une restauration une vraie stratégie plutôt qu'un dernier recours.

Après le déploiement : la liste de vérification de durcissement de la première heure, et des règles de pare-feu par défaut sensées.