Passer à Ubuntu 26.04 ou Debian 13 sur un VPS Linux sans casser la prod

Ubuntu 26.04 LTS est sorti en avril 2026 et, depuis septembre, la mise à niveau depuis 24.04 est ouverte à tous. Debian 13 est la version stable depuis août 2025, et Debian 12 n'est plus suivi que par l'équipe LTS. Voici comment passer votre VPS Linux à la nouvelle version sans transformer une mise à jour en panne de production : état des lieux, checklist, commandes et plan de retour arrière.

Où en sont Ubuntu et Debian en octobre 2026

Chiffres tirés des notes de version de Canonical et du calendrier LTS de Debian :

Version	Sortie	Support	Depuis quelle version
Ubuntu 26.04 LTS (Resolute Raccoon)	23 avril 2026, point release 26.04.1 le 27 août 2026	5 ans de mises à jour standard (avril 2031), 10 ans avec l'ESM d'Ubuntu Pro	24.04 LTS ou 25.10 uniquement
Ubuntu 24.04 LTS	avril 2024	support standard jusqu'en 2029	22.04 LTS
Debian 13 (trixie)	9 août 2025 (13.7 en septembre 2026)	équipe sécurité jusqu'au 9 août 2028, puis LTS jusqu'au 30 juin 2030	Debian 12 uniquement
Debian 12 (bookworm)	10 juin 2023	en LTS depuis le 11 juin 2026, jusqu'au 30 juin 2028	Debian 11

Deux conséquences pratiques :

Depuis Ubuntu 22.04, il n'y a pas de saut direct. Canonical l'écrit noir sur blanc : il faut d'abord passer en 24.04 LTS (ou 25.10), puis en 26.04. Comptez donc deux mises à niveau, avec un redémarrage et des tests entre les deux.
Debian ne saute pas non plus de version. Seule la mise à niveau depuis la version précédente est prise en charge : un serveur en Debian 11 passe d'abord en 12, puis en 13.

Rien ne presse sur un VPS en Ubuntu 24.04, couvert jusqu'en 2029. Un serveur en Debian 12, lui, ne reçoit plus que les correctifs de l'équipe LTS, sur un périmètre plus restreint : planifiez le passage en Debian 13 calmement, plutôt que dans l'urgence en 2028.

Mise à niveau en place ou nouveau serveur ?

La méthode la plus sûre pour une production n'est pas toujours la mise à niveau en place. Vous avez deux options :

Mise à niveau en place (do-release-upgrade ou apt full-upgrade) : rapide, garde l'adresse IP et la configuration, mais le service est coupé pendant l'opération et le retour arrière passe par une restauration.
Nouveau VPS installé en 26.04 ou 13, puis bascule : vous migrez les données, testez tranquillement, puis changez le DNS. L'ancien serveur reste intact et sert de retour arrière immédiat.

Pour un serveur simple, la mise à niveau en place suffit si la préparation est sérieuse. Avec beaucoup de dépôts tiers ou de vieux conteneurs, la réinstallation propre est souvent moins risquée.

La checklist avant de toucher à la prod

1. Un snapshot ET une vraie sauvegarde

Le snapshot du VPS, si votre hébergeur en propose, est le moyen le plus rapide de revenir en arrière : il fige le disque entier. Mais il est stocké sur la même infrastructure que le serveur et ne remplace pas une sauvegarde. Faites les deux :

un snapshot juste avant l'opération, services arrêtés ou au moins bases de données à l'arrêt, pour obtenir un état cohérent ;
une sauvegarde externe des données qui comptent, copiée hors du serveur : dumps des bases, /etc, les répertoires des sites, les volumes Docker, les crontabs.

# En root (sudo -i), adaptez à votre installation
mkdir -p /root/backup

# Dumps des bases
mysqldump --all-databases --single-transaction > /root/backup/mysql-all.sql
su - postgres -c pg_dumpall > /root/backup/pg-all.sql

# Configuration et liste des paquets installés
tar czf /root/backup/etc.tar.gz /etc
dpkg --get-selections '*' > /root/backup/paquets.txt
apt-mark showmanual > /root/backup/paquets-manuels.txt

