Ubuntu 26.04 LTS : faut-il migrer vos serveurs ?

Ubuntu 26.04 LTS est la nouvelle édition à support étendu de la distribution Canonical. Pour un administrateur système, l’arrivée d’une LTS n’est pas seulement une occasion de disposer de paquets plus récents : c’est surtout un point de décision pour la sécurité, la compatibilité logicielle, le cycle de vie des serveurs et les procédures d’exploitation.

La bonne question n’est donc pas « faut-il installer Ubuntu 26.04 LTS partout ? », mais plutôt : quels serveurs ont un bénéfice concret à migrer maintenant, lesquels doivent attendre, et comment réduire le risque pendant l’opération ? Sur un VPS applicatif, un serveur dédié de bases de données ou un hôte de virtualisation, la réponse dépend beaucoup plus des dépendances que de la liste des nouveautés.

Ce guide propose une méthode pragmatique pour décider et préparer une migration vers Ubuntu 26.04 LTS, sans sacrifier la disponibilité ni la capacité de retour arrière.

Ce que change Ubuntu 26.04 LTS pour les infrastructures professionnelles

Le premier intérêt d’une version LTS est son cycle de maintenance. Canonical indique que les versions Ubuntu LTS bénéficient d’un support de sécurité standard pendant cinq ans. Ce cadre donne de la visibilité aux équipes qui exploitent des serveurs sur plusieurs années, notamment lorsque les applications métier, les procédures de conformité ou les contrats clients rendent les changements fréquents coûteux.

Ubuntu 26.04 LTS apporte un environnement logiciel plus récent que les générations LTS précédentes : noyau Linux, chaîne de compilation, bibliothèques système, langages, outils de conteneurisation et composants d’administration évoluent avec la distribution. Cela peut être utile dans plusieurs cas concrets :

un serveur qui doit prendre en charge un matériel ou des pilotes plus récents ;
une application qui dépend d’une version récente de Python, PHP, Java, Node.js ou PostgreSQL ;
une plateforme de conteneurs qui doit rester compatible avec les versions maintenues de Docker, containerd ou Kubernetes ;
un environnement qui arrive à la fin du support de son système actuel ;
une infrastructure qui cherche à homogénéiser ses images système et ses pipelines de déploiement.

Il faut toutefois distinguer le système hôte de l’application. Une distribution plus récente n’améliore pas automatiquement les performances d’un site web, d’une API ou d’une base de données. Une migration peut même introduire des écarts de comportement : modification de versions majeures, politiques cryptographiques plus strictes, changement dans les services systemd, renommage ou retrait de paquets.

Pour un VPS moderne, le gain le plus immédiat est souvent la durée de support restante. Pour un serveur dédié récent, la compatibilité matérielle et les correctifs du noyau peuvent être déterminants. À l’inverse, pour un serveur stable dont la pile applicative est figée et pleinement maintenue, l’urgence est rarement technique.

Les organisations qui ont besoin d’une durée de maintenance plus longue peuvent aussi examiner Ubuntu Pro. Cette offre de Canonical inclut notamment une couverture de sécurité étendue pour davantage de paquets. Elle ne remplace pas une stratégie de migration : elle peut en revanche donner du temps lorsqu’un logiciel métier ne peut pas être mis à niveau à court terme.

Ne confondez pas disponibilité de la LTS et obligation de migrer

Le fait qu’Ubuntu 26.04 LTS soit disponible ne signifie pas que tous les serveurs doivent être mis à niveau immédiatement. En production, une LTS est une cible de standardisation, pas un ordre de déploiement.

La première étape consiste à classer les machines selon leur rôle et leur criticité. Un serveur de préproduction, un runner CI, un bastion, un serveur web stateless et une base de données transactionnelle ne se migrent ni au même rythme, ni avec le même niveau de contrôle.

Les cas où une migration est pertinente rapidement

Une migration dans les premiers mois peut être justifiée si votre système actuel approche de sa fin de support, si vous achetez de nouveaux serveurs, ou si un composant indispensable exige une base système plus récente. C’est aussi un bon choix pour les nouveaux VPS : démarrer directement sur la LTS actuelle évite une migration d’OS prématurée.

Les environnements de développement, de test et de recette sont les meilleurs premiers candidats. Ils permettent de valider les images, les scripts Ansible, les rôles Terraform, les agents de supervision et les procédures d’installation sans mettre le service client en danger.

