Mise à jour de Plesk Obsidian : nouvelles fonctionnalités pour les hébergeurs

Distinguer clairement la version et les composants

La situation telle qu'elle a été consignée au 2 octobre 2026 est la suivante pour le produit phare Plesk Obsidian 18.0.81, mise à jour 2. Cette mise à jour a été publiée le 29 septembre 2026 et corrige un problème de sécurité critique. Les nouvelles fonctionnalités du panneau décrites dans cet article font partie de la version Plesk Obsidian 18.0.81 du 15 septembre 2026 ; en revanche, la mise à jour 1 et la mise à jour 2 contiennent des corrections de bogues et de sécurité documentées.

Des mises à jour ultérieures peuvent néanmoins exister sans modifier la version de base 18.0.81 Update 2 : Le journal des modifications mentionne par exemple des mises à jour pour des extensions telles que SSL It! et Let’s Encrypt datant du 29 septembre, ainsi que des mises à jour des paquets PHP datant du 30 septembre 2026. Quiconque se contente de parler d’un „ Plesk à jour “ omet donc une information importante pour la planification et l’assistance.

Plesk distingue plusieurs niveaux de mise à jour. Les packs Plesk constituent le panneau de contrôle lui-même et ses fonctionnalités directement associées. À cela s'ajoutent les packs de services et les extensions fournis par Plesk, qui offrent des fonctionnalités supplémentaires ou permettent de se connecter à des services externes. Un nouveau numéro de version d'une extension ne signifie donc pas nécessairement que le cœur de Plesk a également été mis à jour – et inversement.

De plus, chaque Panneau d'hébergement Au sein d'un système d'exploitation, il existe d'autres niveaux : les paquets du système d'exploitation ainsi que les composants tiers, tels que les bases de données, les moteurs d'exécution PHP, les serveurs Web et les services de messagerie. Leurs sources de paquets, leurs cycles de support et leurs dépendances ne suivent pas nécessairement le rythme de publication de Plesk. Pour un hébergeur, cette distinction revêt une importance pratique, car les types de pannes, les fenêtres de maintenance et les responsabilités peuvent varier en fonction du composant concerné.

La documentation de l'environnement doit donc toujours mentionner la combinaison précise : version de Plesk avec numéro de mise à jour, version des extensions installées, système d'exploitation et paquets d'exécution pertinents. Pour les fonctions liées aux certificats ou aux applications, l'intégration utilisée doit également être indiquée. Cela permet ainsi de déterminer si une modification provient de SSL It!, d’une intégration Let’s Encrypt ou du noyau du panneau de contrôle. Cela évite les attentes ambiguës lors des annonces destinées aux clients et facilite le ciblage des problèmes lors de l’assistance.

Comment les mises à jour de Plesk affectent les fournisseurs

Au sein de la branche Obsidian 18.0, les mises à jour sont publiées de manière continue et séquentiel installé. Il n’est pas possible de sauter certaines mises à jour intermédiaires. Cela permet de définir un parcours de mise à jour précis, mais ne dispense pas un hébergeur de vérifier son propre environnement : plus un serveur héberge de sites web de clients, de dépendances PHP spécifiques et d’extensions, plus il est important de déterminer quelle modification affecte quelle classe de service.

Plesk décrit les mises à jour automatiques pour ses propres mises à jour et propose des options distinctes pour les composants tiers fournis ainsi que pour les paquets système. La page de documentation fournit toutefois des informations contradictoires concernant l'état par défaut de l'option relative aux composants tiers. Les administrateurs ne doivent donc pas partir du principe qu’il existe un paramètre par défaut valable globalement, mais vérifier les options effectivement définies pour chaque serveur sous Tools & Settings > Update Settings Vérifier. Il convient de faire preuve d'une prudence particulière, car les composants récents peuvent s'avérer incompatibles avec les sites web hébergés.

Pour l'exploitation de nombreuses instances client, cette distinction constitue un avantage lorsqu'elle est transposée en processus. Les corrections apportées au panneau de configuration et les modifications de sécurité peuvent être planifiées en fonction de leur ampleur ; les changements de composants font quant à eux l'objet d'une évaluation de compatibilité distincte. Une offre d’hébergement géré n’est pas tenue d’adopter immédiatement toutes les versions de paquets disponibles. Ce qui importe, c’est de déterminer quelles versions correspondent à la pile logicielle promise, à la base de clients testée et au modèle d’assistance prévu.

