Quand tu utilises Claude Code dans ton terminal (cet écran noir où tu tapes des commandes), Claude peut explorer et lire tous les fichiers de ton projet pour t'aider.

Tous.

Y compris tes mots de passe, tes clés API, et tous tes secrets.

Et c'est un problème si tu ne fais pas attention.

Le Problème Expliqué Simplement

Imagine que tu demandes à Claude de t'aider avec un bug :

Pour t'aider, Claude va explorer ton projet. Il va regarder les fichiers de configuration, les connexions à la base de données, et potentiellement tomber sur ton fichier .env qui contient quelque chose comme :

DATABASE_PASSWORD=MonSuperMotDePasse123!
STRIPE_SECRET_KEY=sk_live_51abc123xyz...
OPENAI_API_KEY=sk-proj-abcdef123456...

Le problème ? Ces informations sont maintenant dans le contexte de la conversation avec Claude.

Alors, est-ce grave ? Claude ne va pas utiliser tes clés malicieusement. Mais :

1. Si tu partages ta conversation avec quelqu'un (capture d'écran, copier-coller), tes secrets sont exposés
2. C'est une mauvaise habitude de laisser traîner des secrets
3. Tu pourrais accidentellement les inclure dans un commit Git et les envoyer sur GitHub

Qu'est-ce qu'un fichier .env ?

Avant d'aller plus loin, expliquons ce qu'est ce fameux fichier .env dont tout le monde parle.

Le fichier .env (ou .env.local, .env.production, etc.) est un fichier texte simple qui contient les "variables d'environnement" de ton projet. En français courant : c'est le coffre-fort où tu ranges tes secrets.

Pourquoi on met les secrets dans un fichier séparé ?

Imagine que tu codes une app qui utilise Stripe pour les paiements. Tu as besoin de la clé secrète Stripe pour que ton code fonctionne. Tu pourrais l'écrire directement dans ton code :

// MAUVAISE PRATIQUE - NE FAIS JAMAIS ÇA
const stripe = new Stripe("sk_live_51abc123xyz...");

Mais si tu mets ce code sur GitHub, tout le monde peut voir ta clé. Et quelqu'un pourrait l'utiliser pour faire des transactions frauduleuses avec ton compte.

La solution : mettre la clé dans un fichier .env qui n'est JAMAIS envoyé sur GitHub :

// BONNE PRATIQUE
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

Le fichier .env contient :

STRIPE_SECRET_KEY=sk_live_51abc123xyz...

Comme ça, ton code ne contient pas le secret, et tu peux partager ton code sans exposer tes clés.

La Solution : Le Fichier .claudeignore

Le fichier .claudeignore est super simple : tu y listes les fichiers que Claude n'a pas le droit de lire. C'est comme dire à ton assistant "Tu peux regarder partout sauf dans ce tiroir." Il fonctionne exactement comme le fichier .gitignore (qui dit à Git quels fichiers ne pas sauvegarder).

Comment le créer ?

Étape 1 : À la racine de ton projet (là où il y a ton package.json si tu fais du JavaScript), crée un fichier nommé .claudeignore Étape 2 : Ajoute les fichiers et dossiers que Claude ne doit pas lire :

# Fichiers de secrets
.env
.env.local
.env.development
.env.production
.env

Dossiers sensibles
secrets/
credentials/
private/

Fichiers de configuration sensibles
config/production.json
firebase-adminsdk.json
service-account.json

Étape 3 : C'est tout !

Claude Code respecte automatiquement ce fichier. Si tu lui demandes d'ouvrir un fichier listé dans .claudeignore, il te dira qu'il ne peut pas y accéder.

Ce Que Tu Dois TOUJOURS Ignorer

Voici ma liste de base que je mets dans tous mes projets dès le premier jour :

# === SECRETS ET ENVIRONNEMENT ===
Tous les fichiers .env sous toutes leurs formes
.env
.env

Clés et certificats
.pem
.key
.crt
.p12

Credentials de services cloud
credentials.json
service-account.json
firebase-adminsdk.json
google-cloud.json

=== DOSSIERS SENSIBLES ===
secrets/
private/
credentials/

=== FICHIERS DE BUILD (pas sensibles mais inutiles) ===
node_modules/
.next/
dist/
build/
.cache/

=== FICHIERS PERSONNELS ===
.log
.DS_Store
Thumbs.db

=== HISTORIQUE ET SESSIONS ===
.history/
.sqlite
.db

Vérifier Que Ça Marche

Après avoir créé ton .claudeignore, tu peux tester que Claude le respecte bien. Demande-lui directement :

Si tout est bien configuré, Claude devrait te répondre quelque chose comme :

"Je ne peux pas accéder au fichier .env car il est listé dans .claudeignore"

Si Claude te montre le contenu, c'est que le fichier .claudeignore n'est pas bien configuré. Vérifie :

• Que le fichier est bien à la racine du projet
• Que le nom est exactement .claudeignore (avec le point au début)
• Que tu n'as pas fait de faute de frappe dans les chemins

