Pourquoi la montée n'est pas urgente, et quand elle devient raisonnable
Ubuntu 26.04 LTS est sortie le 23 avril 2026. Comme pour chaque LTS, Canonical n'ouvre le saut depuis la LTS précédente qu'à la première version ponctuelle : 26.04.1 a été annoncée le 27 août 2026, mais l'offre de mise à niveau a encore été retenue quelques semaines, le temps de rétroporter des correctifs à des régressions de rust-coreutils. L'équipe de publication a annoncé l'ouverture le 29 septembre 2026, avec un déploiement progressif côté bureau et do-release-upgrade disponible à tout moment côté serveur.
Disons-le franchement : rien ne presse. Ubuntu 24.04 LTS reçoit ses correctifs de sécurité standard jusqu'en mai 2029, et jusqu'en mai 2034 avec Ubuntu Pro. Un VPS 24.04 à jour n'est pas un VPS exposé. 26.04, elle, est maintenue jusqu'en mai 2031.
La montée devient raisonnable quand trois conditions sont réunies : vos dépôts tiers (Docker, PHP, Node, agents de supervision) publient pour resolute, un clone du VPS a passé la montée avec votre pile réelle, et vous avez un créneau de maintenance convenu avec le client. Pour une agence, le bon moment est souvent celui où l'on standardise un parc : un seul socle à documenter plutôt que deux.
Ce que ce guide vous permet de faire
- Trancher entre montée en place et VPS neuf — par critères mesurables, pas par habitude.
- Disposer d'un filet réel — une sauvegarde déjà restaurée une fois, pas un snapshot jamais testé.
- Survivre à une coupure SSH — grâce à la session
screenque l'outil ouvre lui-même et au démon de secours sur le port 1022. - Savoir où se trouve le point de non-retour — et ce que votre sauvegarde doit donc couvrir avant de l'atteindre.
- Anticiper ce qui casse —
sudo-rs,rust-coreutils, PHP, MySQL, OpenSSH,docker-composev1, dépôts tiers. - Remettre les dépôts tiers en service — avec le bon nom de version, sans réintroduire
apt-key. - Répéter la procédure sur un parc — chaque étape se vérifie par une commande, donc se reproduit.
Mettre à niveau en place ou réinstaller un VPS neuf
La montée en place garde l'adresse IP, les clés d'hôte SSH, les comptes et la configuration. Elle échoue surtout là où le serveur s'est éloigné d'une installation standard. La réinstallation sur un VPS neuf coûte une migration, mais vous laisse l'ancien serveur intact jusqu'à la bascule DNS : c'est le seul scénario qui offre un vrai retour arrière.
Tranchez avec quatre questions. Combien de dépôts tiers et de PPA sont actifs ? Au-delà de deux ou trois, chacun est une inconnue que l'outil désactive pendant la montée. Votre sauvegarde a-t-elle déjà été restaurée ? Si non, la montée en place est un pari. Quelle tolérance à l'arrêt a le client ? La montée prend plusieurs heures selon la documentation Ubuntu, et la machine redémarre à la fin. Le serveur est-il décrit dans du code (Ansible, cloud-init, Compose) ? Si oui, un VPS neuf se reconstruit vite et la réinstallation devient le choix le plus sûr.
Règle pratique : serveur documenté et pile conteneurisée, réinstallez ; serveur historique avec peu de dépôts tiers et une sauvegarde éprouvée, montez en place, après un essai sur clone.
Prérequis avant de lancer quoi que ce soit
Le VPS doit tourner en 24.04 entièrement à jour : do-release-upgrade refuse sinon, avec un message explicite. Comptez plusieurs heures de fenêtre, une personne présente pour répondre aux questions de l'outil, et une console hors bande (console web ou VNC du fournisseur) pour le cas où SSH ne revient pas. Le port 1022/tcp doit pouvoir être ouvert temporairement dans le pare-feu.
L'outil calcule lui-même l'espace disque nécessaire et s'arrête s'il manque de place : vérifiez df -h / et df -h /boot avant, et videz le cache APT si besoin. Côté applicatif, il vous faut une sauvegarde des données hors du VPS, et un snapshot de la machine entière fourni par la plateforme.
Un point d'honnêteté : les ruptures listées plus bas viennent des notes de version officielles de 26.04 et de la documentation des paquets concernés. Elles n'ont pas été relevées par un essai complet de notre côté sur une pile Docker, Nginx et PHP-FPM. C'est précisément pourquoi la procédure passe par un clone.
La procédure, étape par étape
Faire l'inventaire de ce qui sort de la distribution
Listez les sources APT tierces avec
ls /etc/apt/sources.list.d/et repérez les paquets hors archive Ubuntu avecapt list --installed 2>/dev/null | grep -v ubuntu. Notez la version de PHP (php -v), la présence de l'ancien binaire Compose (which docker-compose && docker-compose version) et le contenu de/etc/sudoers.d/. Cette liste est votre plan de test.Sauvegarder, puis restaurer une fois
Un snapshot du VPS côté plateforme n'est un filet que s'il a déjà été restauré une fois. Faites le snapshot, restaurez-le sur une machine de test, vérifiez que les services démarrent. Doublez-le d'une sauvegarde applicative hors du serveur (bases, volumes,
/etc) : notre guide sauvegardes Restic sur VPS détaille la mise en place.Monter d'abord un clone
Créez un VPS de test depuis le snapshot (à partir de 99 DH/mois) et déroulez toute la procédure dessus. Relevez chaque question posée par l'outil, chaque service en échec, chaque dépôt désactivé. La montée de production ne doit plus réserver de surprise.
Mettre 24.04 entièrement à jour
La documentation Ubuntu Server prescrit
sudo apt updatepuissudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true. Si le fichier/run/reboot-requiredexiste, redémarrez avant d'aller plus loin. Vérifiez enfin que/etc/update-manager/release-upgradescontientPrompt=lts.Préparer l'accès de secours
Lancée sous SSH, la montée prévient qu'elle démarrera un démon SSH supplémentaire sur le port 1022, sans l'ouvrir dans le pare-feu. Ouvrez-le vous-même :
sudo ufw allow 1022/tcp. Gardez la console web du fournisseur ouverte dans un autre onglet.Lancer la montée
Exécutez
sudo do-release-upgrade, sans-d: l'option sert aux versions de développement et n'est plus nécessaire depuis l'ouverture du chemin LTS. L'outil se relance de lui-même dans une sessionscreennomméeubuntu-release-upgrade-screen-window. Si votre connexion tombe, reconnectez-vous et reprenez-la avecsudo screen -d -r ubuntu-release-upgrade-screen-window. Les journaux sont dans/var/log/dist-upgrade/.Répondre aux questions sans réflexe
L'outil annonce les dépôts tiers désactivés, puis le nombre de paquets à installer, mettre à jour et supprimer. Lisez la liste des suppressions. Pour chaque fichier de configuration modifié localement (
sshd_config,php.ini,nginx.conf), conservez votre version par défaut et comparez après coup avec le fichier.dpkg-dist.Franchir le point de non-retour en connaissance de cause
La documentation Ubuntu est claire : une fois le téléchargement terminé, le processus ne peut plus être annulé. Les paquets sont remplacés et aucun retour à 24.04 n'est prévu par la distribution. À partir de là, votre seul retour arrière est la restauration du snapshot de l'étape 2.
Redémarrer et vérifier
Le système n'est considéré comme mis à niveau qu'après le redémarrage proposé en fin de procédure. Contrôlez ensuite
cat /etc/os-release,uname -r,systemctl --failedet les journaux de vos services. Refermez le port de secours avecsudo ufw delete allow 1022/tcp.Réactiver les dépôts tiers, puis Docker
Réécrivez chaque source tierce avec le nom de version
resolute. Docker documente une source au format.sourcesdont la ligneSuiteslit le nom depuis/etc/os-release. Pour PHP, le PPA de Ondřej Surý renvoie désormais verspackages.sury.org/php/pour Resolute. Vérifiez ensuite vos stacks avec notre guide migration Docker v29 sur VPS.
24.04 et 26.04 : ce qui change sous vos applications
Faites défiler le tableau
| Composant | Ubuntu 24.04 LTS | Ubuntu 26.04 LTS |
|---|---|---|
| Noyau (GA) | 6.8 | 7.0 |
| PHP (archive Ubuntu) | 8.3 | 8.5 |
| Python 3 | 3.12 | 3.14 |
| OpenSSL | série 3.0 | série 3.5 |
| OpenSSH | 9.6p1 | 10.2p1, clés DSA retirées |
| MySQL | 8.0 | 8.4 LTS, `mysql_native_password` verrouillé par défaut |
| sudo et coreutils | sudo C, GNU coreutils | `sudo-rs` et `rust-coreutils` par défaut ; `cp`, `mv`, `rm` restent GNU |
| Compose | paquet `docker-compose` v1 (1.29.2) | paquet v1 absent ; `docker-compose-v2` (2.40.3) |
Ce qui casse : ce que disent les notes de version
Le changement le plus visible est sudo-rs, devenu le fournisseur par défaut. L'implémentation d'origine reste installée sous le nom sudo.ws. Les réglages requiretty, timestamp_type ou mailto d'un fichier sudoers peuvent produire une erreur de réglage inconnu, la journalisation des entrées-sorties n'existe pas et sudo-ldap est retiré. Le retour à l'ancien sudo passe par sudo update-alternatives --set sudo /usr/bin/sudo.ws, que l'annonce Ubuntu déconseille sans l'interdire.
Les utilitaires de base viennent de rust-coreutils, à l'exception de cp, mv et rm. Les notes de version listent encore des CVE ouvertes sur ce paquet et un défaut d'héritage des ACL avec mkdir -p. Le paquet coreutils-from-gnu rétablit les versions GNU si un script de sauvegarde ou de déploiement en dépend.
Pour un serveur web, retenez aussi : apt-key est retiré, le module libapache2-mod-php perd le JIT de PHP à cause d'un durcissement systemd (PHP-FPM est recommandé), et le support de cgroup v1 disparaît avec systemd 259.
Les ruptures à tester sur le clone
- sudo — lancez
sudo visudo -cet rejouez vos scripts qui appellentsudosans terminal. - Scripts shell — exécutez vos sauvegardes et déploiements tels quels ; un écart de
rust-coreutilsse voit sur les options rares dedate,lsoustat. - PHP 8.5 — vérifiez les extensions chargées avec
php -met la compatibilité de vos CMS ; le passage depuis 8.3 saute une version majeure intermédiaire. - MySQL 8.4 — les comptes en
mysql_native_passwordsont verrouillés par défaut ; repérez-les avant la montée. - SSH — les clés DSA ne sont plus acceptées, et OpenSSH avertit désormais quand l'échange de clés n'est pas post-quantique.
- Compose v1 — le paquet
docker-composev1 n'existe plus en 26.04 ; tout script qui appelledocker-composeavec tiret doit passer àdocker compose. - Synchronisation de l'heure — chrony remplace systemd-timesyncd sur les installations neuves ; sur un serveur monté, la bascule est manuelle et facultative.
- Dépôts tiers — chaque source désactivée doit être réécrite pour
resolute, et sa clé gérée hors deapt-key.
Refermer ce que la montée a ouvert
Après le redémarrage, vérifiez que le démon de secours a bien disparu (sudo ss -tlnp | grep 1022 ne doit rien rendre) et que la règle de pare-feu est retirée. Comparez /etc/ssh/sshd_config avec sshd_config.dpkg-dist s'il existe, puis validez la configuration avec sudo sshd -t avant tout redémarrage du service. Notre checklist de durcissement Linux sert ensuite de contrôle complet.
Dépannage : les messages que vous risquez de voir
« Please install all available updates for your release before upgrading. » Le système n'est pas entièrement à jour : rejouez la commande apt dist-upgrade de l'étape 4, y compris l'option sur les mises à jour échelonnées.
« You have not rebooted after updating a package which requires a reboot. » Un noyau ou une bibliothèque attend un redémarrage. Redémarrez, puis relancez la montée.
« No new release found. » Vérifiez Prompt=lts dans /etc/update-manager/release-upgrades. Avec Prompt=never, l'outil le dit explicitement et refuse.
« Required apt sources are missing » L'outil ne trouve plus de source Ubuntu utilisable, souvent à cause d'un miroir maison. Acceptez de poursuivre avec les sources par défaut, ou corrigez la source principale avant de relancer.
Liste de paquets étrangers impossible à faire défiler. Les notes de version signalent ce défaut lors des montées depuis 24.04 : annulez, purgez les paquets étrangers inutiles, puis relancez.
La connexion SSH tombe. Reconnectez-vous sur le port 22 ou 1022, puis reprenez la session avec sudo screen -d -r ubuntu-release-upgrade-screen-window.
Une montée par VPS, une méthode pour tout le parc
La montée de 24.04 vers 26.04 n'est pas une urgence : c'est un chantier à planifier avant mai 2029, à votre rythme et à celui de vos clients. Ce qui fait la différence n'est pas la commande, qui tient en une ligne, mais ce qui l'entoure : un inventaire, une sauvegarde déjà restaurée, un essai sur clone, une fenêtre convenue, un retour arrière que vous savez exécuter.
Pour une agence, l'intérêt est de faire de cette procédure une routine. Notez la liste des ruptures rencontrées sur le premier clone, et elle deviendra le plan de test des VPS suivants. Le parc entier finit sur un seul socle, documenté une seule fois, maintenu jusqu'en mai 2031. Ce guide décrit la procédure ; la montée de version reste à votre charge, ServOrbit ne l'exécute pas sur votre VPS.
