Pourquoi vos données workplace méritent une base isolée

Quand une équipe IT ou sécurité évalue un outil de réservation d'espaces de travail, le questionnaire porte généralement sur le chiffrement, l'authentification unique et l'emplacement des serveurs. Il pose rarement la question qui compte le plus pour cette catégorie de données : les données de notre organisation sont-elles physiquement séparées de celles de tous les autres clients, ou sont-elles une colonne dans une table partagée ?

La réservation de bureaux ressemble à des données à faible risque jusqu'à ce qu'on liste ce qu'elle contient : qui était dans quel bâtiment quel jour, à quel bureau, à côté de qui, avec quels visiteurs, et où sa voiture était garée. C'est un journal des déplacements de vos effectifs. Il mérite la même isolation que celle que vous exigeriez pour des données RH ou de paie.

Cet article explique les deux manières dont les éditeurs SaaS stockent des données multi-locataires, pourquoi Desk & Park donne à chaque organisation sa propre base de données isolée, et ce que cette décision signifie pour les personnes qui valident la sécurité, la confidentialité et la conformité.

Deux architectures, un compromis

Presque tous les produits SaaS sont multi-locataires : une application sert de nombreux clients. La question est de savoir où se situe la frontière entre les clients.

Base partagée, colonne de locataire

L'approche courante. Les lignes de chaque client se trouvent dans les mêmes tables, et chaque ligne porte un tenant_id. Chaque requête doit filtrer dessus. C'est l'application, et non la base de données, qui est responsable de séparer les clients.

Elle est populaire parce qu'elle est peu coûteuse à exploiter : une base, un schéma, une migration. C'est aussi de là que vient toute une classe d'incidents de sécurité. Un seul WHERE tenant_id = ? manquant dans l'une des milliers de requêtes, un rapport qui joint des tables sans le filtre, un bug de cache, et le client A voit les données du client B. Ces bugs ne sont pas hypothétiques ; ils constituent une catégorie récurrente de fuites SaaS divulguées, et ils sont difficiles à trouver parce que chaque requête, prise individuellement, semble correcte.

Base de données isolée par organisation

Chaque client dispose de sa propre base de données, avec ses propres tables, ses propres identifiants et ses propres sauvegardes. L'application se connecte à la bonne base pour l'organisation qui fait la requête. Il n'y a pas de filtre tenant_id à oublier, parce qu'il n'y a pas d'autre locataire dans la base d'où fuir.

Cela coûte à l'éditeur davantage de discipline opérationnelle : provisionner, migrer et surveiller des centaines ou des milliers de bases au lieu d'une seule. Ce coût est précisément le but. Il est payé par l'éditeur, une fois, en ingénierie, plutôt que par le client, plus tard, lors d'un incident.

Comment Desk & Park est construit

Desk & Park repose sur une architecture une base de données par organisation. Concrètement :

Un plan de contrôle ne contient que ce qui est nécessaire au routage et à la facturation : noms des organisations, offre souscrite, correspondance entre une organisation et sa base, et la piste d'audit de la plateforme elle-même. Il ne contient ni réservations, ni plans d'étage, ni annuaire des collaborateurs.
Une base PostgreSQL par organisation contient tout ce qui concerne cette organisation : utilisateurs, rôles, sites, plans, bureaux, places de parking, salles, réservations, enregistrements, visiteurs, notifications et le journal d'audit de l'organisation.
Des identifiants par organisation. L'application ouvre une connexion à la base d'une organisation avec des identifiants limités à cette base. Une requête de l'organisation A ne peut pas être exécutée sur la base de l'organisation B, même par erreur, parce qu'elle n'en détient jamais de connexion.
Sauvegardes, restauration et effacement par organisation. Les sauvegardes sont réalisées par base. Restaurer une organisation à son état de la veille ne touche personne d'autre. Supprimer une organisation à la fin d'un contrat revient à supprimer sa base, ce qui est un effacement complet et vérifiable, plutôt qu'un DELETE WHERE tenant_id qui espère avoir trouvé chaque ligne.

Le code de l'application est partagé ; les données ne le sont pas. C'est la frontière qu'un auditeur peut désigner.

Ce que l'isolation apporte à ceux qui valident

Pour le RSSI : un rayon d'impact réduit

Une vulnérabilité dans une couche de requêtes multi-locataire expose tous les clients à la fois. Avec des bases isolées, la même classe de bug ne peut pas franchir la frontière d'une organisation, parce que cette frontière est imposée par le moteur de base de données et les identifiants de connexion, pas par la logique applicative. L'isolation ne rend pas une application immunisée contre les bugs ; elle fait d'un bug à un endroit un problème pour un seul client au lieu d'un problème à l'échelle de la plateforme.

