SaaS
Comment séparer les données des clients dans un SaaS
Dans une plateforme SaaS, les données des clients sont séparées selon l'un des trois modèles d'AWS. Dans le silo, chaque client a ses propres ressources. Dans le pool, les clients partagent les ressources. Le bridge combine les deux. Le modèle se choisit dans le plan du système, avant d'écrire du code.
Si vous pensez à un produit SaaS, l'une des premières questions est de savoir à quel point les données de chaque client seront séparées. La réponse pèse sur le coût et sur la sécurité, et elle se change difficilement plus tard. L'article explique les trois options d'AWS avec des exemples simples, pour que vous puissiez en parler avec votre équipe.
Qu'est-ce qu'un tenant ?
Un tenant est un client du produit SaaS, avec ses utilisateurs et ses données. Une entreprise qui utilise votre plateforme est un tenant, et son organisation voit le produit comme s'il était le sien. En réalité, le même logiciel sert des dizaines ou des centaines de tenants en même temps.
C'est pourquoi l'isolation des tenants compte autant. Le Well-Architected SaaS Lens d'AWS en fait un sujet fondamental, que tout fournisseur de SaaS doit traiter. Il ajoute que franchir cette limite, de quelque manière que ce soit, serait un événement grave et probablement irréversible pour une entreprise SaaS. Un client qui voit les données d'un autre perd sa confiance en un instant.
Qu'est-ce que le modèle silo ?
Dans le modèle silo, chaque tenant a ses propres ressources, qui lui sont réservées. AWS donne deux exemples : un ensemble d'infrastructure entièrement indépendant pour chaque tenant, ou une base de données distincte pour chacun. Quand une partie ou la totalité des ressources d'un tenant lui est dédiée, on parle de silo.
Même dans ce cas, AWS souligne que l'identité, l'inscription et l'exploitation restent communes à tous. C'est ce qui distingue un SaaS d'un service où chaque client fait tourner sa propre version du produit. Le gain est une séparation forte, car les données se trouvent à des endroits différents. Le coût est plus de travail d'exploitation, car chaque changement doit atteindre toutes les ressources.
Qu'est-ce que le modèle pool ?
Dans le modèle pool, les tenants partagent les mêmes ressources. AWS y voit le sens le plus classique de la multi-location (multi-tenancy) : une infrastructure partagée et évolutive qui apporte une économie d'échelle, une gestion plus simple et de la rapidité dans les changements. Les ressources partagées peuvent être de la puissance de calcul, du stockage ou des files de messages.
Ici, la séparation ne vient pas de la structure. Elle vient du code, qui doit filtrer par tenant dans chaque requête vers la base. Si un filtre manque dans un écran, les données d'un autre client peuvent apparaître. C'est pourquoi le pool demande un contrôle systématique, avec des tests qui cherchent justement cette erreur.
Qu'est-ce que le modèle bridge ?
Le bridge est la combinaison des deux. AWS note que les produits SaaS ne sont pas toujours purement silo ou pool, et que beaucoup de systèmes ont une forme mixte. Par exemple, un service du système peut être en silo et un autre en pool.
Qu'est-ce qui pousse vers le silo ? AWS cite le profil réglementaire des données et l'effet de « voisin bruyant », où un tenant à forte charge ralentit les autres. Qu'est-ce qui pousse vers le pool ? La souplesse, le mode d'accès et le coût. En pratique, les données aux exigences élevées restent séparées, tandis que les autres fonctions partagent les ressources.
Comment choisissons-nous un modèle pour un projet ?
Nous choisissons selon les besoins du projet, pas selon la préférence d'une technologie. Dans la première étape, nous notons trois choses : quelles données sont stockées, combien de tenants sont attendus et ce que vos clients vous demandent. Avec cela, la comparaison devient simple.
Question | Penche vers le silo | Penche vers le pool |
|---|---|---|
Les données sont-elles sensibles ? | Très sensibles ou réglementées | Données professionnelles courantes |
Combien de tenants sont attendus ? | Peu, grands | Beaucoup, petits |
La charge varie-t-elle d'un tenant à l'autre ? | Beaucoup | Peu |
Quelle priorité pour le coût d'exploitation ? | Secondaire | Élevée |
Le résultat est écrit dans le plan du système que vous approuvez. Vous savez ainsi dès le début ce que coûte chaque choix, et la discussion n'a pas lieu plus tard, quand le code existe déjà.
Qu'avons-nous choisi pour Praion AI ?
Dans notre propre produit Praion AI, chaque client a sa propre base de données. Nous le décrivons en détail dans l'étude de cas de Praion AI. On y trouve des conversations, des contacts et des notes privées, des données que le client veut savoir à lui seul. C'est pourquoi l'isolation a été construite dans la structure, et non dans l'attention de celui qui écrit le code.
Ce choix a un coût, et nous l'avons accepté en connaissance de cause : chaque mise à jour doit atteindre toutes les bases. Dans un autre projet, avec des données moins sensibles et beaucoup de petits clients, le même raisonnement pourrait mener au pool. C'est la logique que nous suivons, pas une recette fixe. La question suivante, c'est-à-dire qui voit quoi parmi les utilisateurs de chaque client, est expliquée dans l'article sur les rôles et les droits. Ensemble, ces deux décisions définissent qui a accès à quelles données.
Questions fréquentes: Comment séparer les données des clients dans un SaaS
Quel modèle est le meilleur ?
Aucun n'est meilleur dans tous les cas. Le silo donne une séparation plus forte, avec plus de travail d'exploitation. Le pool donne de l'économie et une gestion plus simple, mais demande un contrôle systématique du code. Le choix se fait projet par projet.
Le modèle peut-il changer plus tard ?
Oui, mais cela coûte. Le changement touche la base, le code et l'exploitation de la plateforme. C'est pourquoi la décision est écrite et approuvée au début, quand la changer ne coûte rien.
Un filtre par tenant dans chaque requête suffit-il ?
Le filtre est indispensable dans le pool, mais il ne suffit pas qu'il existe dans le code. Il faut aussi des tests qui vérifient que chaque écran et chaque rapport n'affichent que les données du bon tenant. Cette erreur se voit mal avec peu de données de test.
Quel rapport avec les droits des utilisateurs ?
Ce sont deux niveaux différents. L'isolation du tenant définit quelles données appartiennent à quel client. Les rôles et les droits définissent ce que fait chaque utilisateur dans son compte. Nous expliquons ce sujet dans l’article sur les rôles et les droits dans un SaaS.
Vous voulez que nous concevions votre plateforme ?
Si vous construisez un produit SaaS ou une plateforme interne pour plusieurs clients, le modèle de données est le premier sujet à discuter. Décrivez votre projet dans la demande de projet et nous l'examinerons ensemble, à l'étape des besoins. Voyez aussi la page sur les plateformes SaaS.