Créer un SaaS B2B : donner à chaque entreprise son espace et son équipe

Décrire deux organisations, leurs membres et une personne présente dans les deux. Un scénario complet d’invitation, de changement de rôle et de départ, avec matrice des droits à vérifier.

Dans un SaaS destiné à plusieurs entreprises, un compte utilisateur ne suffit pas à décrire les accès. Il faut savoir à quelle organisation appartient chaque dossier, à quelles équipes participe chaque personne et avec quel rôle. Commencez par ces règles avant de dessiner le bouton qui permet de changer d’espace.

Le terme multi-tenant désigne ici un service qui accueille plusieurs organisations clientes avec des limites entre leurs données et leurs usages. Cette page traite le parcours des organisations : création, invitation, appartenance multiple, modification des droits et départ. La connexion individuelle et le paiement sont des sujets distincts.

Nous suivons deux agences fictives, Rivage et Atelier Nord, dans un logiciel fictif de collecte de pièces. Le scénario et la matrice ci-dessous décrivent les comportements attendus. Ils n’ont pas été exécutés dans une application et ne prouvent aucun isolement réel des données. Ils fournissent un cahier de vérification à appliquer à votre produit.

Distinguer une personne, son appartenance et l’organisation

Une personne possède une identité pour se connecter. Son appartenance relie cette identité à une organisation avec des droits précis. L’organisation possède ses dossiers et ses membres. Garder ces notions séparées permet à une personne de travailler pour plusieurs entreprises sans mélanger leurs informations.

Dans notre scénario, Léa est propriétaire de Rivage, Sami en est membre et Inès en est lectrice. Inès est aussi administratrice d’Atelier Nord, dont Malik est propriétaire. Son rôle dépend donc de l’espace où elle travaille. Administrer Atelier Nord ne doit pas lui donner un pouvoir supplémentaire chez Rivage.

La documentation des organisations de Clerk décrit ce lien entre utilisateurs, appartenances, rôles et organisation active. Ce modèle aide à formuler le problème. Le choisir ou utiliser un service similaire ne dispense pas de protéger les données et les actions de votre propre application.

Écrivez une règle pour chaque objet : à qui appartient le dossier, qui l’a créé et qui peut le consulter maintenant ? Le créateur n’est pas toujours le propriétaire métier. Un dossier créé par Sami peut appartenir à Rivage et devoir rester accessible après son départ de l’équipe.

Définir les droits avec des actions concrètes

Le nom d’un rôle ne suffit pas. Dans notre exemple, une lectrice consulterait les dossiers sans modifier les pièces. Un membre pourrait créer et corriger les dossiers. Un administrateur gérerait les invitations et les rôles ordinaires. Le propriétaire conserverait les actions de transfert et de fermeture de l’espace selon les règles retenues.

Ce sont des choix fictifs à adapter, pas une hiérarchie obligatoire. Une organisation peut avoir besoin de restrictions par dossier ou de personnes chargées uniquement des invitations. Avant d’ajouter un rôle, cherchez quelle action précise doit être permise ou interdite et dans quelle situation.

• Lire un dossier : autorisé selon l’appartenance et le périmètre choisi.
• Modifier une pièce : réservé aux rôles qui travaillent sur le dossier.
• Inviter un membre : réservé aux rôles qui gèrent l’équipe.
• Transférer la propriété : action distincte avec confirmation et destinataire admissible.

Décidez également qui peut exporter, supprimer et consulter l’historique. Ces opérations sont parfois oubliées parce qu’elles apparaissent moins souvent. Une lectrice autorisée à lire un dossier peut-elle exporter toutes les pièces de l’entreprise ? La réponse doit être explicite dans votre offre et dans vos vérifications.

Pour comprendre · illustration du guide

Créer un espace sans créer une autorité ambiguë

