Passer de Debian 12 à Debian 13 sans casser son système

Passer de Debian 12 Bookworm à Debian 13 Trixie n’est pas une opération spectaculaire. C’est précisément ce qui la rend piégeuse : on lance quelques commandes, l’écran défile, puis un service ne repart pas, un dépôt tiers bloque APT ou un poste ne démarre plus comme avant. Une migration Debian réussie commence donc avant la première mise à jour.

Debian 13 Trixie est sortie officiellement le 9 août 2025 et constitue désormais la branche stable. Debian a aussi publié plusieurs mises à jour de point release, dont Debian 13.6 le 11 juillet 2026. Le sujet n’est plus de savoir si Trixie existe : il faut décider quand migrer, sur quelle machine, avec quel plan de retour arrière.

La bonne règle tient en une phrase : on ne migre pas un système dont on ne sait pas restaurer les données. Pour un poste personnel, cela peut être une sauvegarde complète et une clé USB de secours. Pour un serveur, il faut ajouter la fenêtre d’intervention, les services critiques et les tests après redémarrage.

Décider si la migration est nécessaire maintenant

La question paraît simple, mais elle mérite une vraie réponse avant de toucher au système : sur Debian, le bon moment dépend d’abord de l’usage réel, de la tolérance à l’arrêt et du temps disponible pour réparer. Sur un poste de test, un ordinateur personnel récent ou une machine de développement sans dépendances fragiles, migrer vers Debian 13 peut être pertinent rapidement. Vous bénéficiez de paquets plus récents, d’un noyau Linux 6.12 LTS, de bureaux mis à jour et d’un socle stable pour les prochaines années.

Sur un serveur de production, un NAS bricolé, une machine qui héberge une base de données ou un poste indispensable à une PME, la priorité est différente. Il faut d’abord confirmer que les services, pilotes, outils de supervision, scripts internes et dépôts tiers ont un chemin clair vers Trixie. La stabilité opérationnelle vaut mieux qu’une migration précipitée.

Debian 12 reste maintenue pendant sa période de support, mais cela ne dispense pas de préparer la suite. Le bon compromis consiste souvent à migrer une machine secondaire, documenter les problèmes, puis traiter les systèmes critiques dans une fenêtre planifiée.

Préparer la sauvegarde et le retour arrière

Une sauvegarde utile n’est pas seulement un dossier copié sur un disque externe avant de lancer la commande : elle doit être localisable, lisible et exploitable sans dépendre du système que vous êtes en train de modifier.

Elle doit permettre de retrouver un système exploitable si la migration échoue, y compris lorsque le démarrage ne fonctionne plus ou que le réseau est indisponible. Sur un poste, sauvegardez les documents, profils navigateurs, clés SSH, fichiers de configuration personnels et liste des applications importantes; sur une machine utilisée chaque jour, ajoutez aussi les licences, profils VPN, modèles de mails, favoris de navigateur et petits scripts que personne ne pense à documenter.

Sur un serveur, la liste s’allonge : bases de données, fichiers de configuration dans /etc, virtual hosts, tâches cron, certificats, secrets d’application, volumes Docker, règles firewall, scripts de sauvegarde et journaux utiles. Si vous utilisez des VM ou du cloud, un snapshot vérifié change complètement le niveau de risque.

Le point souvent oublié est la restauration. Avant une migration importante, vérifiez que vous savez démarrer sur un support de secours, monter le disque, relire la sauvegarde et récupérer les fichiers critiques. Une sauvegarde jamais testée reste une hypothèse.

1. Données : documents, projets, bases, volumes applicatifs.
2. Configuration : /etc, services systemd, clés, certificats, règles réseau.
3. Inventaire : paquets installés, dépôts APT, versions de services, ports ouverts.
4. Retour arrière : snapshot, image disque, sauvegarde distante ou procédure manuelle documentée.

Lire les release notes avant de modifier APT

Les release notes Debian sont la feuille de route de la migration, pas une annexe à lire après coup. Elles décrivent les changements importants, les limites connues et la procédure officielle de mise à niveau. Pour Bookworm vers Trixie, c’est la référence à lire avant de remplacer les noms de version dans les sources APT, parce qu’une commande correcte dans un tutoriel peut devenir incomplète si votre machine utilise un paquet retiré, une architecture particulière, Secure Boot, OpenSSH avec réglages locaux ou un dépôt tiers encore bloqué sur Bookworm.

