Le module WHMCS pour CyberPanel, et l’alternative

Si vous faites tourner WHMCS et que vous voulez vendre de l’hébergement OpenLiteSpeed, vous partez à la recherche d’un module de provisionnement CyberPanel. Mesurés le 21 août 2026, les résultats pour cette recherche sont un dépôt GitHub tenu par une seule personne, et un fil de forum communautaire.

Ce n’est pas une critique du travail de qui que ce soit. C’est la description d’un manque : un logiciel qui se tient entre vos factures et les sites de vos clients, et que la plupart des hébergeurs trouvent sous la forme d’un projet de côté plutôt que d’un produit.

Cette page traite de ce qu’un tel module peut faire, de ce qu’il ne peut structurellement pas faire, et de ce à quoi ressemble une autre forme de solution. La première partie pèse le plus lourd, car le plafond n’est pas le module, c’est l’API de CyberPanel.

Le plafond : ce que l’API de CyberPanel autorise

Mesuré contre CyberPanel 3.0, non repris de la documentation. Tout module, celui de GitHub, un que vous écrivez vous-même, ou celui décrit plus bas, est borné par tout ce qui suit.

Créer un site répond avant de connaître le résultat

createWebsite rend la main en trois secondes environ avec createWebSiteStatus: 1. Ce n’est pas un verdict ; cela signifie que le travail a commencé. Le point d’accès lance une commande en arrière-plan et rend la main aussitôt. La vraie progression vit dans un fichier d’état qu’il faut sonder séparément.

Mesuré avec des données volontairement fausses :

Seule la forme du domaine et de l’adresse est validée en amont. Un module qui fait confiance à la première réponse passe une commande WHMCS en actif pour un site qui n’a jamais été créé, et le client reçoit des identifiants de bienvenue pour quelque chose qui n’existe pas.

Sonder ce fichier d’état comporte deux autres pièges. Lire un état achevé le supprime, un sondage de trop transforme donc une création terminée en « en cours » permanent. Et l’appel d’état se trouve sur la partie de l’API de CyberPanel qui refuse tout administrateur ne s’appelant pas littéralement admin.

La création complète dure une cinquantaine de secondes, dont environ vingt-huit consacrées à une tentative SSL que CyberPanel engage sans condition : l’API écrase ce champ quoi que vous envoyiez. Tout module a besoin d’un délai d’attente qui en tienne compte.

Changer de paquet change un champ en base

changePackageAPI rend la main en 270 millisecondes environ et le panneau affiche le nouveau nom. Mesuré ensuite depuis l’intérieur du serveur, avec un paquet portant 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é. Une commande de montée de gamme WHMCS peut donc aboutir, être facturée et changer le nom dans le panneau, alors que les limites réelles du client sont exactement celles d’avant. Aucun module ne peut corriger cela : toute l’implémentation de ce point d’accès est une modification de champ.

La suspension ne verrouille pas le compte

CyberPanel suspend un site en réécrivant son vhost vers une page de suspension et en redémarrant le serveur web. L’utilisateur unix n’est pas verrouillé ; le FTP, le courrier et les bases de données continuent de fonctionner. Si vous suspendez pour impayé, votre client dispose toujours de son courrier et de sa base. Cela peut être exactement ce que vous voulez, mais cela devrait être une décision et non une surprise.

Il y a aussi un bord plus tranchant : l’implémentation est if state == "Suspend": … else: <reactiver>, sans validation. Mesuré, envoyer "suspend" en minuscules a réactivé un site suspendu et annoncé un succès. Tout module devrait garder ces deux valeurs comme constantes et ne jamais les composer depuis une variable.

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

Le trafic est calculé par CyberPanel puis jeté avant d’atteindre la moindre liste. La consommation de disque provient d’un cache posé sur l’enregistrement du site, vide sur un site neuf, la valeur retombe donc à zéro, et un zéro issu d’un cache vide ne se distingue pas d’un site qui ne consomme rien.

WHMCS dispose d’un point d’ancrage de collecte de consommation qui attend des chiffres de disque et de trafic. Sur CyberPanel, il n’y a rien d’honnête à y mettre : un module qui le remplit malgré tout rapporte une valeur par défaut, pas une mesure.

L’accès à l’API est désactivé, et l’ordre des vérifications masque pourquoi

