APT en 2026 : migrer vos dépôts au format deb822 proprement

Les fichiers deb822, reconnaissables à leur extension .sources, constituent le format moderne de déclaration des dépôts APT. Ils ne changent pas la fonction d’APT : le système continue de télécharger des index, de vérifier leurs signatures et d’installer des paquets. En revanche, ils rendent la configuration plus structurée, plus facile à relire et mieux adaptée à une gestion propre des clés de signature.

Sur un poste Debian, Ubuntu ou une distribution dérivée, la migration est aussi l’occasion de supprimer de mauvaises habitudes : clés ajoutées globalement avec apt-key, dépôts tiers mélangés dans un unique fichier, ou lignes deb laissées sans documentation. L’objectif n’est pas de convertir tous les fichiers sans réfléchir, mais d’obtenir une configuration APT explicite, testable et réversible.

Pourquoi le format deb822 devient la norme dans APT

Historiquement, les dépôts APT sont définis dans /etc/apt/sources.list et dans des fichiers portant l’extension .list dans /etc/apt/sources.list.d/. Chaque ligne décrit un dépôt :

deb https://deb.debian.org/debian stable main

Ce format reste pris en charge, mais devient vite peu pratique dès qu’un dépôt nécessite plusieurs options : architecture particulière, composantes multiples, clé dédiée ou dépôt de code source. La lisibilité se dégrade encore lorsque l’administration ajoute des commentaires, désactive des lignes ou duplique une même URL.

Le format deb822 transpose ces informations sous forme de champs nommés. Une entrée n’est plus une ligne compacte, mais un bloc descriptif. APT prend en charge ce format depuis longtemps, et sa documentation recommande les fichiers .sources pour les nouvelles configurations. Les fichiers au format historique restent compatibles, mais l’orientation est claire : privilégier des définitions de dépôts séparées, structurées et associées à leurs clés.

Un fichier deb822 présente plusieurs avantages opérationnels :

Une information par champ : l’URL, la suite, les composantes et la clé sont distinguées.
Une configuration plus facile à auditer : un fichier peut correspondre à un fournisseur ou à une application.
Une gestion locale de la confiance avec le champ Signed-By.
Une désactivation propre grâce au champ Enabled: no, sans modifier toute la définition.
Une meilleure automatisation dans Ansible, Puppet, scripts shell ou procédures de gestion de parc.

Il faut toutefois distinguer deux sujets. Deb822 améliore la description des dépôts ; il ne remplace pas les mécanismes cryptographiques d’APT. La sécurité reste fondée sur la signature des métadonnées du dépôt et sur les clés explicitement approuvées. Pour comprendre ce modèle, la page de manuel apt-secure reste une référence utile.

Préparer la migration sans casser les mises à jour

Avant de créer des fichiers .sources, commencez par inventorier ce qu’APT lit réellement. Les fichiers de configuration se trouvent généralement dans /etc/apt/sources.list et dans /etc/apt/sources.list.d/. Une machine peut aussi recevoir des fichiers déposés automatiquement par un installateur, un outil de gestion de configuration ou un paquet tiers.

grep -R --line-number --include='*.list' --include='*.sources' . /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Cette commande permet d’identifier les fichiers présents et les adresses de dépôts utilisées. Examinez particulièrement les éléments suivants :

les dépôts officiels de la distribution ;
les dépôts de sécurité et de mises à jour ;
les dépôts tiers, par exemple Docker, GitHub CLI, Kubernetes, HashiCorp ou un éditeur métier ;
les lignes en double ;
les dépôts correspondant à une ancienne version de la distribution ;
les clés installées dans des trousseaux globaux sans lien clair avec un dépôt.

Ne migrez pas un dépôt obsolète uniquement parce qu’il est présent. Si une URL répond encore mais que le fournisseur ne documente plus le dépôt pour votre version de Debian ou d’Ubuntu, la bonne action est souvent de le supprimer, pas de le moderniser.

Faites également une sauvegarde hors du répertoire lu par APT. Par exemple :