Les cas où il vaut mieux attendre

Attendre est raisonnable lorsqu’un serveur héberge une application ancienne, un éditeur métier qui ne certifie pas encore la nouvelle distribution, un module propriétaire, un pilote particulier ou une pile fortement personnalisée. Un serveur critique qui fonctionne correctement sous une LTS encore maintenue n’a pas à être transformé en environnement de test.

Il est également prudent de différer une migration lorsqu’elle tombe dans une période commerciale sensible : fin de mois, soldes, clôture comptable, lancement produit ou pic saisonnier. La fenêtre de maintenance doit être choisie selon le coût réel d’une indisponibilité, pas selon la date de publication de l’OS.

Une LTS est conçue pour durer. Vous disposez donc d’une fenêtre de décision : utilisez-la pour tester sérieusement plutôt que pour accélérer une bascule non maîtrisée.

Si votre besoin est avant tout de choisir une nouvelle machine ou de redimensionner l’existant, consultez aussi notre checklist pour choisir un VPS et notre guide VPS ou serveur dédié. La capacité CPU, la mémoire, le stockage et le niveau d’accès administrateur influencent directement la manière de préparer la migration.

Vérifier la compatibilité avant toute mise à niveau

Le risque principal d’une montée de version n’est pas Ubuntu elle-même : ce sont les dépendances installées autour d’elle. Avant de planifier une intervention, construisez un inventaire réel de chaque serveur. Évitez de vous fier uniquement à la documentation historique ou à une liste de paquets exportée il y a plusieurs mois.

Sur chaque machine, documentez au minimum :

la version d’Ubuntu actuellement installée et le noyau en cours d’utilisation ;
les services exposés : Nginx, Apache HTTP Server, HAProxy, PostgreSQL, MariaDB, Redis, RabbitMQ, etc. ;
les versions des runtimes applicatifs et des frameworks ;
les dépôts APT activés, y compris les PPA et dépôts d’éditeurs ;
les paquets installés manuellement et les services systemd personnalisés ;
les conteneurs, images et volumes présents si Docker ou Podman sont utilisés ;
les agents de sauvegarde, de sécurité et de supervision ;
les règles de pare-feu, certificats TLS, tâches cron et scripts maison ;
les connexions externes : SMTP, stockage objet, API de paiement, LDAP, Active Directory ou VPN.

Les dépôts tiers méritent une attention particulière. Pendant une mise à niveau majeure, un dépôt non compatible peut bloquer APT, introduire des conflits de dépendances ou installer un paquet non prévu. Il faut vérifier sur le site de chaque éditeur que son dépôt cible bien Ubuntu 26.04 LTS. En cas de doute, désactivez temporairement le dépôt dans l’environnement de recette et prévoyez une méthode d’installation compatible.

Les PPA sont encore plus sensibles. Ils sont pratiques pour tester un logiciel, mais constituent rarement une dépendance idéale pour un serveur de production. Si un paquet essentiel provient d’un PPA, cherchez une source maintenue par l’éditeur, un paquet officiel de la distribution ou un déploiement conteneurisé documenté.

Enfin, testez les changements de comportement, pas uniquement le démarrage des démons. Une application peut répondre en HTTP tout en échouant sur les tâches asynchrones, les envois d’e-mails, l’authentification SSO, les requêtes SQL spécifiques ou la rotation de journaux.

Contrôler les outils d’administration, de sécurité et de supervision

Un serveur est rarement administré avec les seuls outils du système. Les agents installés par l’équipe infrastructure ou par l’hébergeur font partie du périmètre de migration. Il serait contre-productif de réussir la mise à niveau d’un VPS tout en perdant la sauvegarde automatique, les alertes ou l’accès d’administration distant.

Vérifiez la compatibilité de vos outils de gestion de configuration, par exemple Ansible, Puppet, Salt ou Chef. Rejouez les playbooks et les rôles dans une machine de test fraîchement installée sous Ubuntu 26.04 LTS. Cette approche révèle les paquets renommés, les dépôts manquants et les hypothèses implicites présentes dans les scripts.

Faites de même pour l’observabilité. Selon votre stack, cela peut inclure Zabbix, Centreon, Prometheus avec node_exporter, Grafana, Datadog, New Relic ou Elastic Agent. Après migration, vérifiez que :