Pour le DPO : des réponses nettes aux questions RGPD

Les revues de protection des données posent des questions prévisibles, et la base par organisation leur apporte des réponses courtes.

Question	Réponse avec une base isolée
Où sont nos données ?	Dans votre base, dans la région UE de la plateforme, séparées de tous les autres clients.
Qui peut y accéder ?	L'application, avec des identifiants limités à votre base, et le personnel d'astreinte de l'opérateur selon la procédure d'accès documentée.
Pouvez-vous prouver la suppression ?	Oui : votre base est supprimée et la suppression est consignée dans la piste d'audit de la plateforme.
Pouvez-vous restaurer uniquement nos données ?	Oui : les sauvegardes sont par organisation.
Pouvez-vous tout exporter ?	Oui : un export est le dump d'une base, pas un extrait filtré.

Le droit à l'effacement et l'obligation de limitation du traitement deviennent des opérations de base de données au périmètre clair, plutôt que des fonctionnalités applicatives dont il faut tester l'exhaustivité.

Pour le responsable conformité : un contrôle défendable

Des référentiels comme ISO 27001 et SOC 2 demandent à un éditeur de démontrer une séparation logique entre clients. « Chaque requête filtre sur le locataire » est un contrôle qui doit être revérifié pour chaque nouvelle requête. « Chaque client a sa propre base et ses propres identifiants » est un contrôle vérifié une fois, structurellement, et qui tient à mesure que le produit grandit. Le second est bien plus facile à documenter, pour l'éditeur comme pour l'audit propre du client.

Pour le DSI : des performances et un cycle de vie prévisibles

Le rapport lourd d'une organisation ne ralentit pas la vague d'enregistrements matinale d'une autre, parce qu'elles ne partagent ni tables ni index. Les migrations se déploient base par base, de sorte qu'un problème peut être détecté sur une organisation avant d'atteindre la suivante. La sortie d'un client est une suppression, pas un projet de nettoyage.

Le reste de l'histoire sécurité

L'isolation est la fondation, pas tout l'édifice. Les contrôles que les équipes IT attendent viennent par-dessus, et ils méritent d'être listés parce qu'une bonne architecture avec une authentification faible reste faible :

Authentification unique via OpenID Connect avec votre fournisseur d'identité, et provisionnement SCIM pour que les arrivées et les départs soient créés et désactivés depuis votre annuaire, pas à la main.
Authentification à deux facteurs (TOTP) et passkeys (WebAuthn), avec une politique au niveau de l'organisation pour imposer la MFA.
Des politiques de sécurité par organisation : expiration de session, règles de mot de passe, listes d'adresses IP autorisées.
Gestion des sessions actives pour qu'un administrateur puisse voir et révoquer des sessions.
Un journal d'audit par organisation consignant qui a modifié quoi, dans la base propre de l'organisation.
Paiements via Stripe, pour que les données de carte n'atteignent jamais la plateforme.
Accès par rôles : les collaborateurs consultent et réservent ; les administrateurs configurent ; les membres du conseil et les managers obtiennent des rapports limités à leurs équipes.

Rien de tout cela n'est inhabituel dans un SaaS d'entreprise. Ce qui est inhabituel, c'est de les combiner avec une couche de données où la frontière entre clients est physique.

Les questions à poser à tout éditeur workplace

Si vous comparez des outils, ces cinq questions séparent le marketing de l'architecture :

Nos données sont-elles dans une base dédiée, ou dans des tables partagées avec une colonne de locataire ?
Les sauvegardes, restaurations et suppressions sont-elles effectuées par client ?
Quels identifiants l'application utilise-t-elle pour accéder à nos données, et sont-ils limités à notre périmètre ?
Comment prouvez-vous la séparation des clients à vos auditeurs ?
Un bug dans un rapport ou un export peut-il un jour renvoyer les lignes d'un autre client ?

Un éditeur avec une base isolée répond aux cinq en une phrase chacune. Un éditeur avec une base partagée doit décrire un processus de test.

L'isolation devrait être la norme

Les données workplace sont des données personnelles sur la présence physique de vos collaborateurs. L'architecture la moins coûteuse pour l'éditeur place ces données à côté de celles de tous les autres clients et fait confiance à l'application pour les séparer. Desk & Park a choisi la plus coûteuse, pour que la frontière entre organisations soit une base de données, pas un filtre.

Vous pouvez lire le détail technique dans le résumé d'architecture de la page « comment ça marche » et dans la politique de confidentialité de la plateforme. Pour un déploiement entreprise avec authentification unique, SCIM et revue de sécurité, la page des tarifs indique le contact Enterprise.