Où en est-on depuis le 31 août 2026
Debian a fourni deux ans de support long terme à Debian 11 (bullseye), jusqu'au 31 août 2026. Cette date est passée : le projet Debian ne publie plus de correctifs de sécurité pour cette version. Plesk a aligné son calendrier : l'annonce du 15 octobre 2026 indique que Plesk Obsidian 18.0.81 est la dernière version qui prend en charge Debian 11, et que le serveur peut soit être mis à niveau vers Debian 12 avec l'outil de dist-upgrade de Plesk, soit être remplacé par un serveur sous un système supporté, vers lequel on migre les domaines.
Concrètement, un serveur Debian 11 continue de tourner et de servir ses sites. Mais il ne recevra plus de mise à jour Plesk au-delà de la 18.0.81, et plus de correctif de sécurité côté système. Le risque ne se voit pas : il grandit à bas bruit, jusqu'à la première faille publiée contre un paquet que personne ne corrigera.
Ce que change le fait de rester sous Debian 11
- Plus de correctifs Debian — le support long terme du projet s'est arrêté le 31 août 2026 ; les failles découvertes ensuite restent ouvertes.
- Plesk figé — les versions 18.0.82 et suivantes ne s'installent pas et ne se mettent pas à jour sur Debian 11.
- Support payant tiers possible, mais hors Debian — des prestataires proposent une sécurité étendue jusqu'au 30 juin 2031 ; ce n'est pas un service du projet Debian, et l'annonce de Plesk ne mentionne aucune prise en charge de ce dispositif.
- Intégrations en retard — Plesk prévoit de retirer dans la version 18.0.82 les versions du protocole XML-RPC antérieures à 1.6.9.1 ; une intégration de facturation ou de gestion qui s'appuie sur une version plus ancienne cessera de répondre.
- Une dette qui grossit — plus on attend, plus l'écart avec la version cible est large et plus l'intervention coûte cher le jour où elle devient urgente.
Dist-upgrade ou migration : le critère de décision
La documentation de Plesk présente deux façons de mettre à niveau le système d'un serveur : migrer vers un serveur qui tourne déjà sur un OS plus récent avec Plesk Migrator, ou faire un dist-upgrade en place. Elle recommande la migration, parce que le dist-upgrade n'est pas un processus simple : il demande une expérience solide d'administration système et la connaissance des composants de l'OS. Elle déconseille aussi de le combiner avec des mises à jour de Plesk, qu'il faut donc faire avant.
La règle pratique qui en découle : migrez par défaut les serveurs critiques ou chargés de modules tiers, et réservez le dist-upgrade aux machines simples, bien sauvegardées, que vous pouvez cloner et tester d'abord. Le dist-upgrade impose une coupure complète de Plesk, des sites et du courrier pendant toute la conversion ; la migration, elle, laisse l'ancien serveur en service jusqu'à la bascule.
Dist-upgrade en place ou migration vers un serveur neuf
Faites défiler le tableau
| Critère | Dist-upgrade (outil Plesk) | Migration (Plesk Migrator) |
|---|---|---|
| Recommandation de Plesk | Possible, mais pas un processus simple | Voie recommandée |
| Indisponibilité | Plesk, sites et e-mails coupés pendant toute la conversion, 20 à 30 minutes annoncées | L'ancien serveur reste en ligne jusqu'à la bascule |
| Redémarrages | Trois, avec reprise automatique par le service plesk-dist-upgrader | Aucun sur le serveur d'origine |
| Retour arrière | Snapshot et sauvegarde ; l'option de retour de l'outil ne couvre que l'avant mise à niveau des paquets | L'ancien serveur reste intact tant que vous ne l'éteignez pas |
| Prérequis | Plesk à jour, 5 Go libres, 2 Go de RAM, module Remote management, hors conteneur | Un serveur neuf sous un OS supporté, et un transfert de données |
| Adapté à | Serveur simple que l'on peut cloner et tester | Serveur critique, modules tiers, ou OS à renouveler de toute façon |
Inventorier le parc avant de décider
Avant de choisir une voie, il faut savoir où l'on en est, serveur par serveur. Sur chaque machine, cat /etc/os-release donne la version du système : une valeur VERSION_ID de 11 désigne un serveur concerné. plesk -v affiche la version de Plesk installée, plesk installer list les versions disponibles à l'installation, et apt list --upgradable les paquets en attente de mise à jour. Notez les résultats dans un tableau du parc, avec le client, le rôle du serveur, les modules tiers installés et la date de dernière sauvegarde.
Ordonnez ensuite par criticité. Commencez par une machine de test ou à faible enjeu pour éprouver la procédure, puis traitez les serveurs par importance croissante, en prévenant les clients de la coupure avant chaque intervention. Vérifiez aussi que le serveur n'est pas un conteneur : l'outil ne s'y applique pas, et seul votre hébergeur peut confirmer le type d'environnement.
Préparer le dist-upgrade vers Debian 12
Vérifier l'éligibilité
L'outil de Plesk pour Debian 11 vers Debian 12 demande Plesk Obsidian 18.0.57 ou plus. Contrôlez avec
plesk -v. Vérifiez 5 Go d'espace disque libre et 2 Go de RAM, et que le serveur n'est ni un conteneur Virtuozzo ni un conteneur Docker.Mettre Plesk à jour d'abord
Passez Plesk à la dernière version disponible avant de toucher à l'OS : Plesk déconseille de combiner le dist-upgrade avec des mises à jour de Plesk. Contrôlez les paquets en attente avec
apt list --upgradable.Installer le module Remote management
L'outil exige que le module Remote management soit installé : sans lui, vous risquez de perdre l'accès au serveur si le service SSH ne redémarre pas pendant la conversion.
Sauvegarder, puis créer un snapshot
Faites une sauvegarde complète du serveur, bases de données comprises, puis un snapshot côté hyperviseur ou chez votre hébergeur. Le snapshot est votre vrai retour arrière : l'option de retour de l'outil peut elle-même échouer.
Tester sur un clone
Si vous n'avez jamais fait de dist-upgrade, restaurez le snapshot sur une machine de test et déroulez toute la procédure dessus. Vous y verrez les blocages, la durée réelle et le comportement de vos modules tiers avant de risquer la production.
Annoncer la coupure
Prévenez les clients : Plesk, les sites hébergés et les e-mails sont indisponibles pendant toute la conversion, que la page de l'outil estime entre 20 et 30 minutes. Choisissez une fenêtre creuse et prévoyez une marge, car la durée dépend du serveur.
Lancer la conversion et la suivre
Connectez-vous en root, téléchargez l'outil depuis la page des versions du dépôt plesk/debian11to12 et rendez-le exécutable. La page du dépôt donne l'exemple wget https://github.com/plesk/debian11to12/releases/download/v1.0.7/debian11to12-1.0.7.zip, puis unzip debian11to12-1.0.7.zip et chmod 755 debian11to12 ; relisez la liste des versions pour prendre la plus récente. Lancez ensuite l'outil dans une session screen, afin qu'une coupure SSH n'interrompe pas la conversion : screen -S debian11to12, puis ./debian11to12. Pour reprendre la main après une déconnexion, screen -r debian11to12. Avant de lancer, ./debian11to12 --show-plan affiche les étapes prévues.
Suivre et reprendre une conversion
Surveiller l'avancement
Depuis une autre session,
./debian11to12 --statusdonne l'état et./debian11to12 --monitorouvre un suivi en direct. Le journal est écrit dans/var/log/plesk/debian11to12.log.Attendre les trois redémarrages
La conversion impose trois redémarrages. Après le premier, le service systemd plesk-dist-upgrader reprend le travail seul. Vous pouvez contrôler son état avec
systemctl status plesk-dist-upgraderet lire ses messages avecjournalctl -u plesk-dist-upgrader.Relancer si le processus est interrompu
Si l'interruption a eu lieu avant le premier redémarrage, relancez avec l'option
--resume. Si elle survient après, exécutezsystemctl restart plesk-dist-upgrader.Revenir en arrière si l'échec est précoce
Si la conversion échoue pendant la phase de préparation, avant la mise à niveau des paquets, l'option
--revertrétablit Plesk. Passé ce point, elle ne peut plus défaire les changements : c'est le snapshot qui prend le relais.Vérifier le message de fin
À la fin, un message de l'outil indique que le serveur a été mis à niveau vers Debian 12 ; vous pouvez le retirer de
/etc/motd. Contrôlez ensuitecat /etc/os-release,plesk -v, l'ouverture du panneau, quelques sites, l'envoi et la réception d'un e-mail, et les sauvegardes planifiées.
Modules tiers et protection du serveur : vérifier avant, pas après
La page du dépôt de l'outil ne mentionne pas Imunify360, ni aucun autre module de sécurité tiers. Ce silence ne vaut ni feu vert ni feu rouge : avant de convertir un serveur qui en porte, demandez à l'éditeur de chaque module s'il prend en charge Debian 12 avec votre version de Plesk, et testez sur le clone. Faites le même contrôle pour les extensions Plesk, les tâches planifiées personnalisées et les règles de pare-feu.
Dépanner une conversion qui bloque
Le cas le plus documenté concerne les disques multiples. Avec la version 1.0.7 de l'outil, un serveur BIOS en RAID logiciel peut s'arrêter pendant la préparation avec le message Grub's install-device is not found: /dev/sda, /dev/sdb, alors que les deux disques existent : le contrôle lit la liste de périphériques séparés par des virgules comme un seul chemin. Le dépôt indique que le correctif est dans le code source mais pas dans l'archive de la version 1.0.7 ; utilisez une version ou une construction qui l'inclut. Pour distinguer ce faux positif d'un disque réellement absent, inspectez le système sans lancer la conversion avec debconf-show grub-pc et lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINT.
Le dépôt prévient aussi : ne retirez pas une cible GRUB valide et ne contournez pas le contrôle pour qu'il passe. Si un périphérique configuré manque vraiment, corrigez d'abord la configuration de démarrage. Pour tout autre blocage, ./debian11to12 --prepare-feedback produit une archive à joindre à un ticket GitHub.
Choisir la migration : ce qu'elle change pour le parc
Migrer vers un serveur neuf revient à reconstruire une machine saine et à y déplacer les domaines avec Plesk Migrator. Vous y gagnez un système propre, un ancien serveur intact jusqu'à la bascule et un retour arrière trivial. Vous y perdez du temps de préparation : un serveur à provisionner, un transfert de données, un changement de DNS à planifier, et des certificats et boîtes e-mail à recontrôler après la bascule. Pour un serveur critique, ce coût est souvent inférieur au risque d'une coupure sans issue de secours.
Pour une agence : un chantier de parc, pas de serveur
Pour une agence qui porte plusieurs serveurs Plesk, la mise à niveau d'OS est un chantier de parc : trois redémarrages par machine, des fenêtres de coupure à négocier client par client et des modules tiers à valider un par un. Une alternative consiste à confier l'infrastructure à un prestataire qui la tient pour vous : vous gardez la relation client, nous tenons l'infrastructure. Si vos serveurs ont aussi besoin de licences Plesk, la page des licences Plesk détaille ce qui est disponible. Une administration de serveur reste une option à part, jamais incluse par défaut.
La documentation officielle
Annonce de Plesk Obsidian 18.0.81 : https://www.plesk.com/blog/plesk-news-announcements/plesk-obsidian-18-0-81-is-now-available/
Page de la version Debian 11 (bullseye) : https://www.debian.org/releases/bullseye/
Procédure de dist-upgrade Plesk : https://support.plesk.com/hc/en-us/articles/12377714344983
Outil de conversion Debian 11 vers 12 : https://github.com/plesk/debian11to12
La page de documentation Plesk sur le support du dist-upgrade présente la recommandation de migration : https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/dist-upgrade-support.74627/