sudo cp -a /etc/apt/sources.list /etc/apt/sources.list.d /root/apt-sources-backup

Évitez de conserver des copies avec les extensions .list ou .sources dans le même répertoire : APT pourrait alors les interpréter comme des dépôts actifs. Les noms de fichiers APT doivent aussi rester simples. La documentation recommande des noms constitués de lettres, chiffres, tirets, underscores et points, avec l’extension exacte .list ou .sources.

Enfin, effectuez la migration dépôt par dépôt. C’est particulièrement important sur un serveur : une erreur dans le dépôt du système, une clé absente ou une définition dupliquée peut empêcher apt update de mettre à jour les index attendus. La méthode la plus sûre consiste à ajouter le nouveau fichier, désactiver l’ancienne définition correspondante, puis tester immédiatement.

Lire la structure d’un fichier .sources

Un fichier deb822 contient un ou plusieurs paragraphes. Les champs principaux sont Types, URIs, Suites et Components. Les valeurs multiples sont séparées par des espaces.

Voici une structure typique pour un dépôt Debian :

Types: deb
URIs: https://deb.debian.org/debian
Suites: stable stable-updates
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Dans cet exemple :

Types: deb demande les paquets binaires. Ajoutez deb-src seulement si vous avez besoin des paquets source.
URIs contient l’adresse du miroir ou du dépôt.
Suites désigne la distribution ou le canal publié par le dépôt.
Components précise les sections disponibles, comme main, contrib, non-free ou non-free-firmware dans l’écosystème Debian.
Signed-By limite la clé de confiance à ce dépôt.

La définition exacte des suites et composants dépend de la distribution et du fournisseur. Il ne faut pas transposer mécaniquement une ligne Debian vers Ubuntu, ni remplacer une suite nommée par stable sans vérifier la documentation du dépôt. Certaines organisations publient des dépôts par nom de version, d’autres par nom de distribution, d’autres encore avec un chemin fixe.

Un cas particulier mérite de l’attention : lorsqu’une suite est un chemin exact et se termine par une barre oblique, le champ Components ne doit pas être utilisé. Ce cas est moins fréquent pour les dépôts généralistes, mais se rencontre dans certains dépôts internes ou archives spécialisées.

Vous pouvez aussi désactiver temporairement une entrée deb822 sans effacer son contenu :

Enabled: no

C’est utile lors d’un diagnostic ou pour conserver la référence d’un dépôt qui ne doit pas être utilisé en permanence. Ce mécanisme est plus propre que de commenter ligne par ligne une ancienne liste APT.

La syntaxe complète et les champs disponibles sont décrits dans la page sources.list(5). Consultez-la notamment avant d’utiliser des options d’architecture, des dépôts de code source ou des paramètres inhabituels.

Créer un fichier deb822 propre pour un dépôt tiers

Pour un dépôt tiers, adoptez une règle simple : un fournisseur, un fichier .sources, une clé dédiée. Par exemple, un dépôt nommé « exemple » peut être décrit dans /etc/apt/sources.list.d/exemple.sources.

Types: deb
URIs: https://packages.example.net/apt
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/exemple.gpg

Cette configuration est un modèle de structure : l’URL, la suite et le nom de la clé doivent toujours provenir de la documentation officielle du fournisseur. Ne déduisez pas l’URL à partir d’un tutoriel ancien, d’une commande trouvée sur un forum ou d’une configuration destinée à une autre distribution.

Le répertoire /etc/apt/keyrings est généralement approprié pour les clés administrées localement. À l’inverse, /usr/share/keyrings est couramment utilisé pour les trousseaux fournis et maintenus par des paquets. Cette séparation aide à savoir si une clé dépend de la distribution, d’un paquet installé ou d’une décision locale d’administration.

Lorsque le fournisseur publie une clé ASCII armée, elle doit être convertie dans un format exploitable par APT si vous souhaitez la stocker en .gpg. La documentation APT indique aussi que les clés ASCII armées peuvent être utilisées avec une extension .asc. Dans tous les cas, vérifiez l’empreinte de la clé via un canal fiable avant de lui accorder votre confiance.

