En juillet 2026, des utilisateurs ont découvert qu'en utilisant la syntaxe de recherche de Google, il était possible de récupérer en masse les conversations partagées par les utilisateurs de Claude. La raison en est que la fonction de partage de Claude génère des pages publiques plutôt que des liens privés ; bien que ces pages soient protégées par un fichier robots.txt, elles manquent de la balise métadonnée noindex essentielle, ce qui a conduit les moteurs de recherche à indexer à la fois les URL et le contenu des pages. Les résultats de recherche ont révélé des informations sensibles telles que des clés de portefeuilles de cryptomonnaies et des numéros de sécurité sociale. Anthropic a désormais corrigé d'urgence le problème en ajoutant la balise noindex pour empêcher tout nouvel indexage. Ce problème n'est pas isolé : OpenAI avec ChatGPT et xAI avec Grok ont déjà connu exactement le même vulnérabilité de confidentialité.Auteur et source de l'article : Leifengwang
De clés privées de cryptomonnaies à des informations d'identité, Reddit connaît une frénésie de surveillance des autres.
Intelligence incarnée, pénètre la cuisine encombrée de fumée
La vie d'un robot sous un million de flux
Le Dr. Mu Wei, ancien vice-président de Covariant AI et CTO de Zhoupu Data, devient CTO de « Shu Tu Technology ».
L'équipe fondatrice vient de faire ses débuts, et le financement ainsi que la liste des actionnaires de cette startup d'IA physique sont désormais révélés.
Beta Infinity ciblera le marché bleu de mille milliards de robots grand public.
26 ans pour l'intelligence incarnée, c'est ce que 23 ans ont été pour les grands modèles linguistiques.
Le 26 juillet 2026, un utilisateur Reddit a publié un message sur la communauté affirmant qu'en utilisant la syntaxe de recherche de site Google site:claude.ai/share, il est possible d'extraire des milliers de conversations partagées par les utilisateurs de Claude.
Après avoir cliqué sur le bouton "Partager" dans Claude, le système génère une page web publique qui ne nécessite ni connexion ni vérification d'identité, et non un lien privé réservé à des destinataires spécifiques.
Ce type de page n'a pas de différence fondamentale avec les pages de sites web ordinaires sur Internet et répond aux conditions nécessaires pour être indexées par les robots des moteurs de recherche. Pourtant, la plupart des utilisateurs ayant utilisé la fonction de partage n'ont jamais reçu de notification de risque associée.
Le post a rapidement pris de l'ampleur sur les réseaux sociaux internationaux ; les débats autour de la conception du mécanisme « partager = rendre public » s'intensifient, et de nombreux cas de fuites de données privées dépassant les attentes du public émergent en succession.
Au fur et à mesure que de plus en plus de personnes participaient à la recherche, certains cas extrêmement dramatiques ont été découverts. Pendant un certain temps, consulter les historiques de discussion d'autres internautes est devenu un grand plaisir pour la communauté. Les gens cherchaient les données privées d'autres utilisateurs, en discutaient parfois et en étaient constamment émerveillés.
Les deux types d'informations extraites présentent les risques les plus marqués.
L'un des éléments concerne les informations sur les actifs cryptographiques. Certains ont trouvé le portefeuille et le mot de passe d'un utilisateur. En suivant l'historique des discussions, les internautes ont localisé le portefeuille correspondant, qui ne contenait que 2,73 dollars américains. Encore plus absurde, un internaute bien intentionné a voulu avertir l'utilisateur que sa clé était compromise, mais n'a trouvé aucun moyen de contact dans la conversation — cet utilisateur ignore probablement toujours que sa clé de portefeuille a été exposée ainsi à l'ensemble du réseau.
Le deuxième point concerne les informations d'identité essentielles. Des utilisateurs ont confirmé avoir découvert des conversations complètes contenant des numéros de sécurité sociale (SSN) dans les résultats de recherche. Ces informations, une fois divulguées sur le marché noir, pourraient entraîner directement des dommages concrets tels que le vol d'identité et la fraude financière.
En outre, les contenus récupérés incluent des documents de projets de professionnels identifiés, des conversations de conseil juridique, des CV personnels, des contenus pour adultes et d'autres types d'informations privées. De nombreux contenus privés, destinés à un cercle restreint, se sont retrouvés sans aucune barrière dans l'index des moteurs de recherche publics.
Pourquoi le fichier robots.txt ne bloque-t-il pas l'indexation ?
Après l'escalade de l'événement, des internautes attentifs ont retrouvé le fichier robots.txt de Claude, qui indique clairement Disallow: /share/*, interdisant ainsi aux robots d'accéder au chemin /share.
Puisque des règles claires existent, pourquoi la conversation a-t-elle quand même été indexée par les moteurs de recherche ? C'est le détail technique le plus central de cet événement.
Pour clarifier cette question, il faut d'abord distinguer deux concepts : le crawl et l'indexation :
robots.txtsert à convenir avec les robots d'arrêter de récupérer activement le contenu des pages sous ce chemin. Il ne peut bloquer que les comportements de爬虫 qui explorent activement les liens internes du site ; il n'a pas de force contraignante et ne peut pas empêcher les moteurs de recherche d'inclure l'URL elle-même dans les résultats de recherche.- Un moteur de recherche découvre un lien, ainsi qu'un autre chemin : via des liens externes provenant de pages publiques externes. Dès qu'un utilisateur partage un lien vers Claude sur Reddit, X, des forums publics, des documents GitHub ou toute autre page publique accessible aux robots d'exploration, Google détecte ce lien /share lors de l'exploration de cette page.
Even if robots.txt prohibits crawlers from reading the page content, Google will still include the URL in search results, just without displaying a snippet. The only way to completely prevent a page from appearing in search results is through the noindex meta tag in the page's HTML, which directly instructs search engines not to index this page.
À l'époque des faits, toutes les pages partagées de Claude manquaient précisément cette configuration clé noindex. La plateforme ne disposait que d'une protection partielle via robots.txt, sans mécanisme réellement efficace pour empêcher l'indexation. Selon les investigations des internautes de la communauté, en septembre 2025, Claude avait déjà connu un incident similaire à plus petite échelle, au cours duquel Google avait estimé qu'environ 600 conversations avaient été indexées puis supprimées, sans toutefois inciter la plateforme à compléter entièrement ses configurations de protection.
Un autre problème avec cet événement est que Google a découvert ces liens de partage composés d'UUID aléatoires par quel chemin ?
Certains utilisateurs ont clairement indiqué qu'il est presque impossible de deviner des milliards de combinaisons de caractères par force brute ; le chemin principal doit être des liens externes. La conjecture dominante est que certains utilisateurs ont publié des liens de partage sur des forums publics, des plateformes sociales, des documents de projets open source, ou d'autres pages accessibles aux robots d'exploration, et que Google a découvert les liens /share correspondants en extrayant ces pages.
Certains internautes ont également suggéré que les produits de communication de Google, tels que Gmail et Google Chat, pourraient être une source de lien. Toutefois, cette affirmation n'est qu'une hypothèse de la communauté et n'est pour l'instant soutenue par aucune preuve concrète.
À ce sujet, Anthropic semble avoir effectué des mesures correctives d'urgence. Les utilisateurs ont constaté que la commande site:claude.ai/share affiche désormais le résultat « Aucun document correspondant trouvé » sur Google. Il est généralement estimé que la plateforme a ajouté en urgence des balises noindex à toutes les pages de sessions partagées afin d'empêcher toute nouvelle indexation.
Mais la correction présente un retard naturel : les caches des autres moteurs de recherche comme Bing et Brave ont des cycles de mise à jour indépendants, et les pages historiques déjà indexées ne disparaîtront pas immédiatement.
Failles de confidentialité d'OpenAI et de Grok
En fait, ce type de problème de configuration d'index n'est pas exclusif à Anthropic.
Il y a quelques années, la fonction de partage de conversations de ChatGPT a connu exactement le même problème de conception de confidentialité. Après l'incident, OpenAI a rapidement corrigé la configuration noindex de la page et ajouté un avertissement de risque dans la fenêtre de partage, mais la conception fondamentale du mécanisme de partage n'a pas été modifiée.
Aujourd'hui, Anthropic rencontre le même problème, car les deux principaux fabricants ont adopté la même approche de conception sécurisée.
Grok, dans le même secteur, a également rencontré le même piège. En 2025, des centaines de milliers de conversations partagées sur la plateforme Grok ont été collectées en masse par Google, suscitant une controverse sur la vie privée de même ampleur.
Bien que l'accident soit survenu, xAI a mis en place une défense multicouche au niveau de l'architecture, par exemple en imposant systématiquement des balises noindex sur toutes les pages partagées et en renforçant simultanément les règles de capture du robots.txt sur l'ensemble du site ; ces deux protections ont été mises en œuvre en parallèle, établissant des restrictions claires à la fois lors de la collecte par les robots et de l'indexation des résultats.
L'avantage principal de cette solution réside dans la prévention proactive, et non dans la dépendance aux habitudes d'utilisation des utilisateurs. Toutefois, du point de vue de l'ensemble de l'industrie, la logique de conception sous-jacente à ce type de problème n'a pas été corrigée de manière généralisée.
Comment combler les lacunes dans la configuration de l'index et la conception du partage
Les mêmes vulnérabilités qui se sont répétées chez OpenAI et Anthropic poussent la communauté à réfléchir sur les modèles de conception produits courants dans l'industrie.
La fonction de partage de conversation facilite la diffusion du contenu et stimule la croissance du produit ; les fabricants accordent donc la priorité à l’expérience utilisateur. Toutefois, des mesures de protection de la vie privée telles que l’anti-indexation et les permissions hiérarchisées sont souvent ajoutées de manière précipitée par des correctifs temporaires seulement après la survenance d’un incident de sécurité et la montée de la controverse médiatique.
De nombreux internautes ont appelé la plateforme à construire un système de protection plus complet depuis la base. La plupart des utilisateurs ordinaires ne comprennent pas les technologies web telles que noindex ou le cache des robots d'exploration, et ont du mal à percevoir les risques cachés dans le partage de liens.
Du point de vue technique produit, les pistes d'optimisation actuellement réalisables sont relativement matures et les coûts de mise en œuvre sont maîtrisables ; la couche la plus fondamentale consiste à définir noindex comme configuration par défaut des pages de partage, afin de bloquer à la source l'indexation par les moteurs de recherche.
Sur cette base, il est également possible de réduire davantage les risques grâce à une conception des permissions, par exemple en ajoutant une vérification d'accès à la connexion, en permettant aux utilisateurs de définir un mot de passe d'accès pour le lien et de personnaliser sa durée de validité, afin de mieux contrôler la portée et la durée du partage.
En même temps, fournissez un avertissement de risque plus direct à côté de l’action de partage, sans termes obscurs : expliquez simplement que le lien peut être indexé par les moteurs de recherche, afin que l’utilisateur comprenne clairement son caractère public avant de cliquer.
Ces ajustements ne nécessitent pas de modifications majeures de l'architecture produit, mais permettent de réduire efficacement l'écart entre les attentes des utilisateurs en matière de confidentialité et les mécanismes réels du produit.