Les avantages des dernières versions d'Obsidian se répartissent sur plusieurs domaines d'activité : les fonctions de diagnostic permettent de structurer l'assistance de premier niveau, les nouveaux outils d'hébergement d'applications élargissent les options tarifaires, tandis que les fonctions de certification et d'assistance concernent la sécurité et la gestion des droits. L'article présente également les fondements et les évolutions antérieures de la gamme de produits. Plesk Obsidian 2025 : des nouveautés révolutionnaires pour l'hébergement web . Pour le lancement actuel, c'est toutefois la composition exacte qui fait foi, et non pas uniquement le nom du produit.

L'automatisation ne constitue donc pas une décision de validation générale. Il est judicieux d'opérer une distinction entre l'installation régulière de mises à jour Plesk documentées et les modifications apportées de manière ciblée à la pile du client. Sur les serveurs partagés notamment, cette distinction permet d’éviter qu’un changement de composant passé inaperçu n’affecte simultanément de nombreux sites web indépendants les uns des autres. Elle ne remplace pas les tests, mais rend les risques visibles et identifiables.

Nouvelles fonctionnalités selon le scénario d'hébergement

Dans le cadre de l'hébergement mutualisé, l'un des premiers cas d'utilisation consiste à identifier plus rapidement les dysfonctionnements liés aux noms de domaine. Les données contenues dans Plesk Obsidian 18.0.81 : le diagnostic DNS accessible à tous regroupe des vérifications portant sur la résolution, les aspects liés aux enregistrements MX, le protocole DNSSEC, les serveurs de noms et l'expiration du domaine. Le rapport clair et lisible affiché dans le panneau de contrôle peut aider les techniciens du support à examiner de manière structurée les problèmes liés au DNS, à la messagerie et à la délégation avant qu'ils ne s'aggravent.

Ce rapport est toutefois un Diagnostic et aucune correction automatique. Les alias de domaine, en particulier, ne sont actuellement pas pris en charge. Même si un résultat indique une délégation ou une zone erronée, la correction peut, le cas échéant, incomber au registraire ou à un opérateur DNS externe. En tant qu’outil d’assistance, cette fonctionnalité s’avère donc particulièrement utile lorsque les responsabilités et la prochaine étape d’escalade sont clairement définies dans le ticket.

Un deuxième domaine est Hébergement d'applications pour les agences et les développeurs. Node.js Toolkit 2.5.0 propose désormais une vue d'ensemble centralisée des applications Node.js activées et permet la configuration en un clic des projets existants. La détection automatique prend en charge plusieurs frameworks serveur courants ainsi que des front-ends statiques. De plus, l'extension pnpm est prise en charge exclusivement sous Plesk pour Linux. Cela réduit les étapes répétitives, mais ne garantit pas que chaque déploiement individuel puisse être repris tel quel.

La nouvelle extension Python 1.0.0 prend également en charge les systèmes Linux et offre une prise en charge de Python par domaine, des environnements virtuels, la gestion des dépendances, des variables d'environnement et le stockage chiffré des secrets. Les applications s'exécutent sous forme d'applications WSGI via Phusion Passenger ; l'autorisation „ Python support management “ peut être gérée via des plans de service et des abonnements. Cela peut devenir une fonctionnalité tarifaire contrôlée, mais ne remplace pas automatiquement toute architecture Python.

Un troisième domaine concerne les certificats et les fonctions d'assistance. Dans la version 18.0.81, SSL It! prend en charge la validation DNS comme alternative à la validation HTTP pour les intégrations « ext-acme » et « ext-letsencrypt » mentionnées. Cela s'applique notamment aux domaines dont le port 80 n'est pas ouvert. Il reste toutefois nécessaire de disposer d’un moyen approprié pour créer des enregistrements DNS dans la zone effectivement concernée ; le simple fait d’afficher un enregistrement ne confère pas de droits d’écriture.

