L'architecture multi-tenant signifie qu'une seule application en cours d'exécution sert de nombreux clients, appelés tenants, tout en maintenant les données de chaque tenant séparées. C'est la base standard des produits SaaS, car chaque client partage le même code et la même infrastructure, ce qui maintient les coûts de fonctionnement bas. Le travail de conception consiste à isoler les tenants les uns des autres.
Qu'est-ce qu'un tenant
Un tenant est un compte client qui possède ses propres utilisateurs et données, par exemple une entreprise utilisant votre produit. Les employés du tenant A ne doivent jamais voir les données du tenant B, même si les deux utilisent la même application et souvent la même base de données.
En quoi est-ce différent du single-tenant
Dans une configuration single-tenant, chaque client dispose de son propre déploiement. Cela offre une isolation robuste et une personnalisation facile par client, mais multiplie le travail : chaque mise à jour, sauvegarde et incident se répète pour chaque client.
| Multi-tenant | Single-tenant | |
|---|---|---|
| Infrastructure | Partagée | Par client |
| Coût de fonctionnement par client | Plus faible | Plus élevé |
| Mises à jour | Une seule fois pour tous | Par client |
| Isolation | Par conception et règles d'accès | Physique |
| Personnalisation | Limitée, via les paramètres | Large |
| Convient à | La plupart des SaaS | Conformité stricte, grands contrats sur mesure |
Quels modèles de base de données existent
Les équipes choisissent généralement parmi trois options :
- Base de données partagée, tables partagées. Chaque ligne porte un identifiant de locataire. C'est la solution la moins coûteuse et la plus simple à faire évoluer, et elle repose sur un filtrage correct de chaque requête.
- Base de données partagée, schéma par locataire. Chaque locataire dispose de son propre schéma. L'isolation est plus forte et les migrations deviennent plus lourdes à mesure que le nombre de locataires augmente.
- Base de données par locataire. L'isolation la plus forte et le coût le plus élevé, souvent utilisée pour les grands clients ou les clients soumis à des réglementations strictes.
De nombreux produits démarrent avec des tables partagées et migrent les grands clients vers leur propre base de données par la suite.
Comment garantir l'isolation des locataires
Appliquez l'isolation à plusieurs niveaux. Intégrez l'identifiant de locataire dans chaque table et chaque chemin de requête, et ajoutez des contrôles au niveau de la base de données tels que la sécurité au niveau des lignes, afin qu'un filtre manquant dans le code applicatif ne provoque pas de fuite de données. Testez-le explicitement : rédigez des tests qui tentent de lire les données d'un autre locataire et s'attendent à un échec. Une fuite entre locataires figure parmi les anomalies les plus graves qu'un produit SaaS puisse connaître.
Qu'est-ce que le problème du voisin bruyant
Lorsque des locataires partagent des ressources, un locataire très consommateur peut ralentir les autres. Anticipez ce problème avec des limites de débit, des quotas par locataire, des files de traitement en arrière-plan avec une planification équitable et une surveillance affichant la charge par locataire. Migrer un client consommateur vers des ressources dédiées est un remède courant.
Quelles sont les implications pour la conformité
Une infrastructure partagée soulève des questions lors des audits de sécurité. Les grands clients demandent souvent où leurs données sont hébergées, comment elles sont séparées et qui peut y accéder. Décidez tôt si vous pouvez proposer un hébergement régional, comme la résidence des données dans l'UE, ou un déploiement dédié pour les clients qui l'exigent. Intégrer cette exigence a posteriori dans une conception basée sur des tables partagées représente un effort considérable.
Ce que cela implique pour votre équipe d'ingénierie
La structure de location est difficile à modifier une fois que les données existent, et cette décision mérite l'attention d'un ingénieur senior dès le départ. Les agents de codage AI peuvent générer des requêtes rapidement, et ils oublieront volontiers un filtre de locataire ; les tests d'isolation et les contrôles au niveau de la base de données sont donc d'autant plus importants lorsque des agents écrivent le code. Consultez comment réviser du code généré par l'IA pour les bonnes pratiques de révision permettant de détecter ce type d'erreur.
Des plateformes backend telles que Supabase proposent une sécurité au niveau des lignes adaptée à la location avec tables partagées. Notre processus de sélection place les candidats dans une base de code réelle lors de deux sessions de soixante minutes, l'une sans outils IA et l'autre avec leurs propres agents. Pour renforcer les capacités seniors d'une équipe SaaS, consultez ingénieurs backend, à partir de €5 600 par mois pour un ingénieur à temps plein.
Réponses courtes
La multi-location est-elle synonyme de SaaS ?
Pas exactement. La plupart des produits SaaS utilisent la multi-location car elle réduit les coûts, mais un produit SaaS peut également fonctionner avec un déploiement distinct par client.
Quel modèle de base de données multi-locataire est le meilleur ?
Les tables partagées avec un identifiant de locataire constituent la solution la plus simple et la moins coûteuse. Un schéma ou une base de données par locataire offre une isolation plus forte, mais à un coût plus élevé.
Comment empêchez-vous les fuites de données entre locataires ?
Filtrez par locataire partout, ajoutez des contrôles au niveau de la base de données tels que la sécurité au niveau des lignes, et rédigez des tests qui tentent de franchir les frontières entre locataires.
Puis-je passer d'une architecture mono-locataire à une architecture multi-locataire ultérieurement ?
Oui, mais cela représente un changement important pour les modèles de données et le contrôle d'accès ; décidez-en tôt si vous le pouvez.
