Architecture multi-tenant : la bonne manière d’isoler les données client
Un guide pratique des compromis entre les modèles silo, bridge et pool, et pourquoi le Row-Level Security s’impose souvent comme la meilleure option.
Les produits SaaS multi-tenant imposent une décision fondamentale dès le premier jour : comment isoler les données de chaque client ? Une mauvaise décision ici peut créer des problèmes de conformité, des difficultés de passage à l’échelle et, dans le pire des cas, des fuites de données entre tenants.
Le modèle silo attribue une base de données physique séparée à chaque tenant. Il offre le niveau d’isolation le plus fort et rend les sauvegardes et restaurations par client très simples, mais il augmente fortement les coûts d’infrastructure et complique la gestion des évolutions de schéma.
Le modèle bridge place plusieurs schémas de tenants dans la même instance de base de données. Il réduit les coûts tout en améliorant la séparation, mais le modèle opérationnel peut devenir lourd lorsque le nombre de schémas grandit ou que le moteur commence à mal gérer trop de tables.
Le modèle pool garde tous les tenants dans les mêmes tables et sépare les enregistrements grâce à une colonne tenant_id. C’est l’approche la plus scalable et la plus rentable, mais aussi celle qui introduit le plus grand risque applicatif : un bug de requête peut exposer les données d’un autre client si l’isolation n’est pas rigoureusement appliquée.
C’est pourquoi de nombreuses équipes SaaS B2B modernes utilisent des tables partagées combinées au Row-Level Security. Les politiques définies au niveau base de données déplacent l’isolation dans la couche de persistance et réduisent le risque qu’un bug applicatif renvoie des données d’un autre tenant.
Le bon choix dépend toujours des exigences réglementaires, de la segmentation client et de la maturité opérationnelle. Mais pour beaucoup de produits SaaS modernes, le modèle pool avec Row-Level Security offre l’équilibre le plus solide entre sécurité, coût et passage à l’échelle.