MCP est désactivé par défaut dans la version 18.0.81 et peut être connecté via un compte WebPros. Les administrateurs définissent dans panel.ini les types d'utilisateurs autorisés à se connecter aux clients MCP. Son adéquation ne dépend donc pas uniquement de la fonction, mais aussi des rôles, des autorisations et de la journalisation. Les fonctionnalités d’extension spécifiques à la plateforme, la gestion externe du DNS et l’architecture de l’application client déterminent globalement quelle nouveauté doit être incluse dans quelle formule.

Comparaison des fonctionnalités pour la planification des produits

Pour la planification des produits, la désignation « Plesk Obsidian » ne suffit pas : les fonctionnalités concernées ici proviennent en partie du produit de base et en partie d'extensions dont les versions sont gérées séparément. C'est pourquoi un fournisseur ne devrait pas évaluer les fonctionnalités uniquement en fonction de leur utilité, mais doit également intégrer dans son catalogue tarifaire le système d'exploitation, le modèle de licence et les dépendances techniques de chacune d'entre elles.

Ce tableau établit une distinction particulièrement claire entre une fonctionnalité de plateforme et une prestation tarifaire commercialisable. Le diagnostic DNS peut être largement utilisé comme outil d'assistance. Python, en revanche, ne doit être inclus que dans les offres Linux dont la gestion des droits et les limites d'assistance sont prévues à cet effet. Dans le cas de Node.js, le fournisseur doit distinguer les différentes fonctionnalités : pnpm est documenté comme étant exclusif à Linux, tandis que le journal des modifications (changelog) n'impose pas de restrictions correspondantes concernant la vue d'ensemble centrale et la configuration automatique.

Les fonctionnalités liées aux certificats et au MCP nécessitent elles aussi un choix de produit plutôt qu'une activation globale. Avec DNS-01, c'est la responsabilité de la zone qui détermine la faisabilité pratique. Dans le cas du MCP, la connexion technique ne constitue qu’une partie du projet ; ce qui est déterminant, ce sont le cercle des personnes autorisées, la traçabilité des processus et la gestion des actions ayant des effets secondaires.

Diagnostic DNS et certificats dans l'assistance

La version de Plesk Obsidian 18.0.81 désormais disponible au grand public Diagnostic génétique Cela constitue une première évaluation technique d'un ticket de domaine. Dans le panneau, l'option „ Troubleshoot DNS “ ouvre un rapport clair sur la résolution DNS, les vérifications liées aux enregistreurs MX, le protocole DNSSEC, les problèmes de serveurs de noms et la date d'expiration du domaine. Cela permet de raccourcir l’examen préliminaire, mais ne remplace ni l’analyse de la zone d’autorité, ni la concertation avec le registraire ou l’opérateur DNS externe.

Pour garantir un processus de premier niveau reproductible, le service d'assistance doit d'abord enregistrer le domaine principal concerné et le rapport, puis déterminer la responsabilité et la nature de l'anomalie. Si le rapport fait par exemple état d'une délégation erronée, la correction ne relève souvent pas de la compétence du panel. Il est également important de noter la limite documentée : les alias de domaine ne sont actuellement pas pris en compte dans cette vérification.

Pour le diagnostic en ligne de commande, le journal des modifications documente l'appel suivant avec un domaine d'exemple neutre. Avant toute utilisation, un administrateur doit vérifier l'aide ou la documentation relative aux commandes de la version de Plesk effectivement installée. La syntaxe mentionnée dans le journal des modifications ne permet à elle seule pas de garantir l'ensemble des effets de la commande.

plesk repair dns -n -j -check-resolution example.com

Fonctionnalités étendues pour les certificats Validation DNS-01 le domaine d'application possible : SSL It ! peut être utilisé dans Plesk Obsidian 18.0.81 comme alternative à la validation HTTP pour l'émission et le renouvellement. Cela concerne notamment les domaines API ou de messagerie pour lesquels le port 80 n'est délibérément pas ouvert. Plesk affiche les enregistrements DNS requis et enregistre la méthode choisie pour chaque domaine en vue des renouvellements ultérieurs.

Cependant, le processus ne se déroule pas automatiquement avec succès simplement parce qu'un enregistrement s'affiche. L'opérateur doit disposer d'un accès en écriture à la zone DNS réellement concernée ou d'un processus d'automatisation correctement configuré. Selon le journal des modifications, la validation DNS introduite avec la version 18.0.81 ne s'applique qu'aux intégrations « ext-acme » et « ext-letsencrypt » de SSL It !, et non de manière générale à tous les fournisseurs de certificats.

