Rédigé par Rédaction CyberSDF / 15 septembre 2026

Ubuntu : installer et mettre à jour sans confondre avec Debian

Pour installer Ubuntu aujourd’hui, partez d’une image LTS; la 26.04 LTS publiée en avril 2026 ou la 24.04 LTS publiée en avril 2024, dont la maintenance de sécurité standard court jusqu’en mai 2029; vérifiez son empreinte SHA256, puis exécutez l’installateur Subiquity. Pour maintenir une installation existante, la séquence quotidienne documentée est sudo apt update puis sudo apt upgrade. Pour passer d’une LTS à la suivante sans sauter d’étape, le paquet ubuntu-release-upgrader fournit do-release-upgrade, lancé en mode server ou desktop. Ce qui suit décrit ces commandes: aucune n’est exécutée à votre place.

Mesures datées: 2026-09-15, Ubuntu 24.04.4 LTS « Noble Numbat », noyau 6.8.0-106-generic, apt 2.8.3, do-release-upgrade du paquet ubuntu-release-upgrader-core 1:24.04.28, snap 2.76+ubuntu24.04.1. La machine porte 43 paquets Ubuntu en attente via les dépôts officiels et un dépôt tiers (Tailscale 1.102.4 depuis pkgs.tailscale.com). Aucun paquet n’a été modifié pendant les mesures; les sorties ci-dessous proviennent de apt -s upgrade et apt-cache policy.

Quelle version LTS choisir en pratique ?

Pour un poste de travail, un serveur ou une machine de production, le critère tient en une ligne: installez la dernière LTS publiée. Le numéro suit l’année et le mois de sortie, en avril des années paires; 24.04 en avril 2024, 26.04 en avril 2026. Chaque version est annoncée avec sa date de fin de maintenance standard sur la page du cycle de publication d’Ubuntu (nouvel onglet).

Trois conséquences pratiques.

• La maintenance de sécurité standard court cinq ans pour le dépôt main. Sur la 24.04 LTS Noble, cela va jusqu’en mai 2029; sur la 26.04 LTS « Resolute Raccoon », jusqu’en mai 2031. Lire les notes de version associées avant d’installer: la note de version de noble (nouvel onglet) détaille le matériel reconnu, les paquets phares et les pièges connus.
• Le choix LTS n’est jamais sauté. La LTS 22.04 « Jammy Jellyfish » voit sa maintenance standard s’achever en avril 2027. La LTS 24.04 sera maintenue jusqu’en avril 2029. Quand une LTS arrive en fin de support, Canonical publie do-release-upgrade pour passer à la suivante; passer d’une LTS à l’autre LTS reste supporté, mais jamais sauter deux versions d’un coup.
• Hors support, hors correctifs standard. Une machine Ubuntu reste utilisable après la fin de maintenance, mais elle ne reçoit plus de correctifs pour le dépôt main. Canonical propose une souscription Ubuntu Pro qui prolonge la couverture à dix ans pour les dépôts main, restricted et universe; sans souscription, la machine ne reçoit plus rien.

La commande qui dit, sans ambiguïté, quelle version est installée :

lsb_release -dc

Sur la machine de mesure (24.04.4 LTS Noble, 2026-09-15) cette commande renvoie Description: Ubuntu 24.04.4 LTS et Codename: noble. Tant que noble apparaît ici, la maintenance standard court.

Comment vérifier l’image ISO avant de la graver ?

C’est l’étape que l’on saute le plus souvent, et celle qui coûte le moins cher. Ubuntu publie, à côté de chaque image, un fichier SHA256SUMS sur releases.ubuntu.com (nouvel onglet). La 26.04 LTS expose son fichier d’empreintes à l’adresse publiée par Canonical ; sa lecture est un acte de cinq secondes.

sha256sum ubuntu-26.04-desktop-amd64.iso

La commande calcule l’empreinte. Comparez-la, caractère par caractère, à la ligne correspondante du fichier SHA256SUMS téléchargé depuis le même miroir. La moindre différence signifie que le téléchargement est incomplet ou altéré : retéléchargez.

