Un logiciel en ligne qui a grandi chez les particuliers reçoit toujours la même demande : « pouvez-vous facturer ma société, avec notre numéro de TVA, et ouvrir vingt accès pour mon équipe ? » Elle ouvre trois chantiers distincts : la facturation d'abonnements européens, les licences multi-sièges et l'architecture multi-locataire, qui ressemblent de loin à du travail déjà fait.
AzurIT construit ces trois volets sur des applications qui existent déjà. Le socle qui les porte relève du backend sur-mesure, les écrans d'administration de l'application web, et le catalogue complet est sur la page services. Celle-ci traite de ce qui change quand votre client devient une organisation.
En B2C, un compte égale une personne, un paiement et une adresse. En B2B, le payeur n'est plus l'utilisateur : une organisation achète un quota, un administrateur le distribue, les membres entrent et sortent, et la facture porte les mentions du pays de l'acheteur. Chacune de ces phrases est un modèle de données, pas un écran de plus. Ajouter un champ « entreprise » sur la fiche utilisateur est le raccourci le plus coûteux : il tient six mois, puis il faut tout reprendre au moment précis où les premiers gros comptes arrivent.
La conversion change d'échelle aussi : le motif le plus efficace reste de rendre la fonctionnalité premium visible de tous et de n'en réserver que l'exécution aux abonnés.
Le périmètre ne varie guère : plusieurs devises, un taux de TVA par pays, l'autoliquidation intracommunautaire avec contrôle du numéro de TVA auprès du service européen VIES, une numérotation légale des factures, un PDF et une relance automatique des impayés. Brancher un prestataire de paiement n'est pas la partie difficile : c'est la seule qui soit documentée.
L'autoliquidation n'est pas une propriété du client, c'est une propriété de la vente. Elle dépend du pays du vendeur autant que de celui de l'acheteur : deux entreprises établies dans le même pays restent en régime domestique, et la TVA locale est due même quand le numéro de TVA de l'acheteur est parfaitement valide. Le contrôle VIES dit que le numéro existe ; il ne dit jamais que la vente est exonérée. Confondre les deux produit des factures à 0 % qui se découvrent au contrôle.
Deux autres points se posent avant d'écrire la première ligne. Une numérotation de facture est une contrainte légale, pas un compteur : chronologique, continue, sans trou, et une facture émise ne se corrige pas — elle s'annule par un avoir. Un webhook de paiement non signé est une porte ouverte : c'est par là que le prestataire annonce le résultat de l'encaissement, et si rien ne vérifie la signature, n'importe qui peut annoncer la même chose. Le retour du navigateur après paiement, lui, ne prouve rien : l'utilisateur peut l'interrompre.
Vendre à un établissement, c'est vendre un quota de sièges plutôt qu'un accès. Ce qu'il faut construire varie peu d'un produit à l'autre : invitation des membres, activation par le membre lui-même, révocation qui libère réellement le siège, rachat de sièges en cours de période — donc au prorata —, tableau de bord pour l'administrateur de l'organisation, export CSV et back-office côté éditeur.
Une question revient à chaque cadrage : faut-il un dispositif pour les entreprises et un autre pour les écoles ? Non. C'est un seul mécanisme à deux types de sièges, étudiant et professionnel, qu'une même licence peut porter en même temps. Les traiter comme deux prestations double le code, les écrans et les anomalies pour une différence qui tient dans un champ.
Les points sensibles, nous les mettons au cadrage plutôt qu'en recette. Le rachat de sièges doit être idempotent : un double clic ou un webhook rejoué ne doivent jamais produire deux paiements ni deux fois les sièges. Les webhooks liés aux organisations doivent être signés au même titre que ceux du paiement, faute de quoi un appel anonyme peut suspendre une licence ou en augmenter le quota.
Donner à chaque organisation son espace, à sa propre
adresse, provisionné à la création et libéré ensuite. La
mécanique tient en peu de code : une
réécriture qui lit l'en-tête Host et sert
l'espace correspondant, plus un appel à l'API de domaines
de l'hébergeur — sur Vercel, une douzaine de lignes de
middleware et une soixantaine de lignes de client HTTP.
Ce n'est pas là qu'est le travail, et un
prestataire qui vous vend « les sous-domaines »
vous vend la partie la plus simple.
Le travail est dans ce qui entoure ces lignes. Le DNS
générique qui fait exister *.votre-domaine.fr doit être documenté. Le domaine racine ne doit pas être
écrit en dur, sans quoi la recette devient impossible. La
réécriture doit conserver le chemin demandé, sinon les pages
internes d'un espace sont inatteignables depuis son propre
sous-domaine — un défaut invisible sur la page d'accueil,
donc invisible tout court. La création du domaine chez
l'hébergeur et l'écriture en base doivent se compenser l'une
l'autre. Et la vérification se fait sur une vraie adresse,
en production : une case cochée dans un plan n'est pas
une vérification.
Reste la question que le sous-domaine ne règle pas. Une adresse n'est pas une frontière : la séparation des données entre organisations se joue dans les requêtes et les contrôles d'accès, jamais dans l'URL — et c'est cette partie-là qu'il faut concevoir en premier.
Nous savons construire ces trois volets et nous savons ce qui les casse. Nous ne les vendons pas comme une conformité fiscale : l'arbitrage des règles applicables à votre activité revient à votre expert-comptable. Notre travail est que le code applique exactement les règles qu'il a arrêtées, et qu'on puisse le vérifier. Nous ne promettons ni délai ni résultat commercial.
Ce que nous mettons par écrit avant de commencer, c'est la liste des points à prouver — signature de chaque webhook, cas domestique couvert par un test, numérotation continue sous concurrence, idempotence du rachat de sièges, vérification sur une vraie adresse — et la façon dont chacun sera vérifié. Une chaîne de paiement qui n'a jamais quitté le mode test n'est pas une chaîne de paiement : c'est une intention.
La conversation utile tient en trois questions : qui paie, qui utilise, qui décide. Écrivez-nous avec ces trois réponses, et nous vous dirons ce qui manque.
