Vendre de l’hébergement web avec ISPConfig

La plupart des panneaux de contrôle gèrent un serveur. ISPConfig gère un parc : une seule installation posée devant des machines web, courrier, DNS et base de données distinctes, avec les sites et les boîtes aux lettres répartis dessus et une interface unique sur l’ensemble. Il fait cela depuis très longtemps, il est libre, et il ne coûte rien.

C’est aussi le panneau de cette catégorie qui a l’idée la plus complète de ce qu’est un client. ISPConfig a des clients, des revendeurs, des limites et des modèles comme objets de premier rang, ce que la plupart de ses concurrents ne peuvent pas dire. Ce qu’il n’a pas (et c’est toute la raison d’être d’une page comme celle-ci), c’est la moindre notion de client qui vous paie.

Ce qu’ISPConfig vous donne déjà

Trois choses, et elles sont inhabituellement bonnes.

Des clients, pas seulement des comptes. Un client ISPConfig est une personne ou une entreprise qui possède des choses : des sites web, des boîtes aux lettres, des zones DNS, des bases de données. C’est la forme qu’a réellement un produit d’hébergement, et vous n’avez pas à l’inventer.

Des limites, et des modèles pour les appliquer. Chaque client porte des limites : combien de domaines web, combien de boîtes aux lettres, combien de bases de données, combien d’espace. Les modèles de client vous laissent définir un jeu de limites une fois et l’appliquer à de nombreux clients, ce qui est exactement un catalogue produit sous un autre nom. Une limite à -1 signifie illimité, ce qu’il vaut mieux savoir avant de lire un modèle et d’en conclure que quelque chose est cassé.

Des revendeurs. ISPConfig comprend qu’un client peut lui-même avoir des clients. Si vous vendez à des agences qui vendent à leurs propres clients, cette hiérarchie existe dans le panneau plutôt que dans un tableur que vous entretenez à côté.

À elles trois, ces choses couvrent les parties que la plupart des panneaux vous laissent construire vous-même.

La partie inhabituelle : un panneau, plusieurs machines

C’est ce qui sépare véritablement ISPConfig de DirectAdmin, cPanel, CloudPanel et les autres.

Une seule installation ISPConfig peut piloter des serveurs web dédiés, un serveur de courrier séparé, des serveurs DNS séparés et un serveur de base de données séparé, configurés en multiserveur, avec de la mise en miroir pour les parties qui demandent de la redondance. Quand vous ajoutez un site web, ISPConfig l’écrit sur la machine censée le porter.

Pour un hébergeur, deux conséquences en découlent. La bonne : grandir veut dire ajouter une machine derrière le panneau, et non monter un second panneau et répartir vos clients sur deux systèmes qui s’ignorent. Celle à prévoir : votre idée de « un serveur » et celle d’ISPConfig cessent d’être la même chose. Un compte n’est plus épinglé à une machine que vous pouvez désigner du doigt, ce qui n’est pas grave. Mais tout inventaire que vous tenez au-dessus d’ISPConfig doit s’accommoder d’un client dont le site web est sur une machine et les boîtes aux lettres sur une autre.

L’API distante, et les deux choses à savoir dessus

L’automatisation d’ISPConfig passe par son API distante, disponible en versions SOAP et JSON. Deux propriétés façonnent tout ce que vous bâtirez dessus.

Elle fonctionne par session, pas par jeton. Vous appelez login avec le nom et le mot de passe d’un utilisateur distant, vous récupérez un session_id, et vous le passez à chaque appel suivant. La session n’est valable qu’un temps limité. C’est un cycle de vie différent des jetons bearer que distribuent la plupart des panneaux modernes : votre client doit tenir une session, s’apercevoir qu’elle a expiré, et se reconnecter. Et il ne doit pas le faire en réessayant à l’aveugle, car une boucle de connexion contre de mauvais identifiants est la façon dont on finit enfermé dehors.

Les permissions sont par fonction, et elles sont vérifiées. Vous créez un utilisateur distant dans le panneau (System, puis Add Remote User) et vous cochez les catégories d’appels qu’il a le droit de faire. ISPConfig vérifie cette permission à chaque appel qu’il reçoit.

Cette seconde propriété a une vraie valeur et mérite d’être utilisée correctement. Elle signifie que l’identifiant posé dans votre automatisation n’a pas besoin de pouvoir tout ce qu’ISPConfig sait faire. Donnez-lui les fonctions que votre provisionnement appelle réellement et rien d’autre, et une erreur dans votre propre code ne pourra pas atteindre les parties du panneau que vous n’aviez jamais eu l’intention de toucher. Très peu de panneaux de cette catégorie vous laissent tracer cette ligne.

