Au début d'un projet, on imagine deux rôles : « admin » et « utilisateur ». Six mois plus tard arrivent commerciaux, comptables, partenaires externes, clients accédant à leurs propres données, et les droits commencent à être codés au cas par cas. C'est ainsi que naissent failles et bugs. Le modèle d'accès mérite d'être conçu en amont ; c'est l'une des tâches de base du développement d'applications web.
En bref : séparez deux axes : à quelles données l'utilisateur accède (tenant, organisation, projet) et quelles actions il peut effectuer (rôle et droits). Vérifiez les droits côté serveur à chaque requête et journalisez les actions importantes.
Multi-tenant : à qui appartiennent les données
Si plusieurs entreprises utilisent le produit, les données de chacune doivent être cloisonnées. Les principales approches :
| Approche | Fonctionnement | Quand l'utiliser |
|---|---|---|
| Base partagée avec ID de tenant | Chaque enregistrement porte l'ID de l'organisation | La plupart des SaaS, démarrage rapide |
| Schéma par tenant | Un jeu de tables par client | Exigences d'isolation renforcées |
| Base par tenant | Isolation complète | Grands comptes, exigences réglementaires |
Modèles de droits
- RBAC (par rôles) : des rôles avec des ensembles de droits : propriétaire, admin, gestionnaire, lecteur. Simple et lisible.
- Droits par ressource : voir, créer, modifier, supprimer par section ; plus souple, idéal pour CRM et back-offices.
- Règles par attributs (ABAC) : l'accès dépend de propriétés, par exemple « un commercial ne voit que ses affaires ». Puissant mais plus lourd à maintenir.
Ce qu'il faut prévoir dès le départ
- Un ID d'organisation dans chaque table métier.
- Une vérification des droits côté serveur, pas seulement des boutons masqués.
- Des invitations avec rôle et lien à durée limitée.
- Un journal d'audit : qui a modifié quoi et quand.
- Des droits spécifiques pour l'export et la suppression de données.
Erreurs fréquentes
- Droits vérifiés uniquement côté front : l'API est ouverte à tout utilisateur connecté.
- Identifiants séquentiels non contrôlés quant à l'organisation propriétaire.
- Rôles codés en dur, impossibles à configurer.
- Aucun journal d'actions : impossible d'analyser un incident.
Questions fréquentes
Peut-on ajouter le multi-tenant plus tard ?
Oui, mais à grands frais : migration des données et réécriture des requêtes. Si le produit doit servir plusieurs entreprises, prévoyez-le dès le départ.
Faut-il l'authentification unique (SSO) ?
Souvent pour les clients grands comptes, mais elle peut attendre dans le MVP. Voir notre article sur les priorités d'un MVP SaaS.
Quel lien avec le CRM ?
Les droits par ressource sont l'ossature de tout CRM : les commerciaux voient leurs affaires, les responsables leur service. Nous utilisons le même modèle dans nos systèmes CRM/ERP et connectons les données d'autres services via des API.
Vous concevez un produit avec rôles et espaces clients ? Envoyez votre demande sur la page applications web : nous concevrons le modèle de données, d'accès et d'audit avant le développement.