Achats · deux clients
Deux clients, un seul hub.
Les mêmes fichiers, la même table.
Leurs commandes portent les mêmes numéros.
Clients fictifs · données synthétiques
Le problème
Une table partagée peut fuir.
- Un filtre oublié montre les lignes de l'autre.
- Un SQL généré par un modèle ne connaît pas le client.
- Un identifiant deviné ouvre une lecture.
Rien n'est dupliqué
Un hub, une table, deux clients.
- Le client vient du jeton Keycloak.
- Chaque ligne porte son tenant_id.
- La base filtre à chaque lecture.
Le scénario complet tient en 2 fichiers de déclaration, 56 lignes.
La même question
SELECT COUNT(*) FROM "connector"."v_tenants_order_b"
WHERE "status" = 'cancelled'Le même SQL, deux réponses: 26 et 5.
Le SQL du modèle s'exécute sous le client du jeton.
Chacun ses lignes
PO-2025-0001 existe deux fois.
- Client A: 240 commandes, SUP-006.
- Client B: 60 commandes, SUP-104.
- Aucun ne voit l'autre.
Rejeu du 3 novembre 2026, OIDC Keycloak.
La porte fermée
Le client B demande la lecture du client A.
API error 404: run … not found
Comme un identifiant qui n'existe pas.
La limite
Le client est un attribut Keycloak.
- Le créer reste un geste d'administration.
- Le client A administre aussi son tenant.
- La réponse du modèle peut varier, le filtrage non.
Essayer
Le scénario se rejoue de bout en bout.
Deux jetons, une table, une question: chaque étape est publiée avec sa sortie.