Vendre de l’hébergement web avec CyberPanel

CyberPanel est le panneau que les hébergeurs sous OpenLiteSpeed citent le plus souvent aux côtés de DirectAdmin. Mesuré sur GitHub le 21 août 2026 : 2 007 étoiles, 723 bifurcations et 362 tickets ouverts, avec un rythme de publication plus lent que la plupart de ses pairs.

Il possède une API REST, et tout ce dont vous avez besoin pour y vendre de l’hébergement, créer un site, le suspendre, changer son paquet, le supprimer, en fait partie. Ce qu’il n’a pas, c’est quoi que ce soit qui décide quand faire ces choses, et ce qu’il a bel et bien, c’est un ensemble de réponses faciles à mal lire.

Avant tout : l’accès à l’API est désactivé

Sur un CyberPanel neuf, l’API est désactivée, et cela vaut aussi pour votre administrateur principal. Vous l’activez sous Users → API Access, pour l’utilisateur admin. Rien d’autre n’est nécessaire : vous vous connectez avec les identifiants que vous avez déjà.

Laissez-la désactivée et chaque appel revient en API Access Disabled., quoi que vous envoyiez. Ce qui coûte un après-midi, c’est l’ordre : CyberPanel vérifie cet interrupteur avant de vérifier le mot de passe, donc avec l’interrupteur éteint un mot de passe juste et un mot de passe faux renvoient le même 403. Tout désigne vos identifiants alors que le problème se trouve une case plus loin.

Une fois l’interrupteur activé, le contrat en dessous est net et vraiment utile :

mot de passe juste  → HTTP 200  {"verifyConn": 1}
mot de passe faux   → HTTP 401  {"verifyConn": 0, "error_message": "Invalid password."}
utilisateur inconnu → HTTP 404  {"error_message": "Administrator not found."}

Trois situations, trois actions différentes pour le client, et les trois se distinguent.

L’administrateur doit s’appeler admin

Pas un réglage mais une condition, et elle vient de CyberPanel, pas de ce qui se construit dessus. Une partie de cette API est gardée par une vérification littérale du nom qui refuse tout utilisateur autre qu’admin, et cette partie est précisément celle qui énumère les sites du panneau et indique où en est un site en cours de création.

Les deux sont incontournables si vous voulez y vendre de l’hébergement : vous avez besoin de la liste pour savoir ce qui existe, et de l’indication de progression pour la raison exposée dans la section suivante. Un administrateur renommé n’est pas utilisable, et tout ce que vous construirez devrait le dire pendant le test de connexion, avant que votre première commande ne le découvre pour vous.

Un compte est un domaine, pas un nom d’utilisateur

C’est la différence structurelle avec DirectAdmin, cPanel et Virtualmin, et elle change la façon de modéliser le produit.

L’enregistrement de site de CyberPanel a un champ domain unique, et chaque commande le vise : la suppression prend domainName, la suspension et le changement de paquet prennent websiteName, et les trois retrouvent le site par son domaine. Il n’y a pas de nom d’utilisateur à adresser. L’utilisateur unix est engendré, pas choisi : cinq lettres extraites du domaine plus quatre chiffres aléatoires. Mesuré pour provibr-test-1.example.com : provi7346, avec le répertoire personnel nommé d’après le domaine et non d’après l’utilisateur. Vous ne pouvez ni choisir ce nom, ni le prévoir, et il apparaît dans exactement une réponse d’API et dans aucune énumération.

Une conséquence mérite d’être connue avant votre centième compte : créer un site crée aussi un identifiant de panneau en dessous, avec l’accès à l’API, et cet identifiant survit à la suppression du site. Mesuré après une suppression : utilisateur unix parti, répertoire personnel parti, vhost parti, ligne en base partie, et l’identifiant propriétaire toujours là. Le chemin de nettoyage de CyberPanel est gardé par une vérification qui ne peut pas aboutir au moment où elle s’exécute, et l’erreur qui en résulte est avalée. Si rien au-dessus du panneau ne le retire, chaque client résilié laisse un identifiant derrière lui.

Créer un site annonce le succès avant de savoir

C’est le point le plus important à comprendre de l’API de CyberPanel.

createWebsite répond en trois secondes environ avec :

{"status": 1, "createWebSiteStatus": 1, "error_message": "None",
 "tempStatusPath": "/home/cyberpanel/2424", "LinuxUser": "provi7346"}

Cela arrive avant que l’essentiel du travail soit fait : le point d’accès construit une ligne de commande, la lance sans attendre, et rend la main. La vraie progression vit dans un fichier d’état, lisible par un appel séparé. Mesuré, une création réelle :

+ 2,8s   10%  Creating DNS records..
+ 4,8s   25%  Setting up directories..
+ 6,9s   70%  Setting up SSL..        ← reste ici 28 secondes
+35,3s   80%  Creating mail child domain..
+49,5s  100%  Website successfully created. [200]

Environ cinquante secondes, dont environ vingt-huit consacrées à une tentative SSL que le panneau engage de toute façon : l’API écrase ce champ sans condition, il n’existe donc aucun moyen de créer un site sans SSL par l’API. Sur un domaine qui ne résout pas encore publiquement, cela fait vingt-huit secondes d’attente d’un certificat qui n’arrivera pas.

Et la première réponse n’est pas un verdict. Mesuré avec des données volontairement fausses :

