Lorsque plusieurs clients utilisent la même instance logicielle, un fournisseur SaaS doit répondre à une question fondamentale : comment les données de chaque client (tenant) sont-elles séparées ? La réponse la plus répandue dans le secteur est une base de données commune dans laquelle chaque table comporte une colonne supplémentaire comme « tenant_id », utilisée pour filtrer chaque requête. Cela fonctionne, mais dépend entièrement de la bonne implémentation de ce filtre à chaque endroit du code. 1Tool emprunte une voie structurellement différente.
Une base de données dédiée par client plutôt qu'une table commune
Chez 1Tool, chaque client dispose de sa propre base de données, physiquement séparée. Celle-ci est connectée dynamiquement à l'exécution : lorsqu'un utilisateur se connecte, le système sait avec quelle base de données client il doit communiquer et établit la connexion en conséquence. La séparation ne se fait donc pas au niveau applicatif via une condition de filtre, mais dès le niveau de l'infrastructure. Une erreur de programmation qui, avec une base commune, pourrait en théorie faire oublier la condition de filtre et rendre visibles les données d'un autre client est exclue d'emblée avec une architecture stricte « une base par client » : il n'existe tout simplement aucune table commune dans laquelle on pourrait lire trop de données par erreur.
Des serveurs dédiés pour les grands clients, un cache séparé pour tous
Cette séparation peut être poussée encore plus loin si nécessaire. Pour les clients particulièrement importants, 1Tool peut même attribuer un serveur de base de données entièrement dédié – avec son propre hôte et ses propres identifiants – au lieu de faire tourner la base sur la même infrastructure de serveurs partagée que les autres clients. L'isolation passe ainsi du niveau logique au niveau physique de l'infrastructure, lorsque cela se justifie pour un client pour des raisons de sécurité ou de performance. En complément, 1Tool gère aussi le cache par client : les données mises en cache sont elles aussi conservées séparément pour chaque client, si bien qu'aucun mélange entre clients n'est possible à ce niveau non plus.
Des droits d'accès fins au sein du client
La séparation entre clients n'est qu'un des niveaux du contrôle d'accès. Au sein d'un même client, un système de droits comptant des dizaines de règles de filtrage spécialisées – appelées scopes – détermine en plus quels enregistrements un utilisateur donné a le droit de voir. On peut ainsi faire en sorte, par exemple, qu'un commercial ne voie que ses propres contacts, tandis qu'un responsable dispose d'une vue d'ensemble complète – le tout au sein de la même base de données, déjà isolée par client. Pour les entreprises ayant des exigences élevées en matière de protection et de sécurité des données, cette combinaison est un argument de poids dans le choix d'un fournisseur. Une base commune avec des colonnes tenant_id est moins coûteuse à faire évoluer en exploitation, mais exige que chaque requête de tout le système soit correctement filtrée – pendant des années et à travers de nombreuses générations de développeurs. Une véritable architecture « une base par client » transfère cette garantie de la logique applicative à l'infrastructure elle-même.
Questions fréquentes
Une base de données par client signifie-t-elle que les données sont stockées physiquement séparément ?
Oui, chaque client dispose de sa propre base de données séparée, au lieu de tables partagées avec un identifiant client comme colonne de filtre.
Certains clients peuvent-ils être hébergés sur un serveur entièrement dédié ?
Pour les clients particulièrement importants, c'est possible – avec leur propre hôte et leurs propres identifiants, séparés de l'infrastructure de serveurs partagée.
Comment détermine-t-on, au sein d'un client, qui voit quels enregistrements ?
Un système de droits doté de nombreuses règles de filtrage spécialisées s'en charge ; il s'ajoute à la séparation des bases de données et restreint l'accès aux enregistrements individuels pour chaque utilisateur.
Quelle importance une véritable isolation des bases de données a-t-elle pour les exigences de protection des données de votre entreprise ?
À lire aussi
- Notifier d'autres systèmes : des requêtes HTTP directement depuis le workflow d'automatisation
- Webhooks entrants : intégrer des données externes dans le CRM de manière structurée
Réserver une démo