Ubuntu Server 26.04 LTS : ce qu'il faut savoir avant de migrer

Ubuntu 26.04 LTS est sortie le 23 avril 2026 sous le nom Resolute Raccoon.

Pour un poste desktop, c’est une nouvelle LTS avec GNOME 50, Wayland et quelques changements visibles. Pour un serveur, c’est autre chose : une base qui peut rester en production pendant plusieurs années, avec un nouveau noyau, une pile crypto plus stricte, des paquets serveur mis à jour, des changements de comportement sur des services courants, et une stratégie de support à bien comprendre avant de lancer un do-release-upgrade.

Je regarde donc Ubuntu 26.04 LTS sous l’angle qui m’intéresse le plus ici : serveurs, VPS, homelab, cloud, sécurité et migration propre.

En bref

#

Les points importants côté serveur :

• Ubuntu 26.04 LTS est disponible depuis le 23 avril 2026.
• Le support standard court jusqu’en avril 2031.
• Avec Ubuntu Pro, Canonical annonce une maintenance étendue jusqu’en 2036, puis une option Legacy jusqu’en 2041.
• Ubuntu Server 26.04 LTS peut démarrer avec des besoins modestes, selon l’usage : les release notes indiquent un plancher à 1,5 Go de RAM et 4 Go de stockage.
• Le noyau mis en avant par Canonical pour cette LTS est Linux 7.0.
• OpenSSH passe en 10.2, avec des choix crypto plus stricts.
• sudo-rs et uutils coreutils deviennent des composants par défaut, avec les variantes historiques disponibles en secours.
• Chrony devient le démon de temps par défaut pour les nouvelles installations.
• Plusieurs piles serveur changent de version : PHP 8.5, Django 5.2 LTS, Samba 4.23, Dovecot 2.4.2, OpenSSH 10.2.
• CUDA, ROCm et des briques Intel oneAPI arrivent dans les dépôts Ubuntu, ce qui compte pour les serveurs GPU et les workloads IA.
• Pour une machine de production en Ubuntu 24.04 LTS, je planifierais la migration plutôt que de la forcer immédiatement.

Ubuntu 26.04 LTS n’est pas une mise à jour à traiter comme un simple apt upgrade. C’est une migration de socle.

Support et cycle de vie

#

Ubuntu 26.04 est une LTS, donc une version pensée pour durer. Les release notes officielles annoncent cinq ans de mises à jour de sécurité et de correctifs critiques, jusqu’en avril 2031.

La page du cycle de vie Ubuntu va plus loin pour les environnements couverts par Ubuntu Pro : maintenance de sécurité étendue jusqu’en avril 2036, puis option Legacy jusqu’en avril 2041.

Pour un serveur, ce calendrier est central. Il permet de raisonner en fenêtres de maintenance :

• nouvelles installations en 26.04 LTS ;
• migrations progressives depuis 24.04 LTS ;
• maintien temporaire des machines sensibles sur 24.04 LTS ;
• bascule des services critiques après validation ;
• retrait des versions intermédiaires avant leur fin de support.

Les release notes rappellent aussi qu’on ne saute pas n’importe quelle version. Une machine en Ubuntu 22.04 LTS ou 25.04 doit d’abord passer par Ubuntu 24.04 LTS ou 25.10 avant d’aller vers 26.04 LTS.

Installation serveur et images disponibles

#

La page de téléchargement d’Ubuntu 26.04 LTS propose une image Server install image pour les machines AMD64. Elle précise aussi une chose simple, mais utile : l’image serveur installe Ubuntu sans interface graphique.

C’est exactement ce que je veux sur un VPS, une VM, un serveur bare metal ou un noeud de lab :

• moins de paquets ;
• moins de services inutiles ;
• moins de surface d’attaque ;
• moins de bruit lors des mises à jour ;
• une base plus lisible.

Ubuntu 26.04 LTS est aussi disponible sous plusieurs formes selon les usages : images cloud, images virtualisées, WSL, netboot, et variantes pour d’autres architectures via les canaux Ubuntu. Pour un parc serveur, ce point compte autant que la version elle-même : la bonne image de départ évite beaucoup de bricolage ensuite.

Noyau, matériel et plateformes

#

