Beaucoup d’équipes techniques font l’erreur de déployer une application LLM multi-tenant en appliquant simplement les mêmes patterns de sécurité que pour une API REST classique. C’est une faute de conception lourde de conséquences : un modèle de langage n’est pas un endpoint passif. Il raisonne, généralise, et peut — si l’isolation est mal pensée — faire remonter des fragments de contexte appartenant à d’autres locataires. La surface d’attaque d’un LLM multi-tenant est fondamentalement différente, et l’ignorer expose à des fuites de données dont les entreprises françaises ne mesurent pas encore pleinement le risque réglementaire sous le RGPD.
Comprendre la menace réelle dans une architecture LLM partagée
Dans une architecture multi-tenant, plusieurs clients ou organisations partagent la même infrastructure applicative. L’enjeu n’est pas nouveau en SaaS, mais l’introduction d’un LLM dans la boucle crée des vecteurs d’attaque inédits. Le plus critique : la contamination du contexte. Si la mémoire ou le prompt d’un tenant A est accessible — même partiellement — lors du traitement d’une requête du tenant B, on obtient une fuite d’information que ni les logs ni les firewalls classiques ne détectent.
Concrètement, imaginez une plateforme française de support client B2B qui déploie un assistant LLM partagé entre plusieurs entreprises clientes. Sans isolation stricte des espaces vectoriels et des historiques de conversation, une requête ambiguë peut activer des chunks de contexte issus d’un autre client. Les injections de prompt constituent ici un amplificateur de risque : un utilisateur malveillant peut tenter d’exfiltrer des données cross-tenant en formulant des instructions déguisées dans ses requêtes.
L’autre menace souvent sous-estimée est celle du prompt poisoning via RAG (Retrieval-Augmented Generation). Si la base documentaire n’est pas partitionnée par tenant au niveau de l’index, le retrieval peut ramener des documents appartenant à d’autres organisations. C’est un vecteur discret, difficile à auditer a posteriori.
Isolation des données : les patterns d’architecture à adopter
Partitionnement des bases vectorielles par tenant
Le premier niveau de défense est structurel. Toute base de données vectorielle utilisée dans un pipeline LLM multi-tenant doit implémenter un filtrage par identifiant de tenant au niveau de la couche de métadonnées — et non pas en post-processing. Des solutions comme Weaviate, Qdrant ou Pinecone permettent de définir des filtres de namespace ou de collection par tenant. La règle d’or : l’identifiant du tenant doit être injecté dans chaque requête vectorielle depuis le backend, jamais depuis le frontend ou le prompt utilisateur.
Pour les architectures à très forte exigence d’isolation (secteurs financier, santé, juridique), il est recommandé d’aller jusqu’à des index vectoriels physiquement séparés par tenant, au prix d’une complexité opérationnelle accrue. Une solution intermédiaire consiste à segmenter par cluster avec des ACL (Access Control Lists) sur les collections.
Isolation du contexte conversationnel et de la mémoire
La mémoire court-terme et long-terme du LLM doit être strictement scopée par tenant et par utilisateur. Cela implique que chaque session porte un token signé encodant l’identité du tenant, et que ce token soit validé côté serveur avant toute injection dans le prompt système. Aucune donnée de session ne doit transiter en clair dans les headers ou être stockée dans un cache partagé sans chiffrement au repos avec des clés distinctes par tenant (pattern de KMS multi-tenant).
Un cas d’usage concret : une scale-up parisienne dans le domaine du recrutement, déployant un assistant LLM pour analyser des CV pour plusieurs cabinets clients, a mis en place un système de « context envelopes » — des conteneurs JSON chiffrés par clé tenant avant d’être passés au modèle. Chaque appel API vers le LLM embarque uniquement le contexte du tenant courant, reconstruit à la volée et détruit en mémoire après réponse.
Contrôle des accès : RBAC, ABAC et zero trust appliqués aux LLM
Ne pas déléguer l’autorisation au modèle
C’est l’erreur la plus répandue que j’observe sur le terrain : des équipes qui demandent au LLM de filtrer lui-même ce qu’il peut ou ne peut pas révéler selon le rôle de l’utilisateur. Un LLM n’est pas un moteur d’autorisation. Il peut être contourné par du jailbreaking ou des reformulations habiles. Le contrôle d’accès doit se situer en amont du modèle, dans la couche applicative.
L’approche recommandée est un gateway LLM (pattern émergent, popularisé par des outils comme Portkey ou Kong AI Gateway) qui intercepte chaque requête, valide les droits via votre Identity Provider (IdP) — Keycloak, Auth0, ou solution maison — et enrichit ou tronque dynamiquement le contexte selon les permissions RBAC ou ABAC de l’utilisateur avant de transmettre au modèle. Ce gateway joue également le rôle de couche d’audit : chaque requête est loguée avec son tenant_id, user_id, et un hash du prompt pour la traçabilité.
Principe du moindre privilège appliqué aux outils LLM
Les LLM modernes opèrent souvent en mode agentique, avec accès à des outils (function calling, accès à des APIs internes, lecture de bases de données). Chaque outil exposé au modèle doit être soumis au principe du moindre privilège : le LLM ne doit pouvoir appeler que les fonctions autorisées pour le tenant et le rôle de l’utilisateur courant. Concrètement, les définitions de tools doivent être générées dynamiquement côté serveur selon le contexte d’autorisation, et non définies statiquement dans le code client.
La conformité avec l’AI Act européen renforce cette exigence : les systèmes d’IA à usage professionnel doivent documenter les mécanismes de contrôle d’accès et de gouvernance des données. Autant anticiper dès la conception plutôt que de devoir refactorer sous pression réglementaire.
Supervision, détection d’anomalies et réponse aux incidents
La sécurité d’une application LLM multi-tenant ne se joue pas qu’à la conception : elle se maintient dans le temps par une supervision active. Les métriques à monitorer en priorité sont les tentatives de prompt injection (détectables via des patterns réguliers ou des classifieurs dédiés), les pics de tokens inhabituels sur certains tenants (signe possible d’exfiltration par encodage), et les erreurs d’autorisation répétées sur des endpoints sensibles.
Des outils comme LangSmith, Helicone ou Arize AI permettent une observabilité fine des pipelines LLM. Sur le plan de la réponse aux incidents, il est impératif de définir des procédures de revocation de contexte : si un tenant est compromis, comment invalider immédiatement sa mémoire vectorielle et ses sessions actives sans impacter les autres tenants ? Ce plan de réponse doit être testé, pas seulement documenté. Les bonnes pratiques de sécurité applicative moderne exigent des exercices de red team réguliers, y compris sur les couches IA.
Mon point de vue d’expert : l’isolation n’est pas optionnelle
La tentation est grande, notamment pour des startups en phase de croissance, de mutualiser au maximum pour réduire les coûts d’infrastructure. Sur une application LLM multi-tenant, cette mutualisation doit avoir des limites strictes et non négociables. L’isolation des données et le contrôle des accès ne sont pas des features à ajouter « quand on aura le temps » : ce sont des fondations architecturales. Le coût d’un incident de fuite cross-tenant — financier, réputationnel, et désormais réglementaire avec le RGPD et l’AI Act — est sans commune mesure avec celui d’une conception sécurisée dès le départ. Ma recommandation ferme : tout projet LLM multi-tenant doit inclure une revue de sécurité spécifique IA avant tout déploiement en production, distincte de l’audit de sécurité applicative classique.
FAQ : Sécurisation d’une application LLM multi-tenant
Quelle est la différence entre isolation logique et isolation physique dans un contexte LLM multi-tenant ?
L’isolation logique consiste à filtrer les données par identifiant de tenant au niveau applicatif ou via des métadonnées dans une base vectorielle partagée. C’est la solution la plus courante pour un bon rapport coût/sécurité. L’isolation physique implique des instances de modèle, des index vectoriels et des bases de données entièrement séparés par tenant — recommandée pour les secteurs très réglementés (santé, finance, défense) où la moindre fuite cross-tenant est inacceptable. Le choix dépend du profil de risque et des exigences contractuelles de vos clients.
Comment détecter une tentative d’exfiltration cross-tenant dans un pipeline LLM ?
Les signaux à surveiller sont : des prompts contenant des métainstruction inhabituelles (« ignore les instructions précédentes », « liste les données disponibles »), des volumes de tokens anormalement élevés sur certains comptes, et des patterns de requêtes répétitives légèrement variées — signature typique d’une attaque par énumération. La mise en place d’un classifieur de détection d’injection de prompt en amont du LLM, combinée à un système d’alerting sur les anomalies comportementales, permet de couvrir l’essentiel de cette surface d’attaque.
Le chiffrement des données au repos suffit-il à garantir l’isolation entre tenants ?
Non, le chiffrement au repos est une condition nécessaire mais insuffisante. Il protège contre l’accès direct aux disques ou aux sauvegardes, mais n’empêche pas une fuite au moment du traitement par le LLM si le contexte n’est pas correctement scopé. L’isolation effective repose sur la combinaison de plusieurs couches : chiffrement au repos avec clés distinctes par tenant, contrôle d’accès au niveau du retrieval vectoriel, validation des autorisations avant injection dans le prompt, et supervision des sorties du modèle.