Pendant quelques heures dans l'après-midi du 2026-06-05, l'API Claude semble avoir renvoyé des réponses qui n'appartenaient pas à l'utilisateur qui les avait demandées. Vous envoyez une requête et vous récupérez une sortie qui ressemble à la réponse au prompt de quelqu'un d'autre.
La page d'état d'Anthropic a enregistré l'événement comme « erreurs élevées sur de nombreux modèles Claude », touchant Opus 4.5 à 4.8 et Sonnet 4.6. Elle ne décrit pas, à ce jour, une fuite de données. La lecture d'un croisement de données entre utilisateurs provient de captures d'écran qui circulent et de témoignages directs : il faut donc la considérer comme une interprétation précoce, pas comme une violation confirmée.
Ce qui est intéressant n'est pas de savoir si un fournisseur a eu un mauvais après-midi. C'est la classe de défaillance. Quand ce genre de chose arrive, cela remonte presque toujours à un état mutable partagé sous charge, et c'est un risque que porte aujourd'hui tout fournisseur d'IA qui passe à l'échelle rapidement.
Ce qui semble s'être passé
D'après la page d'état d'Anthropic, l'incident s'est étalé sur l'après-midi du 2026-06-05 : l'investigation a été ouverte vers 15:19 UTC, le problème a été identifié vers 15:43 UTC et marqué comme résolu vers 18:28 UTC. Les modèles touchés étaient Claude Opus 4.5, 4.6, 4.7 et 4.8, ainsi que Sonnet 4.6. L'étiquette officielle était « erreurs élevées », la catégorie générique que les fournisseurs utilisent pour tout, des délais d'attente aux réponses mal formées.
Les signalements qui ont attiré l'attention décrivent quelque chose de plus précis. Des utilisateurs ont déclaré que certains appels à l'API renvoyaient un contenu sans aucun rapport avec leur propre prompt et, dans au moins un cas très partagé, la tâche d'une personne est apparue dans la réponse d'un utilisateur totalement étranger. Plusieurs personnes ont dit avoir reçu ce qui ressemblait à la sortie d'inférence d'un autre client, et l'avoir vérifié soigneusement avant de conclure qu'il s'agissait d'une erreur côté serveur et non d'un bug de leur côté.
Deux choses sont vraies en même temps. Anthropic n'a pas confirmé d'exposition de données entre utilisateurs, et les preuves publiques sont cohérentes avec elle. Une lecture responsable tient les deux : cela ressemble à une fuite de réponses entre clients (cross-tenant), et ce n'est pas encore officiellement confirmé. Je ne reproduis pas ici les captures divulguées, car elles contiennent le prompt et la sortie d'un autre client, c'est-à-dire exactement les données qui ne devraient pas circuler davantage.
La classe de défaillance : état mutable partagé sous charge
La fuite entre clients survient lorsque les données d'un client apparaissent dans la session d'un autre. C'est l'un des bugs les plus anciens et les plus dangereux des systèmes multi-locataires, et il vient rarement d'une violation spectaculaire. Il vient généralement d'un morceau d'état partagé et mutable qui devait être isolé par requête et qui, dans les mauvaises conditions, ne l'a pas été.
Une API d'IA moderne n'est pas un programme unique qui répond à une requête à la fois. C'est une pile de couches partagées : répartiteurs de charge, routeurs de requêtes, passerelles, files d'attente, caches en mémoire et pools de connexions, tous au service de chaque client en même temps pour maintenir une faible latence et un faible coût. Chacune de ces couches conserve un état. Chacune est un endroit où une requête peut récupérer la mauvaise réponse si une clé de cache entre en collision, si une connexion est réutilisée après avoir dû être abandonnée, ou si une requête annulée laisse derrière elle un objet périmé.
Le symptôme est presque toujours le même : vous demandez vos données et vous recevez celles de quelqu'un d'autre. La cause est presque toujours banale : une petite erreur dans la façon dont un objet partagé est réutilisé, déclenchée par la charge ou par un cas limite comme une requête annulée ou expirée.
Nous avons déjà vu ce schéma exact
Le précédent le plus clair est OpenAI, en mars 2023. Le 2023-03-20, une modification de ses serveurs a provoqué un pic de requêtes Redis annulées, qui a déclenché un bug dans la bibliothèque cliente redis-py. Pendant une fenêtre ce jour-là, certains utilisateurs de ChatGPT pouvaient voir les titres de conversation d'autres utilisateurs actifs et, dans certains cas, le premier message d'une conversation nouvellement créée.
Le même incident a exposé des données de facturation limitées. OpenAI a notifié environ 1,2 % des abonnés ChatGPT Plus qu'un autre utilisateur avait pu voir leurs nom et prénom, adresse de facturation, type de carte, date d'expiration et les quatre derniers chiffres de leur carte. Les numéros de carte complets n'ont jamais été exposés. Comme Help Net Security l'a rapporté à l'époque, et comme OpenAI l'a confirmé dans son propre post-mortem, la cause racine était une couche partagée de cache et de connexions qui renvoyait des données au mauvais client après des requêtes annulées.
C'est la même classe de défaillance que le symptôme décrit dans les signalements concernant Claude : une couche partagée et mutable qui remet les données d'un client à un autre sous charge. Entreprise différente, bibliothèque différente, même forme.
Pourquoi passer à l'échelle rend cela plus probable, pas moins
Voici la partie structurelle inconfortable. Les fournisseurs d'IA ajoutent de la capacité plus vite que presque toute infrastructure de l'histoire de l'informatique. La demande dépasse le matériel, alors les équipes continuent d'empiler des couches pour tenir : plus de cache pour réduire le coût des tokens, plus de routage pour répartir la charge entre régions et versions de modèle, plus de proxys et de passerelles pour gérer les quotas et le basculement.
Chacune de ces couches est un gain de performance et un nouvel endroit par lequel l'état peut fuir. Un cache qui sert la mauvaise clé, un routeur qui réutilise une connexion, un proxy qui replie une réponse dans un autre flux : chacun est à un seul bug d'une fuite entre clients. Plus un fournisseur passe à l'échelle agressivement, plus il exploite de ces couches et plus il y pousse de charge.
C'est donc moins une histoire sur Anthropic qu'une histoire sur tout le monde. Les fournisseurs qui courent le plus vite pour ajouter de la capacité sont précisément les plus exposés à cette classe de bug, car la vitesse et l'infrastructure partagée sont la façon de servir des millions de requêtes à bas coût. Ce n'est pas le signe qu'une entreprise est négligente. C'est une propriété de l'architecture sur laquelle toute l'industrie se construit.
Ce que cela signifie si vous construisez sur des API de LLM
Le point pratique est un changement de mentalité. La réponse d'une API de LLM n'est pas un canal privé et de confiance entre vous et le modèle. Ce sont des données qui reviennent d'un système massivement partagé et en évolution rapide et qui, un mauvais jour, peuvent être erronées, périmées ou croisées avec un autre client.
Traitez-les ainsi :
- Supposez qu'une réponse peut de temps en temps appartenir à la mauvaise requête. Ne concevez pas de flux où une seule réponse croisée corrompt en silence l'enregistrement d'un utilisateur ou l'expose à quelqu'un d'autre.
- N'envoyez pas à une API de LLM des données que vous ne toléreriez pas de voir apparaître ailleurs, sauf si votre contrat et les contrôles du fournisseur les couvrent réellement. Les conditions de rétention zéro et d'isolation pour les entreprises comptent ici.
- Validez et limitez les réponses avant d'agir dessus. Vérifiez la forme, le type et la plausibilité, comme vous valideriez n'importe quelle entrée non fiable.
- Journalisez suffisamment pour détecter les fuites. Si vous ne stockez jamais les métadonnées de requête et de réponse, vous ne pouvez pas distinguer une erreur du modèle d'une réponse qui n'a jamais été la vôtre.
Il existe une version de tout cela au niveau du navigateur qu'il est facile de manquer. De plus en plus d'applications injectent la sortie du modèle directement dans la page : réponses en streaming, HTML généré par IA, résultats d'outils affichés en ligne. Si cette sortie peut être croisée ou injectée, l'afficher aveuglément transforme un problème de backend en problème côté client. Vous pouvez finir par montrer le contenu d'un autre utilisateur au vôtre, ou par exécuter du balisage que vous n'avez pas écrit, dans une session où votre utilisateur est déjà authentifié.
Quoi faire cette semaine
- Cartographiez chaque endroit où une réponse d'API de LLM entre dans votre système et marquez ceux qui s'affichent directement dans le navigateur.
- Traitez ces réponses comme une entrée non fiable : validez la structure, échappez tout ce qui est affiché dans la page et n'injectez jamais de HTML brut du modèle sans l'assainir.
- Décidez explicitement quelles données vous êtes prêt à envoyer à chaque fournisseur et confirmez les conditions de rétention et d'isolation qui s'appliquent.
- Ajoutez une journalisation et des alertes capables de distinguer une réponse mal formée d'une réponse qui ne correspond pas à la requête envoyée.
- Surveillez la couche du navigateur, où la sortie d'IA, les scripts tiers et les données utilisateur se rencontrent désormais dans la même session.
Comment cside s'intègre
cside ne s'exécute pas dans le backend d'Anthropic ni d'aucun fournisseur, et ne peut pas réparer un cache qui renvoie les données du mauvais client. Ce qu'il traite, c'est la même classe de problème un cran plus près de votre utilisateur : le navigateur, où les réponses d'IA, les scripts tiers et les sessions authentifiées partagent désormais la même page.
cside offre une visibilité en temps réel sur ce qui s'exécute réellement dans cette session de navigateur : quels scripts se chargent, comment ils changent après le déploiement, quelles données ils lisent et où ils les envoient. À mesure que de plus en plus d'applications affichent la sortie du modèle directement dans la page, cette visibilité est la façon de détecter les conséquences côté client d'une réponse erronée ou croisée, comme un contenu affiché dans la mauvaise session ou un script qui cherche des données qu'il ne devrait jamais toucher.
Le point plus large est celui que cside a toujours défendu à propos des scripts tiers, désormais généralisé à l'infrastructure d'IA. Chaque couche que vous ajoutez pour aller plus vite est une couche par laquelle des données peuvent apparaître au mauvais endroit. Vous ne pouvez pas supprimer ces couches, mais vous pouvez instrumenter celle qui est la plus proche de votre utilisateur.
Commencez par la sécurité côté client pour la surveillance des scripts en temps réel, ou par Privacy Watch pour voir exactement ce que le code de vos pages collecte et envoie.
À lire aussi sur cside
- Comment des scripts tiers compromis peuvent injecter des prompts aux agents IA
- L'inférence sur l'appareil arrive dans votre pile de sécurité
- L'IA comprime le cycle des exploits
- Bonnes pratiques pour sécuriser les scripts tiers
À la date du 2026-06-05. Les détails de l'incident de l'API Claude reflètent la page d'état d'Anthropic et les signalements publics d'utilisateurs disponibles à cette date. Anthropic a qualifié l'événement d'erreurs élevées et n'a pas, à ce jour, confirmé d'exposition de données entre utilisateurs.