Canonical annonce Ubuntu 26.04 LTS avec Linux 7.0. La promesse principale est classique pour Ubuntu : fournir un noyau récent au moment de la sortie, avec de l’activation matérielle pour les plateformes modernes.

Côté serveur, les points à surveiller sont :

• support matériel récent ;
• cartes réseau ;
• stockage NVMe ;
• virtualisation ;
• passthrough PCIe/IOMMU ;
• plateformes ARM64 ;
• RISC-V ;
• serveurs GPU ;
• machines cloud.

Canonical met aussi en avant le support des images optimisées pour AWS, Azure, Google Cloud, IBM Cloud et Oracle Cloud. Si vous utilisez Ubuntu comme base cloud, il vaut mieux partir des images officielles du fournisseur que d’importer une ISO générique et reconstruire à la main.

OpenSSH 10.2 : la migration à ne pas négliger

#

OpenSSH est une brique critique. Quand elle change, on lit les notes.

Ubuntu 26.04 LTS passe d’OpenSSH 9.6p1 dans Ubuntu 24.04 LTS à OpenSSH 10.2p1. Les release notes indiquent plusieurs changements importants :

• avertissement en cas de négociation sans échange de clés post-quantique ;
• support par défaut de l’échange hybride mlkem768x25519-sha256 ;
• retrait du support DSA ;
• clés hôte DSA non générées ;
• nouvelle option PerSourcePenalties ;
• alias sshd.service vers ssh.service ;
• durcissement autour de la lecture de ~/.pam_environment.

Sur un serveur moderne, c’est une bonne nouvelle. Sur un vieux parc, cela peut révéler des clients SSH anciens, des appliances oubliées, des scripts de backup ou des automatisations qui n’ont pas été revus depuis trop longtemps.

Avant migration, je testerais au minimum :

ssh -V
sudo sshd -t
sudo sshd -T | less

Et je garderais une session root ou console ouverte pendant toute modification SSH. C’est banal, mais beaucoup de mauvaises soirées commencent par un redémarrage de ssh.service trop confiant.

Crypto moderne et sécurité système

#

Ubuntu 26.04 LTS pousse une ligne claire : durcir le socle, retirer les vieilles cryptos, et introduire plus de composants mémoire sûrs.

Canonical met en avant :

• OpenSSL avec support de mécanismes post-quantiques ;
• OpenSSH plus strict ;
• retrait de DSA ;
• chiffrement complet du disque lié au TPM disponible dans l’installateur ;
• support de confidential computing côté AMD SEV-SNP et Intel TDX ;
• sudo-rs comme implémentation par défaut de sudo ;
• uutils coreutils comme implémentation par défaut de plusieurs commandes de base.

Le passage à sudo-rs et uutils mérite une attention particulière côté serveur. Dans la majorité des cas, les commandes doivent rester compatibles. Mais dans une infra réelle, on trouve toujours des scripts qui dépendent d’un comportement exact, d’un message d’erreur, d’une option peu utilisée ou d’un format de sortie.

Je testerais donc les scripts d’administration qui utilisent :

• sudo ;
• cp ;
• mv ;
• ls ;
• install ;
• stat ;
• chown ;
• chmod ;
• toute commande appelée dans une CI, un hook de déploiement ou un script de backup.

Ce n’est pas une raison pour refuser la migration. C’est une raison pour la tester proprement.

Chrony par défaut : le temps redevient un sujet

#

Les release notes indiquent que Chrony devient le démon de temps par défaut pour les nouvelles installations, en remplacement de systemd-timesyncd.

Sur un serveur, le temps est une dépendance silencieuse :

• certificats TLS ;
• journaux ;
• corrélation d’incidents ;
• Kerberos ;
• bases distribuées ;
• files de messages ;
• sauvegardes ;
• authentification ;
• signatures.

Une dérive d’horloge peut produire des erreurs qui ressemblent à tout sauf à un problème d’horloge.

Après migration ou nouvelle installation, je vérifierais :

timedatectl
chronyc sources -v
chronyc tracking

Si vous aviez une configuration NTP spécifique, notamment en environnement isolé ou avec des sources internes, il faudra la reporter proprement dans Chrony.

Paquets serveur à surveiller

#

