Comment je construirais un SaaS - locataires, facturation, et ce qui en fait un produit

Un MVP répond : est-ce que quelqu’un ira au bout de ce travail ? Un SaaS répond : est-ce que plusieurs entreprises continueront à payer pour qu’on tienne une seule base de code pour toutes ? La deuxième question n’est pas « ajouter Stripe et un login ». C’est l’isolation des comptes, la facturation, l’accueil, et un moyen d’aider un inconnu à 2 h du matin sans SSH dans leurs données.

Comment je choisirais la stack d’un MVP, je l’ai déjà écrit. Ici, la couche suivante : quand la forme du business est software-as-a-service, ce que je construirais vraiment, dans quel ordre, et ce que je ne copierais pas de Linear ou Salesforce au premier mois.

1. D’abord : est-ce vraiment un SaaS ?

Beaucoup d’« idées SaaS » sont un système sur mesure pour un client avec une facture mensuelle. Ça peut être un bon business. Ce n’est pas du SaaS. SaaS veut dire : un produit, beaucoup de locataires, inscription autonome ou vente légère, et le coût d’ajouter la prochaine entreprise est proche de zéro - pas un autre projet.

• SaaS : beaucoup d’organisations, les mêmes fonctions, la facturation dans le produit, la disponibilité est votre responsabilité.
• Sur mesure : un acheteur, des workflows uniques, vous facturez les demandes de changement. Ne faites pas semblant que le deuxième client « se connectera juste ».
• Si les trois premiers clients ont chacun besoin d’un fork, arrêtez d’appeler ça un SaaS. Vendez des projets jusqu’à ce que le recouvrement soit évident - puis extrayez le produit.

2. L’unité du produit est l’espace de travail, pas l’utilisateur

Je modéliserais le domaine autour d’une organisation (workspace, tenant, account - un mot, et on s’y tient). Les utilisateurs appartiennent aux organisations. Les données appartiennent aux organisations. Les factures appartiennent aux organisations. Si vous partez de « User a des Projects », vous passerez six mois à boulonner équipes, invitations et « qui paie ».

• L’organisation a un plan, un email de facturation et un statut : trial, active, past_due, canceled.
• L’appartenance est une ligne : user + org + rôle (owner, admin, member suffisent au départ).
• Chaque table métier a org_id. Une requête sans org_id est un bug, pas un raccourci.
• Des invitations plutôt que « créer un compte pour eux ». Email, acceptation, arrivée dans le bon espace.

3. Isolation : base partagée, cloisonnement strict

Pour un premier SaaS je n’ouvrirais pas un Postgres par client. Une base, org_id sur chaque ligne, et une défense en profondeur pour qu’un WHERE oublié ne devienne pas une fuite. Une base par locataire, c’est pour l’isolation réglementée ou des voisins bruyants déjà mesurés - pas pour le locataire numéro quatre.

• Row-level security ou un helper de requêtes qui injecte toujours org_id depuis la session - pas depuis le body client.
• Des identifiants non devinables (UUID). Les /org/12/invoices/4 séquentiels sont une invitation.
• Stockage fichiers préfixé par org_id, URLs signées, jamais un bucket public de « tous les uploads ».
• Un schéma ou une base par locataire seulement si un contrat, une checklist de conformité ou un vrai voisin bruyant l’impose. Des migrations sur 200 schémas sont un produit que vous ne vouliez pas.

4. La facturation est une fonction, pas un plugin pour plus tard

Si personne ne peut payer, vous n’avez pas de SaaS. Je mettrais le Checkout sur le chemin critique dès la semaine deux, même si le reste de l’app est mince. Une phase « on facture à la main » est ok pour les cinq premiers partenaires de conception - ensuite la carte doit marcher.

• Stripe Billing (ou le processeur que votre premier marché utilise vraiment) : products, prices, customer portal, webhooks. Ne stockez pas les numéros de carte. N’écrivez pas un moteur de relance.
• Un ou deux plans, pas sept. Un essai avec une fin claire. Après l’essai : lecture seule ou blocage dur - choisissez et dites-le dans l’interface.
• Prix sur une chose que le client comprend : sièges, projets ou volume mensuel. La facturation à l’usage est puissante et facile à rater ; commencez par un siège ou un forfait jusqu’à savoir ce qu’est « l’usage ».
• Les webhooks sont la source de vérité pour « est-ce payé ? ». Votre base reflète Stripe (ou Paddle). Un cron qui devine, c’est comme ça qu’on bloque un client payant.

5. La stack que je prendrais (et en quoi elle diffère d’un MVP site)

Le défaut web tient toujours : Next.js, TypeScript, Tailwind, Postgres. Le SaaS ajoute quelques pièces dont un site marketing n’a pas besoin - et n’a toujours pas besoin d’un maillage de services.

