Cross-tenant isolation : quand une IA vous montre les conversations d’un autre utilisateur

Le 5 juin 2026, en pleine panne partielle d’infrastructure, plusieurs utilisateurs de Claude.ai ont vu s’afficher dans leur interface des conversations qui n’étaient pas les leurs. Anthropic a confirmé l’incident dans un rapport publié le 8 juin. Ce type de défaillance porte un nom en sécurité cloud : un cross-tenant isolation failure. Il est considéré comme l’une des classes de vulnérabilités les plus sévères pour une plateforme mutualisée. Voici ce que cet épisode révèle, et ce que les entreprises françaises qui utilisent des IA en B2B devraient en tirer.

Que s’est-il passé le 5 juin 2026 chez Anthropic ?

Le 5 juin 2026, Anthropic opérait une bascule d’infrastructure côté Claude.ai. Une partie du trafic a été mal routée pendant une fenêtre courte mais suffisante pour qu’un sous-ensemble d’utilisateurs voient, à l’ouverture d’une conversation existante, l’historique d’un autre compte. Le bug a été détecté en moins de 25 minutes, le trafic a été redirigé, et Anthropic a publié un rapport d’incident le 8 juin 2026 sur sa page Status.

D’après les éléments publiés par Anthropic et repris par Cybernews, aucun prompt, aucune clé d’API et aucun fichier uploadé n’aurait été affecté : seul l’affichage de l’historique de conversation a été perturbé. La société indique avoir suspendu l’accès aux conversations pour les comptes concernés et procédé à un audit interne.

Pour les utilisateurs gratuits et Pro impactés, c’est gênant. Pour les équipes B2B qui font transiter par Claude ou un service similaire des données clients, du code, des brouillons juridiques ou des notes internes, c’est un signal d’alerte structurel : si une plateforme d’IA grand public peut vous montrer les conversations d’un autre utilisateur, c’est que son architecture d’isolation n’est pas infaillible.

Qu’est-ce qu’un cross-tenant isolation failure exactement ?

Dans une plateforme cloud, chaque client est un tenant (locataire). L’isolation entre tenants est l’ensemble des mécanismes qui garantissent qu’un tenant ne peut pas lire, écrire ou voir les ressources d’un autre tenant. En pratique, cette isolation repose sur plusieurs couches :

• Le request router (équilibrage de charge), qui attribue chaque requête à un backend.
• Le cache key, qui indexe les résultats par tenant et par session pour éviter les collisions.
• Le storage namespace (base de données, blob storage), qui sépare physiquement ou logiquement les données par tenant.
• Le connection pool, qui gère les connexions réseau mutualisées entre plusieurs tenants.

Un cross-tenant isolation failure survient lorsqu’une de ces couches dérive : un cache key mal construit, un router qui prend en compte un identifiant de session au lieu d’un identifiant de tenant, un pool de connexions qui réutilise une socket entre deux utilisateurs, ou encore une migration de schéma qui perd un filtre de partition.

La base de données MITRE classe ce type de défaut sous la référence CWE-668 (Exposure of Resource to Wrong Sphere). La matrice MITRE ATLAS, qui modélise les menaces sur les systèmes d’IA, le range dans la tactique AML.T0043 (Craft Adversarial Data) et AML.T0025 (Exploit Public-Facing Application).

Pourquoi ce type de faille est-il considéré comme “sévère” ?

Une fuite de données classique (compromission d’un compte admin, exfiltration d’une base) reste contenue à un périmètre : l’attaquant récupère un volume de données, mais l’incident est borné dans le temps et dans la surface.

Un cross-tenant isolation failure est plus inquiétant pour trois raisons :

Quels sont les précédents en 2022-2026 ?

Le secteur cloud n’a pas attendu Anthropic pour rencontrer ce type d’incident. Voici les précédents les plus documentés :

Le pattern récurrent est presque toujours le même : une couche d’isolation (cache, router, namespace, pool) dérive après un déploiement, une migration ou un pic de charge, et le défaut n’est pas détecté tout de suite car il ne touche qu’un sous-ensemble de requêtes. C’est précisément pour cela que les audits d’architecture red team existent : on ne découvre ces défauts qu’en générant des requêtes malveillantes qui ciblent explicitement les frontières entre tenants.

Comment une entreprise française peut-elle s’en protéger ?

Le risque zéro n’existe pas en cloud public. Mais on peut réduire la surface d’exposition avec quatre leviers concrets :

Choisir un fournisseur avec un hébergement dédié ou privé

Les grands éditeurs (Anthropic, OpenAI, Google, Mistral, Microsoft) proposent tous des offres Enterprise ou Dedicated avec des instances isolées au niveau de l’infrastructure, pas seulement de la session. Le surcoût (souvent 3 à 5× le prix de l’offre mutualisée) se justifie dès que les données manipulées sont sensibles (santé, droit, finance, R&D).

Mettre en place du BYOK (Bring Your Own Key)

Le principe : l’entreprise garde le contrôle de la clé de chiffrement de ses données, et la plateforme ne peut pas lire les prompts ni les réponses sans cette clé. En cas d’incident d’isolation, les données d’autres tenants sont illisibles côté entreprise. Compatible avec Azure OpenAI Service, AWS Bedrock, GCP Vertex AI, et désormais avec plusieurs offres européennes (Mistral, Aleph Alpha, Nscale).

Auditer l’architecture avec un red team IA

Un audit red team IA ne se limite pas à tester le prompt : il inclut des tests d’isolation (un compte A tente d’accéder à des ressources du compte B), des tests de cache poisoning, et des tests de fuite par canal latéral (timing, taille de réponse, jeton d’erreur). Le coût d’un audit ponctuel varie de 15 à 50 k€ pour une PME, 80 à 200 k€ pour un grand groupe.

Exiger des engagements contractuels sur la notification d’incident

Le RGPD impose une notification sous 72h en cas de violation de données personnelles. Pour un incident d’isolation qui n’est pas une “violation” au sens juridique strict, l’éditeur n’est pas tenu de notifier. D’où l’intérêt d’un avenant contractuel imposant une notification sous 24h dès qu’un cross-tenant isolation failure est détecté, même sans impact démontré.

Faut-il s’inquiéter si on utilise ChatGPT, Claude ou Copilot en B2B ?

Non, pas de panique. Mais il faut arrêter de confondre usage personnel et usage professionnel. Pour un usage ponctuel, non sensible, l’offre mutualisée reste acceptable. Pour un usage régulier sur des données à caractère personnel, du code source, des données financières ou toute information couverte par un secret professionnel, l’offre mutualisée n’est pas dimensionnée pour le risque.

La bonne métrique n’est pas “est-ce que mon fournisseur a déjà eu un incident ?” (tout le monde en a eu, tôt ou tard), mais “est-ce que mon fournisseur le détecte vite, le déclare vite, et m’aide à m’en protéger ?” Anthropic a publié son rapport d’incident en moins de 72h. C’est un signal positif sur la transparence, pas sur la sécurité elle-même.

L’épisode du 5 juin 2026 doit être lu comme un rappel, pas comme un procès. Le cloud mutualisé reste le modèle économique dominant, et ses avantages (coût, mise à l’échelle, accessibilité) restent réels. Mais pour les entreprises qui manipulent des données sensibles, l’isolation n’est plus un acquis : c’est une décision d’architecture, pas un paramètre par défaut.