Isolation des données multi-locataires : pourquoi « nous filtrons par compte » ne suffit pas
Si vous gérez des biens pour plus d'un propriétaire, ou pour plusieurs entités juridiques, il y a une question qui vaut la peine d'être posée pour tout logiciel dans lequel vous entrez ces données : qu'est-ce qui empêche réellement les finances du Propriétaire A d'apparaître quelque part visible par l'équipe du Propriétaire B ? « Nous filtrons par compte dans l'interface » et « il n'est pas possible d'interroger plusieurs comptes à la fois » sont des réponses très différentes — et la différence compte le plus précisément quand quelque chose se passe mal, pas quand tout fonctionne comme prévu.
Le filtrage au niveau applicatif est une convention, pas une garantie
La plupart des logiciels isolent les données des locataires en ajoutant un filtre à chaque requête — « uniquement les lignes où company_id correspond ». Cela fonctionne, jusqu'au jour où une requête quelque part dans le code oublie ce filtre : un nouveau point d'accès, une requête de reporting écrite à la hâte, une tâche de fond qui parcourt « toutes » les données au lieu de celles d'une seule entreprise. Rien n'impose cette règle, sinon que chaque développeur s'en souvienne, chaque fois, pour toujours. Pour une application à un seul client, c'est un risque mineur. Pour un logiciel qui détient les données financières et locatives de plusieurs propriétaires, c'est une catégorie de problème différente.
Ce que signifie réellement l'isolation au niveau de la base de données
L'alternative consiste à faire respecter cette limite directement dans la base de données — la sécurité au niveau des lignes (row-level security) de Postgres, dans le cas de Casement — de sorte que même une requête qui oublie de filtrer par entreprise ne puisse tout simplement pas voir les lignes d'une autre entreprise. Ce n'est pas une couche de restriction d'interface ajoutée par-dessus une vue partagée des données ; la base de données elle-même refuse de les renvoyer. C'est une garantie nettement plus solide que « l'application est censée filtrer cela », car elle ne dépend pas du fait que chaque ligne de code applicatif soit correcte.
Pourquoi cela compte spécifiquement pour les gestionnaires immobiliers
- Vous n'êtes pas le seul propriétaire des données. Contrairement à un utilisateur SaaS classique d'une seule entreprise, un gestionnaire immobilier agissant pour plusieurs propriétaires manipule couramment les informations financières et locatives d'autres personnes — l'enjeu d'une fuite concerne quelqu'un d'autre, pas seulement vous.
- Les propriétaires posent la question. Un client propriétaire qui évalue s'il doit confier à un gestionnaire les données de son portefeuille est en droit de demander comment elles sont isolées de celles de tous les autres — « imposé au niveau de la base de données » est une réponse concrète ; « nous faisons attention » ne l'est pas.
Comment Casement gère cela
Chaque table de données locataire dans Casement porte un identifiant d'entreprise imposé par la sécurité au niveau des lignes de Postgres, pas seulement par un filtrage applicatif — et la couche applicative continue de filtrer explicitement en plus de cela, comme une seconde vérification plutôt que la seule. Ce n'est pas la fonctionnalité la plus visible dans une démo produit, mais c'est celle sur laquelle toutes les autres reposent.
Casement intègre actuellement un petit nombre d'entreprises de gestion immobilière pilotes. Si vous gérez pour plus d'un propriétaire, cela vaut la peine de le demander directement lors d'une démo en direct.