Puis copiez /root/backup sur une autre machine (rsync, stockage objet, votre ordinateur). Une sauvegarde jamais restaurée reste une hypothèse : testez au moins un dump.

2. Vérifier cgroup v2 (bloquant pour Ubuntu 26.04)

C'est le changement qui fait le plus de dégâts cette année. systemd 259, livré avec Ubuntu 26.04, ne gère plus du tout cgroup v1 (hiérarchies legacy et hybrid). Selon les notes de version de Canonical :

une installation Ubuntu qui tourne en cgroup v1 ne pourra pas être mise à niveau en 26.04 ;
les charges conteneurisées en 26.04 ne tournent pas sur un hôte démarré en cgroup v1 ;
un hôte en 26.04 n'accepte plus les conteneurs qui exigent cgroup v1, par exemple les images Ubuntu antérieures à 18.04.

Ubuntu et Debian utilisent cgroup v2 par défaut depuis plusieurs versions, mais certains serveurs ont été forcés en v1 pour faire tourner de vieux conteneurs, d'anciennes versions de Docker ou des agents de supervision. Vérifiez :

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2, tout va bien
# tmpfs      -> cgroup v1 ou hybride, à corriger avant la mise à niveau

grep -o 'systemd.unified_cgroup_hierarchy=[0-9]' /proc/cmdline
grep -n 'cgroup' /etc/default/grub /etc/default/grub.d/* 2>/dev/null

Si un paramètre systemd.unified_cgroup_hierarchy=0 traîne dans la configuration de GRUB, retirez-le, lancez sudo update-grub, redémarrez, et vérifiez que vos conteneurs fonctionnent toujours avant la mise à niveau. Côté Docker, listez les conteneurs et leurs images avec docker ps -a et repérez les distributions très anciennes : une image dont le systemd interne date d'avant cgroup v2 est à remplacer, pas à contourner : systemd 259 ne sait plus démarrer en cgroup v1, il n'y a donc pas de réglage pour revenir en arrière en 26.04.

Sur Debian 13, systemd 257 considère déjà cgroup v1 comme obsolète : la même vérification vous évitera une mauvaise surprise lors du passage suivant.

3. Recenser les dépôts tiers

Docker, PHP d'un dépôt externe, Node.js, PPA divers : ce sont eux qui cassent les mises à niveau. Listez-les :

ls /etc/apt/sources.list.d/
grep -rhE '^(deb|URIs|Suites)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Pour chacun, vérifiez qu'il publie bien une version pour la cible (resolute pour Ubuntu 26.04, trixie pour Debian 13). Le dépôt officiel de Docker, par exemple, prend en charge Ubuntu 26.04 et Debian 13. do-release-upgrade désactive les dépôts tiers pendant l'opération ; sous Debian, c'est à vous de le faire. Dans tous les cas, notez-les pour les réactiver ensuite.

4. Les paquets bloqués

apt-mark showhold

Un paquet essentiel mis en hold fait échouer la mise à niveau. Les notes de Debian recommandent de retirer les holds avant de commencer (sudo apt-mark unhold paquet), sauf pour un paquet que vous avez recompilé vous-même.

5. Espace disque, accès de secours et fenêtre de maintenance

Gardez plusieurs Go libres sur / et vérifiez /boot : df -h / /boot. Sous Debian, apt -o APT::Get::Trivial-Only=true full-upgrade estime la place nécessaire une fois les nouvelles sources en place.
Repérez l'accès console de secours de votre hébergeur (console VNC ou équivalent dans l'espace client) : c'est elle qui vous sauvera si le réseau ne remonte pas après le redémarrage.
Travaillez dans tmux ou screen : si votre connexion SSH tombe, la mise à niveau continue et vous vous rattachez à la session.
Prévenez vos utilisateurs, baissez à l'avance le TTL de vos enregistrements DNS si vous envisagez une bascule, et choisissez un créneau calme.

6. Écrire le plan de retour arrière

Décidez avant de commencer, pas pendant : « si les services ne sont pas revenus au bout de X minutes, je restaure le snapshot ». Notez où se trouve la restauration, combien de temps elle prend et ce que vous perdez (les écritures faites après le snapshot).

Ubuntu 24.04 vers 26.04, étape par étape

Depuis la sortie de 26.04.1, la mise à niveau est proposée normalement : l'option -d, qui servait à forcer le passage avant l'ouverture officielle, n'est plus nécessaire.

# 1. Mettre la 24.04 parfaitement à jour, puis redémarrer si un noyau a été installé
sudo apt update && sudo apt full-upgrade
sudo reboot

# 2. Vérifier l'outil et la politique de mise à niveau
sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades   # doit afficher Prompt=lts

# 3. Lancer la mise à niveau dans tmux
tmux new -s upgrade
sudo do-release-upgrade

Lancé en SSH, l'outil propose d'ouvrir un second démon SSH sur un autre port en secours ; si vous l'acceptez, ouvrez temporairement ce port dans votre pare-feu. Aux questions sur les fichiers de configuration, conservez votre version en cas de doute et comparez ensuite avec le fichier .dpkg-dist.

Si vous partez d'Ubuntu 22.04, la même commande vous amène en 24.04. Redémarrez, vérifiez vos services, puis relancez do-release-upgrade pour atteindre 26.04.

Ce qui change sur un serveur Ubuntu 26.04

Noyau 7.0 et systemd 259 ; 26.04 est la dernière version à accepter les scripts System V : migrez-les vers des unités systemd.
sudo-rs remplace sudo par défaut ; l'ancien sudo reste disponible sous le nom sudo.ws. Testez vos scripts et vos playbooks qui utilisent des options de sudoers peu courantes.
rust-coreutils fournit désormais les utilitaires de base. Canonical continue de fournir les outils GNU pour les cas d'incompatibilité : testez vos scripts shell.
/tmp en tmpfs par défaut : ce qui était stocké dans /tmp consomme maintenant de la RAM et disparaît au redémarrage.
OpenSSH 10.2 : les clés DSA ne sont plus prises en charge.
Chrony devient le service de temps des nouvelles installations ; sur un serveur mis à niveau, la migration est manuelle (sudo apt-mark auto systemd-timesyncd puis sudo apt install chrony).
Apache et mod_php : l'unité systemd d'Apache active MemoryDenyWriteExecute=yes, ce qui casse le JIT de PHP avec libapache2-mod-php. Canonical recommande de passer à php-fpm, ou à défaut de désactiver l'option avec sudo systemctl edit apache2.
PostgreSQL : Canonical signale une régression de performances avec le noyau 7.0 et recommande d'activer les huge pages.
Versions : PHP 8.5, MySQL 8.4 LTS. Relisez les notes de migration de vos applications.

Debian 12 vers Debian 13, étape par étape

Debian n'a pas d'équivalent à do-release-upgrade : on change les sources APT, puis on met à niveau en deux temps.

# 1. Mettre la Debian 12 à jour (dont le correctif OpenSSH pour les mises à niveau à distance)
sudo apt update && sudo apt full-upgrade
sudo reboot

Les notes de version signalent qu'une coupure de la session SSH pendant la mise à niveau pouvait rendre le serveur inaccessible avec l'OpenSSH d'origine de bookworm : assurez-vous d'avoir au moins la version 1:9.2p1-2+deb12u7 (dpkg -l openssh-server), puis travaillez dans tmux.

Ensuite, passez les sources au format deb822 recommandé par Debian 13 : un seul fichier /etc/apt/sources.list.d/debian.sources, en retirant l'ancien /etc/apt/sources.list.

sudo mv /etc/apt/sources.list /root/backup/sources.list.bookworm
sudo tee /etc/apt/sources.list.d/debian.sources <<'EOF'
Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF

Ajoutez contrib ou non-free à la ligne Components si votre ancienne configuration les utilisait. Désactivez les dépôts tiers (renommez leurs fichiers en .disabled) et retirez les entrées bookworm-backports-sloppy, pour lesquelles Debian ne prévoit pas de chemin de mise à niveau propre.

# 2. Mise à niveau minimale, puis complète
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

Avant de redémarrer, vérifiez le nom de votre interface réseau : le passage à systemd 257 peut changer le nom généré pour certaines cartes, et un VPS dont l'interface change de nom redémarre sans réseau. Les notes de version donnent la commande à lancer juste avant le redémarrage :

ip -br link
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Remplacez eth0 par le nom affiché par ip -br link. Si ID_NET_NAME diffère du nom actuel, adaptez /etc/network/interfaces ou figez le nom avec un fichier .link de systemd avant de redémarrer. Vérifiez aussi qu'un métapaquet de noyau est installé (dpkg -l 'linux-image*' | grep ^ii | grep -i meta).

Après le redémarrage, faites le ménage et convertissez les sources restantes :

sudo apt modernize-sources   # convertit les fichiers .list restants au format deb822
sudo apt autoremove
apt list '?obsolete'          # paquets qui ne viennent plus d'aucun dépôt

Debian 13 indique aussi que les chemins de trousseaux en .gpg ne sont plus que des liens de compatibilité vers les fichiers .pgp : une fois la mise à niveau terminée, vous pouvez remplacer debian-archive-keyring.gpg par debian-archive-keyring.pgp dans vos sources.

Ce qui change sur un serveur Debian 13

Noyau 6.12, OpenSSH 10.0 (plus de clés DSA), OpenSSL 3.5, PHP 8.4, PostgreSQL 17, MariaDB 11.8, Nginx 1.26, Python 3.13.
/tmp passe en tmpfs (jusqu'à 50 % de la RAM par défaut), et /tmp et /var/tmp sont nettoyés régulièrement : un service qui y laisse des fichiers durables doit être déplacé.
i386 n'est plus une architecture complète : ne mettez pas à niveau un serveur 32 bits.

Après le redémarrage : les vérifications

lsb_release -a               # bonne version ?
systemctl --failed           # aucun service en échec ?
journalctl -p err -b         # erreurs depuis le démarrage
ss -tlnp                     # les ports attendus écoutent-ils ?
stat -fc %T /sys/fs/cgroup/  # cgroup2fs
docker ps -a                 # conteneurs relancés ?

Réactivez ensuite les dépôts tiers avec le nom de la nouvelle version. Pour Docker, il suffit en général de mettre Suites: resolute (Ubuntu 26.04) ou Suites: trixie (Debian 13) dans /etc/apt/sources.list.d/docker.sources, puis sudo apt update && sudo apt full-upgrade. Testez enfin vos sites et API depuis l'extérieur, vos tâches cron, vos sauvegardes automatiques et le renouvellement des certificats (sudo certbot renew --dry-run si vous utilisez Certbot).

Si ça casse : le retour arrière

Le serveur ne répond plus : passez par la console de secours de l'hébergeur. La cause la plus fréquente est le réseau (nom d'interface, Netplan) ou le pare-feu.
Un service ne démarre plus : journalctl -u service -b donne presque toujours la raison (option de configuration supprimée, module PHP absent, version de base de données).
La situation n'est pas réglée dans le délai que vous vous étiez fixé : restaurez le snapshot, remettez le service en ligne et analysez à froid sur une copie. Il n'existe pas de « downgrade » propre d'une distribution : le retour arrière, c'est le snapshot ou la sauvegarde.

FAQ

Peut-on passer directement d'Ubuntu 22.04 à 26.04 ?

Non. Canonical impose de passer d'abord par 24.04 LTS (ou 25.10). Sur un serveur, faites deux mises à niveau successives avec des tests entre les deux.

Pourquoi do-release-upgrade répond-il qu'aucune nouvelle version n'est disponible ?

Vérifiez Prompt=lts dans /etc/update-manager/release-upgrades et que la 24.04 est entièrement à jour. Retenez aussi qu'un système qui tourne en cgroup v1 n'est pas autorisé à passer en 26.04 : passez d'abord en cgroup v2.

Debian 12 est-il encore sûr en production ?

Il reçoit des correctifs de sécurité de l'équipe LTS jusqu'au 30 juin 2028, mais sur un périmètre de paquets plus restreint. Il reste utilisable, mais planifiez le passage en Debian 13.

Mes vieux conteneurs Docker vont-ils fonctionner sur Ubuntu 26.04 ?

Ceux qui exigent cgroup v1, comme les images Ubuntu antérieures à 18.04, ne fonctionneront plus. Mettez à jour ces images avant la mise à niveau, sur un serveur de test si possible.