Offre Durée limitée : -10% sur tout le site* avec le code WELCOME10

Migrer son VPS de Debian 12 Bookworm à Debian 13 Trixie : guide complet

Mis à jour le 2 novembre 2026 9 min de lecture 10 sections

Pourquoi migrer de Debian 12 vers Debian 13 Trixie

Debian 12 Bookworm a quitte le support complet le 12 juillet 2026. Depuis cette date, seule l'equipe LTS (Long Term Support) assure les correctifs de securite, avec une couverture reduite a environ 230 paquets. Le support LTS de Debian 12 prendra fin le 30 juin 2028. Apres cette date, plus aucun correctif ne sera publie pour Bookworm.

Debian 13 Trixie, publiee le 9 aout 2025, est la version stable actuelle. Sa derniere mise a jour mineure, Debian 13.7, date du 12 septembre 2026. Le support complet de Trixie court jusqu'au 9 aout 2028, suivi du LTS jusqu'au 30 juin 2030. Migrer maintenant garantit quatre ans de correctifs de securite pour votre VPS Linux.

Au-dela du support, Trixie apporte des mises a jour majeures de paquets qui impactent directement l'administration d'un serveur : nouveau noyau Linux 6.12, PHP 8.4, Python 3.13, OpenSSL 3.5, MariaDB 11.8 et PostgreSQL 17. Ce guide couvre la procedure complete de migration sur un VPS en production : sauvegarde, modification des sources APT, mise a niveau, pieges courants et verification post-migration.

Ce qui change entre Debian 12 et Debian 13

Le tableau ci-dessous compare les versions des principaux paquets serveur entre Bookworm et Trixie. Chaque changement de version majeure peut casser des scripts, des fichiers de configuration ou des applications qui dependent d'un comportement specifique.

ComposantDebian 12 BookwormDebian 13 TrixieImpact serveur
Noyau Linux6.1 LTS6.12 LTSNouveaux pilotes, ameliorations KVM, reboot obligatoire
GCC12.214.2Recompilation necessaire pour les modules natifs
glibc2.362.41Compatibilite binaire preservee, gains de performance
Python3.113.13Modules distutils et imp supprimes
PHP8.28.4Fonctions depreciees supprimees, nouvelles regles de typage
OpenSSL3.03.5Algorithmes obsoletes desactives par defaut
MariaDB10.1111.8Nouveaux formats de stockage, verifier la compatibilite
PostgreSQL1517Changements de configuration postgresql.conf
systemd252257Nouveaux types de service, journaux structure evolue

Sauvegarder avant la migration

Une mise a niveau majeure modifie des centaines de paquets en une seule operation. Si la migration echoue a mi-chemin (coupure reseau, disque plein, conflit de paquets), le systeme peut se retrouver dans un etat intermediaire inutilisable. La sauvegarde est la seule assurance de retour en arriere.

Commencez par sauvegarder les fichiers de configuration, l'etat des paquets et les donnees critiques :

sudo tar czf /root/backup-etc-$(date +%F).tar.gz /etc
dpkg --get-selections '*' > /root/dpkg-selections-$(date +%F).txt
sudo cp /var/lib/dpkg/status /root/dpkg-status-$(date +%F)
sudo cp /var/lib/apt/extended_states /root/apt-extended-states-$(date +%F)

Si votre VPS heberge des bases de donnees MySQL ou MariaDB, exportez-les avant la migration :

sudo mysqldump --all-databases --single-transaction > /root/all-databases-$(date +%F).sql

Pour PostgreSQL :

sudo -u postgres pg_dumpall > /root/pg_dumpall-$(date +%F).sql

Copiez l'ensemble des sauvegardes hors du VPS avec rsync ou scp. En cas d'echec de la migration, vous aurez besoin d'y acceder depuis une autre machine. Notre guide sauvegarder un VPS avec rsync detaille la procedure de copie vers un serveur distant.

Si votre hebergeur propose des snapshots de la machine virtuelle, creez-en un avant de commencer. C'est le moyen le plus rapide de revenir a l'etat initial en cas de probleme.

Preparer le systeme avant la mise a niveau

La migration vers Trixie n'est officiellement supportee que depuis la derniere version mineure de Bookworm. Verifiez votre version actuelle :