l’agent démarre automatiquement après un redémarrage ;
les métriques CPU, mémoire, disque et réseau remontent ;
les journaux sont toujours centralisés ;
les alertes de disponibilité et de capacité fonctionnent ;
les tableaux de bord ne présentent pas de trou de données.

La surveillance est particulièrement importante au cours des premières heures suivant la bascule. Retrouvez des repères de choix dans notre article sur les outils de monitoring selon votre infrastructure, ainsi que dans notre sélection d’outils open source de supervision serveur.

Côté sécurité, contrôlez les mécanismes d’accès SSH, les clés administrateur, les politiques sudo, le pare-feu UFW ou nftables, Fail2ban si vous l’utilisez, ainsi que le renouvellement des certificats Let’s Encrypt via Certbot. Une vérification post-migration doit confirmer qu’aucun port inattendu n’est exposé et que les journaux d’authentification restent exploitables.

Notre guide de durcissement Linux peut servir de contrôle complémentaire après l’opération. Une migration est un moment pertinent pour retirer les comptes obsolètes, désinstaller les services inutiles et formaliser les règles de sécurité, à condition de ne pas mélanger trop de changements dans la même fenêtre critique.

Choisir entre mise à niveau sur place et nouveau serveur

Deux approches sont possibles : effectuer une mise à niveau sur place ou déployer un nouveau serveur sous Ubuntu 26.04 LTS, puis y basculer la charge. Le meilleur choix dépend de l’architecture, du niveau de dette technique et du besoin de retour arrière.

La mise à niveau sur place

La montée de version en place conserve la machine, son adressage, une grande partie de sa configuration et ses données. Elle peut être adaptée à un VPS simple, correctement documenté, avec peu de services et une procédure de restauration éprouvée.

Elle reste néanmoins plus difficile à diagnostiquer si le serveur a accumulé des années de paquets, de fichiers de configuration modifiés et de dépôts tiers. Avant de lancer l’outil de mise à niveau recommandé par Ubuntu, appliquez tous les correctifs de la version actuelle, supprimez les paquets devenus inutiles et lisez attentivement les demandes de remplacement de configuration.

Ne comptez pas sur un saut de plusieurs générations LTS. Les chemins de mise à niveau pris en charge doivent être suivis dans l’ordre indiqué par la documentation officielle d’Ubuntu Server. Une machine ancienne peut nécessiter une ou plusieurs étapes intermédiaires.

La migration vers une nouvelle instance

Le déploiement d’un nouveau VPS ou d’un nouveau serveur dédié est souvent plus propre. Vous installez Ubuntu 26.04 LTS sur une base vierge, appliquez l’infrastructure as code, restaurez les données nécessaires, testez les flux, puis basculez le trafic par DNS, proxy inverse ou équilibrage de charge.

Cette méthode simplifie le retour arrière : l’ancien serveur reste disponible tant que vous ne l’avez pas décommissionné. Elle est particulièrement adaptée aux applications web stateless, aux architectures conteneurisées et aux environnements où une réplication de base de données peut être organisée.

Son coût est temporairement plus élevé, car deux environnements coexistent. En contrepartie, elle réduit le risque d’un état intermédiaire impossible à réparer rapidement. Pour des systèmes critiques, ce surcoût est souvent plus faible que le coût d’une indisponibilité prolongée.

Plan de migration sécurisé : sauvegardes, recette, bascule et retour arrière

Une migration sûre se prépare comme un changement de production à part entière. Le mot clé est réversibilité. Vous devez savoir quoi faire si le service démarre mais répond mal, si un connecteur tiers échoue ou si les performances se dégradent.

1. Produire des sauvegardes réellement restaurables

Réalisez une sauvegarde complète avant toute action. Selon le serveur, elle peut inclure un snapshot fourni par l’hébergeur, une image disque, une sauvegarde de fichiers, un export de base de données et une copie des secrets hors du serveur. Un snapshot est utile, mais il ne remplace pas une stratégie de sauvegarde indépendante.

Pour PostgreSQL, un export effectué avec les outils adaptés fait partie des vérifications classiques ; pour MariaDB ou MySQL, utilisez une méthode cohérente avec votre volume de données et vos exigences de disponibilité. Les volumes Docker, répertoires de configuration, certificats, clés SSH et fichiers d’environnement doivent être inclus dans le périmètre.

