L’équipe LTS de Debian a publié son annonce le 31 août 2026 : Debian 11 Bullseye est en fin de vie, cinq ans après sa publication initiale du 14 août 2021. À partir de septembre, plus aucune mise à jour de sécurité ne sortira pour cette version.
Et pourtant, ce matin, votre serveur a démarré normalement, le site répond, les mails partent, rien ne signale quoi que ce soit. Le danger est là : il ne se passe rien de visible, donc personne ne fait rien, et la machine continue de tourner pendant des mois avec des vulnérabilités publiées que plus personne ne corrige. Si vous n’avez pas d’administrateur système en interne pour suivre ça, c’est le genre de sujet que couvre l’infogérance de serveurs Linux.
Debian 11 fin de vie : je détaille plus bas les conséquences réelles, la commande qui vous répond en 30 secondes, et les options qui vous restent.
Au 1er septembre 2026, Debian ne corrige plus rien
Debian ne publie plus de correctifs de sécurité pour Bullseye. Concrètement, la prochaine faille sérieuse dans OpenSSH, dans le noyau ou dans une bibliothèque système ne donnera plus lieu à un paquet corrigé dans les dépôts officiels, et votre apt upgrade vous répondra que tout est à jour alors que ce n’est plus vrai depuis longtemps.
Un sous-ensemble de paquets reste pris en charge par des intervenants extérieurs, via le dispositif Extended LTS. C’est payant, c’est partiel, et ça ne couvre pas l’ensemble de ce qui tourne sur un serveur web ordinaire. C’est un sursis pour les parcs qui ne peuvent pas bouger tout de suite, rien de plus.
Debian 12 Bookworm devient donc la version oldstable suivie, avec un suivi à long terme annoncé jusqu’au 30 juin 2028, sur les architectures amd64, i386, arm64, armhf et ppc64el. Ça vous laisse presque deux ans de tranquillité si vous migrez maintenant, ce qui est le point important : vous n’avez pas besoin de sauter sur la version la plus récente, une version stable et supportée suffit.
Comment savoir si vous êtes concerné
Deux commandes en SSH, et vous avez la réponse :
# cat /etc/debian_version 11.11 # lsb_release -ds Debian GNU/Linux 11 (bullseye)
Si vous lisez 11.x ou bullseye, vous êtes concerné.
Le cas typique, c’est le VPS commandé en 2022 ou 2023, installé avec l’image Debian 11 proposée par défaut à ce moment-là, puis jamais touché parce que le site marchait. Une distribution installée une fois, mise à jour par apt upgrade de temps en temps, et jamais migrée d’une version majeure à l’autre. Si votre machine est un VPS ou un dédié chez OVH, l’image d’installation d’origine vous dira tout de suite à quoi vous avez affaire.
Regardez aussi votre version de PHP dans la foulée. Debian 11 livre PHP 7.4, qui n’est plus supporté par ses propres développeurs depuis fin 2022. Si votre WordPress ou votre Dolibarr tourne encore là-dessus, vous avez deux problèmes de sécurité empilés.
Debian 11 fin de vie : les trois options pour votre serveur
| Option | Conséquences | Pour qui |
|---|---|---|
| Migrer vers Debian 12 Bookworm | Passage de PHP 7.4 à 8.2, de MariaDB 10.5 à 10.11, de PostgreSQL 13 à 15. Suivi de sécurité jusqu’au 30 juin 2028 | La majorité des serveurs en production, dont les applications ne sont pas certifiées au delà |
| Viser directement Debian 13 Trixie | Deux sauts de version majeure à enchaîner, donc deux fois plus de configurations à reprendre, mais une seule fenêtre d’interruption | Les serveurs récents, dont vous maîtrisez la totalité de la pile applicative |
| Souscrire à l’Extended LTS | Correctifs sur un sous-ensemble de paquets seulement, contre paiement, sans rien résoudre sur le fond | Les parcs importants qui ont besoin de temps pour planifier, pas les serveurs isolés |
Il existe une quatrième option, ne rien faire, et c’est celle que choisissent la plupart des gens sans s’en rendre compte. Elle se paye plus tard, et rarement à un moment qui vous arrange.
Migrer de Debian 11 vers Debian 12 : les services qui ne se relancent pas
La migration elle-même n’est pas compliquée sur une installation propre. Le temps part dans les services qui ne se relancent pas parce que leur configuration a changé ou est devenue incompatible.
Les points de rupture qui reviennent le plus souvent :
- PHP 7.4 vers 8.2. C’est le vrai sujet pour un site en production. Une extension abandonnée, une syntaxe qui n’existe plus, un thème qui n’a pas été mis à jour depuis trois ans, et la boutique ne répond plus après le redémarrage. Ça se teste avant la migration.
- rsyslog remplacé par systemd-journald. Vos scripts de surveillance qui font un
tailsur/var/log/ne trouvent plus rien, il faut passer parjournalctl. - Le paquet
ntpremplacé parntpsec. Sans démon de synchronisation, c’estsystemd-timesyncdqui prend la main, avec un comportement différent. - Puppet 5 vers Puppet 7. Si vous gérez un parc, le puppetmaster se met à jour avant tous les autres serveurs, sans exception.
- Python 3.9 vers 3.11, avec l’interdiction par défaut d’installer des paquets Python non empaquetés par Debian. Tout ce qui a été installé à coups de
pip installen dehors d’un environnement isolé est à revoir avecpipxou unvenv. - OpenSSH 8.4 vers 9.2, qui peut refuser des algorithmes anciens si vos accès datent.
La procédure complète, commande par commande, est publiée dans mon mémo technique : mettre à jour Debian 11 vers Debian 12 Bookworm. C’est le document que je consulte moi-même quand je le fais, avec le tableau des versions de paquets, les fichiers sources.list à reprendre et la séquence de mise à jour minimum puis complète. Si vous enchaînez ensuite vers la version suivante, le mémo Debian 12 vers Debian 13 Trixie prend la suite. Et pour la référence officielle, il y a le chapitre « Mises à niveau » des notes de publication de Bookworm.
Avant de lancer la moindre commande
Une mise à jour de version majeure peut mal se passer, détruire des données, rendre le serveur non bootable. Donc dans l’ordre, et sans en sauter :
- Sauvegarde à distance, dans un autre datacenter que celui de la machine.
- Export SQL des bases avant la sauvegarde des fichiers, parce qu’une copie de fichiers de base de données à chaud ne vaut rien.
- Snapshot de la machine virtuelle en plus, si c’en est une.
- Vérifier que vous savez redémarrer en mode rescue, et pas le découvrir à 23h avec un serveur qui ne boote plus.
- Prévoir un créneau calme, avec du temps devant vous pour réparer.
Le point 4 est celui qu’on saute le plus souvent, et c’est celui qui vous coûte le week-end.
Je ne fais pas de dist-upgrade sur une machine que je ne connais pas
Je ne mets pas à jour sur place un serveur Debian 11 que je n’ai pas installé. Je prépare un nouveau serveur propre, sous contrôle, conforme à ma stack, et je migre les services dessus.
La raison est simple : une machine installée il y a cinq ans a accumulé des dépôts tiers, des paquets compilés à la main, des fichiers de configuration modifiés par trois personnes différentes et des services dont plus personne ne sait à quoi ils servent. Faire un full-upgrade là dedans sans inventaire préalable, je ne le fais pas. La cible de la migration se décide avec vous, VPS, instance cloud ou serveur dédié, mais la machine est neuve.
Si vous voulez d’abord savoir ce que contient réellement votre serveur avant d’arbitrer, c’est l’objet d’un audit serveur.
À faire cette semaine
Lancez cat /etc/debian_version sur toutes vos machines, aujourd’hui. Vous saurez combien de serveurs sont sortis du support, et vous pourrez décider en connaissance de cause au lieu de l’apprendre le jour où une faille est exploitée.
Si le résultat vous inquiète, ou si personne chez vous n’a envie de porter cette migration, écrivez-moi via le formulaire de contact avec le nombre de serveurs concernés et ce qui tourne dessus. Je vous dis ce qui est urgent et ce qui peut attendre.
Ceci n’est pas un guide pour migrer seul un serveur en production.