Multi-tenant

Un logiciel multi-tenant sert plusieurs clients (les « tenants ») avec une seule installation et une seule base de code, tout en cloisonnant strictement leurs données. C’est l’architecture typique d’un SaaS : une mise à jour profite à tous, les coûts d’exploitation sont mutualisés.

Le cloisonnement des données est le point critique : il se conçoit dès le départ, il ne se rajoute pas.

Pas seulement pour un éditeur de SaaS

Une application multi-tenant sur mesure sert plusieurs organisations aux données séparées : les clients d’un éditeur, ou plusieurs sociétés servies par le même outil, comme notre outil de gestion interne. Au 2 octobre 2026, la règle d’accès y est écrite dans la base de données elle-même pour 76 tables : une ligne n’est lue que par les comptes qui ont accès à sa société. Les 15 tables communes, comme les comptes et les droits, ont ensuite reçu leurs propres règles. Le contrôle coûte 2,8 ms sur la plus grosse table (35 295 lignes), et chaque changement de règle est d’abord simulé compte par compte.

Cloisonnement multi-tenant d’une IA

Un assistant d’IA doit respecter le même cloisonnement, or une règle écrite dans la base ne s’applique qu’aux comptes qui y sont soumis : dans PostgreSQL, les super-utilisateurs, les rôles autorisés à la contourner et, sauf réglage contraire, le propriétaire de la table y échappent. Branché avec un tel accès, un assistant peut lire, puis répéter, les données de tous les clients.

Ce qu’il faut exiger d’un assistant d’IA

L’assistant agit avec les droits de l’utilisateur qui l’interroge, et les documents où il cherche ses réponses (RAG) sont séparés par client. L’OWASP classe la fuite entre clients qui partagent une même base vectorielle parmi les risques propres aux applications d’IA.