Le choix du mode de stockage des données de chaque client est une décision d’architecture qui a des conséquences sur la sécurité, l’exploitation et l’évolution du produit. Dans un SaaS multi-tenant, il ne suffit pas que chaque utilisateur voie une interface différente : le système doit contrôler les données que chaque client peut consulter et modifier, y compris en cas d’erreur de code, de tâche en arrière-plan ou de changement de configuration.
Il n’existe pas de modèle universellement meilleur. Une base partagée peut simplifier l’exploitation, tandis qu’une base dédiée peut faciliter le respect de certaines exigences d’isolation, mais elle multiplie aussi les tâches et les coûts opérationnels. Le bon choix dépend du risque que l’on veut réduire, des engagements pris envers les clients et de la capacité réelle de l’équipe à exploiter l’architecture.
Ce que signifie isoler les données par client
L’isolation des données, ou multitenancy, consiste à séparer logiquement les informations de chaque organisation au sein d’un service partagé. Le tenant est généralement une entreprise cliente, même si le modèle commercial peut définir une autre unité. L’application doit associer chaque requête, processus et donnée à un tenant autorisé, puis faire respecter cette relation de manière cohérente.
La séparation du stockage ne résout pas automatiquement tous les risques. Une autorisation incorrecte peut permettre à un utilisateur d’accéder aux fonctions d’un autre client ; un journal exporté ou un système d’analyse peut exposer des données alors même que la base principale est correctement segmentée. Il faut également tenir compte des sauvegardes, des journaux, des caches, des fichiers, des intégrations et des environnements d’assistance.
La bonne question n’est donc pas seulement de savoir où stocker les données, mais quels contrôles empêchent les accès entre clients et comment vérifier leur efficacité. L’architecture de stockage est un volet de cette stratégie, et non un substitut à l’authentification, à l’autorisation, à la revue du code ou à la gestion sécurisée des opérations.
Trois modèles de stockage courants
Base de données partagée
Tous les clients utilisent la même base de données et, souvent, les mêmes tables. Chaque enregistrement comporte un identifiant de tenant, et les requêtes doivent appliquer un filtre correspondant. Ce modèle réduit généralement la complexité du provisionnement et facilite l’application des changements de schéma en une seule fois. Il convient lorsque le produit démarre, que les exigences sont similaires d’un client à l’autre et que l’équipe est en mesure de mettre en place des contrôles fiables.
Son principal risque est qu’une requête ou un processus oublie le filtre. Cela peut entraîner la lecture ou la modification de données appartenant à un autre client. En outre, les clients partagent les ressources : si la capacité n’est pas gérée, une forte charge chez une entreprise peut affecter les autres.
Schéma distinct par client
Une base de données héberge plusieurs schémas, un par client, avec des tables similaires. Cette séparation peut rendre la frontière entre les ensembles de données plus visible et faciliter certaines opérations propres à un client. Elle n’élimine toutefois ni le risque d’erreur de routage ni le partage des ressources. Les migrations et les outils doivent parcourir les schémas de manière cohérente ; lorsque le nombre de clients augmente, la gestion des versions et des exceptions peut devenir difficile.
Base de données dédiée
Chaque client, ou un petit groupe de clients, dispose de sa propre base de données. Cette approche peut faciliter la localisation des données, les restaurations sélectives et le respect d’exigences contractuelles imposant des ressources ou des limites d’accès différenciées. Selon le déploiement des services, elle peut aussi réduire l’impact d’une forte charge ou d’un incident sur les autres clients.
Le coût est d’ordre opérationnel : provisionner, mettre à jour, surveiller, sauvegarder et tester de nombreuses bases nécessite de l’automatisation et des ressources au sein de l’équipe. Une base dédiée ne protège pas non plus contre des autorisations trop étendues, des identifiants compromis ou des erreurs dans l’application. Il faut vérifier le niveau d’isolation réellement fourni par la plateforme retenue.
Critères de décision
Évaluez les modèles au regard des exigences concrètes du produit, plutôt qu’en fonction d’une préférence abstraite pour la séparation. Documentez les besoins actuels ainsi que les engagements susceptibles d’influencer l’évolution du produit.
- Risque d’accès entre clients : déterminez quelles données sont sensibles, quels acteurs y accèdent et à quels endroits le contexte du tenant peut être perdu. Définissez des contrôles préventifs et des tests négatifs visant à tenter d’accéder aux données d’un autre client.
- Exigences des clients : vérifiez les obligations contractuelles et les besoins en matière de localisation, de conservation, de restauration ou d’audit. Ne considérez pas une demande de « base dédiée » comme une obligation légale sans l’avoir validée auprès des équipes compétentes.
- Exploitation : estimez la charge liée aux déploiements, aux sauvegardes, aux restaurations, à l’observabilité, à l’assistance et à la gestion des incidents. Demandez-vous si l’équipe peut automatiser ces tâches de manière reproductible.
- Variabilité du produit : des clients aux versions, extensions ou politiques très différentes peuvent nécessiter des limites plus nettes. Toutefois, éviter une plateforme commune risque de créer des divergences difficiles à maintenir.
- Coût du changement : réfléchissez à la manière de déplacer un client, de vérifier les données transférées et d’estimer la durée de la transition. Un choix initial simple est plus sûr s’il ne ferme pas la porte à d’autres options.
Une matrice de décision permet de rendre les compromis explicites. Évaluez chaque option au regard d’exigences vérifiables et distinguez les critères obligatoires des critères souhaitables. Si un client impose une condition que le modèle partagé ne peut pas satisfaire, cette contrainte doit primer sur une préférence générale pour la simplicité.
Contrôles pour un modèle partagé
Si vous choisissez une base partagée, considérez l’identifiant du tenant comme un élément essentiel de la conception. Il doit provenir d’une identité et d’un contexte validés par le serveur, et non d’une valeur arbitraire envoyée par le navigateur. Les couches d’accès aux données doivent recevoir ce contexte de façon cohérente et éviter les requêtes qui ne sont pas limitées au tenant concerné.
Lorsque la technologie le permet, mettez en place des contrôles à plusieurs niveaux : contraintes de base de données, permissions limitées, politiques d’accès et validations dans l’application. Ne les considérez pas comme interchangeables ; vérifiez lesquels s’appliquent à vos processus, connexions et tâches administratives. Pour les processus asynchrones, les files d’attente et les tâches planifiées, transmettez et validez explicitement le tenant.
Incluez des tests automatisés qui créent au moins deux tenants et vérifient les lectures, les écritures, les recherches, les exports et les opérations d’assistance. Ajoutez des revues pour les nouvelles requêtes et surveillez des indicateurs tels que les erreurs d’autorisation, les requêtes sans contexte et les tâches ayant échoué. Les journaux doivent faciliter l’analyse des incidents sans exposer inutilement des données sensibles.
Quand adopter une approche hybride
Un modèle hybride associe une base partagée pour la majorité des clients à un stockage séparé pour ceux qui en ont une justification. Il peut être utile lorsqu’une différence avérée existe en matière d’exigences, de volume, de localisation ou d’isolation. Il permet aussi de commencer avec une exploitation commune et de réserver des ressources spécifiques là où elles apportent une réelle valeur.
Définissez les règles d’attribution avant de créer des exceptions : quelle exigence justifie une base dédiée, qui approuve le changement, comment le coût est calculé et quel niveau d’assistance est fourni. Conservez un mécanisme commun pour identifier l’emplacement de chaque tenant et évitez que la logique métier dépende du nom ou de l’adresse des bases de données. Sans critères clairs, l’approche hybride devient un ensemble de cas particuliers.
Concevoir la migration et garder une décision révisable
Dès le départ, séparez l’identité du tenant de son emplacement physique. Utilisez une couche d’accès capable de diriger les opérations vers le stockage approprié, et automatisez le provisionnement et les migrations. Dans la mesure du possible, veillez à ce que les changements de schéma restent compatibles pendant les transitions et définissez comment vérifier les volumes, l’intégrité et les permissions avant d’activer la destination.
Une migration peut nécessiter de copier les données, d’interrompre les écritures ou de synchroniser les changements avant de modifier le routage. La procédure dépend de la technologie et des exigences de continuité : testez-la, définissez une stratégie de retour arrière et communiquez l’impact attendu. Ne partez pas du principe qu’il est toujours plus simple de déplacer une base dédiée ; le volume, les dépendances et la cohérence déterminent la difficulté.
Avant de prendre une décision définitive, répondez par écrit aux questions suivantes :
- Quelle unité représente un tenant et d’où vient son contexte ?
- Quelles exigences sont obligatoires et lesquelles sont des préférences négociables ?
- Quels contrôles détectent et bloquent les accès entre clients ?
- Qui gère les sauvegardes, les restaurations, les déploiements et les exceptions ?
- Quels indicateurs justifieraient un changement de modèle et comment la migration serait-elle menée ?
Choisissez le modèle qui satisfait les exigences tout en restant exploitable par l’équipe. Réexaminez cette décision lorsque les clients, les risques ou les capacités de la plateforme évoluent. Une isolation adaptée n’est pas la plus complexe : c’est celle qui repose sur des contrôles vérifiables et peut être exploitée de manière cohérente.