BlogTechnique · 8 octobre 2026

Lancer un SaaS : ce qu'il faut décider avant le code

Comptes, isolation des clients, données personnelles, facturation : les décisions qui structurent un SaaS, à prendre avant d'écrire le code.

Tous les articles Nous écrire

Lancer un SaaS : ce qu'il faut décider avant le code

Un logiciel vendu sur abonnement, un SaaS, ressemble vu de l'extérieur à n'importe quelle application web. La différence se joue en dessous. Plusieurs entreprises clientes partagent la même plateforme, chacune avec ses utilisateurs, ses données et ses droits. Certaines décisions prises au premier jour déterminent alors ce qui sera simple ou très coûteux plus tard. Il ne s'agit pas de tout prévoir, mais de ne pas fermer de portes par inadvertance. Voici les choix qui méritent d'être faits avant d'écrire la première ligne de code.

Le modèle multi-clients

Une maquette d'immeuble en coupe montrant des appartements identiques et cloisonnés. — Un même immeuble, des locataires bien séparés.

C'est la décision la plus structurante. Un SaaS sert plusieurs organisations, que l'on appelle souvent des « locataires ». Il faut choisir comment leurs données cohabitent.

Une base partagée, cloisonnée par organisation

Toutes les données sont dans la même base, et chaque ligne porte l'identifiant de son organisation. C'est l'approche la plus courante pour démarrer : simple à exploiter, économique, facile à faire évoluer. Elle exige une discipline absolue : chaque lecture et chaque écriture doit filtrer par organisation, côté serveur. Des mécanismes comme la sécurité au niveau des lignes de PostgreSQL, utilisée notamment par Supabase, permettent de faire appliquer cette règle par la base elle-même.

Une base par client

Chaque client a sa propre base, voire sa propre instance. L'isolation est plus forte, ce qui rassure certains secteurs, mais l'exploitation se complique : chaque mise à jour doit être appliquée partout, chaque sauvegarde gérée séparément.

Le bon choix dépend de la clientèle visée. L'important est de le faire consciemment, et de le documenter.

Les comptes et les rôles

Dans un SaaS, un utilisateur n'est presque jamais seul. Il appartient à une organisation, parfois à plusieurs, et y tient un rôle. Quelques questions à trancher tôt :

Un utilisateur peut-il appartenir à plusieurs organisations ? Un comptable qui suit plusieurs clients, un consultant, un groupe avec des filiales.

Quels rôles existent ? Propriétaire, administrateur, membre, lecteur. Mieux vaut peu de rôles bien définis qu'une matrice de droits illisible.

Qui invite qui ? Le parcours d'invitation et de départ d'un collaborateur doit être pensé, y compris ce que deviennent ses données.

Quelle connexion ? Mot de passe, lien magique, connexion via le compte professionnel de l'entreprise. Les clients plus importants demandent souvent cette dernière option.

Le standard de vérification de la sécurité applicative de l'OWASP (ASVS) fournit une liste de contrôles utiles pour l'authentification et la gestion des sessions.

Les données personnelles

Un SaaS européen manipule presque toujours des données personnelles, ne serait-ce que celles des utilisateurs. Le RGPD impose la protection des données dès la conception et par défaut (article 25). Concrètement, cela veut dire :

ne collecter que ce qui sert réellement ;

savoir où les données sont hébergées, et par qui ;

prévoir l'export et la suppression des données d'un client qui part ;

tenir à jour la liste de vos propres sous-traitants (hébergeur, envoi d'e-mails, paiement).

Vos clients, eux, vous considéreront comme leur sous-traitant au sens de l'article 28. Ils vous demanderont un contrat de traitement des données. Autant le préparer tôt.

La facturation et les offres

Le modèle économique influence l'architecture. Facturé par utilisateur, par volume, par fonctionnalité ? Chaque option demande de mesurer quelque chose et de limiter l'accès en conséquence. Il est sage de séparer dès le début la notion d'offre (ce que le client a payé) de la logique métier (ce que l'application fait). Ainsi, changer une grille tarifaire ne demande pas de réécrire l'application.

L'exploitation au quotidien

Un SaaS ne s'arrête jamais. Il faut pouvoir déployer une nouvelle version sans interrompre le service, savoir rapidement qu'une erreur touche un client, et restaurer une sauvegarde sans improviser. Ces sujets paraissent lointains au lancement ; ils deviennent urgents dès les premiers clients payants.

Les outils choisis dépendent de l'architecture. Selon les projets, nous travaillons par exemple avec Vercel pour le déploiement, TanStack Start pour l'application, Convex ou Supabase pour les données. Aucun n'est imposé : chacun est retenu parce qu'il répond au besoin.

Ce qui peut attendre

Tout ne doit pas être décidé d'avance. Un tableau de bord d'analyse avancé, une application mobile, une place de marché d'extensions : ces sujets peuvent venir plus tard, à condition que les fondations (organisations, rôles, données) soient saines. C'est tout l'enjeu d'un premier MVP bien cadré, que nous décrivons sur la page produits SaaS.

Questions fréquentes

Peut-on transformer un outil interne en SaaS ?

Oui, mais il faut presque toujours revoir le cloisonnement des données et la gestion des comptes. Un outil pensé pour une seule entreprise suppose implicitement que tout le monde voit tout.

Faut-il une base de données par client ?

Pas nécessairement. Une base partagée, bien cloisonnée, convient à la plupart des SaaS. Une base par client se justifie surtout pour des exigences contractuelles ou réglementaires fortes.