Ubuntu 26.04 LTS met à jour beaucoup de composants serveur. Les plus visibles dans les release notes :

Ce tableau est la raison principale pour laquelle je ne traite jamais une montée LTS serveur comme une formalité.

Un serveur qui ne fait que reverse proxy + Docker n’aura pas le même risque qu’un serveur mail, un contrôleur Samba AD ou une plateforme applicative PHP. La migration doit suivre les services réellement présents, pas la fiche marketing de la distribution.

Serveurs mail : prudence maximale

#

Si votre serveur Ubuntu héberge du mail, 26.04 demande une lecture attentive.

Dovecot 2.4 introduit des changements importants dans la configuration. Postfix évolue aussi côté packaging, notamment avec le changement autour du chroot par défaut.

Avant migration d’un serveur mail, je ferais au minimum :

• export de la configuration complète ;
• sauvegarde des boîtes ;
• sauvegarde des bases d’authentification ;
• test de restauration ;
• vérification SPF, DKIM, DMARC ;
• test SMTP entrant et sortant ;
• test IMAP ;
• test antispam et antivirus ;
• vérification des certificats ;
• fenêtre de rollback claire.

Le mail est l’un des pires services à migrer dans la précipitation : il semble simple quand il marche, puis devient une enquête quand il casse.

Samba et partages réseau

#

Samba passe en 4.23. Les release notes mentionnent notamment SMB3 Unix Extensions activé par défaut, NetBIOS désactivé par défaut dans les nouvelles configurations, des changements autour des modules VFS et des évolutions côté AD.

Pour un simple partage de fichiers dans un homelab, le risque reste limité, mais il faut tester les clients réels : Windows, Linux, macOS, scanners, copieurs, vieilles applications métiers.

Pour un serveur Samba plus ambitieux, surtout avec AD DC ou intégration domaine, je ne migrerais pas sans environnement de test.

GPU, IA et calcul : CUDA et ROCm dans les dépôts

#

Ubuntu 26.04 LTS est intéressante pour les serveurs GPU.

Canonical annonce CUDA dans les dépôts Ubuntu :

sudo apt install cuda-toolkit

ROCm côté AMD est également disponible dans les dépôts. Ubuntu 26.04 LTS intègre aussi des briques autour d’Intel oneAPI, DPC++, oneDNN et SYCL.

Pour un serveur IA ou calcul, c’est important parce que l’installation de stacks GPU a longtemps été un mélange fragile de dépôts tiers, versions de drivers, documentation périmée et dépendances incompatibles.

Je resterais prudent malgré tout :

• vérifier la matrice GPU/driver ;
• figer les versions en production ;
• tester les workloads réels ;
• surveiller les performances après migration ;
• documenter la méthode de rollback ;
• éviter de mélanger dépôts Ubuntu, dépôts vendor et scripts d’installation sans stratégie.

Le fait qu’un paquet soit dans les dépôts simplifie la maintenance. Cela ne remplace pas une validation applicative.

Livepatch, ARM64 et disponibilité

#

Canonical annonce l’extension de Livepatch à Arm64 avec Ubuntu 26.04 LTS. Pour les serveurs et l’edge, c’est un vrai signal.

Livepatch ne supprime pas le besoin de redémarrer éternellement, mais il réduit la pression sur certains correctifs noyau critiques. Dans un parc, cela permet de découpler partiellement :

• correction urgente ;
• fenêtre de reboot ;
• disponibilité applicative ;
• maintenance planifiée.

Pour un serveur unique de homelab, ce n’est pas forcément vital. Pour des noeuds exposés, des machines edge ou des workloads difficiles à interrompre, cela mérite d’être intégré à la stratégie de patching.

Confidential computing

#

Ubuntu 26.04 LTS met aussi en avant le confidential computing avec support hôte et invité pour AMD SEV-SNP et Intel TDX.

Le principe : protéger les workloads en chiffrant et isolant la mémoire des machines virtuelles au niveau matériel. Cela vise surtout :

• cloud public ;
• environnements multi-tenant ;
• secteurs réglementés ;
• workloads sensibles ;
• traitement de données confidentielles ;
• IA avec données privées.

Dans un homelab, ce n’est pas le premier sujet. Dans une infra cloud ou souveraine, c’est une brique à surveiller sérieusement.

