Automatiser la facturation et le provisionnement Plesk

Un produit d’hébergement automatisé a trois moments où l’argent et les machines se touchent :

1. 01La commande est payée : un abonnement doit exister, sur la bonne offre de service, en quelques secondes.
2. 02La facture est en souffrance : l’abonnement doit s’éteindre, et revenir dès qu’elle est payée.
3. 03L’abonnement prend fin : il doit être supprimé, pour de bon, données comprises.

Plesk a des appels pour les trois. Ce qu’il n’a pas, c’est ce qui décide quand les exécuter, et c’est la moitié que vous construisez. Cette page traite du raccordement des deux, et de quatre comportements inoffensifs quand vous les déclenchez à la main et dangereux quand un planificateur les exécute à trois heures du matin.

Tout ceci a été mesuré sur un serveur Plesk Obsidian 18.0.80 en fonctionnement en août 2026.

Les trois moments et les appels qui les sous-tendent

Deux de ces chiffres façonnent la conception. Un abonnement met quatre secondes et demie à se créer et près de huit à se supprimer. C’est assez long pour qu’un formulaire de commande doive signaler que quelque chose se passe, assez long pour qu’un budget de délai d’expiration écrit pour une API rapide coupe en plein milieu un appel qui fonctionne, et assez long pour que deux commandes arrivant ensemble soient réellement concurrentes plutôt que théoriquement.

Notez aussi la ligne de lecture. Un seul appel XML renvoie tous les abonnements avec leur offre, leur statut, leur quota et leur utilisation en un tiers de seconde, quel que soit leur nombre, et un système de facturation se réconcilie sans cesse avec le panneau.

Le piège de la suspension est un bogue de facturation, pas un détail d’API

Plesk propose deux façons de suspendre, et elles écrivent des champs différents. Dans un produit d’hébergement, cela cesse d’être une anecdote.

Mesuré, sur le même abonnement :

Un cycle de relance qui suspend via REST écrit un champ que la lecture groupée ne regarde pas, si bien que votre plateforme continue de signaler le compte comme actif. Voici pourquoi cela nuit à la facturation en particulier : quand la facture est enfin payée, votre automatisation regarde son propre état, voit un compte qui n’a jamais été suspendu, et ne le réactive pas. Le client a payé et reste éteint, et rien n’a consigné d’erreur.

La règle tient en une ligne : suspendez par le champ que vous lisez. Provibr écrit <webspace><set><gen_setup><status>, après quoi les deux vues s’accordent.

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

Une réserve honnête : nous n’avons pas mesuré la suspension d’un abonnement déjà suspendu. Sur HestiaCP, ce cas n’est pas idempotent et renvoie une erreur qui a l’allure d’une erreur d’authentification (exactement ce sur quoi un cycle de relance trébuche chaque jour). Établissez-le donc sur votre propre serveur avant de vous y fier.

Une clé expirée ressemble exactement à un serveur vide

C’est l’échec qui peut causer de vrais dégâts, et il tient en une phrase.

L’API XML renvoie un HTTP 200 pour une clé erronée. L’erreur se trouve à l’intérieur du document, sous le code 11003. Un client qui vérifie le code de statut lit donc un échec d’authentification comme un tour réussi qui n’a trouvé aucun abonnement.

Mettez maintenant cela dans une tâche de réconciliation nocturne. Un tour réussi qui n’a rien trouvé signifie, pour toute plateforme d’hébergement, que chaque compte présent hier a été supprimé. Une seule clé expirée, et du jour au lendemain votre système marque toute votre base de clients comme disparue.

Deux règles en découlent, et elles s’appliquent à tout panneau qui signale l’échec par un 200, ce qui, parmi les panneaux que nous avons intégrés, est le cas de la plupart :

• Sur l’API XML, le code de statut ne porte aucune information, pas même sur l’authentification. Analysez le document.
• Une réponse illisible est inconnue, jamais vide. Un serveur vide existe bel et bien, et il produit un unique résultat vide plutôt qu’une erreur. Ces deux cas sont réellement différents, et les distinguer, c’est là tout le travail.

REST échoue encore autrement : une clé inutilisable revient en HTTP 401 avec un corps entièrement vide. Un test de connexion doit donc sonder les deux surfaces et les signaler séparément. Un résultat REST au vert avec une API XML muette signifie que la liste des comptes, la liste des offres et chaque changement d’offre resteront vides, et la conclusion tentante est que le client n’a aucun compte.

Le code d’erreur ne vous dit pas ce qui a échoué

Les erreurs REST de Plesk portent un code numérique, et il est tentant d’en faire un aiguillage. Mesuré, il ne classe pas :

• 1007 couvre à la fois « ce domaine existe déjà » et « cet identifiant client existe déjà ».
• 1013 couvre à la fois « il n’existe pas d’offre de service de ce type » (REST) et « le domaine n’existe pas » (XML).
• 0 signifie aucun code, pas aucune erreur.

Pour une intégration de facturation, les dégâts atterrissent dans la logique de nouvelle tentative. « Le domaine existe déjà » après une commande payée peut signifier que la tentative précédente a à moitié réussi et que vous devriez regarder avant de réessayer ; « aucune offre de service de ce type » signifie que la commande ne réussira jamais et relève d’un humain. Elles partagent une famille de codes. C’est donc le texte qui classe, et cette correspondance doit se trouver à un seul endroit de votre code plutôt que d’être redéduite à chaque point d’appel.