cat /etc/debian_version
# Doit afficher 12.x (par exemple 12.9)

Mettez a jour Debian 12 vers sa derniere revision :

sudo apt update
sudo apt upgrade
sudo apt full-upgrade

Nettoyez les paquets obsoletes et les fichiers de configuration residuels pour eviter les conflits pendant la migration :

sudo apt autoremove --purge
sudo apt clean

Verifiez qu'aucun paquet n'est en etat "hold" (bloque), ce qui empecherait sa mise a jour :

apt-mark showhold

Si un paquet est bloque, debloquez-le avec sudo apt-mark unhold nom-du-paquet avant de continuer.

Desactivez temporairement les depots tiers (backports, PPA, depots d'editeurs comme Docker, Nginx, Node.js, PHP Sury). Commentez leurs lignes dans /etc/apt/sources.list.d/ avec un # en debut de ligne. Vous les reactiverez apres la migration avec les URL adaptees a Trixie.

Modifier les sources APT pour Trixie

Debian 13 adopte le nouveau format deb822 pour les fichiers de sources APT. Ce format remplace le traditionnel /etc/apt/sources.list par des fichiers .sources dans /etc/apt/sources.list.d/.

Creez le fichier de sources pour Trixie :

sudo nano /etc/apt/sources.list.d/debian.sources

Collez le contenu suivant :

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.pgp

Commentez l'ancien fichier /etc/apt/sources.list pour qu'il ne soit plus lu par APT :

sudo sed -i 's/^deb/#deb/' /etc/apt/sources.list

Si vous utilisez les composants contrib ou non-free, ajoutez-les a la ligne Components. Par defaut, un serveur n'a besoin que de main et non-free-firmware (pour les firmwares reseau et stockage).

Notez le changement d'extension du trousseau de cles : .pgp au lieu de .gpg. Ce changement est automatique si vous utilisez le paquet debian-archive-keyring a jour.

Lancer la migration vers Debian 13

Mettez a jour l'index des paquets avec les nouvelles sources :

sudo apt update

Si APT affiche une erreur de signature GPG, mettez a jour le trousseau de cles :

sudo apt install debian-archive-keyring

Pour les migrations a distance via SSH, utilisez screen ou tmux pour proteger la session. Si la connexion SSH se coupe pendant la mise a niveau, le processus continue en arriere-plan et vous pouvez vous reconnecter :

sudo apt install screen
screen -S upgrade

Commencez par une mise a jour minimale qui ne supprime et n'installe aucun nouveau paquet :

sudo apt upgrade --without-new-pkgs

Puis lancez la mise a niveau complete. C'est l'etape principale qui installe les nouveaux paquets, supprime les paquets obsoletes et effectue les transitions :

sudo apt full-upgrade

APT affichera un resume des paquets a installer, supprimer et mettre a jour. Lisez le resume et confirmez. L'operation prend entre 10 et 30 minutes selon la puissance du serveur et le nombre de paquets installes.

Pendant la mise a niveau, APT vous demandera quoi faire des fichiers de configuration modifies localement. Si vous avez personnalise un fichier (par exemple /etc/ssh/sshd_config), conservez votre version et fusionnez les changements manuellement apres la migration. Si vous n'avez jamais modifie le fichier, acceptez la version du mainteneur.

Pieges courants et comment les eviter

PHP 8.2 vers PHP 8.4

Les applications PHP hebergees sur votre VPS doivent etre compatibles avec PHP 8.4. Les changements principaux :

  • Les proprietes implicitement nullables sont depreciees : function f(string $x = null) doit devenir function f(?string $x = null) ;
  • Les fonctions utf8_encode() et utf8_decode(), depreciees depuis PHP 8.2, sont supprimees. Utilisez mb_convert_encoding() ;
  • Le module php8.2-* devient php8.4-*. Les extensions installees manuellement devront etre reinstallees pour la nouvelle version.

Testez vos applications en mode CLI avant de relancer le serveur web :

php -v
php -m
php -r "echo 'PHP fonctionne';"

Si vous installez PHP depuis les depots Sury (packages.sury.org) pour disposer de plusieurs versions en parallele, reactiver le depot apres la migration avec l'URL Trixie. Pour une installation securisee de PHP-FPM, consultez notre guide d'installation PHP-FPM securise sur VPS Linux.

Python 3.11 vers Python 3.13

Python 3.13 supprime les modules distutils et imp, deprecies depuis Python 3.10. Les scripts qui utilisent import distutils casseront. Remplacez distutils par setuptools.

Les environnements virtuels (venv) crees sous Python 3.11 ne sont pas compatibles avec Python 3.13. Recréez-les apres la migration :

rm -rf monenv/
python3 -m venv monenv
source monenv/bin/activate
pip install -r requirements.txt

Cles GPG et depots tiers

Le format de trousseau de cles change de .gpg a .pgp. Si vos depots tiers (Docker, Nginx, Node.js) referencent un fichier .gpg, mettez a jour le chemin dans leurs fichiers .sources ou .list sous /etc/apt/sources.list.d/.

Exemple pour le depot Docker officiel :

# Telecharger la cle mise a jour
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# Mettre a jour la source avec le bon nom de suite
echo "deb [signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/debian trixie stable" | sudo tee /etc/apt/sources.list.d/docker.list

OpenSSL 3.5 et algorithmes obsoletes

OpenSSL 3.5 desactive par defaut certains algorithmes consideres comme faibles (RSA inferieur a 2048 bits, SHA-1 pour les signatures). Si vos certificats TLS ou connexions utilisent ces algorithmes, ils echoueront apres la migration. Verifiez vos certificats :

openssl x509 -in /etc/ssl/certs/mon-certificat.pem -text -noout | grep "Signature Algorithm"

Paquets renommes ou supprimes

Certains paquets Bookworm ont ete remplaces par des paquets de transition dans Trixie. APT gere la plupart des transitions automatiquement, mais les paquets sans successeur seront supprimes. Apres la migration, listez les paquets obsoletes :

apt list '?obsolete' 2>/dev/null

Redemarrer et verifier la migration

Apres le full-upgrade, redemarrez le VPS pour charger le nouveau noyau Linux 6.12 :

sudo reboot

Reconnectez-vous en SSH et verifiez la version du systeme :

cat /etc/debian_version
# Doit afficher 13.x
uname -r
# Doit afficher un noyau 6.12.x

Verifiez que les services essentiels ont redemarre correctement. La commande systemctl liste les unites en echec :

systemctl --failed

Si un service systemd refuse de demarrer, consultez ses logs avec journalctl -u nom-du-service --no-pager -n 50.

Verifiez les points critiques un par un :

  • SSH : verifiez la configuration avec sshd -t. Si le fichier /etc/ssh/sshd_config contient des directives obsoletes, le service peut refuser de demarrer. Consultez notre guide securiser SSH sur VPS Linux pour les bonnes pratiques de configuration ;
  • Certificats TLS : verifiez que le renouvellement Let's Encrypt fonctionne avec sudo certbot renew --dry-run ;
  • Crontabs : les taches planifiees survivent a la migration, mais verifiez que les commandes referent des chemins valides (crontab -l pour l'utilisateur courant, sudo crontab -l pour root) ;
  • Bases de donnees : connectez-vous a MySQL/MariaDB ou PostgreSQL et executez une requete de test ;
  • Docker : si Docker est installe, verifiez que le daemon tourne avec docker info et que vos conteneurs redemarrent avec docker ps -a.

Nettoyez les paquets devenus inutiles apres la migration :

sudo apt autoremove --purge
sudo apt clean

Reactiver les depots tiers un par un, en remplacant bookworm par trixie dans leurs URL, puis lancez sudo apt update pour verifier qu'ils fonctionnent.

Apres la migration : automatiser les mises a jour

Une fois sur Debian 13, configurez les mises a jour automatiques de securite pour ne pas rater les prochains correctifs. Le paquet unattended-upgrades fonctionne de la meme maniere sur Trixie que sur Bookworm :

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Si vous administrez plusieurs VPS, un outil comme Ansible permet d'appliquer la migration et les verifications en serie. La distribution Linux que vous choisissez pour vos VPS determine le cycle de mise a jour auquel vous etes soumis : Debian privilegie la stabilite avec une version majeure tous les deux ans environ.

Conclusion

La migration de Debian 12 Bookworm vers Debian 13 Trixie est une operation sans risque si elle est preparee : sauvegarde complete, nettoyage des paquets obsoletes, passage en deux etapes (upgrade --without-new-pkgs puis full-upgrade), et verification methodique des services apres redemarrage. Le support complet de Bookworm est termine depuis juillet 2026 : rester sur une version en LTS reduit expose votre serveur a un perimetre de correctifs plus restreint.

Avec Trixie, vous beneficiez du noyau Linux 6.12, de PHP 8.4, Python 3.13 et de quatre ans de support complet. Pour les administrateurs qui gerent des serveurs de jeu, des applications web ou des services auto-heberges, c'est la base la plus solide jusqu'en 2030.

FAQ

Combien de temps prend la migration de Debian 12 vers Debian 13 sur un VPS ?

La migration prend entre 10 et 30 minutes selon le nombre de paquets installés et la puissance du VPS. Un VPS avec 2 vCPU et un stockage SSD NVMe termine généralement en moins de 15 minutes. Prévoyez du temps supplémentaire pour la sauvegarde préalable et la vérification des services après redémarrage.

Peut-on migrer directement de Debian 11 Bullseye vers Debian 13 Trixie ?

Non. Debian ne supporte que la migration d'une version majeure à la suivante. Si votre VPS est sous Debian 11 Bullseye, migrez d'abord vers Debian 12 Bookworm, puis vers Debian 13 Trixie. Sauter une version majeure risque de laisser le système dans un état incohérent.

La migration casse-t-elle les conteneurs Docker existants ?

Non. Les conteneurs Docker sont isolés du système hôte. Cependant, le paquet Docker doit être réinstallé depuis le dépôt officiel avec l'URL adaptée à Trixie. Après la mise à jour du dépôt et de Docker Engine, vos conteneurs et volumes restent intacts.

Faut-il recréer les environnements virtuels Python après la migration ?

Oui. Les environnements virtuels (venv) créés avec Python 3.11 ne fonctionnent pas avec Python 3.13. Supprimez le dossier du venv et recréez-le avec python3 -m venv, puis réinstallez les dépendances depuis votre fichier requirements.txt.

Que faire si un service systemd ne redémarre pas après la migration ?

Consultez les logs avec journalctl -u nom-du-service --no-pager -n 50. Les causes les plus fréquentes sont un fichier de configuration incompatible (directive obsolète ou chemin modifié) ou un paquet manquant. Vérifiez aussi que le service est activé au démarrage avec systemctl is-enabled nom-du-service.

La migration est-elle réversible ?

Debian ne supporte pas le retour en arrière vers une version antérieure. C'est pourquoi la sauvegarde préalable et le snapshot de la machine virtuelle sont indispensables. En cas d'échec, restaurez le snapshot ou réinstallez Debian 12 et restaurez vos données depuis la sauvegarde.

Debian 12 est-il encore supporté si je ne migre pas ?

Debian 12 Bookworm est en phase LTS depuis le 12 juillet 2026. L'équipe LTS assure les correctifs de sécurité pour environ 230 paquets jusqu'au 30 juin 2028. Après cette date, plus aucune mise à jour de sécurité ne sera publiée pour Bookworm.

Mon serveur de jeu (FiveM, Minecraft, Rust) sera-t-il impacté par la migration ?

Les serveurs de jeu qui tournent dans des conteneurs Docker ne sont pas impactés directement. Les serveurs installés nativement peuvent nécessiter une recompilation ou une mise à jour si leurs binaires dépendent de bibliothèques système spécifiques (glibc, libstdc++). Vérifiez la compatibilité avec Debian 13 dans la documentation de votre serveur de jeu avant de migrer.

Le format des sources APT change-t-il avec Debian 13 ?

Oui. Debian 13 adopte le format deb822 avec des fichiers .sources dans /etc/apt/sources.list.d/ à la place de l'ancien format une ligne par dépôt. L'ancien format reste fonctionnel mais est déprécié. La commande apt modernize-sources convertit automatiquement vos sources vers le nouveau format.

Comment vérifier que la migration a réussi ?

Exécutez cat /etc/debian_version (doit afficher 13.x), uname -r (doit afficher un noyau 6.12.x), et systemctl --failed (doit être vide). Vérifiez aussi les versions de PHP (php -v), Python (python3 --version) et les connexions aux bases de données.