La mise à jour d'extension qui suivra est distincte de celle-ci SSL It! 1.24.0 du 29 septembre 2026. Cette version permet de sécuriser un domaine sans hébergement à l'aide d'un certificat « wildcard » via le panneau de configuration ou la ligne de commande ; le renouvellement automatique s'effectue également sous la forme d'un certificat « wildcard ». Cet ajout ne fait pas partie des fonctionnalités d'origine de Plesk Obsidian 18.0.81, mais suit son propre cycle de versions et de publication.

L'hébergement d'applications en tant qu'option tarifaire contrôlée

Grâce aux dernières extensions, l'hébergement d'applications se distingue désormais plus clairement en tant qu'option tarifaire. Le Node.js Toolkit 2.5.0 propose une vue d'ensemble centralisée des applications Node.js activées et permet de configurer en un clic les projets existants. De plus, cette extension prend en charge le gestionnaire de paquets pnpm sous Plesk pour Linux. Cela permet à un fournisseur de standardiser les tâches de configuration récurrentes sans avoir à traiter chaque application client comme une instance de serveur individuelle.

Selon le journal des modifications, la détection de projet prend notamment en charge Express, Next.js, NestJS et Nuxt.js, ainsi que les interfaces statiques basées sur React, Vue.js, Angular ou Vite. Plesk peut créer un fichier de démarrage compatible avec Passenger, prendre en compte les ports codés en dur et définir le répertoire racine, les modifications étant affichées avant confirmation. Les interfaces frontales statiques sont générées et fournies sans processus Node.js fonctionnant en permanence.

Cette automatisation est utile, mais ne remplace pas une revue d'architecture. Plusieurs processus, files d'attente de travailleurs, proxys inversés spécifiques, secrets externes ou pipelines de build personnalisés peuvent nécessiter des règles d'exploitation supplémentaires. Selon le journal des modifications, la restriction concernant Linux s'applique expressément à pnpm ; aucune restriction de plateforme correspondante n'y est mentionnée pour la vue d'ensemble centralisée des domaines et la configuration automatique en un clic. Les descriptions des offres devraient donc mentionner ces sous-fonctionnalités séparément.

La version 1.0.0 de l'extension Python offre, sous Linux, une gestion distincte par domaine. Les clients peuvent créer des environnements virtuels, installer des dépendances via l'interface utilisateur, consulter les métadonnées issues du fichier pyproject.toml et gérer les variables d'environnement ainsi que les secrets stockés de manière chiffrée. L'activation s'effectue via l'autorisation „ Python support management “ dans les plans de service et les abonnements.

D'un point de vue technique, ces applications s'exécutent sous la forme de Applications WSGI via Phusion Passenger ; la configuration du serveur web est générée automatiquement par Plesk. Un forfait „ Python Web App “ peut donc, par exemple, inclure des environnements virtuels, un cadre de ressources défini et une assistance pour les projets WSGI classiques. Cela ne signifie pas pour autant que ce même forfait couvre des piles ASGI complexes, des workers fonctionnant en continu ou des architectures spécialisées conteneurisées.

Pour mieux comprendre les anciennes fonctionnalités et les modifications apportées à l'interface, vous pouvez consulter l'article Plesk Obsidian : aperçu des nouveautés et des améliorations peuvent être utilisées à titre complémentaire. Pour les nouveaux tarifs, il reste essentiel de documenter conjointement la version étendue, les limites documentées de la plateforme, les autorisations et le type d'application concrètement pris en charge.

Déployer les mises à jour de manière échelonnée en production

Dans un environnement de fournisseur d'hébergement, la mise à jour du panneau d'hébergement ne doit pas démarrer dès le premier clic sur le serveur principal en production. Commencez par créer un Inventaire des versions de Plesk, des versions du système d'exploitation, des extensions activées et des applications client qui y sont exécutées. Les dépendances externes telles que les fournisseurs DNS, les relais de messagerie, les sauvegardes, les paquets PHP personnalisés et les processus de déploiement sont également importantes. Cela permet d’identifier les systèmes qui ont le même niveau de mise à jour et les cas particuliers qui doivent être traités séparément.