cd ~/Téléchargements && grep ubuntu-26.04-desktop-amd64.iso SHA256SUMS

grep filtre le fichier SHA256SUMS à la ligne concernant l’image de bureau 26.04. Vous obtenez alors l’empreinte officielle et la signature ISO. Canonical documente la procédure et propose en complément un fichier SHA256SUMS.gpg signé par la clé d’archive Ubuntu ; la vérification de cette signature GPG est documentée dans le guide d’installation officiel (nouvel onglet), sans logiciel supplémentaire au-delà de gpg.

Deux issues, deux gestes.

• L’empreinte correspond : le fichier est identique à celui publié, vous pouvez préparer le support amorçable.
• L’empreinte diffère : le téléchargement n’est pas celui que Canonical a publié. Retéléchargez depuis ubuntu.com/download/desktop (nouvel onglet) ou un miroir officiel, puis vérifiez à nouveau.

Comment ouvrir une session d’administration ?

Toutes les commandes de mise à jour d’Ubuntu écrivent dans la base de paquets du système. Sans privilège, elles échouent avec le message Could not open lock file /var/lib/dpkg/lock-frontend. Trois situations se présentent sur une machine de bureau, dans l’ordre usuel.

sudo -v

La page de manuel sudoers(5) décrit cette commande : sans argument, elle confirme l’horodatage d’authentification. Sur une Ubuntu où le compte courant est sudoer (cas général des installations par défaut), elle renvoie en silence. Sur une machine où la session est ouverte depuis plus de cinq minutes, elle demande le mot de passe à la prochaine commande. Sur un serveur, le shell est souvent directement root et sudo n’est pas requis.

Pour une série d’opérations longues, utilisez sudo -s pour ouvrir un shell élevé, ou sudo -i pour une session propre. Sur la machine de mesure, le shell par défaut est resté utilisateur hermes-gw (uid 992) et sudo est appelé commande par commande ; c’est la pratique documentée et la plus prudente pour les opérations destructives.

Quelle est la mise à jour quotidienne d’Ubuntu ?

Deux commandes, dans cet ordre, sous droits d’administration :

sudo apt update
sudo apt upgrade

apt update met à jour la liste des paquets disponibles à partir des dépôts configurés dans /etc/apt/sources.list.d/ubuntu.sources. Sans elle, apt upgrade travaille sur un index obsolète. La page de manuel apt(8) décrit précisément les deux commandes :

• update ne modifie aucun paquet installé ; elle ne fait que lire les métadonnées (Packages, Release, InRelease) et les rend visibles aux commandes suivantes.
• upgrade installe les nouvelles versions des paquets présents, sans supprimer ni ajouter de paquets. Les paquets qui ne peuvent pas être mis à jour sans modifier le statut d’installation d’un autre paquet restent à leur version courante : c’est le cas « held back » que la page apt-get(8) mentionne.

Pour voir ce qu’apt compte faire sans rien modifier, l’option -s (simuler) est l’outil de lecture :

apt -s upgrade

Sur la machine de mesure, la sortie du simulateur (réduite aux totaux) est :

43 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Cela signifie : 43 paquets Ubuntu officiels ont une nouvelle version candidate dans noble-updates ou noble-security ; un paquet nouveau arrive par dépendance ; aucun paquet n’est retiré. Tant que la première ligne reste à zéro, la mise à jour quotidienne est inoffensive pour le système.

Deux commandes de lecture complètent le duo :

apt list --upgradable
apt-cache policy apt

