Comment garder vos secrets hors du code généré par l'IA et des commits Git

Les agents de codage IA sont rapides, mais ils ont un angle mort : ils collent volontiers une clé d'API dans un fichier, recopient un jeton dans un journal, ou committent un .env que vous vouliez garder en local. Chaque agent disposant d'un accès au terminal — Claude Code, Cursor, Gemini CLI, Codex — peut aussi lire votre configuration shell et vos fichiers de projet, c'est-à-dire précisément là où les identifiants ont tendance à se cacher. Ce guide détaille une configuration pratique et en couches pour que vos secrets restent hors du code généré par l'IA et hors de votre historique Git.

Pourquoi cela compte encore plus avec l'IA

Une clé divulguée est l'une des erreurs les plus courantes et les plus coûteuses en logiciel, et les assistants IA augmentent les enjeux de deux façons. Premièrement, ils génèrent du code rapidement, de sorte qu'une clé codée en dur peut atterrir dans une douzaine de fichiers avant que vous ne le remarquiez. Deuxièmement, les agents ingèrent le contexte de manière agressive — comme le formule un article sur la gestion des secrets, votre configuration shell devrait référencer les clés, pas les contenir, car l'agent peut lire tout ce que vos dotfiles exposent. La solution n'est pas de se méfier de l'outil ; c'est de s'assurer qu'il n'y a aucun secret en clair à trouver dès le départ.

Étape 1 : Gardez les secrets dans des variables d'environnement, jamais dans le code

La règle de base : aucune clé d'API, mot de passe ou jeton ne devrait jamais apparaître sous forme de chaîne littérale dans le code source. Placez-les dans un fichier .env à la racine de votre projet et lisez-les à l'exécution.

# .env  — never committed
ANTHROPIC_API_KEY=sk-ant-...
DATABASE_URL=postgres://...

// app.js — reads from the environment, no secret in the file
const apiKey = process.env.ANTHROPIC_API_KEY;

Ainsi, le code que vous (et votre agent IA) éditez ne contient que le nom du secret, jamais sa valeur.

Étape 2 : Assurez-vous que .env ne puisse jamais être committé

Ajoutez-le à .gitignore avant d'écrire le moindre secret :

.env
.env.local
*.env

Committez plutôt un .env.example avec des emplacements vides, afin que les collaborateurs sachent quelles variables définir :

ANTHROPIC_API_KEY=
DATABASE_URL=

Si vous avez déjà committé un véritable .env, le supprimer dans un nouveau commit ne suffit pas — il subsiste dans l'historique. Faites immédiatement tourner la clé exposée et considérez-la comme compromise.

Étape 3 : Activez la protection contre les push de GitHub

La protection contre les push de GitHub analyse les commits au moment où vous les poussez et bloque le push si elle repère un secret, stoppant la fuite avant qu'elle n'atteigne le dépôt distant. Elle reconnaît plus de 200 motifs de secrets de fournisseurs comme AWS, OpenAI, Stripe, et bien d'autres, et les mises à jour de 2026 ont élargi les motifs bloqués par défaut. Elle est gratuite pour les dépôts publics — activez-la dans les paramètres de votre dépôt, sous Settings → Code security. Voyez-la comme une ceinture de sécurité pour le moment où un agent (ou vous-même) fait une erreur.

Étape 4 : N'autorisez pas les agents à récolter votre configuration shell

Les agents disposant d'un accès au shell peuvent lire .zshrc, .bashrc et .zshenv. Si vous y avez exporté des clés par commodité, l'agent peut les voir. Gardez les secrets valables pour toute la machine hors de vos dotfiles — chargez-les à la demande depuis un gestionnaire de secrets ou un trousseau du système d'exploitation plutôt que d'exporter du texte en clair au démarrage du shell.

Étape 5 : Restreignez la portée et faites tourner les clés

Deux habitudes limitent les dégâts en cas de fuite, un conseil repris dans le guide de sécurité des clés d'API d'OpenAI :

• Moindre privilège : accordez à chaque clé la portée la plus étroite dont elle a besoin, et utilisez des clés distinctes par projet et par environnement afin qu'une seule fuite n'expose pas tout.
• Rotation régulière : faites tourner les clés selon un calendrier et immédiatement dès que vous soupçonnez une exposition. Une clé renouvelée transforme une brèche en non-événement.

Une liste de contrôle rapide

Avant de lâcher un agent sur un dépôt :

1. Les secrets résident dans .env, lus via process.env — jamais codés en dur.
2. .env est dans .gitignore ; seul .env.example est committé.
3. La protection contre les push est activée sur le dépôt distant.
4. Aucune clé en clair dans les dotfiles du shell.
5. Les clés ont une portée étroite et sont renouvelées selon un calendrier.

Rien de tout cela ne vous ralentit une fois en place — et cela vous permet de confier davantage de travail à votre agent IA avec beaucoup moins de soucis.