RAG multi-tenant : isoler les données de chaque client

En bref

• Dès qu'un assistant sert plusieurs clients, aucun ne doit voir les données d'un autre, ni via la recherche, ni via l'IA.
• La bonne approche : pousser l'isolation dans la base (Row Level Security PostgreSQL/Supabase), pas seulement dans le code applicatif.
• Côté RAG : filtrer la recherche vectorielle par tenant (métadonnées) et répliquer les droits d'accès du SI source.
• Les pièges qui causent les fuites : la clé service_role qui ignore tout, les jointures vers une table non protégée, et les claims modifiables par l'utilisateur.

Le problème, concrètement

BeForBuild.com est multi-tenant : chaque client a ses dossiers, ses contrats, ses documents. Le cauchemar absolu serait qu'une requête (ou une réponse d'agent IA) laisse fuiter les données d'un client vers un autre. En B2B, c'est la faute qui tue la confiance, et le contrat.

Pourquoi le faire dans le code ne suffit pas

Filtrer « WHERE tenant_id = ? » dans chaque requête applicative marche… jusqu'à l'oubli d'un développeur, un nouvel endpoint, une jointure mal pensée. L'isolation doit être garantie au niveau de la base, là où aucune requête ne peut y échapper.

Comment on isole, pour de vrai

1. Row Level Security (RLS) dans PostgreSQL

Avec Supabase/PostgreSQL, on définit des policies SQL que la base évalue à chaque requête : USING pour les lectures, WITH CHECK pour les écritures. Chaque ligne est rattachée à un tenant ; impossible d'en sortir, même par erreur applicative. Bonne pratique : traiter ces policies comme du code (versionnées, testées, relues).

2. Filtrage de la recherche vectorielle

La recherche RAG est bornée au tenant via les métadonnées (chaque vecteur porte son tenant_id). Avec pgvector, l'avantage est net : la RLS s'applique aussi à la table des vecteurs, données et embeddings au même endroit, mêmes règles.

3. Réplication des droits du SI

Si un document est restreint à certains utilisateurs dans votre gestion documentaire, l'assistant doit respecter la même restriction. Le RAG ne doit jamais devenir un moyen de contourner les permissions existantes.

Les pièges qui font fuiter (la nuance d'expert)

• La clé service_role de Supabase bypass la RLS : à n'utiliser que côté serveur pour des jobs admin, jamais avec une requête utilisateur.
• Jointures : une policy sur la table A ne protège pas la table B jointe ; il faut une RLS sur chaque table touchée.
• Activer la RLS sans policy verrouille tout le monde dehors : on crée les policies immédiatement.
• Baser une policy sur user_metadata (modifiable par l'utilisateur) est une faille : on s'appuie sur des claims fiables (app_metadata, table de rattachement).
• Indexer les colonnes utilisées dans les policies, sinon les performances s'effondrent à l'échelle.

En pratique

C'est structurel sur BeForBuild.com : plusieurs agents IA tournent sur une base multi-tenant sécurisée par RLS, chaque client parfaitement isolé, recherche vectorielle filtrée par tenant. C'est cette base éprouvée que j'adapte à votre contexte, avec les policies versionnées et testées.

Sources

• Supabase · Row Level Security (documentation)
• Bonnes pratiques RLS multi-tenant en production