La première liste les paquets en attente de mise à jour avec leurs versions source et candidate. La seconde montre, pour un paquet précis, l’origine du candidat (http://archive.ubuntu.com/ubuntu noble-updates/main), la priorité de pin (500 sur Ubuntu par défaut) et la version installée. Une origine tierce ; par exemple https://pkgs.tailscale.com/stable/ubuntu noble/main ; apparaît avec sa propre URL, ce qui permet de savoir d’où vient la mise à jour avant de l’accepter.

Quand faut-il utiliser apt full-upgrade plutôt que apt upgrade ?

La page apt(8) dit de full-upgrade qu’elle « effectue la fonction de upgrade mais supprimera les paquets actuellement installés si c’est nécessaire pour mettre à jour le système dans son ensemble ». La page apt-get(8) ajoute la définition historique, dist-upgrade, qui gère en plus les changements de dépendances. Sur Ubuntu, les deux commandes existent, mais do-release-upgrade modifie automatiquement la nature de l’opération lors d’une montée de version.

En pratique, sur la même machine et le même index :

apt -s full-upgrade

Le bilan du simulateur reste :

43 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Les totaux sont identiques à apt -s upgrade. La différence entre les deux commandes n’apparaît que lorsqu’une dépendance change vraiment ; par exemple si un paquet est renommé ou éclaté entre deux versions. Tant que la machine reste sur la même version Ubuntu, la distinction est théorique ; elle devient pratique au moment où l’on change de version Ubuntu, et c’est alors do-release-upgrade qui orchestre les changements de dépendances, pas apt full-upgrade lancé à la main.

Un usage prudent d’apt full-upgrade :

sudo apt -o APT::Get::Trivial-Only=true full-upgrade

L’option APT::Get::Trivial-Only=true, documentée dans apt.conf(5), demande à apt de signaler ce qu’il ferait sans rien modifier. C’est un test à blanc : si la sortie mentionne beaucoup de paquets à retirer, c’est qu’une migration est en cours et qu’il faut probablement préparer autrement.

Comment empêcher un paquet de se mettre à jour ?

apt-mark gère l’état d’un paquet. Sur Ubuntu, un cas fréquent est un paquet de pilote ou un outil de test qu’il ne faut pas pousser vers la dernière version. La commande est :

sudo apt-mark hold linux-firmware

La page apt-mark(8) décrit cette forme : apt-mark hold pkg empêche apt d’installer une nouvelle version du paquet. Pour dresser la liste des paquets retenus :

apt-mark showhold

Et pour lever la retenue :

sudo apt-mark unhold linux-firmware

Sur la machine de mesure, la commande renvoie rien d’exploitable tant qu’aucun paquet n’a été mis sous hold ; le système est dans l’état par défaut. Le geste se justifie quand une dépendance casse une fonction précise après une mise à jour : retenir le paquet, ouvrir un ticket, attendre la correction amont, puis débloquer. Aucun automatisme ne doit retenir un paquet au-delà d’un cycle de maintenance.

Comment lire l’origine d’un paquet avant une montée de version ?

do-release-upgrade exige que le système soit « Ubuntu pur », c’est-à-dire sans dépôts tiers empêchant la mise à niveau. La commande pour lister les paquets d’origine non Ubuntu est documentée dans les notes de version de chaque LTS :

apt list '?narrow(?installed, ?not(?origin(Ubuntu)))'

apt interprète l’argument entre apostrophes comme un filtre booléen : parmi les paquets installés, retirer ceux dont l’archive d’origine porte le label « Ubuntu ». Cette étiquette est posée par les définitions Signed-By du fichier /etc/apt/sources.list.d/ubuntu.sources. Sur la machine de mesure, l’origine « Ubuntu » est déclarée par la clé ubuntu-archive-keyring.gpg et la ligne URIs: http://archive.ubuntu.com/ubuntu.

Un paquet tiers se voit dans la commande précédente comme installé depuis un label d’origine différent. Pour un cas concret :

apt-cache policy tailscale

Sur la machine de mesure, l’origine apparaît :

*** 1.102.2 500
     500 https://pkgs.tailscale.com/stable/ubuntu noble/main amd64 Packages

Le candidat provient d’un dépôt tiers, pas du label « Ubuntu ». Avant une montée de version LTS, do-release-upgrade désactive par défaut les dépôts tiers en les commentant dans /etc/apt/sources.list.d/, et l’option --allow-third-party permet de les conserver. La règle simple : si un paquet tiers bloque une montée de version, le conserver en hold ou supprimer le dépôt est plus prudent que tenter une montée forcée.

Comment passer d’une LTS à la suivante ?

Le paquet ubuntu-release-upgrader-core fournit l’outil. Vérifiez qu’il est installé :

dpkg -l ubuntu-release-upgrader-core

Sur la machine de mesure (24.04 Noble), la sortie abrégée du contrôle d’état donne 1:24.04.28, la version livrée par les dépôts officiels de Noble. La commande de migration est :

sudo do-release-upgrade -m server

L’option -m server ou -m desktop sélectionne le mode d’interface ; sur un poste de travail sans serveur X disponible, server est le mode par défaut et fonctionne depuis un terminal distant. Le programme affiche le numéro de version cible, désactive les dépôts tiers, configure un nouveau fichier sources.list pour la nouvelle version, et lance les téléchargements. Une étape critique demande la confirmation pour redémarrer les services système ; elle se déclenche automatiquement en fin de procédure.

Avant de lancer la migration, deux vérifications documentées :

• cat /etc/update-manager/release-upgrades : la ligne Prompt= doit être lts pour passer de LTS à LTS et normal pour suivre la chaîne intermédiaire. Sur la machine de mesure, Prompt=lts est la valeur par défaut.
• do-release-upgrade -c : -c signifie --check-dist-upgrade-only. Sur la machine de mesure (2026-09-15, Noble), la commande renvoie There is no development version of an LTS available, suivi d’un rc=1. Ce message signifie qu’aucune LTS supérieure à Noble n’est actuellement annoncée ; le calendrier meta-release-lts du paquet n’a pas encore publié la cible 26.04 comme LTS stable à cette date.

Les notes de version de chaque LTS insistent : ne sautez pas de version. Passer de 22.04 Jammy à 26.04 directement n’est pas une procédure officielle ; la commande vise la cible intermédiaire. Si vous souhaitez suivre les versions intermédiaires sur une machine dédiée, passez Prompt= à normal et appelez do-release-upgrade une version à la fois.

Comment gérer les paquets snap sur Ubuntu ?

Ubuntu installe snapd dès l’installation, et la commande snap est disponible pour gérer le contexte particulier des paquets Snap. snapd n’est pas un paquet .deb du dépôt main à part entière ; sa mise à jour passe par Snap.

snap version

Sur la machine de mesure (2026-09-15) cette commande affiche snap 2.76+ubuntu24.04.1 et snapd 2.76+ubuntu24.04.1. Les deux lignes prouvent que snap est distinct d’apt mais lié : il utilise sa propre base transactionnelle (Snapd), un confinement AppArmor par défaut, et un canal de mise à jour parallèle aux paquets Debian.

Une liste propre :

snap list

La commande affiche les snaps installés : nom, version, révision, canal (stable, candidate, beta, edge), éditeur. La machine de mesure ne porte aucun snap utilisateur, ce qui est cohérent avec un serveur orienté Debian ; snap reste disponible pour installer des applications comme Firefox ou le client Telegram en mode confiné.

Le piège courant est de mélanger les deux systèmes. Une commande comme :

sudo apt install firefox

est susceptible de basculer l’installation sur le snap Firefox préconfiguré par Canonical selon le paquet firefox des dépôts officiels. Sur Ubuntu 24.04 LTS, le navigateur Firefox est livré en snap par défaut. Pour rester en .deb, il faut le paquet firefox-deb et non firefox. Ce choix a une date : la bascule a eu lieu avec la 22.04 et se poursuit. La page apt(8) ne documente pas ce basculement ; il faut lire la note de version concernée (nouvel onglet) pour savoir quelle version de Firefox est livrée par quel paquet.

Pour mettre à jour les snaps installés :

sudo snap refresh

La commande interroge les canaux configurés et applique les nouvelles versions des snaps. Pour vérifier sans modifier :

sudo snap refresh --list

Tant que vous ne posez pas la question séparément, les mises à jour snap ne sont pas coordonnées avec les opérations apt. Une machine Ubuntu supporte ainsi deux flux distincts à maintenir à jour, ce qu’aucune autre fille de Debian n’impose par défaut.

Que faire quand une mise à jour ne se passe pas comme prévu ?

Trois cas documentés, trois lectures.

Paquets « held back » après apt upgrade. La page apt-get(8) l’explique : un paquet dont la mise à jour exigerait de modifier le statut d’installation d’un autre paquet est laissé à sa version courante. Pour le débloquer, deux gestes documentés : installer explicitement le paquet concerné (sudo apt install nom-du-paquet) ou passer par aptitude, qui propose plusieurs résolutions par défaut. Sur Ubuntu, aptitude n’est pas installé par défaut ; le paquet aptitude reste disponible dans universe si vous en avez besoin ponctuellement.

Snap qui ne s’actualise pas. Premier réflexe : sudo snap refresh nom-du-snaps pour cibler, puis snap change <ID> pour lire le journal de la dernière opération. Le confinement AppArmor peut bloquer une mise à jour si la nouvelle révision exige des permissions supplémentaires ; le diagnostic est alors sudo journalctl -u snapd | tail. Restaurer une révision antérieure est documenté : snap revert nom-du-snaps republie la version précédente.

Mise à niveau interrompue. Si do-release-upgrade s’arrête en cours de procédure, ne relancez pas immédiatement. Les notes de version de chaque LTS indiquent un fichier d’état /var/lib/ubuntu-release-upgrader/ qui peut contenir une trace partielle. La commande sûre pour reprendre est sudo dpkg --configure -a, qui termine la configuration des paquets déballés. Une mise à niveau interrompue est un état à lire, pas à forcer : ajouter l’option -f à apt-get pour terminer est parfois légitime, supprimer des paquets essentiels sans diagnostic ne l’est jamais.

Ce qu’Ubuntu ne résout pas, et ce qu’il faut savoir avant de partir

Une installation Ubuntu peut rester sans intervention pendant des années si elle est sur LTS et bien configurée. Mais aucun outil ne remplace l’attention à la machine. Quatre limites à garder en tête.

• Hors maintenance, Ubuntu Pro est optionnel, pas automatique. Une machine qui dépasse la date de fin de maintenance standard sans souscription Ubuntu Pro ne reçoit plus de correctifs de Canonical. C’est une décision d’exploitation, pas un défaut technique : choisir la LTS en connaissance de cause évite la transition ratée.
• Snap coexiste avec apt, pas à sa place. Sur un poste de travail, le navigateur par défaut et certaines applications graphiques vivent en snap. Le reste reste en .deb via apt. Confondre les deux flux produit des questions sans réponse (« pourquoi cette mise à jour ? »). La section « Comment gérer les paquets snap sur Ubuntu ? » qui précède donne les commandes utiles.
• Le matériel atypique reste à charge de l’utilisateur. La commande ubuntu-drivers list liste les pilotes propriétaires reconnus. Sur une carte Wi-Fi Broadcom, un GPU Optimus ou un lecteur d’empreintes particulier, l’installation manuelle peut être nécessaire. La liste de matériel certifié est une aide, pas une garantie.
• L’installateur ne remplace pas une sauvegarde. C’est le rappel que la page de présentation d’Ubuntu porte déjà, et il reste vrai ici : modifier le disque peut effacer ses données. Une copie externe vérifiée reste le seul filet de sécurité que la documentation valide.

Ces quatre points ne sont pas des défauts à corriger : ce sont des paramètres de la distribution, que sa documentation officielle assume.

Repères pour aller plus loin

Pour pratiquer les commandes décrites ici :

• Présentation d’Ubuntu : le cycle de publication, les dépôts, et les règles de la LTS ;
• Debian : installer et mettre à jour : la fiche soeur, utile si vous voulez comprendre la base dont Ubuntu est dérivée ;
• Le guide Linux et terminal : la porte d’entrée de l’univers Linux sur le site ;
• Les commandes de base : se repérer dans un terminal sans risque ;
• Diagnostiquer une connexion : quand apt update ne résout pas ses miroirs, côté réseau.

Installer une distribution n’est que le début. Ce qui compte ensuite, c’est de savoir quelle version tourne sur la machine, d’où viennent ses paquets, et comment revenir en arrière si une mise à jour casse un service. La documentation Ubuntu fournit les commandes ; le reste reste à votre main.