Comment utiliser : Générateur .env.example
- Collez votre
.env(il ne quitte jamais le navigateur), ou passez sur Depuis le code source et collez votre code. - Les secrets comme les clés, tokens, mots de passe et chaînes de connexion sont vidés ; les valeurs sûres comme
PORT=3000sont conservées. - Vérifiez le résumé de ce qui a été supprimé, conservé et signalé.
- Copiez ou téléchargez le
.env.exampleet versionnez-le.
Pourquoi versionner un .env.example ?
Un fichier .env contient des secrets et ne doit jamais être versionné. Pourtant, les nouveaux membres de l'équipe, la CI et les plateformes de déploiement doivent savoir quelles variables existent. Un .env.example (aussi appelé .env.sample ou .env.template) liste chaque clé avec des valeurs fictives et des commentaires, afin que chacun puisse le copier en .env et renseigner ses propres valeurs.
Comment les secrets sont détectés
- Noms de clés contenant SECRET, TOKEN, PASSWORD, PASS, PWD, KEY, PRIVATE, CREDENTIAL, AUTH, SALT, DSN ou WEBHOOK.
- Formats de valeurs comme les clés Stripe (
sk_live_…), GitHub (ghp_…), AWS (AKIA…), Slack, OpenAI et Anthropic, les JWT, les clés privées PEM et les URL contenant un mot de passe (postgres://user:pass@…). - Chaînes à forte entropie : les longues valeurs d'apparence aléatoire sont traitées comme des secrets, même si le nom de la clé semble anodin.
Les valeurs par défaut sûres (ports, niveaux de log, NODE_ENV, booléens, URL en localhost) sont conservées pour que l'exemple fonctionne immédiatement. Vérifiez le fichier final avec le validateur de fichier .env, et gardez .env hors de Git avec le générateur .gitignore.
Aussi recherché comme : .env.example, générer fichier env example, modèle env, dotenv example, supprimer secrets fichier env, trouver variables d'environnement dans le code.
Outils complémentaires : Générateur .env.example
- Générateur Dockerfile — Choisissez votre stack et obtenez un Dockerfile prêt pour la production : build multi-étapes, couche de dépendances en cache, utilisateur non-root, health check et .dockerignore assorti, le tout expliqué ligne par ligne.
- Générateur Docker Compose — Cochez les services dont vous avez besoin — application, base de données, cache, interface d'administration, gestionnaire de messagerie — et obtenez un fichier compose.yaml épuré comprenant des images épinglées, des volumes nommés, des contrôles d'intégrité et depends_on conditions, ainsi qu’un fichier .env correspondant contenant des mots de passe générés.
- Validateur GitHub Actions — Collez un workflow issu de .github/workflows et repérez les problèmes avant la CI : déclencheurs invalides, runs-on manquant, needs incorrect, expressions erronées, actions obsolètes et risques d’injection de script.
- Validateur YAML — Collez un fichier Docker Compose, un manifeste Kubernetes, un workflow GitHub Actions ou tout autre YAML pour localiser les erreurs, repérer les pièges courants et obtenir une version proprement formatée.
Questions fréquentes
Mon fichier .env est-il envoyé quelque part ?
Quels langages l'analyse de code prend-elle en charge ?
process.env.X, process.env["X"], import.meta.env.X, Deno.env.get), Python (os.environ, os.getenv), Go (os.Getenv), Ruby (ENV["X"]), PHP (getenv, $_ENV), Rust (env::var), Java (System.getenv), C# et les références ${VAR} de Docker Compose.À quoi servent les indications de type ?
# number, # boolean ou # url, déduits de la valeur d'origine, afin que la personne qui complète le fichier sache quel format attendre.