Depuis le 29 septembre 2026, un serveur sous Ubuntu 24.04 LTS peut passer directement à Ubuntu 26.04.1 LTS avec la commande do-release-upgrade. Canonical n’impose rien : la 24.04 reste maintenue jusqu’en 2029, ou 2034 avec Ubuntu Pro. Vous pouvez donc préparer sans urgence la mise à niveau Ubuntu 26.04 d’un serveur web en production. Elle se fait en cinq temps : choisir le moment, prendre un snapshot et une sauvegarde, vérifier les dépôts tiers et la version de PHP, tester sur une préproduction, puis basculer avec un plan de retour arrière fixé d’avance.
Ubuntu 26.04.1 LTS : ce que Canonical a ouvert le 29 septembre 2026
Le 29 septembre 2026, Canonical a activé la mise à niveau directe d’Ubuntu 24.04 LTS (Noble Numbat) vers Ubuntu 26.04.1 LTS (Resolute Raccoon). Sur un poste de bureau, la proposition arrive progressivement dans le Gestionnaire de mises à jour. Sur un serveur, rien ne se déclenche seul : l’administrateur lance l’opération à la main.
Ce calendrier déroute ceux qui cherchent la date de sortie d’Ubuntu 26.04 LTS. La version est disponible depuis avril 2026, et son premier correctif, la 26.04.1, est sorti le 27 août 2026. Le passage depuis la 24.04 n’a pourtant été ouvert qu’un mois plus tard environ. En cause : des régressions dans rust-coreutils, la réécriture en Rust des commandes de base du système (ls, cp, mv…). L’annonce publiée par Canonical sur la liste ubuntu-announce le précisait :
« Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils. »
En français : les utilisateurs de la 24.04 recevraient la proposition quelques semaines après la sortie de la 26.04.1, une fois rétroportés les correctifs prévus pour rust-coreutils.
La presse parle surtout du bureau (GNOME 50, Wayland). Sur un serveur, les changements qui comptent sont ailleurs :
- le noyau Linux passe de la version 6.8 à la version 7.0 ;
- systemd 259 et APT 3 remplacent les versions de la 24.04 ;
- les chaînes d’outils PHP, Python, Perl, Ruby et Go sont mises à jour ;
- sudo-rs et une partie d’uutils, écrits en Rust, remplacent des outils Unix historiques.
Par défaut, une LTS ne propose que la LTS suivante. Ubuntu 26.10, attendue le 15 octobre 2026, ne s’affichera donc pas sur votre serveur.
Faut-il migrer maintenant ? Le calendrier de support et les raisons d’attendre
Non, rien ne presse. La migration est facultative : un serveur à jour sous 24.04 reçoit ses correctifs de sécurité pendant encore plusieurs années. Vous avez le temps de choisir une fenêtre compatible avec votre activité et de préparer l’opération.
Dates de fin de support d’Ubuntu 24.04 et 26.04
Le support standard d’Ubuntu 24.04 LTS court jusqu’en mai 2029. La 26.04 est couverte jusqu’en mai 2031, et plus longtemps avec les offres payantes de Canonical.
| Version | Sortie | Fin du support standard | Avec Ubuntu Pro |
|---|---|---|---|
| Ubuntu 24.04 LTS (Noble Numbat) | Avril 2024 | Mai 2029 | Avril 2034 |
| Ubuntu 26.04 LTS (Resolute Raccoon) | Avril 2026 | Mai 2031 | Avril 2036 |
Avec l’offre Legacy Support, la couverture de la 26.04 monte à quinze ans. Sa date de fin ne bouge pas selon le moment où vous migrez : passer à la 26.04 en 2027 plutôt qu’en octobre 2026 ne vous coûte aucune année de support.
Les cas où il vaut mieux attendre
Le report lié à rust-coreutils le montre : des composants système encore jeunes peuvent régresser, et les premiers mois d’une LTS servent souvent à corriger ce type de défaut. Attendez si l’une de ces situations vous concerne :
- votre boutique entre dans sa période forte (Black Friday, fêtes de fin d’année, soldes de janvier) ;
- un module PrestaShop, une extension WordPress ou un logiciel métier n’est pas encore annoncé compatible avec Ubuntu 26.04 ou avec sa version de PHP ;
- votre hébergeur ne propose pas de snapshot et vous n’avez pas de serveur de préproduction ;
- votre contrat d’infogérance mentionne « les mises à jour » sans préciser les montées de version.
Ce dernier point est un piège de contrat classique, et il justifie de relire la clause. Une mise à jour (apt upgrade) et un changement de version (do-release-upgrade) n’ont ni le même coût ni le même risque : certains prestataires facturent le second à part. Notre conseil : passez d’Ubuntu 24.04 à 26.04 dans les 12 à 18 mois, en période creuse. Pour une boutique en ligne, février ou mars conviennent bien.
Il existe une autre méthode pour un serveur. Vous installez un VPS neuf en 26.04, vous y déplacez le site, puis vous basculez le DNS ; l’ancien serveur reste intact en cas de problème. Comptez plus de configuration et quelques semaines d’hébergement en double. En échange, c’est la voie la plus sûre pour un serveur ancien, très personnalisé ou déjà migré plusieurs fois.
Avant de toucher au serveur : sauvegarde, snapshot et inventaire
Canonical recommande de sauvegarder les données et de lire les notes de version avant toute mise à niveau majeure. Sur un serveur, cela veut dire deux protections distinctes et un inventaire écrit de ce qui tourne.
Snapshot et sauvegarde externe : les deux sont nécessaires
Le snapshot est une copie complète du disque du VPS ou de la machine virtuelle, prise depuis l’interface de l’hébergeur. Il ramène le serveur en quelques minutes à l’état exact d’avant la migration. Mais il reste stocké chez le même hébergeur : si le compte ou la plateforme rencontre un problème, il disparaît avec le reste.
Ajoutez donc une sauvegarde externe, hors de l’hébergeur. Elle contient les fichiers du site, un export des bases MySQL ou MariaDB (avec mysqldump, par exemple) et une archive du dossier /etc, où se trouve la configuration du système. Vérifiez aussi dans votre contrat la durée de conservation du snapshot et son prix. Un snapshot supprimé automatiquement au bout de quelques jours ne vous servira pas si un bug apparaît la semaine suivante.
Contrôlez l’espace disque avec df -h : l’outil télécharge les nouveaux paquets avant de les installer et s’arrête si la place manque. Dans le test de The Register, sudo apt clean a libéré 1 Go sur une partition de 24 Go, de quoi débloquer un petit VPS.
Inventaire des services et des configurations modifiées
Notez sur une page ce qui fait fonctionner le site. Les services actifs (systemctl list-units --type=service --state=running), la version de PHP (php -v), celle de Nginx ou d’Apache, celle de MySQL ou MariaDB, les tâches cron de chaque utilisateur, les certificats SSL et leur mode de renouvellement. Cette page vous servira de liste de contrôle sur la préproduction, puis après la migration.
Listez aussi les fichiers de configuration modifiés à la main : php.ini, pools PHP-FPM, virtual hosts, my.cnf. Pendant la mise à niveau, l’outil demandera pour chacun s’il faut garder votre version ou installer celle du nouveau paquet. Mieux vaut connaître la réponse avant que la question s’affiche à 23 h dans une fenêtre SSH.
Dépôts tiers et version de PHP : le vrai point de rupture des sites WordPress et PrestaShop
Sur un serveur web, deux causes de panne passent avant les autres : les logiciels installés hors des dépôts officiels et le changement de version de PHP. Vérifiez-les avant de lancer la mise à niveau, pas après.
Pendant la migration, l’outil désactive automatiquement les dépôts tiers et les PPA (Personal Package Archives, des dépôts maintenus hors de Canonical). Dans le test de JustGeek sur un poste de bureau, cinq dépôts ont été coupés, dont Firefox et WineHQ. Sur un serveur web, ce sera plutôt le dépôt qui fournit PHP, MariaDB, Nginx ou un agent de supervision. Listez-les avec ls /etc/apt/sources.list.d/, puis cherchez sur le site de chaque éditeur une version pour la 26.04. Sans elle, le paquet reste bloqué dans son ancienne version, ou il apparaît dans la liste des paquets obsolètes à supprimer.
La 24.04 fournit PHP 8.3 ; la 26.04 change de branche. Relevez la version exacte dans les notes de version officielles d’Ubuntu 26.04. Comparez-la ensuite avec la compatibilité annoncée pour votre version de WordPress ou de PrestaShop, pour chaque module et pour votre thème. Une boutique PrestaShop ancienne, avec des modules achetés il y a plusieurs années et qui ne sont plus maintenus, demande une vérification module par module. Si un élément bloque, gardez temporairement votre version actuelle de PHP, via un dépôt tiers qui la maintient pour la 26.04 ou dans un conteneur, le temps que vos prestataires valident le site.
La configuration de PHP-FPM cache un piège moins connu. Elle est rangée dans un dossier qui porte le numéro de version (/etc/php/8.3/fpm/pool.d/), et vos pools personnalisés ne suivront pas seuls la nouvelle branche. Il faudra les recopier, puis adapter le chemin du socket dans Nginx ou Apache. Les extensions PHP (Redis, Imagick…) sont à réinstaller pour la nouvelle version. Les modules compilés à part, comme Brotli pour Nginx, sont à reconstruire.
Tester en préproduction puis lancer la mise à niveau Ubuntu 26.04 en production
Faites d’abord la mise à niveau sur une copie du serveur, jamais directement sur la production. Ce clone vous montre ce qui casse, combien de temps dure l’opération et quelles questions l’outil va poser.
Valider sur un clone de préproduction
Créez un nouveau serveur à partir du snapshot. Dès son premier démarrage, coupez l’envoi d’e-mails et les crons qui synchronisent un ERP, relancent des paniers ou passent commande chez un fournisseur : sans cette précaution, vos clients reçoivent des doublons. Mettez ensuite le clone à niveau et testez le site comme un client, puis comme un gestionnaire. Tunnel de commande jusqu’au paiement en mode test, back-office, formulaires, exécution des crons, e-mails transactionnels : tout doit passer.
Chronométrez l’opération. C’est cette durée, mesurée sur votre serveur et non sur un PC de bureau, qui fixe la fenêtre de maintenance.
Lancer la mise à niveau en SSH sur la production
Une fois la préproduction validée, programmez la bascule en heure creuse, passez le site en mode maintenance et prenez un snapshot frais juste avant de commencer.
- Mettez la 24.04 complètement à jour : sudo apt update && sudo apt full-upgrade. Si des paquets restent « retenus » (mises à jour déployées par étapes, dites phased updates), relancer la commande n’y change rien : attendez quelques jours qu’Ubuntu les propose à votre serveur, ou forcez-les avec
sudo apt -o APT::Get::Always-Include-Phased-Updates=true full-upgrade. Redémarrez ensuite si un nouveau noyau a été installé. - Ouvrez une session screen ou tmux (screen -S upgrade). Si la connexion SSH tombe, la mise à niveau continue et vous vous rattachez avec screen -r upgrade.
- Lancez sudo do-release-upgrade. Exécuté via SSH, l’outil démarre un serveur SSH de secours sur le port 1022 : ouvrez ce port temporairement dans le pare-feu si vous voulez garder cette porte de sortie, et refermez-le une fois la mise à niveau terminée.
- Répondez aux invites sur les fichiers de configuration à l’aide de votre inventaire, puis relisez la liste des paquets obsolètes avant de valider leur suppression (367 dans le test de bureau de JustGeek).
- Redémarrez : c’est obligatoire pour charger le noyau 7.0. Livepatch évite certains redémarrages pour les correctifs du noyau, pas celui-ci.
N’utilisez pas l’option -d, que conseillent certains forums : elle vise les versions de développement. Si l’outil répond qu’aucune nouvelle version n’est disponible, ne forcez pas la mise à jour Ubuntu par ce biais. Vérifiez plutôt que toutes les mises à jour sont installées et que le fichier /etc/update-manager/release-upgrades contient Prompt=lts.
Pour la durée, prévoyez de la marge. JustGeek a mesuré environ 25 minutes sur un poste de bureau ; un serveur chargé, avec une base volumineuse, peut demander nettement plus. Réservez au moins deux heures, retour arrière compris.
Après le redémarrage : vérifications et plan de retour arrière
Après le redémarrage, contrôlez le système, puis chaque brique du site, avant de lever le mode maintenance. Le critère de retour arrière se fixe avant de commencer, jamais en plein incident.
Vérifiez la version avec lsb_release -a (elle doit afficher 26.04.1 LTS) et le noyau avec uname -r (7.0). Listez les services en échec avec systemctl --failed. Testez la configuration du serveur web avec sudo nginx -t ou sudo apachectl configtest, puis l’état de PHP-FPM et de la base de données avec systemctl status. Rejouez enfin les tests de la préproduction : commande, back-office, formulaires, e-mails.
Réactivez ensuite les dépôts tiers un par un, et seulement ceux qui publient une version pour la 26.04, avec un apt update après chacun. Si vous les réactivez tous d’un coup et qu’un conflit apparaît, impossible de savoir lequel l’a provoqué.
Surveillez les journaux (journalctl, logs PHP et du serveur web) et les temps de réponse pendant 48 heures. Une erreur liée à un cron nocturne ou à un pic de trafic ne se voit pas dans la première heure.
Pour le retour arrière, écrivez la règle noir sur blanc. Par exemple : si le site ne prend pas de commande à la fin de la fenêtre de maintenance, on restaure le snapshot et on analyse à froid sur la préproduction. Gardez ce snapshot plusieurs jours après la migration. Si vous confiez la mise à niveau Ubuntu 26.04 à votre infogéreur, demandez un devis qui détaille ces cinq étapes, préproduction et critère de restauration compris. Un prestataire qui propose de lancer do-release-upgrade directement en production saute deux garde-fous.