Il existe aussi une cinquième forme d’échec : demandez à REST une route qui n’existe pas et il répond par une page HTML, pas du JSON.

Une commande ratée peut bloquer la nouvelle tentative

Mesuré : créer un domaine contre une offre de service qui n’existe pas renvoie 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.

Dans un flux de facturation, cela donne : le client a payé, la mise en service a échoué, et la nouvelle tentative échoue désormais différemment, parce que le domaine est utilisé par un compte qu’il n’a jamais reçu. Le second échec ressemble à une commande en double, ce qui compte parmi les choses les plus déroutantes à déboguer depuis un ticket de support.

Deux mesures peu coûteuses en découlent. Résolvez l’offre avant de créer quoi que ce soit : vous avez déjà la liste des offres, cherchez donc le nom en local et faites échouer la commande avant de toucher au panneau, ce qui supprime cet échec au lieu de le gérer. Et faites le ménage après une création ratée, car laisser les décombres transforme une commande ratée en un nom de domaine bloqué à jamais.

En comparaison, une erreur de validation de champ telle qu’un identifiant client en double renvoie un HTTP 400 et ne laisse rien derrière. Cette vérification s’exécute avant la création ; seule la recherche de l’offre arrive trop tard pour vous sauver.

Deux appels qui ont chacun un milieu

Supprimer un abonnement, c’est DELETE /domains/{id} puis DELETE /clients/{id}. Si le premier réussit et pas le second, il vous reste un enregistrement client qui ne possède rien : invisible dans la plupart des vues, et une erreur d’identifiant en double la prochaine fois que ce client revient. À 7,7 secondes, la suppression est aussi assez longue pour qu’un réseau l’interrompe, l’annulation mérite donc le même traitement que la mise en service : relisez le panneau ensuite et réconciliez avec la lecture groupée, pas avec la réponse obtenue.

Les montées et descentes d’offre ont leur propre recoin. <webspace><switch-subscription> n’accepte pas un nom d’offre, seulement le GUID ou l’identifiant externe de l’offre, là où partout ailleurs dans Plesk un forfait est référencé par son nom. Provibr conserve le nom comme ce que voient les humains et fait la traduction nom-vers-GUID en interne à partir de la liste d’offres que l’interrogation récupère déjà. Stocker un GUID dans votre facturation à la place fonctionne jusqu’au moment où quelqu’un reconstruit une offre.

Où vit la facture

Les trois moments ci-dessus ne sont que la moitié d’un produit d’hébergement. L’autre moitié, c’est à quoi ressemble votre propre facture.

Vous payez de la capacité, par type de ressource, et un compte d’hébergement en est un. Chaque abonnement compte, qu’il soit en marche ou non ; seul un abonnement suspendu ne compte pas. C’est le bon sens pour la relance : suspendre un client en souffrance libère la place tandis que ses données restent intactes, et le réactiver la reprend.

Dépasser votre limite n’est pas bloqué au moment où cela se produit. C’est détecté, on vous indique quel type de ressource et de combien, et vous disposez d’un jour ouvré pour y remédier. Si ce délai expire, les serveurs les plus récents au-delà de la limite sont éteints, les plus récents d’abord, pour que ce que vous avez construit en premier survive. Un second dépassement dans la même semaine donne droit à une heure au lieu d’un jour, car sinon le délai de grâce pourrait être renouvelé indéfiniment en repassant sous la limite puis en la dépassant de nouveau. Rien n’est redémarré à votre place lorsque c’est résolu : rallumer une machine est une décision, et la plateforme ne la prend pas pendant que personne ne regarde.

Chaque période donne lieu à une proforma que vous pouvez lire et imprimer, la facture définitive arrivant de la comptabilité sous forme de fichier. Une ligne de facture consigne le nom du forfait tel qu’il était au moment de la facturation, de sorte que renommer une offre plus tard ne réécrit pas l’historique.

Ce que Provibr fait, et ce qu’il ne fait délibérément pas

Provibr se place entre votre facturation et votre serveur Plesk. Un abonnement est une ligne ordinaire : commandez-le, suspendez-le, réactivez-le, changez son offre de service, supprimez-le. La suspension passe par le champ que lit l’interrogation. L’offre est résolue avant la création, et une création ratée est nettoyée. Chaque mutation se termine en relisant l’abonnement, si bien que ce qui est stocké est ce qui a été observé plutôt que ce qui a été demandé. L’agent se connecte vers l’extérieur depuis votre propre réseau, si bien que le port 8443 n’a pas à faire face à Internet.

Ce qu’il ne fait pas : gérer le serveur Plesk lui-même, ni entrer dans un abonnement. Il ne demande jamais non plus à Plesk les jeux de données contenant le mot de passe FTP ou le hachage du mot de passe du client, que le panneau livre l’un et l’autre en clair si vous les demandez.

À lire ensuite

• Vendre de l’hébergement web avec Plesk : le modèle de produit, les deux API, et ce que nous ne demandons jamais au panneau.
• Facturation et licence : la capacité, le tarif par palier, le crédit, les proformas et ce qui se passe en cas de dépassement.
• Configurer Plesk : la clé d’API, les offres de service, les plans web et l’import d’abonnements.

Mesuré sur Plesk Obsidian 18.0.80 en août 2026, les réponses ayant été enregistrées comme fixtures. La suspension répétée, les clés cadrées revendeur et le comportement sous une charge de trafic réelle n’ont pas été mesurés, et sont signalés comme tels plus haut.