Sur un CyberPanel neuf l’API est désactivée, y compris pour l’administrateur principal, et l’interrupteur est vérifié avant le mot de passe : avec lui éteint, un mot de passe juste et un mot de passe faux renvoient donc le même API Access Disabled. La première panne de tout module pour ce panneau ressemble à un problème d’identifiants et n’en est pas un.

Ce que cela signifie pour un module

Rien de tout cela n’est réparable à l’intérieur d’un module WHMCS, car rien de tout cela n’est un problème de module. Ce qui diffère d’un module à l’autre, c’est l’honnêteté du traitement :

• Sonde-t-il l’état de création, ou fait-il confiance à la première réponse ?
• Lit-il l’état une fois en enregistrant le résultat, ou sonde-t-il jusqu’à effacer ce résultat par accident ?
• Vous dit-il qu’un changement de paquet n’a rien appliqué ?
• Laisse-t-il le point d’ancrage de consommation vide, ou le remplit-il de zéros qui ressemblent à des données ?
• Dit-il « l’accès à l’API est désactivé » au lieu de « identifiants invalides » ?

Ce sont les questions à poser à tout module que vous envisagez. On y répond en lisant le code, et elles pèsent plus lourd que la liste des fonctions. Il y en a une de plus, qui vous concerne vous et non le code : qui l’entretiendra dans dix-huit mois ? Un module de provisionnement se tient sur le chemin critique de chaque commande que vous acceptez.

L’alternative : une couche de provisionnement, pas un module de panneau

Provibr se place entre votre système de facturation et votre infrastructure. Ce n’est pas un module WHMCS pour CyberPanel ; c’est une plateforme de provisionnement qui parle à CyberPanel, et à laquelle WHMCS parle par un seul module, quel que soit ce qui se trouve dessous.

La différence pratique :

Deux lignes méritent un développement, car ce sont les honnêtes.

Le coût. Le module est gratuit et Provibr ne l’est pas. Provibr facture la capacité que vous réservez, combien de comptes d’hébergement vous pouvez faire tourner en même temps, à un prix unitaire dégressif qui baisse quand le nombre monte. Ce que vous facturez à vos propres clients reste entièrement le vôtre. Si vous avez douze sites CyberPanel et aucun projet de croissance, un module gratuit est la bonne réponse.

Les mêmes limites, une autre honnêteté. Provibr ne répare pas le changement de paquet de CyberPanel, n’invente pas de chiffres de consommation, et ne verrouille pas un compte suspendu. Il ne le peut pas : ce sont des propriétés du panneau. Ce qu’il fait, c’est refuser de faire croire le contraire.

Comment cela s’insère dans WHMCS

Un module, installé comme une simple archive zip dans modules/servers/. Dans WHMCS vous ajoutez un serveur qui pointe vers Provibr avec une clé d’API, puis vous faites pointer un produit WHMCS vers un forfait d’hébergement web Provibr. Une commande payée crée le compte, une suspension le suspend, une résiliation le supprime. Votre client garde un compte, une facture et un identifiant.

La clé d’API porte des portées, et ce qu’elle peut réellement faire est l’intersection de ces portées et des droits du membre auquel elle appartient : une clé ne peut donc que restreindre l’accès, jamais l’élargir. Retirez un droit à un collègue et chacune de ses clés se resserre à la requête suivante, sans que personne ait à révoquer quoi que ce soit.

Si vous ne faites pas tourner WHMCS, les mêmes opérations sont disponibles par l’API REST : une clé, une URL de base. Tout ce qui touche une machine répond « accepté » avec une commande à suivre, car votre infrastructure n’est joignable que par l’agent qui se trouve dans votre propre réseau. Les lectures répondent immédiatement.

Quand le module est le meilleur choix

Pour être direct : si CyberPanel est le seul panneau que vous faites tourner, que vous avez déjà WHMCS, que votre volume est petit et que lire du PHP quand quelque chose casse ne vous dérange pas, alors un module représente moins de machinerie et aucun coût mensuel. Les limites du haut de cette page s’appliquent également aux deux options.

L’argument pour une couche au-dessus commence dès que vous faites tourner plus d’un panneau, dès que vous voulez sortir les identifiants de votre hôte WHMCS, dès qu’autre chose que WHMCS doit passer des commandes, ou dès que vous voulez que le chemin de provisionnement soit le produit de quelqu’un plutôt que le week-end de quelqu’un.

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, sous un seul modèle de droits, avec un seul journal d’activité. Vous n’avez pas à choisir entre CyberPanel et tout le reste.