Surtout, testez une restauration. Une sauvegarde non restaurée est une hypothèse, pas une garantie. Mesurez le temps nécessaire pour remettre un service en état : cette information permet de décider si la fenêtre de maintenance est réaliste.

2. Créer une recette représentative

Clonez autant que possible la configuration de production dans un environnement isolé. Utilisez des données anonymisées lorsque cela est nécessaire. L’objectif est de reproduire les dépendances importantes : mêmes versions applicatives, mêmes services, mêmes règles réseau et mêmes scripts de déploiement.

Établissez une liste de tests de recette avant de migrer :

connexion SSH avec les comptes d’administration prévus ;
démarrage et redémarrage de tous les services ;
réponse des endpoints de santé et des pages clés ;
lecture et écriture en base de données ;
exécution des tâches planifiées et des workers ;
envoi d’e-mails ou d’événements vers les services tiers ;
collecte des logs, métriques et alertes ;
renouvellement ou lecture des certificats TLS ;
contrôle des performances sur les transactions ou requêtes importantes.

3. Préparer la bascule et les critères d’arrêt

Documentez une fenêtre de changement avec un responsable, des contacts, les commandes principales, la durée estimée et une communication utilisateur si une interruption est attendue. Prévoyez également des critères d’abandon explicites : par exemple, une base non disponible, des erreurs applicatives persistantes ou l’impossibilité de faire fonctionner la supervision.

Pour une migration vers une nouvelle instance, réduisez le TTL DNS à l’avance si votre stratégie de bascule repose sur le DNS, tout en gardant à l’esprit que la propagation n’est jamais instantanée partout. Pour une application placée derrière un proxy ou un load balancer, un basculement progressif peut offrir davantage de contrôle.

4. Exécuter les contrôles après migration

Après la mise à niveau ou la bascule, ne vous limitez pas à vérifier que la machine répond au ping. Contrôlez les versions attendues, les unités systemd en échec, l’espace disque, les journaux système et applicatifs, le pare-feu, les sauvegardes programmées et les tableaux de bord de supervision.

Surveillez le serveur pendant une période adaptée à votre activité. Certaines erreurs ne se déclenchent qu’avec les traitements nocturnes, la rotation des logs, une tâche de facturation, un renouvellement de certificat ou une charge plus importante.

Les points d’attention propres aux VPS et aux serveurs dédiés

Sur un VPS, vérifiez ce qui relève de votre responsabilité et ce qui est géré par le fournisseur : snapshots, console de secours, pare-feu réseau, adresses IP, sauvegardes automatisées et accès au mode rescue. Avant la migration, confirmez que vous pourrez accéder à une console hors SSH si la configuration réseau ou le démon SSH ne redémarre pas correctement.

Sur un serveur dédié, ajoutez la couche matérielle à votre plan : contrôleur RAID, disques, interfaces réseau, firmware, accès IPMI ou équivalent, et éventuels pilotes spécifiques. Une mise à niveau du système n’est pas le bon moment pour improviser une évolution de firmware. Séparez autant que possible les chantiers afin d’isoler les causes en cas d’incident.

Si le serveur héberge Proxmox VE, Kubernetes, une plateforme de bases de données ou une charge virtualisée importante, traitez la migration de l’hôte avec une prudence supplémentaire. Vérifiez les matrices de compatibilité des projets concernés et ne supposez pas qu’une nouvelle version d’Ubuntu est automatiquement validée pour tous les composants. Les sujets de virtualisation disposent de leurs propres cycles : notre article sur la planification d’une migration Proxmox VE illustre cette nécessité de dissocier les niveaux de changement.

Conclusion : migrer avec méthode, pas par réflexe

Ubuntu 26.04 LTS constitue une cible logique pour les nouveaux serveurs et pour les infrastructures qui ont besoin d’un socle maintenu sur la durée. Mais son adoption en production doit suivre une logique de risque : inventaire des dépendances, validation des dépôts et agents, recette représentative, sauvegardes testées et procédure de retour arrière.

Pour un VPS simple, la mise à niveau peut être une opération maîtrisable avec une préparation sérieuse. Pour un serveur dédié critique ou une plateforme complexe, le déploiement parallèle d’une nouvelle instance est souvent l’option la plus sûre. Prenez le temps de classer vos serveurs, de planifier les essais et d’intégrer Ubuntu 26.04 LTS à votre prochain cycle de maintenance plutôt que de transformer une nouveauté en urgence.