Les fonctions elles-mêmes se lisent comme on l’espère. Les clients se créent avec client_add. Les sites web sont sites_web_domain_add, sites_web_domain_update, sites_web_domain_get et sites_web_domain_delete. Et, ce qui est décisif pour tout usage commercial, il y a sites_web_domain_set_status, une manière réelle et prise en charge d’allumer et d’éteindre un site web, c’est-à-dire le verbe unique autour duquel tourne la facturation d’hébergement et dont plusieurs panneaux concurrents sont tout simplement dépourvus.

Ce qu’il ne fait toujours pas

Tout ce qui précède est de l’infrastructure. Rien de tout cela n’est du commerce.

ISPConfig ne prendra pas une commande, ne prendra pas un paiement, ne produira pas de facture, n’en relancera aucune, et ne décidera pas le trente et unième jour que ce client a cessé de payer et qu’il faut le couper. Il a le levier (set_status), mais rien qui décide du moment de l’actionner. Il n’y a pas de catalogue avec des prix, pas de parcours d’inscription, pas de calendrier de relance, et aucune vue qui vous dise ce que votre parc vous coûte face à ce qu’il vous rapporte.

Ce n’est pas un reproche. Un panneau de contrôle qui essaierait d’être aussi un système de facturation serait moins bon aux deux. Mais cela veut dire que le travail intéressant, quand on vend de l’hébergement ISPConfig, se trouve entièrement dans la couche au-dessus, et cette couche est la même que celle qu’il vous faudrait pour n’importe quel autre panneau :

• Un formulaire de commande et un catalogue, avec des formules qui correspondent aux modèles de client.
• Un paiement qui déclenche le provisionnement en quelques secondes.
• Un chemin de relance (en retard, averti, suspendu, rétabli) branché sur set_status à la bonne étape.
• Une capacité visible, pour savoir combien de comptes vous portez sur toutes ces machines et ce qu’ils coûtent.
• Un journal d’activité, pour que « qui a changé cette limite » ait une réponse.
• Un modèle de droits pour vos propres équipes, afin que le support puisse agir sans pouvoir supprimer un client.

Où se situe Provibr

La prise en charge d’ISPConfig est en production. Un agent dans votre propre réseau parle à l’API distante du panneau, de sorte que rien sur votre panneau n’a à faire face à Internet et qu’aucun port n’a à être ouvert. Créer un client avec un site et une formule, le suspendre, le rétablir, changer sa formule et le supprimer fonctionne, les comptes déjà présents peuvent être importés, et le disque et le trafic apparaissent dans les graphiques. Autour de cela se trouve la couche décrite plus haut : des formules et de la capacité à un prix unitaire, un modèle de droits pour votre équipe, un journal d’activité, ainsi qu’une API REST et un module WHMCS pour que la plateforme avec laquelle vous facturez déjà puisse le piloter.

L’identifiant rangé dans le coffre de l’agent peut être bien plus étroit qu’un administrateur, car ISPConfig accorde ses droits distants fonction par fonction : l’utilisateur distant se limite exactement aux appels que fait Provibr, et à rien d’autre. Le choix de la machine sur laquelle ISPConfig pose un site reste celui d’ISPConfig, les actions sur le compte sont les mêmes dans tous les cas, et chaque compte vaut un serveur web dans votre capacité, quelle que soit la machine qui finit par l’héberger.

Ce que l’intégration ne fait pas, c’est toucher aux comptes que vous n’avez pas créés avec elle : ceux-là sont laissés tranquilles jusqu’à ce que vous les importiez, et c’est vous qui choisissez lesquels. Une note pratique sur la connexion elle-même : une installation neuve d’ISPConfig est auto-signée, mieux vaut donc épingler son empreinte TLS au moment d’ajouter l’intégration.

Ce que cela ne fait pas

Gérer des comptes n’est pas gérer le panneau. Installer ISPConfig, le mettre à jour, ajouter des serveurs derrière lui, configurer le routage du courrier et s’occuper du DNS : tout cela reste chez vous, dans ISPConfig, là où c’est sa place. Un client qui modifie sa propre boîte aux lettres le fait sans que rien au-dessus du panneau le sache ou s’en soucie.

Vous n’avez pas besoin de vous normaliser sur un seul panneau pour garder une seule vue d’ensemble. 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é. Un panneau libre multiserveur pour les clients qui veulent le courrier et le DNS inclus, autre chose pour ceux qui demandent cPanel par son nom, et un seul endroit où vous voyez les deux.