Migration depuis Ubuntu 24.04 LTS

#

Si votre serveur est en Ubuntu 24.04 LTS et fonctionne bien, mon conseil est simple : ne forcez pas la migration sans besoin clair.

La documentation Ubuntu rappelle que les migrations LTS vers LTS sont généralement proposées à partir de la première version point. Pour 26.04, cela veut dire qu’il faut surveiller l’ouverture officielle du chemin de migration pour votre cas, plutôt que de contourner le mécanisme avec des options de développement sur une machine de production.

Avant migration, je ferais cette préparation :

1. Inventaire des services.
2. Liste des ports exposés.
3. Sauvegarde système.
4. Sauvegarde applicative.
5. Test de restauration.
6. Snapshot si VM.
7. Lecture des notes pour les paquets critiques.
8. Test sur clone ou environnement proche.
9. Fenêtre de maintenance annoncée.
10. Plan de retour arrière.

Pour un VPS simple, cette liste peut sembler lourde. Elle ne l’est pas. Elle évite surtout de découvrir, au pire moment, que la sauvegarde n’était qu’une décoration.

Commandes de vérification après migration

#

Après migration vers Ubuntu Server 26.04 LTS, je vérifierais au minimum :

lsb_release -a
uname -a
systemctl --failed
journalctl -p warning -b
apt list --upgradable
needrestart
ss -tulpn
timedatectl
chronyc tracking
ssh -V
sudo sshd -t

Puis, service par service :

systemctl status nginx
systemctl status apache2
systemctl status docker
systemctl status postgresql
systemctl status mariadb
systemctl status postfix
systemctl status dovecot
systemctl status smbd

Évidemment, on adapte à ce qui tourne réellement. Le but n’est pas d’exécuter une liste magique, mais de vérifier que le serveur fait encore ce qu’il doit faire.

Ma stratégie pour un homelab

#

Dans un homelab, je migrerais dans cet ordre :

1. VM de test Ubuntu 26.04 fraîche.
2. Nouveau petit service non critique.
3. Clone d’un VPS ou d’une VM existante.
4. Serveur de monitoring ou outil interne.
5. Reverse proxy secondaire.
6. Services applicatifs simples.
7. Services avec données.
8. Mail, annuaire, stockage, bases critiques en dernier.

Je documenterais chaque surprise. Une migration LTS est une bonne occasion de nettoyer :

• dépôts tiers oubliés ;
• services désactivés mais installés ;
• vieux kernels ;
• scripts de backup non testés ;
• clés SSH obsolètes ;
• règles firewall devenues illisibles ;
• timers systemd qui ne servent plus ;
• conteneurs sans stratégie de mise à jour.

La migration est rarement seulement une migration. C’est un audit déguisé.

Mon avis

#

Ubuntu Server 26.04 LTS ressemble à une bonne base pour les nouvelles installations serveur, surtout si vous avez du matériel récent, des workloads cloud, des besoins GPU, ou une stratégie de sécurité qui profite de Livepatch, Ubuntu Pro, TPM, crypto moderne et composants Rust.

Pour les serveurs existants, je serais plus méthodique. Les changements autour d’OpenSSH, Chrony, Dovecot, Postfix, Samba, RabbitMQ, PHP et des coreutils justifient un vrai test.

Je la mettrais rapidement en lab. Je l’utiliserais volontiers pour de nouveaux serveurs non critiques. Je ne pousserais pas tous les serveurs de production dès maintenant juste parce que la version est sortie.

Une LTS est faite pour durer. La bonne approche n’est pas de migrer vite, mais de migrer proprement.

Sources vérifiées

#

Pour écrire cet article j’ai utilisé les informations principales sur les sources suivantes :

• Annonce Canonical : Ubuntu 26.04 LTS Resolute Raccoon
• Release notes officielles Ubuntu 26.04 LTS
• Résumé Ubuntu 26.04 LTS pour les utilisateurs LTS
• Cycle de vie Ubuntu
• Page de téléchargement Ubuntu 26.04 LTS
• Canonical : nouveautés sécurité Ubuntu 26.04 LTS
• Documentation Ubuntu Desktop : mise à niveau d’Ubuntu
• Annonce des fonds d’écran Ubuntu 26.04 LTS