À la création, identifiez l’organisation et la personne qui en devient responsable dans l’application. Un nom affiché ne prouve pas l’identité juridique d’une entreprise. Pour votre parcours, décidez quelles informations suffisent à créer un espace et quelles vérifications supplémentaires sont nécessaires avant les usages prévus.

Dans le scénario, Léa crée Rivage et voit un espace sans dossier. Le logiciel doit lui indiquer qu’elle en est propriétaire et lui permettre d’identifier l’équipe active. Il ne doit pas ajouter automatiquement des personnes parce que leurs adresses ressemblent à celles de la même entreprise, sauf règle expressément conçue et vérifiée.

Prévoyez les doublons. Deux personnes peuvent créer deux espaces au nom de la même agence. Vous devez décider si ces espaces restent indépendants et comment une demande de rapprochement serait examinée. Une fusion automatique fondée sur le nom risquerait de réunir des données qui ne doivent pas l’être.

Conservez une trace de la création et des décisions importantes. Elle doit aider à comprendre qui a fait quoi dans le bon espace, sans exposer des informations inutiles aux autres clients. Cette traçabilité sert notamment lorsque plusieurs personnes portent des noms proches ou participent à plusieurs équipes.

Inviter une personne avec un périmètre visible

Une invitation doit indiquer l’espace concerné, la personne qui invite et le rôle proposé. Léa inviterait Sami comme membre de Rivage. Avant l’envoi, l’écran devrait lui permettre de relire l’adresse et le rôle. Une erreur d’adresse ne doit pas être traitée comme un détail de présentation.

Distinguez invitation envoyée, invitation en attente, acceptée, expirée et révoquée. Une adresse présente dans la liste des invitations ne doit pas être présentée comme un membre actif avant l’acceptation prévue par votre parcours. Choisissez comment renvoyer ou annuler une invitation sans créer des états contradictoires.

La documentation de gestion des membres de Makerkit couvre un ensemble de fonctions liées aux équipes, aux invitations et aux rôles dans sa variante Next.js Drizzle. Elle constitue un exemple documenté de ce périmètre produit ; elle ne certifie pas le comportement d’une application construite à partir du kit.

Pour vérifier l’invitation, prévoyez une adresse d’essai que vous contrôlez et des données fictives. Examinez l’arrivée avec le compte attendu, avec un autre compte et après révocation. Le résultat doit respecter votre règle d’identité, sans donner des droits simplement parce qu’un lien a été transmis à quelqu’un.

Accepter l’invitation et comprendre où l’on arrive

Après acceptation, Sami doit savoir qu’il rejoint Rivage et quel travail lui est accessible. S’il possède déjà un compte personnel ou un autre espace, l’interface doit rendre ce changement visible. Une arrivée silencieuse dans un dossier dont le propriétaire est ambigu peut provoquer une erreur de saisie.

Le scénario attendu comprend une confirmation compréhensible et un accès limité au rôle proposé. Réutiliser une invitation déjà acceptée ne doit pas ajouter une seconde appartenance ni rétablir des droits retirés depuis. Une invitation annulée ne doit plus ouvrir l’accès prévu initialement.

Prévoyez la personne qui possède déjà une appartenance. Le logiciel doit expliquer la situation plutôt que laisser plusieurs invitations modifier son rôle de manière imprévisible. Décidez ce qui prévaut et demandez une confirmation explicite lorsqu’un changement de droits est réellement voulu.

Changer d’organisation sans emporter ses données

Inès travaille chez Rivage comme lectrice et chez Atelier Nord comme administratrice. Le sélecteur d’espace doit montrer ces deux contextes clairement. Après un changement, les dossiers, recherches et actions disponibles doivent correspondre à l’organisation active et aux droits d’Inès dans celle-ci.

Examinez aussi les éléments moins visibles : recherche, notifications, fichiers récents, export et suggestions dans un formulaire. Cacher une liste principale ne suffit pas si un nom de dossier d’une autre agence apparaît ailleurs. Chaque chemin d’accès mérite d’être rattaché à une organisation autorisée.

