Pourquoi une instance séparée par boutique
La confidentialité entre confrères ne devrait pas reposer sur un identifiant de tenant partagé. Voici pourquoi Rempart donne à chaque boutique M&A sa propre instance.
La plupart des outils en marque blanche font cohabiter tous leurs clients dans une seule base de données. Chaque client est isolé par un identifiant, le « tenant », vérifié à chaque requête. Sur le papier, c'est suffisant. Dans un métier où deux boutiques concurrentes peuvent conseiller les deux côtés d'une même table, ça ne l'est pas.
Le risque d'un identifiant partagé
Quand tout le monde partage la même base, une seule erreur de filtrage, une seule requête mal cloisonnée, et les documents d'une boutique deviennent lisibles par une autre. Le contrôle repose entièrement sur du code applicatif, exécuté correctement à chaque fois, sans exception. Ce n'est pas un pari acceptable pour un dossier de cession.
Ce que fait Rempart
Chaque boutique dispose d'une instance séparée : sa propre base, son propre stockage, son propre domaine et ses propres emails. Les documents de deux boutiques ne cohabitent jamais dans la même base. La séparation n'est pas une colonne dans une table commune, c'est une frontière réelle.
À l'intérieur d'une instance, les droits critiques sont appliqués par la base de données elle-même, via le mécanisme RLS de PostgreSQL, et pas seulement dans l'interface. Un membre ne lit que les dossiers et les pièces autorisés pour son rôle et son groupe.
Le coût, et pourquoi il en vaut la peine
Une instance par boutique est plus lourde à exploiter qu'une base unique. C'est un choix assumé : la confidentialité entre confrères est la promesse centrale du produit, et elle ne doit pas dépendre de la discipline d'un filtre applicatif. La marque blanche de Rempart n'est donc pas qu'un habillage : c'est une séparation de bout en bout.