Cacher les secrets avec les variables d'environnement
Garder les clés API et les mots de passe hors du code
⏱ Estim. ~7 min
01 · Lire
L'erreur qui coûte des millions aux entreprises : commiter des clés API et des mots de passe directement dans le code source.
Une fois qu'un secret entre dans l'historique git, il y reste pour toujours. Même si tu le supprimes au commit suivant, n'importe qui clone le repo peut le retrouver dans l'historique. Des bots scannent activement GitHub à la recherche de clés commitées par erreur et les exploitent en quelques minutes.
La solution est simple : les variables d'environnement. Au lieu d'écrire les secrets dans le code, tu les stockes dans un fichier .env qui n'est jamais commité. Ton programme lit les valeurs à l'exécution, et tes secrets restent en sécurité.
💡 Imagine çaPense aux variables d'environnement comme à un coffre-fort de bureau. Tu ne colles pas ton mot de passe à l'écran (c'est ça, écrire en dur dans le code). Tu l'enfermes dans le coffre (le fichier .env) et tu le sors quand tu en as besoin. Et bien sûr tu ne photocopies pas le contenu du coffre pour le distribuer à tout le monde (commiter dans git).
02 · Lire
Tu hérites d'une app Node.js avec un sérieux problème : les secrets sont écrits en dur dans le code source. On va les trouver, puis corriger la configuration pour stocker les secrets en sécurité.
03 · Pratique terminal
Cherche d'abord les secrets en dur dans le code. Utilise grep pour chercher tout ce qui ressemble à une clé API ou un mot de passe.
(Cette section est interactive — active JavaScript pour l'utiliser.)
04 · Pratique terminal
Maintenant, crée un fichier .env pour stocker les secrets en sécurité. C'est là que vont les vraies valeurs, et on s'assurera qu'il n'est jamais commité dans git.
(Cette section est interactive — active JavaScript pour l'utiliser.)
05 · Pratique terminal
L'étape la plus critique : ajouter .env à .gitignore pour qu'il ne soit jamais commité. Sans ça, git add . mettra tes secrets dans le prochain commit.
(Cette section est interactive — active JavaScript pour l'utiliser.)
06 · Exemple de code
Voici à quoi ressemble le app.js corrigé. Au lieu de valeurs en dur, il lit depuis process.env après avoir chargé .env.
app.js — avec variables d'env (corrigé)
require('dotenv').config();
const express = require('express');
const app = express();
// Secrets come from .env, not hardcoded
const API_KEY = process.env.API_KEY;
const DB_PASSWORD = process.env.DB_PASSWORD;
const PORT = process.env.PORT || 3000;
console.log('API key loaded:', API_KEY ? 'Yes' : 'No');
// NEVER log the actual key value!
process.env lit depuis le fichier .env après le chargement par dotenv. Le || 3000 fournit une valeur par défaut si PORT n'est pas défini — un pattern courant pour que ton app fonctionne même sans .env.
07 · Quiz
Pourquoi ne jamais commiter un fichier .env dans git ?
- Il contient des secrets qui seraient exposés à quiconque clone le repo
- Ça rend le repo trop gros
- Git ne prend pas en charge les fichiers .env
- Les fichiers .env ne fonctionnent que sur ta machine locale
08 · Compléter
En Node.js avec dotenv, on accède à une variable d'environnement nommée API_KEY avec process._____.API_KEY.
09 · Liste de vérification
Checklist de sécurité des variables d'environnement. Ces trois étapes doivent devenir un réflexe sur chaque projet.
- .env est listé dans .gitignore
- Je ne logge jamais les vraies valeurs de secrets
- J'ai créé un .env.example avec des valeurs placeholder
Autres leçons de ce chapitre
⚠ L'expérience interactive complète nécessite JavaScript. Active-le et recharge la page.
※ Ce site est un projet éducatif indépendant — pas un produit officiel d'Anthropic. Claude™ est une marque déposée d'Anthropic, PBC.