Multi-location & octrois
Comment PIE isole les organisations au niveau de la base de données et comment les producteurs partagent des produits précis avec des acheteurs précis.
La multi-location est la propriété la plus importante de PIE : les données de chaque organisation sont isolées de celles de toutes les autres, et cette isolation est appliquée dans la base de données — non dans un code applicatif contournable.
Délimitation par organisation
Chaque requête est authentifiée sur un principal portant un identifiant d'organisation, tiré uniquement de l'identifiant validé (JWT ou clé d'API) — jamais du corps de la requête ni des paramètres de requête. L'API ouvre une connexion à la base de données restreinte au locataire pour cette organisation, ce qui définit une variable de session que lisent les politiques de sécurité au niveau des lignes (RLS) de la base. Chaque table contenant des données client possède un org_id et une politique RLS qui filtre sur l'organisation courante, de sorte qu'une requête ne peut jamais voir que les lignes de son propre locataire.
C'est pourquoi un acheteur ne peut pas atteindre les données d'un autre acheteur, et pourquoi les produits en brouillon d'un producteur sont invisibles pour tous les autres — la frontière est structurelle.
Octrois : partage contrôlé
Les producteurs doivent partager des produits précis avec des acheteurs précis. C'est ce qu'est un octroi : un producteur expose un ensemble de produits à une organisation acheteuse. Les octrois sont lus via une RLS tenant compte des octrois — la connexion restreinte au locataire de l'acheteur ne peut voir la ligne produit d'un producteur que lorsqu'un octroi relie les deux organisations. Le « catalogue accordé » d'un acheteur n'est donc pas un filtre applicatif susceptible de fuir ; c'est la seule chose que la base de données renverra.
Quelques ressources ne sont délibérément pas restreintes par octroi — par exemple les propres profils de qualité d'un acheteur — de sorte que les propres écritures d'un acheteur ne se résolvent jamais entre organisations.
Surfaces publiques
Certaines données sont destinées à être publiques — passeports numériques de produit, portails de marque et catalogues imprimés. Elles sont servies via un rôle de base de données public séparé et en lecture seule qui ne peut voir que les données publiées et en liste d'autorisation, figées par instantané au moment de la publication. Rien de privé ne peut atteindre une surface publique.
Cycle de vie & gouvernance
Une organisation peut être suspendue (écritures gelées, lectures et exports en libre-service pour les personnes concernées toujours accessibles) et désengagée (un flux prévisualisé et protégé par confirmation d'export-puis-mise-en-sommeil). Les données personnelles à travers chaque table sont classifiées dans un registre que la CI maintient complet, de sorte que l'accès et l'effacement des personnes concernées ne peuvent jamais manquer silencieusement une table.