1. Le socle : auth indépendante du métier

L'authentification doit être pensée comme un module à part entière, indépendant des features métier. Plutôt que d'emmêler la logique d'inscription dans chaque écran, on centralise : inscription, connexion, déconnexion, réinitialisation de mot de passe et sessions. La séparation passe par une couche d'API claire combinée à des composants frontend réutilisables. Côté serveur, les tokens (JWT avec refresh tokens ou sessions gérées par le framework) sont émis par un service dédié. Côté client, un provider d'authentification expose un état global de session que toutes les pages consomment via un hook ou un contexte.

2. Organisations et multi-tenant

Le multi-tenant est le cœur d'un SaaS : chaque client (entreprise ou organisation) travaille dans son propre espace sans jamais voir les données des autres. Le modèle le plus simple et le plus sûr est une table organizations associée à une colonne organization_id sur chaque table métier. Le filtrage rigoureux par organization_id à chaque requête évite les fuites de données. L'isolation peut être renforcée avec des scopes d'ORM ou des policies de niveau base de données. Un utilisateur peut appartenir à plusieurs organisations, ce qui introduit la notion d'organisation "active" au niveau de la session.

3. Rôles et permissions (RBAC)

Le contrôle d'accès basé sur les rôles (RBAC) est essentiel pour gérer qui peut faire quoi. On distingue des rôles système (propriétaire, administrateur, membre) et des rôles personnalisables par organisation. La mise en place repose sur trois concepts : les rôles (ex. admin, éditeur, lecteur), les permissions (ex. créer un projet, supprimer un fichier) et les assignations (qui détient quel rôle où). En frontend, un hook d'autorisation vérifie la permission avant de rendre un bouton ou de bloquer une route, tandis que le backend re-vérifie toujours la permission en dernier ressort.

4. Abonnements et facturation

La facturation SaaS implique de lier les organisations à des plans et de gérer le cycle de souscription. Le modèle comprend : des plans (gratuit, pro, entreprise), des limites par plan (nombre d'utilisateurs, de projets), et un cycle de paiement (mensuel ou annuel). L'intégration de paiements doit rester déléguée à un fournisseur de paiement pour la conformité. Les webhooks de facturation mettent à jour l'état de l'abonnement (payé, impayé, annulé) et déclenchent les rétrogradations de limites. Une file de jobs asynchrone gère les rappels d'impayés et l'émission des factures PDF.

5. Architecture technique recommandée

  • Frontend : Next.js (SSR/SSG), Tailwind CSS v4, shadcn/ui, TanStack Query pour les données, Zustand pour l'état global
  • Backend : Node.js, API REST structurée, Drizzle ORM avec PostgreSQL, authentification JWT
  • Files asynchrones : jobs en arrière-plan pour facturation, emails et notifications
  • Infrastructure : Docker Compose en dev, Traefik en reverse proxy, déploiement Vercel ou conteneurs

Conclusion

Un socle SaaS modulaire transforme une base de code en plateforme réutilisable. En isolant l'auth, le multi-tenant, le RBAC et la facturation du cœur métier, on peut ensuite bâtir plusieurs produits sur la même ossature sans réécrire les fondations. C'est exactement l'approche que je retiens avec le Wabtechs SaaS Starter : investir dans un socle solide pour accélérer chaque nouveau produit SaaS.
Retour au blog Me contacter