Ce qui s'arrête en mai-juin 2027
Ubuntu 22.04 LTS est sortie en avril 2022. Sa maintenance de sécurité standard s'achève en mai 2027 selon la page ubuntu.com/about/release-cycle, et endoflife.date donne le 1er juin 2027 pour la même échéance. Écrivez « mai-juin 2027 » dans vos plannings et visez le début de la fenêtre, pas son dernier jour.
Passé la date, une faille corrigée par Canonical ne l'est plus pour vous, sauf abonnement Ubuntu Pro, qui prolonge la maintenance de sécurité jusqu'en 2032 (le mois exact varie d'une source à l'autre : avril pour endoflife.date, mai pour ubuntu.com, d'où l'année seule). Le coût réel de la migration n'est pas la licence, c'est le temps : une fenêtre d'intervention, un clone d'essai et une validation site par site.
Pour un parc, l'échéance se lit en trois colonnes : combien de serveurs tournent encore en 22.04, lesquels portent cPanel, lesquels sont de simples VPS applicatifs. Chaque colonne a sa procédure. Le calendrier complet des fins de vie 2027 est dans notre calendrier des fins de vie 2027 : ici, on ne traite que cette ligne.
Ce que ce guide vous permet de faire
- Dater l'échéance sans se tromper — mai 2027 pour Canonical, 1er juin 2027 pour endoflife.date : on planifie avant la fenêtre.
- Choisir client par client — montée en place, ELevate ou serveur neuf, selon des critères mesurables et non par habitude.
- Savoir ce que cPanel impose — dépréciation en version 132, retrait en version 136, et pourquoi
do-release-upgradene se lance pas à la main sur un serveur cPanel. - Disposer d'un filet réel — une image du serveur déjà restaurée une fois, pas une promesse de sauvegarde.
- Anticiper les ruptures — dépôts tiers désactivés, PHP, nginx, SSH, services retirés pendant la montée.
- Garder un retour arrière — un point de non-retour nommé et une restauration planifiée avant d'appuyer sur Entrée.
cPanel & WHM : 22.04 déprécié en 132, retiré en 136
La page « deprecation plan » de la documentation cPanel range Ubuntu 22.04 LTS parmi les fonctionnalités dépréciées puis retirées : dépréciation en version 132, retrait en version 136, avec la consigne « Use ELevate to upgrade to Ubuntu 24.04 LTS ». La page ne donne aucune date de sortie pour ces versions et nous n'en avançons pas : suivez le calendrier de versions de cPanel plutôt qu'une date lue sur un site tiers. Elle ne dit pas non plus si une montée en place hors ELevate est supportée.
Côté ELevate, la consigne est nette : cet outil enveloppe do-release-upgrade parce que lancer l'outil de distribution directement sur une installation cPanel la rend inutilisable. Sur un serveur cPanel, la documentation cPanel indique ELevate ; l'autre voie est un serveur neuf sous 24.04 vers lequel on transfère les comptes. Un simple VPS applicatif sans panneau, lui, suit la procédure standard d'Ubuntu.
Montée en place ou serveur neuf : le critère de décision
La montée en place garde l'adresse IP, les comptes et la configuration. Elle échoue là où le serveur s'est éloigné d'une installation standard. Le serveur neuf coûte un transfert de comptes, mais laisse l'ancienne machine intacte jusqu'à la bascule DNS : c'est le seul scénario où le retour arrière se résume à ne pas basculer.
Tranchez avec quatre questions. Votre sauvegarde couvre-t-elle tout le système ? Les sauvegardes de comptes cPanel ne protègent que les données gérées par cPanel, pas les programmes ni les réglages du système : après un échec, il faudrait réinstaller l'OS, cPanel, puis restaurer les comptes. Quelle interruption le client accepte-t-il ? ELevate peut dépasser 30 minutes et redémarre le serveur plusieurs fois. Combien de personnalisations vivent hors des paquets (dépôts tiers, PHP compilé à la main, scripts) ? Chacune est une inconnue pendant la montée. Enfin, le serveur est-il décrit dans du code, Ansible ou autre ? Si oui, le reconstruire est plus rapide que le réparer.
Règle pratique : serveur historique, très personnalisé ou dont la sauvegarde n'a jamais été restaurée, passez par un serveur neuf. Serveur standard, image restaurée avec succès, fenêtre acceptée, montez en place.
Quelle voie pour quel serveur
Faites défiler le tableau
| Situation du serveur | Voie recommandée | Pourquoi |
|---|---|---|
| VPS applicatif sous 22.04, sans panneau, peu de dépôts tiers | Montée en place avec `do-release-upgrade` | Procédure standard d'Ubuntu, retour arrière par restauration de l'image |
| VPS applicatif décrit dans du code (Ansible, Compose) | Serveur neuf sous 24.04 | Reconstruire coûte moins que réparer, l'ancien reste intact jusqu'à la bascule |
| Serveur cPanel standard, image système restaurable | Montée en place avec ELevate | Montée en place via ELevate, l'outil que la documentation cPanel indique, avec détection des bloqueurs avant de commencer |
| Serveur cPanel très personnalisé ou sauvegarde jamais restaurée | Serveur neuf et transfert des comptes | Les sauvegardes de comptes ne couvrent pas le système ; le transfert garde la source intacte |
| Sites en PHP antérieur à 8.1 sur le serveur cPanel | Serveur neuf, ou migrer d'abord les sites | ELevate se bloque si un utilisateur emploie une version de PHP trop ancienne |
| Serveur en environnement de type conteneur | Serveur neuf | ELevate refuse de tourner dans un environnement de type conteneur |
Prérequis chiffrés avant de lancer quoi que ce soit
Pour un VPS standard, la documentation Ubuntu demande un système entièrement à jour, de la place pour plusieurs gigaoctets de téléchargement et une personne présente : la montée est interactive et peut durer plusieurs heures. Prévoyez une console hors bande (console web ou VNC du fournisseur) au cas où SSH ne reviendrait pas.
Pour un serveur cPanel, ELevate publie ses seuils d'espace libre : 5 Go sur /, 120 Mo sur /boot, 750 Mo sur /tmp pour Ubuntu, 1,5 Go sur /usr/local/cpanel et 5 Go sur /var/lib. Il exige un accès root interactif, une licence cPanel valide, la dernière version mineure de la version de cPanel attendue pour votre système (la documentation ELevate demande la version 134 en partant d'Ubuntu 22 : relisez ce prérequis le jour J) et JetBackup 5 ou plus si vous l'utilisez. Ni upcp ni une sauvegarde cPanel ne doivent tourner pendant le démarrage. Et prévoyez plusieurs accès au serveur : SSH, console du fournisseur, et si possible IPMI.
Procédure pour un VPS applicatif, sans panneau
Faire l'inventaire
Notez la version du système avec
lsb_release -a, les sources APT tierces avecls /etc/apt/sources.list.d/, puis les versions de ce qui sert vos sites :php -v,nginx -v,mysql --version. Cette liste devient votre plan de test.Sauvegarder, puis restaurer une fois
Prenez une image du VPS chez le fournisseur et restaurez-la sur une machine de test : une sauvegarde jamais restaurée est une hypothèse. Doublez-la d'une copie hors serveur des bases, des volumes et de
/etc. Notre guide sauvegardes Restic sur VPS détaille la mise en place.Monter d'abord un clone
Créez un VPS d'essai depuis l'image et déroulez toute la procédure dessus. Relevez chaque question posée par l'outil, chaque service en échec et chaque dépôt désactivé. La montée de production ne doit plus réserver de surprise.
Mettre 22.04 entièrement à jour
Lancez
sudo apt updatepuissudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true, comme le prescrit la documentation Ubuntu Server. Si le fichier/run/reboot-requiredexiste, redémarrez avant de continuer.Ouvrir une session qui survit à une coupure
Lancez
tmux new -s montee(ouscreen) avant la montée, pour que la perte de la connexion SSH n'interrompe pas le travail en cours. Gardez la console du fournisseur ouverte dans un autre onglet.Lancer la montée
Vérifiez d'abord qu'une version est proposée avec
do-release-upgrade -c, puis exécutezsudo do-release-upgrade. L'outil résume ce qu'il va faire et demande confirmation. Avertissement de la documentation : une fois le téléchargement terminé, le processus ne peut plus être annulé. C'est votre point de non-retour, et c'est ensuite la restauration de l'image qui sert de retour arrière.Répondre aux questions, redémarrer, réactiver
Pour chaque fichier de configuration que vous avez modifié, gardez votre version par défaut, sauf pour les fichiers nécessaires au démarrage du nouveau noyau. Redémarrez quand l'outil le demande, car le système n'est considéré comme monté qu'après ce redémarrage. Réactivez ensuite les dépôts tiers désactivés, en les réécrivant pour 24.04, puis rejouez votre plan de test.
Procédure pour un serveur cPanel avec ELevate
Vérifier le point de départ
Contrôlez la licence cPanel, la version de cPanel & WHM attendue par la documentation ELevate et la dernière version mineure installée. Mettez les paquets du système à jour avec
apt upgrade. Vérifiez que la version de MySQL ou de MariaDB est compatible avec Ubuntu 24.04.Prendre une image complète du serveur
ELevate ne fait aucune sauvegarde avant de monter. Faites un instantané du serveur entier et testez sa restauration : c'est le seul retour arrière que la documentation ELevate décrit en cas d'échec grave.
Télécharger le script
Exécutez
wget -O /scripts/elevate-cpanel https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanelpuischmod 700 /scripts/elevate-cpanel. Le script doit tourner depuis/scriptset être à jour.Lancer le contrôle à blanc
/scripts/elevate-cpanel --checkne modifie rien et liste les bloqueurs connus : espace disque, fichiersshd_config, PHP trop ancien, une version de JetBackup antérieure à la 5, environnement de conteneur, noms d'interfaces réseau enethX. Relancez-le jusqu'à obtenir un rapport vide.Lever les bloqueurs un par un
Retirez ou migrez les sites qui emploient une version de PHP antérieure à 8.1, laissez le temps à
upcpet aux sauvegardes de se terminer, libérez de l'espace. Si cPanel gère votre MySQL, l'outil propose de passer à MariaDB pendant la montée : décidez-le avec le client, avant la fenêtre.Démarrer et surveiller
Lancez
/scripts/elevate-cpanel --start. Le processus avance en cinq étapes avec un redémarrage entre chacune et un dernier à la fin, sur plus de 30 minutes de serveur injoignable. Suivez-le avec/scripts/elevate-cpanel --statuset/scripts/elevate-cpanel --log. Si le processus s'arrête sur une erreur, corrigez-la puis exécutez/scripts/elevate-cpanel --continue.Valider après la montée
Ouvrez WHM, contrôlez les services, les sites de chaque compte, l'envoi et la réception du courrier, et les tâches planifiées. Les sites doivent être testés sous le PHP qu'ils emploient réellement, pas seulement sur leur page d'accueil.
Ce qui casse entre 22.04 et 24.04, d'après les notes de version
Ce paragraphe reprend les notes de version d'Ubuntu 24.04 LTS, pas un essai de notre côté sur votre pile. D'abord, les dépôts tiers et les PPA sont désactivés pendant la montée, ce qui laisse Docker, PHP ou un agent de supervision sur l'ancienne source jusqu'à réécriture. Les sources d'Ubuntu passent au format deb822, dans /etc/apt/sources.list.d/ubuntu.sources.
Côté web, nginx passe à la version 1.24 (la précédente LTS livrait la 1.18), Apache à la 2.4.58 et PHP à la 8.3.6, là où 22.04 fournit PHP 8.1. Un site qui dépend d'une fonction retirée entre ces versions de PHP se découvre à l'exécution, pas à la montée. La version 3.12 de Python devient la valeur par défaut, ce qui concerne vos scripts d'administration.
Pour la connexion, la configuration de sshd_config est désormais lue par un générateur systemd qui pilote l'unité ssh.socket : vérifiez le port d'écoute après la montée. needrestart redémarre les services touchés par une mise à jour de bibliothèque, y compris pendant les mises à jour automatiques. TLS 1.0, TLS 1.1 et DTLS 1.0 sont désactivés de force, ce qui peut couper un vieux client de messagerie. Enfin, le paquet freeradius est retiré par l'outil de montée sans toujours apparaître dans le résumé.
À tester sur le clone avant la fenêtre client
- Dépôts tiers — chaque source désactivée doit être réactivée pour 24.04, et sa clé gérée sans
apt-key. - Sites PHP — rejouez les pages critiques de chaque site sous PHP 8.3 : formulaires, paiement, tâches planifiées.
- nginx et Apache — lancez
nginx -taprès la montée et comparez les vhosts, les modules et les redirections. - SSH — contrôlez le port et l'accès par clé avec une seconde session ouverte avant de fermer la première.
- Courrier — envoyez et recevez, y compris depuis un vieux client que TLS 1.0 ou 1.1 ferait échouer.
- Services retirés — comparez
apt list --installedavant et après pour repérer un paquet disparu, commefreeradius. - Tâches planifiées et sauvegardes — une sauvegarde qui échoue en silence après la montée est la panne la plus coûteuse.
Écrire le retour arrière avant la fenêtre
Notez par écrit, avant d'agir, qui restaure l'image, en combien de temps, et à partir de quel symptôme on renonce. La restauration est le seul retour arrière dès que la montée a dépassé son point de non-retour : décidez-en le seuil à froid, pas à 2 h du matin. Préférez une fenêtre où le client peut valider le lendemain matin.
Après 24.04 : le chemin vers 26.04 passe par là
La documentation Ubuntu interdit de sauter une LTS : on monte d'une LTS à la suivante, et la montée 22.04 vers 24.04 est donc l'étape obligatoire avant 26.04. Ubuntu 24.04 reste maintenue en sécurité standard jusqu'en mai 2029 : une fois montés, vos serveurs n'ont plus d'urgence. La montée de 24.04 vers 26.04.1 est ouverte depuis le 29 septembre 2026, ce qui vous laisse le choix du moment ; elle est détaillée dans notre guide Ubuntu 24.04 vers 26.04 sur VPS.
Le même raisonnement, en autre panneau, est dans notre guide Debian 11 en fin de vie avec Plesk. Pour un parc, regroupez par client : une fenêtre d'intervention qui traite système, PHP et base de données coûte moins cher que trois passages.