Vérifiez ensuite les dépendances pour chaque classe de serveur. Une mise à jour d'un produit principal peut avoir des conséquences différentes de celles d'une mise à jour d'une extension ou d'un composant tiers. Les paquets fournis par le système d'exploitation constituent également un domaine de maintenance distinct. Plesk distingue clairement ces catégories ; les mises à jour de composants tiers, en particulier, peuvent affecter les sites web si ceux-ci ne sont pas préparés à des versions ou à des environnements d'exécution modifiés.

Il est ensuite recommandé de réaliser une enquête représentative instance pilote plutôt qu'un serveur de test quelconque. Elle doit refléter des configurations tarifaires typiques : par exemple, des sites Web CMS classiques, des domaines de messagerie, l'utilisation de bases de données ainsi que des applications Node.js ou Python activées, si celles-ci sont proposées. L’objectif n’est pas de simuler une similitude parfaite avec l’environnement de production, mais de mettre en évidence à l’avance les combinaisons pertinentes de systèmes d’exploitation, d’extensions et d’applications client.

Pour le déploiement en production, définissez une fenêtre de maintenance avec un ordre clair des opérations. Commencez par mettre à jour un groupe restreint de serveurs, analysez les résultats, puis étendez le déploiement. Vérifiez ensuite l'accessibilité du panneau de configuration, les sauvegardes planifiées, les services Web et de messagerie, les renouvellements de certificats ainsi que les messages d'erreur des applications concernées. Ces contrôles réduisent les incertitudes, mais ne garantissent pas l'absence de panne ni la compatibilité totale des applications.

En matière de planification des capacités, Plesk recommande des valeurs minimales de 1 Go de RAM plus 1 Go d'espace d'échange sous Linux et de 2 Go de RAM sous Windows. Pour l'hébergement mutualisé, la recommandation générale est de 1 Go de RAM pour 40 à 50 sites web, à condition que 10 % au maximum de tous les sites hébergés enregistrent un nombre constant ou régulier de visiteurs par semaine ou par mois. De tels Valeurs indicatives des ressources Ces chiffres ne constituent pas une garantie de capacité et ne remplacent pas une évaluation de votre propre charge : l'activité de la base de données, le volume de courriels, les logiciels de sécurité et le type d'application peuvent modifier considérablement les besoins.

Identifier les sources d'erreurs et les priorités en matière de sécurité

Les erreurs récurrentes sont généralement dues à des limites de produit mal définies. Veillez donc à indiquer clairement, lors de chaque annonce, la version exacte du produit principal ou de l'extension. Une fonction Node.js ou Python ne doit pas être présentée de manière générale pour les offres Windows si elle n’est documentée que pour Plesk sous Linux. De même, l’hébergement Python avec WSGI via Passenger n’implique pas la prise en charge de toutes les architectures ASGI, Worker ou de conteneurs.

• Ne planifiez le DNS-01 en tant que caractéristique tarifaire que si vous disposez d'un accès en écriture à la zone DNS faisant autorité ou d'un chemin d'automatisation approprié.
• Ne pas confondre les options de mise à jour automatique de Plesk, des composants tiers et des paquets système ; vérifier l'état réellement défini pour chaque serveur sous „ Outils et paramètres > Paramètres de mise à jour “.
• Vérifier les extensions, les autorisations et les systèmes d'exploitation avant l'activation de nouvelles fonctionnalités pour chaque gamme de produits.
• Pour MCP, définir les groupes d'utilisateurs autorisés, les procédures d'autorisation et la journalisation des actions avant l'attribution d'un rôle.

Le Priorité en matière de sécurité ne dépend pas uniquement de la commodité de la fenêtre de maintenance. À la date de publication de cet article, Plesk Obsidian 18.0.81 Update 2, datée du 29 septembre 2026, constitue la dernière version de correctif documentée pour cette branche principale ; Plesk signale à ce sujet un problème de sécurité critique et recommande une installation dans les plus brefs délais. La mise à jour 1 du 21 septembre contenait également un correctif de sécurité critique, explicitement mentionné dans le journal des modifications pour Linux. Pour les systèmes Linux, il ne faut donc pas s'arrêter à la mise à jour 1.

