Le 4 juillet 2026, un développeur a soumis un rapport de bug sur GitHub. Il utilisait Claude Code d’Anthropic — un assistant de programmation IA destiné aux professionnels, fonctionnant dans un espace de travail sécurisé au niveau entreprise. Il s’apprêtait à confier une tâche à l’IA quand celle-ci a soudainement demandé : « De quelle couleur veux-tu les briques pour ton temple Minecraft ? »
▲ Une conversation Claude Code où surgit une discussion sur Minecraft, sans aucun rapport avec la tâche en cours. Source : GitHub Issue #74066
Il n’avait jamais parlé de Minecraft à l’IA. Il a passé au crible tous ses journaux de conversation locaux : aucune trace des mots « temple » ou « briques ». Plus troublant encore, le même phénomène s’est reproduit sur l’application mobile Claude — l’IA s’est mise à parler décoration d’intérieur et triptyque alors qu’il travaillait sur un simple tableur.
L’incident, déjà inquiétant en soi, a vraiment décollé lorsque la discussion Hacker News l’a propulsé en page d’accueil avec 260 points — grâce aux nombreux témoignages similaires qui ont afflué. Et pas seulement pour Claude.
Pas seulement Claude
Un commentaire largement cité émane d’un utilisateur anonyme. Il affirme utiliser intensivement les services IA de plusieurs fournisseurs et avoir personnellement assisté à deux reprises à des « croisements de conversations » : une fois avec un modèle Claude, une fois avec un modèle GPT, chez deux fournisseurs différents — deux géants technologiques valant chacun plus de mille milliards de dollars.
L’un d’eux a fourni un rapport d’incident détaillé : le problème venait de la passerelle API (le « standardiste » du service IA) qui gérait incorrectement un mécanisme du protocole HTTP appelé « code d’état 100 ». En clair, la passerelle s’est trompée d’un cran dans la numérotation des requêtes — votre question recevait la réponse de l’utilisateur précédent, et votre réponse était envoyée au suivant.
L’autre entreprise a refusé d’expliquer la cause, se contentant d’un laconique « faites-nous confiance, cela ne se reproduira plus ».
D’autres utilisateurs rapportent avoir régulièrement vu, via des plateformes tierces, les liens et fichiers que des inconnus envoyaient à l’IA. Un autre encore raconte que Claude a spontanément mentionné un lieu que seul son ami connaissait — un ami qui, coïncidence, utilisait Claude dans le même bureau.
Comment est-ce possible ?
En une phrase : pour rendre l’IA plus rapide et moins chère, plusieurs entreprises ont construit des « couloirs partagés » dans leur infrastructure — et ces couloirs distribuent parfois le courrier à la mauvaise porte.
On peut l’analyser sur trois niveaux.
Premier niveau : le HTTP request smuggling — quand les « numéros de chambre » sont mal collés
Sur Internet, quand vous envoyez une requête à un site, votre navigateur et le serveur dialoguent via le protocole HTTP. Ce protocole, d’apparence simple, est en réalité très complexe, surtout quand un serveur traite simultanément des milliers de requêtes. Pour gagner en efficacité, le serveur « covoiture » plusieurs requêtes sur une même connexion.
Mais si, pendant ce covoiturage, le paquet de données de l’utilisateur A se colle à celui de l’utilisateur B — par exemple à cause d’une erreur dans la longueur déclarée des en-têtes — le serveur peut envoyer la réponse de A à B. Cela porte un nom en cybersécurité : le HTTP Request Smuggling (contrebande de requêtes HTTP).
Le chercheur en sécurité James Kettle enchaîne les démonstrations de variantes de cette attaque depuis des années à la conférence DEF CON. Son dernier exposé s’intitule : « HTTP/1.1 doit mourir » — car seule une migration complète vers le protocole HTTP/2, plus strict, permettrait d’éliminer structurellement cette faille. Ironie du sort : six ans après sa première démonstration, en ce mois de juillet 2026, des entreprises valant mille milliards de dollars continuent de trébucher sur ce même caillou.
Deuxième niveau : le cache KV partagé — les risques du « brouillon commun »
Quand un grand modèle d’IA traite une conversation, il maintient dynamiquement ce qu’on appelle un « cache KV ». Imaginez-le comme le brouillon temporaire de l’IA : à chaque inférence, elle y note ce qu’elle a déjà calculé, pour le réutiliser si un début similaire se présente — économisant ainsi une énorme puissance de calcul.
Pour le fournisseur, cette optimisation est extrêmement tentante. S’il détecte que plusieurs utilisateurs partagent le même « message système » (par exemple, les instructions génériques intégrées au démarrage de Claude Code), il peut leur faire partager le même cache, réduisant drastiquement les coûts.
Mais il y a un hic : le cache est indexé par une clé. Si la fonction qui génère cette clé a un bug, si le cache n’est pas nettoyé à temps, ou si les données de différents utilisateurs atterrissent dans le même emplacement — un fragment de la conversation de l’utilisateur A peut se retrouver dans le cache de B. Un utilisateur de HN note qu’extraire les contenus propres à chaque utilisateur du message système pour les placer dans le premier message utilisateur est une parade courante, mais ce n’est qu’une pratique d’ingénierie, pas une garantie architecturale.
Troisième niveau : le conflit structurel entre vitesse et sécurité
Ces deux problèmes pointent vers la même tension profonde : la course des entreprises d’IA à la vitesse (ajout de caches, connexions partagées) contre l’impératif d’isolation stricte des données utilisateurs.
Ce n’est pas un jugement moral, mais une contrainte quasi physique. Un service IA sans aucun cache partagé est extrêmement coûteux — chaque message doit être calculé de zéro, ce qui peut multiplier la facture par un facteur considérable. À l’inverse, un service optimisé à tous les étages doit nécessairement mutualiser certaines infrastructures entre utilisateurs, créant autant d’occasions de « croisement ».
Comme le résume un des commentaires les plus appréciés sur HN : « Les incitations à optimiser au maximum sont énormes, donc je m’attends à ce qu’ils déploient des astuces incroyablement malignes — et plus ces astuces sont malignes, plus ce genre de bug devient probable. »
Plus qu’une simple « hallucination »
Certains objectent : ne s’agirait-il pas simplement d’une « hallucination » de l’IA — autrement dit, l’IA aurait inventé de toutes pièces cette histoire de Minecraft, sans qu’il y ait véritablement eu fuite de données ?
L’objection est légitime. Les IA inventent souvent. Mais dans ce cas précis, plusieurs détails rendent l’explication de l’hallucination difficile à tenir.
D’abord, le rapporteur a fouillé tous ses journaux de conversation locaux et confirmé l’absence des mots « temple » ou « bricks » (à l’exception d’un fichier sans rapport nommé minecraft.py dans une bibliothèque de coloration syntaxique Python). Cela écarte l’hypothèse d’une association déclenchée par un mot présent dans la conversation.
Ensuite, le même utilisateur a rencontré un phénomène similaire sur un autre appareil (l’application mobile) — l’IA s’est mise à parler décoration d’intérieur, un sujet totalement hors contexte, et ce précisément au seuil d’expiration du cache (plus de 5 minutes depuis la dernière interaction). Il devient statistiquement difficile d’attribuer les deux incidents à des hallucinations indépendantes.
Enfin, plusieurs utilisateurs de différentes sociétés ont corroboré des expériences analogues dans la discussion HN, et l’un d’eux disposait d’un rapport d’incident officiel. Ces témoignages convergents pointent vers un problème systémique, pas vers des artefacts ponctuels du modèle.
Objectivement, le rapporteur du GitHub Issue ne peut pas, à ce stade, identifier avec certitude la provenance de la fuite — collègue ou parfait inconnu. C’est d’ailleurs ce qui rend ce type de bug si insidieux : on le pressent, mais il est extrêmement difficile à prouver formellement.
Ce que cela signifie pour l’utilisateur ordinaire
Si vous ne faites que bavarder avec une IA sur WeChat pour lui demander une recette de cuisine ou un texte marketing, l’impact direct est probablement limité — vos conversations ne contiennent pas d’informations sensibles, et un croisement accidentel resterait sans gravité.
En revanche, si vous ou votre entreprise utilisez l’IA pour traiter des secrets commerciaux, des données médicales, des documents juridiques ou des informations financières, le signal est à prendre au sérieux. Il indique que l’infrastructure des services IA actuels n’atteint pas encore, en matière d’isolation multi-utilisateurs, le standard de sécurité qu’on attendrait d’un produit de niveau entreprise — y compris dans les offres payantes.
Dans la discussion HN, le commentaire de pocksuppet, l’auteur du concept de HTTP request smuggling, est d’une franchise désarmante : « Chaque fois que vous multiplexez les requêtes de plusieurs clients sur une même connexion montante, vous êtes probablement vulnérable. » Le problème dépasse largement ce bug particulier — il révèle une fragilité structurelle de toute l’infrastructure Internet actuelle. Les services IA n’ont fait que l’exposer à un niveau de sensibilité inédit.
Épilogue
À l’heure où nous écrivons ces lignes, Anthropic n’a pas encore publié de déclaration officielle. L’Issue GitHub reste ouverte, étiquetée « bug » et « area:security ». La discussion HN continue d’enfler, et les témoins d’incidents similaires sont de plus en plus nombreux.
Cet épisode met en lumière un angle mort plus large de l’industrie de l’IA : quand tout le monde sprinte pour améliorer les capacités des modèles et réduire les coûts d’inférence, la question la plus élémentaire — « les utilisateurs sont-ils correctement isolés les uns des autres ? » — se retrouve reléguée en bas de la liste des priorités.
Un détail de la discussion HN m’a particulièrement marqué : quand les utilisateurs ont exigé des explications de l’une des entreprises, celle-ci s’est contentée d’un « faites-nous confiance ». Chez l’autre, qui a fourni un rapport complet, la cause se résumait à une seule chose — une erreur de comptage d’une unité.
Liens de référence :