Pour approfondir ce point, consultez debian 13 trixie, qui traite plus précisément de debian 13 trixie, ce qui change vraiment avant de migrer.

Les notes Debian 13 mentionnent plusieurs points à surveiller selon les machines : évolution du support i386, changements de paquets, composants obsolètes, ajustements autour de /tmp, OpenSSH ou encore Secure Boot selon les cas. Tous ne vous concernent pas, mais un seul point ignoré peut suffire à casser une machine critique.

La bonne lecture est pragmatique : parcourez les sections de mise à niveau, cherchez les paquets que vous utilisez vraiment, puis notez les actions spécifiques. Si votre machine héberge PostgreSQL, PHP, Nginx, Samba, Docker, un environnement graphique ou des pilotes particuliers, vous ne devez pas la traiter comme une installation neuve basique.

Nettoyer les dépôts et lancer la mise à niveau

APT est souvent l’endroit où une migration réussit proprement ou se bloque pendant plusieurs heures. Une machine propre, avec des dépôts Debian officiels et peu de paquets exotiques, migre beaucoup mieux qu’un système où s’empilent PPA, dépôts de navigateurs, outils de virtualisation, pilotes et paquets téléchargés à la main. Avant de chercher la commande parfaite, regardez donc la zone APT réelle de la machine : c’est elle qui dira si l’upgrade sera banal ou s’il faut nettoyer, désactiver et documenter avant.

Avant de remplacer bookworm par trixie, listez les fichiers dans /etc/apt/sources.list et /etc/apt/sources.list.d/. Désactivez les dépôts tiers non indispensables, notez ceux qu’il faudra réactiver ensuite et vérifiez que les suites security et updates correspondent à la syntaxe attendue pour Trixie.

La séquence classique reste sobre : mettre Debian 12 à jour, corriger les paquets cassés, modifier les sources, lancer apt update, effectuer une mise à niveau minimale si les notes le recommandent, puis exécuter apt full-upgrade. Le mot important est full-upgrade, car une version majeure peut nécessiter des suppressions ou remplacements de paquets.

Surveiller les questions posées par APT

Ne traitez pas les questions APT comme une formalité à valider machinalement pendant que l’installation défile : elles concernent souvent les fichiers qui font vraiment fonctionner la machine.

APT et dpkg peuvent vous demander quoi faire avec un fichier de configuration modifié localement. Garder votre version peut préserver un réglage important; installer la version mainteneur peut corriger un format devenu obsolète. La mauvaise réponse n’est pas toujours visible immédiatement : un service peut redémarrer, puis échouer plus tard parce qu’un format, une directive ou un chemin a changé entre Bookworm et Trixie.

La bonne décision dépend du fichier. Pour un service critique, ouvrez un second terminal, comparez les versions et documentez le choix. Refuser systématiquement les nouveaux fichiers de configuration est aussi dangereux que les accepter sans lecture. La configuration locale doit être comprise, pas sacrée.

Sur un serveur distant, utilisez une session persistante, par exemple via tmux ou screen, et gardez un accès console alternatif si possible. La coupure SSH pendant une mise à niveau est un classique évitable. Si OpenSSH ou le réseau sont concernés par les changements, prenez encore moins de risques.

Adapter la migration au poste ou au serveur

Le scénario change complètement selon la machine, même si la commande de mise à niveau paraît identique. Sur un ordinateur portable, les problèmes visibles arrivent vite : session qui ne s’ouvre pas, pilote Wi-Fi, écran externe, accélération graphique, imprimante, VPN ou environnement de bureau modifié. Sur une machine qui sert des sites, des sauvegardes ou une base de données, le risque est moins spectaculaire mais plus coûteux, car un service peut sembler actif tout en échouant sur un accès, une dépendance, une tâche planifiée ou une authentification externe.

Sur serveur, la validation post-migration doit donc couvrir les usages réels, pas seulement l’état “running” affiché dans systemd. Testez au moins une requête applicative, une sauvegarde, une connexion distante et le chemin de supervision.

Les dépôts tiers méritent un traitement séparé. Un dépôt Docker, VirtualBox, navigateur, outil de supervision ou agent de sauvegarde peut ne pas être prêt au moment où vous migrez. Le bon réflexe consiste à le désactiver pour la migration principale, puis à le réactiver seulement après confirmation de compatibilité avec Trixie.