• Auth qui comprend les organisations : Clerk, WorkOS, Auth.js plus la table d’appartenance - pas un flag global « connecté ».
• Des tâches de fond dès le premier jour si quelque chose est lent ou relançable : emails, webhooks Stripe, exports, appels LLM. Une file simple (Inngest, Trigger.dev ou un worker sur le VPS) vaut mieux qu’un setTimeout dans une fonction serverless.
• Email transactionnel dès la première minute : invitation, reçu, « votre essai finit vendredi ». Si le mail n’arrive pas, le produit paraît mort.
• Feature flags pour les plans (can_export, seat_limit), pas des if (org.plan === "pro") dans cinquante fichiers.
• Hébergement : Vercel plus Postgres hébergé, tant qu’un worker ou la résidence des données ne dit pas le contraire. Une région suffit. Le multi-région, c’est plus tard.

6. L’accueil est le produit de la première heure

Les tableaux de bord SaaS vides ne convertissent pas. Je concevrais la première session comme un travail, pas comme une visite : créer l’espace, importer ou saisir le premier vrai enregistrement, inviter un collègue, voir un résultat. Des infobulles sur une table vide ne sont pas de l’accueil.

• Un espace d’exemple est ok s’il est clairement factice et à un clic de « commencer avec mes données ».
• Métrique d’activation : ils ont fini le travail central une fois, pas « inscrit ». Mesurez ça. Vendez ça.
• Les réglages peuvent être moches. L’état vide de l’écran principal, non.

7. Exploitation : comment aider des gens que vous n’avez jamais rencontrés

Le jour où une organisation payante écrit « je ne vois pas mes factures », il faut un chemin sans SSH prod. J’ajouterais un admin interne mince avant le dixième client, pas après le premier incident.

• Admin : trouver l’organisation, voir le plan et le dernier webhook, se faire passer pour elle en lecture seule, renvoyer l’invitation. Auditer cette prise d’identité.
• Logs avec org_id et request id. « Ça a planté » sans locataire n’est pas une ligne de log, c’est un haussement d’épaules.
• Des sauvegardes que vous avez restaurées une fois. La nuit suffit au début ; une sauvegarde non testée est une histoire que vous vous racontez.
• Une page de statut peut attendre. Un email « on est down, voilà ce qu’on sait », non.

8. Ce que je ne construirais pas la première année

Un grand SaaS est un musée de fonctions qui se sont payées plus tard. Copier le musée, c’est rater le seul travail.

• SSO, SCIM et un questionnaire de sécurité de 40 pages seulement si un vrai contrat est bloqué là-dessus. Alors c’est le sprint, pas une quête secondaire.
• Une API publique et une vitrine d’intégrations. Un Zapier ou un export CSV débloque souvent le même acheteur.
• Domaines personnalisés par locataire, marque blanche et studio de thèmes. Un envoi de logo suffit pour la plupart du B2B précoce.
• De l’IA partout. Un endroit où le langage est le travail (recherche, brouillons, extraction), avec un schéma et un compteur facturable. Pas une bulle de chat sur chaque écran.

9. Une séquence que je suivrais vraiment

La même honnêteté de calendrier que pour un MVP, avec des jalons en forme SaaS. Si une semaine n’a ni locataire, ni paiement, ni travail, ce n’est pas une semaine SaaS.

• Semaine 0 : nommer le travail, l’acheteur, le plan, le chiffre d’abandon (ex. cinq organisations payantes en 90 jours ou on arrête). Les non-objectifs sur une page.
• Semaines 1-2 : organisation + appartenance + un parcours heureux en prod + Stripe test mode. Tests d’isolation : user A ne voit pas user B.
• Semaines 3-4 : facturation en direct, invitations, emails, accueil d’état vide, admin mince. Le montrer à des entreprises nommées, pas « à internet ».
• Jours 30-90 : regarder l’activation et les raisons de départ. Ajouter la seule intégration ou le rapport pour lequel ils paient. Ne pas ajouter un second produit.

Conclusion : louez un travail, pas une plateforme

Je construirais un SaaS aussi peu glamour qu’un MVP, plus ce qui fait partager un système à plusieurs entreprises : un espace de travail, une facture, un mur entre locataires, une première heure qui n’est pas vide, et un admin pour que le support ne soit pas un root shell. La stack peut rester ennuyeuse. Le produit, non.

Si vous avez un workflow que plusieurs entreprises vous paient déjà à répéter, et que vous le voulez en produit plutôt qu’en tas de déploiements sur mesure - écrivez via la section contacts. On peut nommer le modèle de locataire, le premier plan, et une tranche qui prend une carte sans jouer à Salesforce.