Votre assistant de programmation IA vient de lire votre portefeuille

Ouvrez votre assistant de programmation IA. Avant que vous n'ayez tapé un seul caractère, il a déjà lu le répertoire de votre projet. Votre fichier .env. Vos clés API. Le mot de passe de votre base de données. Votre clé secrète Stripe.

Vous ne le lui avez pas demandé. Vous ne l'avez pas approuvé. C'est une fonctionnalité, pas un défaut — l'outil a besoin du contexte du projet pour être utile. Il lit donc tout ce qu'un développeur peut lire.

Et un développeur peut tout lire.

La version greentext

Un post a circulé cette semaine, rédigé comme un monologue intérieur de développeur :

> Ouvrez Claude Code. Votre .env est lu avant que vous ne tapiez quoi que ce soit. Vos clés API sont maintenant dans la discussion. Vous ajoutez « ne pas lire .env » à CLAUDE.md. Ça ne marche pas.

380 000 personnes ont vu ce post. 2 700 l'ont mis en favori. Pas parce que c'était une nouveauté — parce que c'était un miroir.

Chaque développeur qui l'a lu a eu la même pensée : c'est ma configuration.

Les instructions ne fonctionnent pas

La première chose que les gens ont essayée, ce fut d'écrire des règles. « Ne pas lire les fichiers .env. » Dans CLAUDE.md, dans AGENTS.md, dans les invites système. Des interdictions directes et explicites.

L'outil a lu les fichiers quand même.

Cela a du sens une fois qu'on y réfléchit. Le fichier est lu dans le cadre de la construction du contexte du projet — avant même que les instructions ne soient traitées. Demander au modèle de ne pas lire un fichier qu'il a déjà lu, c'est comme demander à quelqu'un d'oublier ce qu'il vient de voir. L'information est dans la fenêtre de contexte. Elle a été transmise. L'instruction arrive après le dommage.

Un chercheur a découvert que même des règles de refus au niveau du fichier pouvaient être contournées via des scripts personnalisés ou des chaînes de pipes. Un autre a constaté des factures de proxy gonflées parce que ses identifiants HTTP_PROXY étaient automatiquement chargés et utilisés.

L'argent dans votre .env

Les gens présentent cela comme une question de confidentialité. C'est une question financière.

Ouvrez un fichier .env typique d'un projet en production :

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

Cette clé OpenAI est une carte de crédit sans plafond de dépense et sans code PIN. Quiconque détient cette chaîne peut lancer 40 000 $ d'appels API en une nuit. La clé Stripe peut émettre des remboursements, créer des débits, accéder aux données de paiement des clients. Les identifiants AWS — selon la politique IAM, qui est presque certainement trop large — peuvent lancer des instances GPU, accéder à des buckets S3, ou supprimer de l'infrastructure.

Ce n'est pas une liste de mots de passe. C'est une liste de portefeuilles, chacun avec un solde différent et sans verrou.

29 millions de portefeuilles sur le trottoir

Le dernier rapport de GitGuardian a recensé 28,6 millions de secrets exposés dans des commits GitHub publics en 2025. Une hausse de 34 % par rapport à l'année précédente, et la plus forte augmentation annuelle jamais mesurée par l'entreprise.

Les chiffres spécifiques à l'IA sont pires. 1,2 million de secrets de services d'IA exposés — une envolée de 81 % en un an. Les commits co-écrits avec des outils de programmation IA ont fuité des secrets à un taux environ double de la référence. Et 24 000 secrets uniques ont été trouvés dans des fichiers de configuration MCP — la tuyauterie qui relie les agents IA à des services externes.

Douze des quinze types de secrets fuités à la croissance la plus rapide étaient des services d'IA. Pas des bases de données. Pas des fournisseurs cloud. Des services d'IA.

Les outils que nous utilisons pour écrire du code plus vite fuitent les clés des systèmes auxquels ce code se connecte.

Le vrai problème