Prévoyez deux onglets ouverts sur des espaces différents. Un changement dans l’un peut avoir des conséquences selon la façon dont l’application gère son contexte. Définissez le comportement attendu et vérifiez que la personne sait toujours pour quelle entreprise elle agit avant d’enregistrer une modification.

Une action commencée chez Rivage puis envoyée après un changement vers Atelier Nord ne doit pas déposer une pièce dans le mauvais dossier. La demande traitée par le service doit rester associée à la bonne organisation et être contrôlée. L’affichage du nom de l’espace aide l’utilisateur ; il ne remplace pas ce contrôle.

Modifier un rôle et retirer un accès

Supposons que Léa passe Sami de membre à lecteur. Le résultat attendu est qu’il puisse encore consulter les dossiers permis, mais ne puisse plus les modifier. Vérifiez une page fraîche et une page déjà ouverte. Une ancienne interface affichant un bouton ne doit pas suffire à conserver l’ancien droit.

Pour un départ, distinguez retirer l’appartenance à Rivage et supprimer l’identité de Sami dans tout le service. S’il travaille aussi dans une autre organisation, retirer un accès local ne doit pas supprimer automatiquement ses autres activités. Les dossiers de Rivage doivent rester rattachés à leur organisation selon les règles choisies.

Après révocation, essayez un ancien lien direct, une action préparée avant le retrait et un accès à un fichier joint. Consignez le résultat attendu puis le résultat observé. La vérification doit porter sur la réponse du service, et pas seulement sur la disparition d’un bouton dans le menu.

Préparez le message de refus : expliquer que l’accès n’est plus disponible sans révéler des détails du dossier. Donnez une action utile, comme revenir à un espace encore autorisé. Ne laissez pas la personne interpréter un accès retiré comme une perte de toutes ses données ou un problème de mot de passe.

Transférer la propriété sans laisser un espace orphelin

Le départ du propriétaire mérite un parcours distinct. Dans le scénario, Léa transmettrait Rivage à un membre admissible, après avoir vérifié la destination et confirmé l’action. Les règles doivent dire ce que devient son propre rôle et à quel moment le nouveau propriétaire peut agir.

Empêchez les situations incohérentes prévues par votre modèle : dernier propriétaire retiré, transfert vers une invitation non acceptée ou transfert vers une personne d’une autre organisation non autorisée. Vous pouvez choisir d’autres règles, mais elles doivent laisser un responsable identifiable et un moyen de gérer l’espace.

La récupération lorsque le propriétaire ne peut plus se connecter demande une procédure séparée. Un message au support ne doit pas donner automatiquement tous les droits à son auteur. Définissez les éléments permettant d’examiner la demande, les limites d’intervention et la trace conservée.

Vérifier l’isolement au-delà du parcours visible

Préparez deux jeux de données reconnaissables, un pour Rivage et un pour Atelier Nord. Listez les consultations et modifications autorisées, puis les tentatives qui doivent être refusées. Ajoutez les fichiers, les recherches et les exports, qui peuvent suivre des chemins différents des pages principales.

La documentation Supabase sur les règles par ligne décrit un mécanisme pour limiter l’accès aux lignes d’une base. C’est une couche possible selon votre architecture. Elle doit être configurée et vérifiée avec les autres chemins d’accès ; sa présence ne constitue pas une preuve de sécurité complète.

Demandez une trace précise de l’essai : version de l’application, comptes fictifs, rôle, espace, action, résultat attendu et résultat constaté. Laissez « non exécuté » tant qu’aucune observation n’existe. Une matrice bien remplie sur le papier reste un plan, même si toutes ses règles paraissent logiques.

La matrice des organisations et des droits contient les deux agences, les appartenances, le parcours complet et les cas à exécuter. Elle permet de discuter avec la personne ou l’agent qui construit le service. Avant de confier de vrais dossiers au produit, il faudra appliquer ces vérifications à l’implémentation et examiner les risques propres à votre usage.