Blog · 15 août 2026

Vendre de l’hébergement web avec Plesk

Faire d’un serveur Plesk un produit d’hébergement : une clé pour deux API, le piège de suspension qui cache un compte, et ce que nous ne demandons jamais.

Par Provibr

Plesk fera tourner sans peine une centaine d’abonnements pour vous. Ce qu’il ne fera pas, c’est prendre une commande, encaisser l’argent, remarquer qu’une facture est restée impayée, ou suspendre le compte correspondant. C’est dans cet écart entre « un panneau qui héberge des sites » et « une activité d’hébergement » que se trouve le travail, et cette page explique comment le franchir sans mettre le pied dans les quatre endroits où il est facile de le mettre.

Ce que Plesk vous donne déjà

Un abonnement est l’unité que vous vendez : un domaine principal, une offre de service, des limites de disque et de trafic, et tout ce qui se trouve dessous. Une offre de service est la description qu’a le panneau de cet abonnement : quota, trafic mensuel, combien de domaines et de boîtes mail, quels services sont activés. Les deux concepts existent déjà : vous n’inventez donc pas un modèle de produit, vous en nommez un qui est là.

L’API est bonne sur un point qui compte particulièrement pour un produit d’hébergement : un seul appel lit tous les abonnements du serveur, avec leur offre, leur statut, leur quota et leur utilisation. Nous l’avons mesuré à 0,33 seconde quel que soit leur nombre. Trois appels de lecture vous donnent le tableau complet d’un serveur (abonnements, clients, offres), et ce nombre ne croît pas avec votre nombre de clients. Construire le même tableau via REST demanderait un appel plus trois par abonnement.

Une seule clé ouvre deux API, et il vous faut les deux

Plesk dispose d’une API REST v2 moderne et d’une API XML/RPC plus ancienne. Aucune n’est complète à elle seule, et ce n’est pas une question de préférence.

REST v2 n’a ni abonnements ni offres de service. Nous avons énuméré ses 43 chemins à partir de son propre document OpenAPI ; /subscriptions et /service-plans n’y figurent pas, et les demander renvoie un 404 rendu sous forme de page HTML plutôt que de JSON. Puisque l’offre de service est le forfait d’hébergement, tout le volet des forfaits doit passer par XML.

Ce qui sauve la situation, c’est l’identifiant. La clé délivrée par POST /api/v2/auth/keys fonctionne à l’identique dans les deux : comme X-API-Key sur REST et comme KEY sur le point de terminaison XML. Mesuré, même clé, les deux API. Vous ne demandez donc à l’opérateur qu’une seule valeur, pas deux.

Ce que cela vous coûte, ce sont deux vocabulaires d’échec. REST répond à une clé inutilisable par un HTTP 401 et un corps entièrement vide. XML répond à la même clé par un HTTP 200 et un code d’erreur à l’intérieur du document. Ce qui nous amène au tranchant.

Un échec d’authentification qui ressemble à un serveur vide

Parce que l’API XML renvoie un HTTP 200 pour une clé erronée, un client qui vérifie le code de statut lit un échec d’authentification comme un tour réussi qui n’a rien trouvé. Et un tour réussi qui n’a rien trouvé a un sens dans toute plateforme d’hébergement : chaque compte qui était là hier a disparu.

La conséquence n’est pas un tableau de bord cassé. C’est un système qui marque chacun de vos clients comme supprimé parce qu’une clé a expiré. La règle qui en découle est absolue : sur l’API XML, le code de statut ne porte aucune information, pas même sur l’authentification. Analysez le document, et traitez une réponse illisible comme inconnue plutôt que comme vide.

Un serveur vide ne produit pas d’erreur non plus : il produit un unique résultat vide, ce qui est la bonne réponse quand il n’y en a réellement aucun. Distinguer ces deux cas, c’est là tout le travail.

Le piège de la suspension : écrire et lire le même champ