Une erreur fréquente consiste à télécharger une clé depuis une URL et à l’ajouter sans contrôle. Une commande réussie ne prouve ni l’identité de l’éditeur ni l’intégrité du canal de distribution. Préférez les instructions officielles du fournisseur, comparez l’empreinte lorsqu’elle est publiée et évitez les serveurs de clés utilisés comme source unique de confiance.

Associer chaque dépôt à sa clé avec Signed-By

Le champ Signed-By est le point central d’une migration moderne. Sans cette restriction, une clé placée dans un trousseau global peut potentiellement être considérée pour plusieurs dépôts. Ce modèle élargit inutilement le périmètre de confiance : une clé ajoutée pour un logiciel tiers ne devrait pas servir à authentifier autre chose.

Avec une définition explicite, APT sait quelle clé doit être utilisée pour vérifier les métadonnées d’un dépôt donné :

Signed-By: /etc/apt/keyrings/fournisseur.gpg

Le fichier de clé doit être accessible au processus qui effectue les téléchargements APT. En pratique, vérifiez ses droits et son emplacement. Un fichier trop restrictif peut provoquer des erreurs de vérification alors que la clé elle-même est correcte.

La commande historique apt-key est dépréciée. Elle a longtemps été employée pour ajouter des clés dans un espace global, mais ce fonctionnement ne répond plus aux bonnes pratiques actuelles. Pour les nouvelles intégrations, téléchargez la clé selon la procédure officielle, stockez-la dans un trousseau dédié, puis référencez-la avec Signed-By.

Avant de retirer une clé ancienne, recherchez d’abord les dépôts qui en dépendent. Une suppression précipitée peut casser un dépôt encore actif. À l’inverse, laissez le moins possible de clés inutilisées : elles compliquent les audits et rendent les messages d’erreur plus difficiles à interpréter.

Cette démarche complète utilement le durcissement général d’un serveur. La sécurisation des dépôts réduit le risque d’installer des paquets depuis une source non attendue, tandis que les mises à jour doivent rester maîtrisées. Si vous automatisez ces opérations, une procédure de validation est préférable à une mise à jour aveugle ; consultez notamment les principes abordés dans l’automatisation des mises à jour Linux.

Procédure de migration progressive d’un ancien fichier .list

Supposons qu’un ancien fichier contienne une ligne de ce type :

deb [signed-by=/etc/apt/keyrings/fournisseur.gpg] https://repo.fournisseur.example/debian stable main

La conversion consiste à créer un fichier, par exemple /etc/apt/sources.list.d/fournisseur.sources, puis à y reporter les informations :

Types: deb
URIs: https://repo.fournisseur.example/debian
Suites: stable
Components: main
Signed-By: /etc/apt/keyrings/fournisseur.gpg

Une fois le nouveau fichier créé, retirez ou désactivez l’ancienne définition afin que le même dépôt ne soit pas lu deux fois. La duplication peut produire des avertissements sur des cibles configurées plusieurs fois et complique la maintenance. Gardez une sauvegarde hors du répertoire de configuration, puis lancez une mise à jour des index.

sudo apt update

Sur une machine de production, ne mélangez pas dans la même intervention la conversion de format, le changement de miroir, la mise à niveau de distribution et l’ajout d’un nouveau dépôt tiers. Une modification à la fois simplifie énormément le retour arrière.

Si votre configuration est gérée par un outil d’infrastructure, adaptez aussi le manifeste ou le rôle concerné. Sinon, le prochain passage d’Ansible, Puppet, Salt ou d’un script interne peut recréer l’ancien fichier .list et annuler la normalisation.

Tester apt update et comprendre les erreurs courantes

La commande apt update est le test principal après chaque migration. Elle télécharge les index disponibles et vérifie les signatures. Lisez les avertissements, même si la commande semble aller au bout : un dépôt ignoré ou une signature invalide peut ne se manifester qu’au moment où vous attendez un paquet particulier.

