Créer un SaaS B2B : ce qu’il faut construire au-delà de l’écran

Un SaaS n’est pas un site avec un login

Un site vitrine présente votre entreprise. Un outil interne sert vos équipes, comme le back-office qui fait tourner vos opérationsback-office qui fait tourner vos opérations. Un SaaS est un troisième objet : un produit que vous vendez à d’autres entreprises, qui l’utilisent avec leurs propres données, leurs propres utilisateurs, leur propre abonnement. Chacune doit avoir l’impression que l’outil est le sien, sans jamais apercevoir les autres.

C’est cette coexistence qui fait la difficulté. Les écrans métier, ceux qui portent votre savoir-faire, représentent souvent moins de la moitié du travail. Le reste est un socle que vos clients ne voient pas, mais dont l’absence se remarque le jour où quelque chose casse.

Les fondations invisibles d’une application SaaS

L’architecture multi-tenant : isoler chaque client

Dans le vocabulaire du SaaS, chaque entreprise cliente est un tenant, un locataire. Une architecture multi-tenant fait cohabiter tous les locataires sur la même application, ce qui rend le produit économique à exploiter. Le guide SaaS du cadre Well-Architected d’AWSguide SaaS du cadre Well-Architected d’AWS le dit sans détour : l’isolation des locataires est un sujet fondamental, et franchir cette frontière, sous quelque forme que ce soit, serait un événement grave et potentiellement irrécupérable pour un éditeur SaaS.

Il existe plusieurs façons d’isoler : une base par client (simple à raisonner, plus chère à opérer), ou une base partagée où chaque ligne porte l’identifiant de son propriétaire. Dans le second cas, on ne confie pas l’isolation à la seule vigilance des développeurs. PostgreSQL propose la sécurité au niveau des lignes (Row-Level Security)sécurité au niveau des lignes (Row-Level Security) : une fois activée sur une table, toute lecture ou modification doit être autorisée par une règle explicite, et en l’absence de règle, aucune ligne n’est visible. Une requête oubliée ne fuit pas ; elle ne renvoie rien.

Abonnement SaaS et facturation récurrente

Vendre un abonnement, ce n’est pas encaisser un paiement. Il faut gérer les essais gratuits, les changements d’offre en cours de mois, les remises, les cartes expirées, les relances et les factures conformes. On ne réécrit pas cela soi-même : on s’appuie sur un service spécialisé. À titre de repère, la grille tarifaire de Stripe Billinggrille tarifaire de Stripe Billing facture 0,7 % du volume traité en paiement à l’usage, en plus des frais de paiement par carte (1,5 % + 0,25 € pour une carte européenne standard). Le travail côté produit consiste à relier l’abonnement aux droits : ce que le client a payé détermine ce qu’il peut faire, automatiquement.

Comptes, rôles et SSO

Un client B2B n’a pas un utilisateur, il a une organisation : un administrateur qui invite ses collègues, des rôles différents, quelqu’un qui part et dont l’accès doit être coupé le jour même. Dès que vous visez des entreprises de taille moyenne, la question du SSO arrive : se connecter avec le compte Microsoft ou Google de l’entreprise plutôt qu’avec un énième mot de passe. Prévoir ce modèle d’organisation dès le départ coûte peu. L’ajouter après coup oblige à reprendre une bonne partie du produit.

Supervision et sauvegardes

Quand un outil interne plante, un collègue vient vous voir. Quand votre SaaS plante, un client résilie. Un produit vendu a besoin de journaux exploitables, d’alertes quand une erreur se répète, de sauvegardes testées (une sauvegarde jamais restaurée n’est qu’une hypothèse) et d’un hébergement dimensionné, dont nous détaillons le choix dans quel hébergeur cloud choisirquel hébergeur cloud choisir.

RGPD : en vendant un SaaS, vous devenez sous-traitant

Vos clients vont saisir dans votre outil des données personnelles : leurs propres clients, leurs salariés, leurs contacts. Pour ces données, ils restent responsables du traitement, et vous devenez leur sous-traitant au sens de l’ article 28 du RGPDarticle 28 du RGPD. Concrètement, cela impose un contrat qui encadre le traitement, et des obligations précises : ne traiter les données que sur instruction documentée du client, garantir la confidentialité des personnes qui y accèdent, assurer la sécurité, ne pas recourir à un autre sous-traitant (votre hébergeur, votre service d’e-mail) sans autorisation écrite préalable, et supprimer ou restituer les données en fin de contrat.

Rien d’insurmontable, mais tout cela se traduit en fonctionnalités : un export complet des données d’un client, une suppression réelle à la résiliation, une liste à jour de vos propres prestataires. Mieux vaut les prévoir dans l’architecture que les découvrir lors du premier appel d’offres.

Le MVP SaaS : quoi construire en premier

Le réflexe du MVP (produit minimum viable) est le bon : sortir vite une première version pour la confronter à de vrais clients. Mais il y a une règle : on coupe dans les fonctionnalités, jamais dans les fondations. Un MVP qui mélange les données de deux clients n’est pas minimal, il est dangereux.

Côté technique, le choix du framework compte moins que celui de l’architecture ; si le sujet vous intéresse, nous l’avons traité dans les frameworks du monde du webles frameworks du monde du web. Et si votre SaaS doit aussi être trouvé par vos prospects, la page publique du produit mérite le même soin, comme expliqué dans l’importance du SEOl’importance du SEO.

Si vous hésitez encore entre construire votre propre produit et utiliser un outil du marché pour vos besoins internes, la question est différente : nous la traitons dans SaaS ou logiciel sur-mesureSaaS ou logiciel sur-mesure. Pour un produit à vendre, c’est précisément ce que nous construisons sur notre page application web et SaaSapplication web et SaaS, du premier écran à l’infrastructure. Le reste de notre approche est présenté sur l’accueil de pragma oncel’accueil de pragma once.