Le développeur qui a publié ce fil greentext a terminé par un correctif pratique — une configuration settings.json qui bloque les lectures de fichiers. Cela fonctionne. Pour l'instant, pour cet outil-là.

Mais le vrai problème n'est pas Claude Code, ni Cursor, ni Copilot. Le vrai problème, c'est que les secrets sont des fichiers.

Un fichier .env est un document en clair stocké sur le disque, lisible par tout processus s'exécutant sous votre utilisateur. Avant les outils de programmation IA, les processus qui lisaient votre projet étaient git, npm, node, votre éditeur. Vous leur faisiez confiance implicitement. Vous ne pensiez pas au fait que vos secrets n'étaient qu'à une commande cat de l'exposition.

Les outils de programmation IA ont simplement rendu l'implicite explicite. Ils lisent votre projet comme n'importe quel autre outil — ils envoient simplement le contexte quelque part où vous pouvez le voir.

Votre chaîne CI lit aussi les fichiers .env. Votre lanceur de tests aussi. Votre linter aussi. Votre build Docker aussi. Aucun non plus n'a demandé la permission. Vous n'avez simplement pas remarqué parce qu'ils ne vous ont pas montré une transcription de ce qu'ils avaient trouvé.

Le schéma en dessous

70 % des secrets fuités en 2022 sont toujours actifs aujourd'hui. Pas remplacés. Pas révoqués. Toujours fonctionnels, toujours accordant des accès, trois ans plus tard.

C'est le chiffre réel. Pas 29 millions de fuites — 70 % jamais corrigés. Parce que remplacer une clé signifie trouver chaque système qui l'utilise, mettre à jour chaque déploiement, tester chaque intégration. La clé a été créée une fois, collée dans un fichier .env, et plus jamais réfléchie. Le coût de sa fuite est instantané. Le coût de la correction est illimité.

La plupart des organisations ne corrigent donc pas. Elles ne peuvent pas. Elles ne savent pas quelles clés sont où, lesquelles sont encore actives, lesquelles ont été copiées dans d'autres fichiers .env sur d'autres machines par d'autres développeurs qui avaient besoin de faire fonctionner une fonctionnalité un vendredi après-midi.

Ce que cela signifie réellement

Chaque fichier .env est un pari. Un pari selon lequel aucun processus ne le lira sans y être autorisé. Un pari selon lequel aucun outil ne l'enverra à un endroit inattendu. Un pari selon lequel aucun développeur ne le committra par accident.

29 millions de fois l'année dernière, quelqu'un a perdu ce pari. Sur le seul GitHub public. Les dépôts privés — où GitGuardian a trouvé des secrets dans 35 % des dépôts — ne sont même pas comptés.

La correction n'est pas une règle settings.json. La correction n'est pas une entrée .gitignore. La correction n'est pas d'écrire « NE PAS LIRE .ENV » en majuscules dans votre fichier d'instructions.

La correction, c'est que le secret ne devrait pas être là en premier lieu. Pas dans un fichier. Pas dans une variable d'environnement chargée depuis un fichier. Pas sous aucune forme qu'un processus disposant de vos permissions puisse lire en faisant ce que font les processus : lire les fichiers de votre répertoire de projet.

Si le secret est sur le disque, il sera lu. La seule question est quand, et par quoi.

---

Sources

• GitGuardian — State of Secrets Sprawl 2025 — 28,6 M de secrets fuités, tendances des identifiants de services d'IA, statistiques de remédiation
• GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — couverture par Help Net Security avec des ventilations spécifiques à l'IA
• Claude Code Can Consume, Transmit, and Compromise Your .env Files — analyse de Martin Paul Eve sur l'échec des interdictions dans CLAUDE.md
• Claude Code Automatically Loads .env Secrets, Without Telling You — analyse technique par Knostic du chargement automatique des secrets
• From .env to Leakage: Mishandling of Secrets by Coding Agents — analyse plus large par Knostic couvrant Claude et Cursor
• @zodchiii sur X — le post viral qui a motivé cet article (380 K vues, 2,7 K favoris)