Pour approfondir ce point, consultez markdown pdf, qui traite plus précisément de markdown vers pdf, convertir proprement sans casser la mise en page.

Gardez aussi une trace écrite de ce que vous avez changé. Une simple note avec date, machine, ancienne version, nouvelle version, dépôts désactivés, paquets supprimés et anomalies observées suffit souvent. Trois mois plus tard, cette note devient un vrai gain d’exploitation, surtout si vous devez migrer une deuxième machine semblable.

1. Poste graphique : tester session, réseau, imprimante, écran, son, VPN et applications quotidiennes.
2. Serveur web : vérifier HTTP, HTTPS, certificats, logs, runtime applicatif, base de données et sauvegardes.
3. Machine distante : conserver console, snapshot et session persistante avant toute mise à niveau lourde.
4. Dépôts tiers : réactivation progressive, un dépôt à la fois, après validation du socle Debian.

Valider le système après le redémarrage

Un démarrage réussi est seulement le début du contrôle, surtout après un changement de version majeure qui touche noyau, paquets système, services et dépendances applicatives.

Il faut vérifier le noyau chargé, les paquets retenus, les services actifs, les journaux, le réseau et les applications réellement utilisées. Pour un poste graphique, testez le Wi-Fi, le son, l’écran externe, l’impression et les outils de travail; pour une machine partagée, demandez aussi à un utilisateur réel de valider son flux quotidien, car certains défauts n’apparaissent pas dans les commandes d’administration.

Pour un serveur, commencez par les services : web, base de données, SSH, sauvegarde, monitoring, tâches planifiées, conteneurs, certificats et accès applicatifs. Ensuite seulement, réactivez les dépôts tiers nécessaires et mettez à jour les paquets associés. Cette approche évite de mélanger un problème Debian et un problème de dépôt externe.

Gardez les notes de migration pendant quelques jours. Certaines erreurs apparaissent après une rotation de logs, une sauvegarde nocturne, une tâche cron ou une montée de charge. Une migration fiable se juge aussi le lendemain matin.

Les cas où il vaut mieux réinstaller

Parfois, la meilleure migration est une installation neuve, surtout quand l’historique du système est devenu illisible et que personne ne sait expliquer les exceptions accumulées.

Une Debian très ancienne, très bricolée, pleine de dépôts tiers ou de paquets compilés à la main peut coûter plus cher à migrer qu’à reconstruire proprement. C’est particulièrement vrai pour un poste de travail où les données sont bien séparées du système, ou pour un serveur dont la configuration peut être redéployée depuis des scripts, des conteneurs, une documentation à jour et une sauvegarde déjà testée.

Sur un serveur, la réinstallation exige plus de méthode, mais elle peut être saine si vous disposez d’une infrastructure reproductible : scripts Ansible, conteneurs, documentation, sauvegardes testées, DNS maîtrisé et fenêtre d’intervention. Si tout repose sur des réglages faits à la main depuis des années, la migration révèle surtout une dette d’exploitation.

Le bon arbitrage est simple : si vous pouvez reconstruire la machine plus vite que vous ne pouvez expliquer ses exceptions, envisagez une installation neuve. Sinon, migrez prudemment et profitez de l’opération pour documenter ce qui manquait.

La méthode à retenir

La méthode tient en peu d’étapes, mais elles doivent être faites dans le bon ordre, avec une trace claire de chaque décision importante.

Pour passer de Debian 12 à Debian 13, ne commencez pas par remplacer tous les mots “bookworm” par “trixie”. Commencez par lire les release notes, sauvegarder, inventorier, nettoyer les dépôts tiers et décider ce qui doit absolument fonctionner après redémarrage. Cette discipline paraît lente; elle évite surtout de transformer une mise à niveau stable en dépannage improvisé devant une machine qui ne rend plus le service attendu.

La prochaine action utile est concrète : sur la machine concernée, listez les dépôts APT, exportez la liste des paquets installés, sauvegardez /etc et vos données, puis ouvrez les notes officielles Debian 13. Si ces quatre points ne sont pas faits, la migration n’est pas prête.

Pour approfondir ce point, consultez fichier hosts windows, qui traite plus précisément de fichier hosts windows, le modifier sans casser le dns.