Voici les problèmes les plus fréquents et leur interprétation.

Erreur de clé publique ou signature non vérifiable

Des messages contenant NO_PUBKEY, une mention de signature non vérifiable ou l’indication qu’un dépôt n’est pas signé pointent généralement vers une clé absente, une mauvaise clé, un mauvais chemin dans Signed-By ou une clé expirée côté fournisseur.

Ne contournez pas ce problème en désactivant la vérification de signature. Vérifiez l’URL officielle du dépôt, l’empreinte de la clé, les droits de lecture du fichier et la compatibilité entre la clé fournie et le dépôt configuré.

Valeurs Signed-By contradictoires

APT peut signaler des valeurs contradictoires pour Signed-By lorsqu’une même source est définie plusieurs fois avec des clés différentes. Cela arrive souvent quand le nouveau fichier .sources coexiste avec l’ancien .list.

Recherchez l’URL concernée dans /etc/apt/sources.list et /etc/apt/sources.list.d/, puis conservez une seule définition active. Une source ne doit pas être décrite simultanément avec deux politiques de signature différentes.

Erreur 404 ou absence de fichier Release

Une erreur 404 ou l’absence de fichier Release ne se corrige pas par un changement de clé. Elle indique plutôt une URL incorrecte, une suite non publiée, une distribution non prise en charge ou un dépôt retiré. Vérifiez la documentation du fournisseur et la version réelle de votre système avec :

. /etc/os-release && printf '%s\n' "$PRETTY_NAME"

Le nom de code, la version et l’architecture doivent correspondre aux instructions du dépôt. Un dépôt prévu pour une autre version de la distribution peut parfois répondre, mais introduire des paquets incompatibles.

Erreurs de syntaxe dans un fichier .sources

Les fautes simples sont fréquentes : champ mal orthographié, URL placée dans le mauvais champ, composante manquante ou fichier enregistré avec une extension non reconnue. Reprenez la structure minimale : Types, URIs, Suites, Components et, pour un dépôt tiers, Signed-By.

Les fichiers deb822 sont sensibles à leur structure en paragraphes. Gardez une présentation sobre, un champ par ligne et des noms de fichiers explicites. Cela évite de transformer la gestion des dépôts en exercice de débogage permanent.

Standardiser la gestion des dépôts sur un parc Linux

Sur plusieurs serveurs ou postes, définissez une convention avant que les fichiers ne se multiplient. Par exemple :

/etc/apt/sources.list.d/fournisseur.sources pour chaque dépôt tiers ;
/etc/apt/keyrings/fournisseur.gpg pour chaque clé administrée localement ;
une trace de l’origine de la clé et de la procédure de renouvellement ;
une validation apt update dans le déploiement automatisé ;
un contrôle régulier des dépôts devenus inutiles.

Évitez aussi les commandes de téléchargement suivies d’exécution ou d’installation sans revue. Un dépôt APT fait partie de la chaîne d’approvisionnement logicielle : sa configuration mérite le même niveau d’attention qu’un accès SSH, une tâche planifiée ou un service systemd.

Pour les environnements internes, documentez le responsable du dépôt, le mécanisme de publication, la clé attendue et la procédure à suivre en cas de rotation de clé. Le format deb822 facilite cette discipline, mais ne remplace pas la documentation d’exploitation.

Conclusion : une migration simple, à condition d’être méthodique

Passer aux fichiers .sources permet de rendre la configuration APT plus claire et plus sûre, surtout lorsque chaque dépôt est associé à une clé dédiée via Signed-By. La priorité est de conserver une source unique par dépôt, de limiter la portée des clés et de tester chaque changement avec apt update.

Commencez par un dépôt tiers non critique, appliquez la convention de nommage retenue, puis généralisez-la progressivement à vos postes et serveurs. Vous obtiendrez une gestion APT plus lisible aujourd’hui et nettement plus facile à maintenir lors de la prochaine mise à niveau de votre parc Linux.