Le journal des modifications mentionne également, pour le mois de septembre, des correctifs de sécurité critiques pour Node.js Toolkit 2.5.0 du 14 septembre 2026 et Site Import 1.12.2 du 23 septembre 2026. Vérifiez donc toujours si le composant concerné est installé et traitez le noyau du panneau, les extensions, les paquets PHP et les autres modules complémentaires comme des chemins de mise à jour distincts. Une mise à jour ultérieure d'une extension ou d'une version PHP ne remplace pas une mise à jour en attente du produit principal.

MCP mérite un phase pilote au lieu d'une activation immédiate à grande échelle. Cette fonctionnalité est désactivée par défaut ; les administrateurs peuvent, dans panel.ini Définissez quels types d'utilisateurs sont autorisés à se connecter aux clients MCP. Déterminez au préalable quelles tâches doivent être prises en charge, qui est autorisé à valider les modifications et comment les actions suspectes ou indésirables seront retracées. Une connexion à l'IA ne remplace ni les modèles de rôles, ni la gestion du changement, ni les revues techniques.

Avertissement : les composants tiers ne doivent pas être déployés de manière incontrôlée dans tous les environnements clients simplement parce qu'une version plus récente est disponible. Plesk signale d'éventuelles incompatibilités avec les sites Web hébergés ; parallèlement, la page de documentation actuelle contient des informations contradictoires quant à savoir si la fonctionnalité automatique correspondante est activée par défaut. Vérifie donc pour chaque serveur sous Tools & Settings > Update Settings les options définies et prévois, pour les durées d'exécution et les plugins courants, une mise en service progressive avec un groupe pilote représentatif.

Choisir entre une mise à niveau ou un transfert de serveur

Le choix entre Mise à niveau sur place et le transfert du serveur commence à partir de l'état actuel, et non de la version souhaitée d'Obsidian. Une mise à niveau sur le même serveur nécessite que le système d'exploitation et la version initiale de Plesk installée soient pris en charge pour la procédure prévue. Vérifiez également les extensions utilisées, vos propres personnalisations et l'espace disponible pour les sauvegardes. Le fait qu'un parcours de mise à jour soit techniquement possible ne signifie pas pour autant qu'il soit adapté à tous les environnements client.

Pour Plesk Onyx, la documentation relative à la mise à niveau indique des procédures directes de migration vers Obsidian pour les versions 17.0, 17.5 et 17.8. Les environnements de départ plus anciens ou non pris en charge de manière adéquate peuvent nécessiter un transfert vers un nouveau serveur Obsidian, à condition que la version de départ soit migrable. Ce transfert permet de préparer le système d'exploitation, la configuration des ressources et les extensions indépendamment de l'ancien système.

Il est particulièrement recommandé d'envisager un nouveau serveur de destination lorsque le système d'exploitation existant arrive en fin de support, que la plateforme a fait l'objet de modifications personnalisées pendant une longue période ou que plusieurs changements de version majeurs se cumulent. Les exigences système de Plesk ne constituent à cet égard qu'un seuil minimal à prendre en compte lors de la planification. Pour déterminer la taille cible, il faut également tenir compte du nombre de sites web, des boîtes mail, des bases de données, des services de sécurité, de la durée de conservation des sauvegardes et de la charge prévue après la migration.

À l'adresse suivante : Mise à niveau par transfert L'environnement existant est migré vers un serveur sur lequel Plesk Obsidian est installé. Selon la documentation relative à la mise à niveau, il est indispensable que le système d'exploitation du serveur cible soit pris en charge et que la version source installée permette une migration vers Obsidian. Il convient donc de vérifier, avant de planifier l'opération, si cette méthode est disponible en fonction de la version source concrète.

Pour disposer d'une installation à jour, prise en charge et facile à gérer, l'application rapide de correctifs après inventaire et phase pilote est généralement la solution la plus évidente. En cas de nouvelles extensions ou de fonctionnalités spécifiques à Linux, une phase pilote ciblée s’avère judicieuse. Si la prise en charge du système d’exploitation, la version initiale ou des héritages techniques constituent des obstacles, il convient dans un premier temps de Préparation à la migration . Le choix de la variante appropriée dépend du statut du support, de la compatibilité et du modèle d'exploitation – et non d'une mise en production généralisée.