Il y a deux façons de suspendre un abonnement dans Plesk, et elles n’écrivent pas le même champ.

Ce que vous faites	XML `gen_info.status`	Statut REST de l’abonnement
rien (actif)	`0`	`active`
`PUT /domains/{id}/status` vers suspendu	`0`	`suspended`
CLI `subscription --webspace-off`	`1`	`suspended`
XML `<webspace><set>` avec le statut `16`	`16`	`suspended`

Relisez la deuxième ligne. Suspendre via REST laisse à zéro le champ que lit l’interrogation groupée. Un produit d’hébergement qui suspend via REST et interroge via XML affichera donc le compte comme actif alors qu’il est, en réalité, suspendu. Rien n’échoue. Rien ne passe au rouge. Votre panneau et votre serveur sont simplement en désaccord, et la première personne à s’en apercevoir est un client qui ne peut pas joindre un site que vous croyez en marche.

La règle : suspendez et réactivez par le même champ que vous lisez. Provibr utilise XML <webspace><set><gen_setup><status>, après quoi les deux vues évoluent ensemble : le champ XML indique 16 et REST indique suspendu.

gen_info.status est un masque de bits, et les valeurs que nous avons mesurées sont 0 pour actif, 1 pour webspace-off et 16 pour désactivé par l’administrateur. Tout ce qui n’est pas zéro compte comme suspendu, ce qui est la seule lecture qui survit à une valeur que nous n’avons pas encore vue.

Deux jeux de données que nous ne demandons jamais au panneau

L’API XML de Plesk est conçue pour l’administration, si bien que deux de ses jeux de données renvoient des éléments d’identification à l’appelant qui les demande :

<webspace><get> avec le jeu de données hosting renvoie le mot de passe FTP du compte en clair, avec un champ qui le marque explicitement comme tel.
<customer><get> avec le jeu de données gen_info renvoie le hachage du mot de passe du client (bcrypt) ainsi que le type de hachage.

C’est raisonnable pour une API d’administration. Ce n’est pas quelque chose qu’une plateforme d’hébergement devrait tirer sur le réseau à intervalle régulier.

Une couche de caviardage est la mauvaise réponse à cela. La bonne réponse, c’est de ne pas demander. L’interrogation de Provibr demande exactement quatre jeux de données (informations générales, limites, statistiques et abonnements), et nous les avons parcourus champ par champ pour confirmer qu’aucun ne porte de secret. La liste des clients vient de REST, qui n’a aucun champ de mot de passe.

Il y a une conséquence de conception qui mérite d’être dite. L’utilisateur FTP ou système d’un abonnement ferait un identifiant court séduisant, mais il ne vit que dans le jeu de données hosting, si bien que s’en servir comme identité reviendrait à récupérer le mot de passe de chaque client à chaque cycle d’interrogation. D’où le domaine à la place.

L’identité d’un abonnement est un nom de domaine

Dans Plesk, un abonnement porte le nom de son domaine principal. C’est ce que le panneau affiche, ce sur quoi son API filtre, et ce que toute intégration doit stocker.

C’est une vraie différence par rapport à cPanel et DirectAdmin, où un compte a un nom d’utilisateur court et un domaine séparément, et elle a une conséquence pratique : le domaine ne peut plus être modifié par la suite. Ce que votre facturation stocke comme identifiant d’un abonnement Plesk est un nom de domaine, et un client qui veut renommer son site demande un nouvel abonnement plutôt qu’une modification.

Deux points plus modestes mesurés en chemin. La spécification de Plesk elle-même indique qu’un mot de passe client fait de 5 à 14 caractères ; un mot de passe de 22 caractères a été accepté sans broncher, la limite documentée n’est donc pas celle qui est appliquée. Et Plesk choisit lui-même l’adresse IP dans son propre pool, c’est pourquoi un compte d’hébergement dans Provibr a un champ d’adresse vide jusqu’à ce que le panneau en signale une.

Une commande ratée peut laisser la moitié d’un abonnement derrière elle