Seule la forme du domaine et de l’adresse est vérifiée immédiatement. Savoir si le domaine est libre et si le paquet existe n’apparaît que dans le fichier d’état. Une intégration qui fait confiance à la première réponse annonce une commande réussie pour un domaine déjà pris.

Deux détails rendent le sondage plus difficile qu’il n’y paraît. Lire un état achevé supprime le fichier, un second sondage renvoie donc « fichier introuvable » avec un drapeau « pas encore fini » : un client qui sonde une fois de trop voit à jamais « en cours » pour une création qui a réussi. Et l’appel d’état ne vit que sur la surface réservée à admin, ce qui est la raison pour laquelle la condition de nom ci-dessus n’est pas facultative.

La suspension est une ruse du serveur web, pas un verrouillage de compte

Suspendre et réactiver sont la partie bien élevée de cette API : les deux prennent effet immédiatement, et la propre liste du panneau affiche aussitôt le nouvel état.

Mais sachez ce que cela fait. CyberPanel réécrit la configuration vhost du site vers une page de suspension et redémarre le serveur web. L’utilisateur unix n’est pas verrouillé ; le FTP, le courrier et les bases de données continuent de fonctionner. Le site devient injoignable, et rien d’autre. Cela diffère de DirectAdmin, et cela compte dès que vous utilisez la suspension pour faire respecter un paiement.

Encore une chose, qui mérite une constante dans votre code et non une variable : l’implémentation est if state == "Suspend": … else: <reactiver>, sans aucune validation de la valeur. Mesuré sur un site réel :

1. state:"Suspend"  → liste : Suspended
2. state:"suspend"  → {"websiteStatus": 1, "error_message": "None"}
3. liste :          → Active     ← une minuscule a reactive le site

Une faute de frappe remet silencieusement en service un client suspendu et annonce un succès.

Changer de paquet change l’écriture, et rien d’autre

changePackageAPI rend la main en 270 millisecondes environ et le panneau affiche le nouveau nom de paquet. Mesuré ensuite depuis l’intérieur du serveur, avec un paquet portant volontairement d’autres limites : le quota de disque était inchangé (soft 0, hard 0) et la configuration vhost portait encore les limites de mémoire et de processus de l’ancien paquet.

Rien n’a été appliqué. Toute l’opération est une modification de champ en base. Lisez le nom du paquet dans CyberPanel comme une écriture et non comme une limite qui aurait suivi, et ce qui se trouve au-dessus du panneau devrait le dire plutôt que de laisser croire à une montée de gamme effective.

Il n’y a pas de données de consommation

CyberPanel est le seul panneau de contrôle de Provibr sans courbes de consommation, et ce n’est pas un oubli de l’intégration : le panneau ne les mesure pas.

Le trafic est calculé puis jeté, il n’atteint jamais la liste. La consommation de disque sort d’un cache posé sur l’enregistrement du site, et sur un site fraîchement créé ce champ est vide, la valeur annoncée retombe donc à zéro. Un zéro issu d’un cache vide ne se distingue pas d’un site qui ne consomme réellement rien. Une courbe qui reste à zéro pour toujours ressemble à une mesure ; c’est pourquoi il n’y en a aucune.

Ce que Provibr en fait

Provibr se connecte par un agent situé dans votre propre réseau qui sort en connexion sortante : le panneau n’a donc rien à exposer. Il demande quatre choses : l’adresse du panneau avec le port 8090, le nom d’utilisateur admin, le mot de passe de cet administrateur, et, tant que le panneau utilise encore le certificat livré d’origine, l’empreinte SHA-256 à épingler.

Cette dernière n’est pas facultative en pratique. Tout CyberPanel neuf présente le même certificat auto-signé, établi au nom de www.example.com et signé par CyberPanel lui-même. Un navigateur le qualifie donc d’incorrect plutôt que d’auto-signé, et la chaîne n’est jamais validée. Épingler l’empreinte, c’est faire confiance à ce seul certificat au lieu de désactiver la vérification. Posez votre propre certificat sur le nom d’hôte du panneau et la chaîne se valide d’elle-même ; laissez alors le champ vide.

Sachez ce qu’est ce mot de passe. CyberPanel n’a aucun jeton d’API couvrant ces commandes : dans sa propre API, la voie du jeton est ouverte ou fermée selon le point d’accès, et ce sont justement les quatre qui créent, suspendent, changent de paquet et suppriment un site qui exigent le mot de passe. Il s’agit donc bien du mot de passe complet de votre administrateur principal.

Une fois cela en place : les paquets deviennent vendables comme forfaits d’hébergement web sous un nom et un prix à vous, les commandes créent les sites et attendent le vrai résultat plutôt que la première réponse, la suspension et la réactivation fonctionnent à la demande et lorsque votre capacité est dépassée, et les sites déjà présents s’importent.

Ce que cela ne fait pas

Provibr gère des sites, pas le panneau : il n’installe pas CyberPanel, ne le met pas à jour et ne modifie aucun réglage serveur. Il n’y a pas de console. Le DNS, les boîtes aux lettres et les bases de données restent intacts : CyberPanel sait tout faire lui-même, et rien au-dessus ne le pilote. Et il n’y a pas de courbes de consommation, parce qu’il n’y a rien d’honnête à tracer.

Vous n’êtes pas obligé de miser sur un seul panneau. Provibr fait tourner aujourd’hui ses panneaux de contrôle, ses hyperviseurs et ses panneaux de jeu côte à côte, dans un seul inventaire, avec un seul modèle de droits et un seul journal d’activité.