L'Erreur Qui M'a Servi de Leçon

Laisse-moi te raconter ma plus grosse erreur de débutant avec Claude Code.

Au début, je n'avais pas de .claudeignore. Je ne savais même pas que ça existait. Un jour, j'ai eu un bug complexe et j'ai passé 2 heures avec Claude à le résoudre. Content du résultat, j'ai copié-collé toute la conversation pour la montrer à un collègue sur Slack.

"Regarde comment j'ai résolu ce problème !"

Ce que je n'avais pas remarqué : au milieu de la conversation, Claude avait cité une partie de mon fichier .env pour m'expliquer un problème de configuration. Avec ma clé API Stripe de production. Visible par tout mon Slack d'entreprise.

J'ai dû régénérer toutes mes clés en urgence. Heureusement, personne n'a eu le temps de les utiliser. Mais depuis ce jour, .claudeignore est la première chose que je crée dans chaque nouveau projet.

Bonus : Le Fichier CLAUDE.md

Tant qu'on parle de fichiers de configuration pour Claude, parlons de CLAUDE.md. C'est un fichier que tu peux créer à la racine de ton projet pour donner des instructions permanentes à Claude.

Exemple de CLAUDE.md :

# Instructions pour Claude

Ce projet
Application de e-commerce Next.js avec Supabase pour la base de données et Stripe pour les paiements.

Stack technique
- Next.js 14 avec App Router
- TypeScript strict
- Tailwind CSS pour le styling
- Supabase pour auth et base de données
- Stripe pour les paiements

Conventions de code
- Composants React dans /src/components
- Fonctions utilitaires dans /src/lib
- Hooks personnalisés dans /src/hooks
- Ne jamais hardcoder de valeurs sensibles
- Utiliser les Server Components par défaut

Fichiers importants
- /src/lib/supabase.ts : Configuration Supabase
- /src/lib/stripe.ts : Configuration Stripe
- /src/app/api : Routes API

À ne pas faire
- Ne jamais modifier les fichiers dans /migrations sans me demander
- Ne pas toucher à la configuration ESLint

Claude lira ce fichier automatiquement quand tu démarres une session dans ce projet, et il suivra tes instructions. C'est comme lui donner un briefing avant de commencer à travailler.

La Différence Entre .claudeignore et .gitignore

Tu te demandes peut-être : "J'ai déjà un .gitignore, pourquoi j'ai besoin d'un .claudeignore ?"

Bonne question ! Voici la différence :

Ils sont complémentaires :

• .gitignore protège tes secrets d'être publiés sur Internet
• .claudeignore protège tes secrets d'être lus par Claude pendant le développement

Mon conseil : Mets les mêmes fichiers sensibles dans les deux. Ils ont souvent le même contenu pour les fichiers .env et les clés.

Que Faire Si Tu As Déjà Exposé des Secrets ?

Si tu réalises que Claude (ou quelqu'un d'autre) a eu accès à tes secrets, voici quoi faire immédiatement :

Pour les clés API (Stripe, OpenAI, etc.)

1. Va sur le dashboard du service concerné
2. Révoque/supprime la clé exposée
3. Génère une nouvelle clé
4. Mets à jour ton fichier .env avec la nouvelle clé

Pour les mots de passe de base de données

1. Change le mot de passe dans ta base de données
2. Mets à jour ton .env
3. Redéploie ton application

Pour les secrets dans l'historique Git

Si tu as accidentellement commité un secret sur GitHub :

1. Change le secret immédiatement (étapes ci-dessus)
2. Utilise git filter-branch ou BFG Repo-Cleaner pour retirer le secret de l'historique
3. Force push (attention, c'est destructif)

Ou plus simple : considère que la clé est compromise et régénère-la. C'est plus rapide et plus sûr.

---

Résumé en 30 secondes :

1. Crée un fichier .claudeignore à la racine de ton projet
2. Liste tous les fichiers sensibles (.env*, clés, credentials)
3. Claude ne pourra plus les lire
4. Vérifie que ça marche en lui demandant d'afficher un fichier protégé

Simple, mais absolument essentiel. La sécurité, ce n'est pas sexy, mais perdre ses clés API l'est encore moins.

Pour Aller Plus Loin

Pour ceux qui veulent aller plus loin : on a créé le Workshop "Bâtir avec l'IA".

Articles connexes qui pourraient t'intéresser :

• Git pour les nuls - Comprendre .gitignore et protéger tes secrets sur GitHub
• Mettre en ligne ton site - Configurer les variables d'environnement sur Vercel
• Créer un espace membre sécurisé - L'authentification sans risques
• L'écran noir vous fait peur ? - Bien configurer Claude Code dès le départ

Outils mentionnés :

• Claude Code - L'outil IA pour coder dans le terminal
• GitHub - Pour stocker ton code (avec .gitignore)
• Stripe - Service de paiement (protège tes clés !)
• Supabase - Base de données (protège tes credentials !)

— Charles