Mesuré : créer un domaine avec une offre de service qui n’existe pas répond par un HTTP 404 assorti d’un message clair, et l’objet domaine existe malgré tout ensuite, sans type d’hébergement et avec une racine de documents vide. Plesk crée d’abord l’objet et applique l’offre ensuite, et n’annule rien quand la seconde étape échoue.

Le client a payé, la commande a échoué, et la tentative suivante échoue désormais différemment, parce que le domaine est déjà utilisé, par un compte qu’il n’a jamais reçu. Recherchez donc l’offre avant de créer quoi que ce soit, dans la liste d’offres que vous avez déjà récupérée, et faites le ménage après toute création ratée. En comparaison, une erreur de validation de champ telle qu’un identifiant en double revient en HTTP 400 et ne laisse rien derrière : cette vérification s’exécute avant la création, et seule la recherche de l’offre arrive trop tard.

Aucune latence, ce qui est plus rare qu’il ne le faudrait

La liste d’utilisation de DirectAdmin accuse environ trois secondes de retard sur la réalité dans les deux sens, ce qui force un second appel faisant autorité. Pas Plesk. Nous avons mesuré une création et une suppression face à la lecture groupée :

text

    0 ms  create
 4519 ms  create returns 201
 4957 ms  bulk read sees the subscription      <- immediately
 4957 ms  delete
12622 ms  delete returns 200
13001 ms  bulk read no longer sees it          <- immediately

Plesk est transactionnel : dès que l’appel répond, le changement est visible dans la lecture groupée. Une seule source faisant autorité, pas de second appel, pas d’attente.

Les temps eux-mêmes méritent d’être notés. Créer un abonnement prend 4,1 à 4,5 secondes et en supprimer un 7,7 secondes, assez long pour qu’un client qui regarde un formulaire de commande doive être informé que quelque chose se passe. Changer d’offre prend 1,5 seconde et suspendre 0,78.

Ce que Provibr fait de tout cela

Provibr se place entre votre facturation et votre serveur Plesk. Vous connectez le serveur avec une seule clé d’API, après quoi un abonnement est une ligne ordinaire : commandez-le, suspendez-le, réactivez-le, déplacez-le vers une autre offre de service, supprimez-le.

Une seule clé, parce que la même clé ouvre les deux API.
La suspension passe par le champ que lit l’interrogation, pour que panneau et serveur ne puissent pas diverger.
L’interrogation ne demande jamais un jeu de données contenant un mot de passe, pour qu’aucun secret de client n’atteigne la plateforme.
L’offre est résolue avant la création, et une création ratée est nettoyée plutôt que laissée en place.
Rien n’est cru sur parole. Chaque mutation se termine en relisant l’abonnement.
L’agent se connecte vers l’extérieur depuis votre réseau, si bien que le port 8443 ne fait pas face à Internet et que rien n’est installé sur le serveur Plesk.
Les abonnements que vous n’avez pas commandés via Provibr sont laissés tels quels jusqu’à ce que vous les repreniez, ce qui rend reprenable un serveur comptant deux cents clients existants plutôt qu’un chantier de reconstruction.

Ce qu’il ne fait pas

Il gère les abonnements sur un serveur Plesk que vous exploitez, pas le serveur lui-même : les services, les zones DNS, le routage du courrier et les réglages du panneau lui-même restent où ils sont. Il n’y a pas de console, car un compte d’hébergement n’est pas une machine. Les boîtes aux lettres, les bases de données et le DNS à l’intérieur d’un abonnement appartiennent à Plesk et à votre client.

Une réserve honnête : tout ceci a été mesuré avec une clé administrateur. Qu’une clé cadrée revendeur ou client puisse ne serait-ce qu’utiliser l’API XML n’a pas été testé, si bien que l’intégration sonde au moment de la connexion et refuse des identifiants qui ne voient qu’une partie d’un panneau plutôt que d’en gérer la moitié en silence.