Fichier .env : 5 règles essentielles pour garder ses secrets hors de Git

Le fichier .env est devenu un standard dans presque tous les projets web modernes. Laravel, Symfony, Next.js, Django, Docker Compose : tous l’utilisent ou le reconnaissent. Son principe est simple : regrouper dans un fichier texte, à la racine du projet, toutes les valeurs qui changent d’un environnement à l’autre ou qui doivent rester secrètes, et ne jamais l’envoyer dans Git.

Ce dernier point est le plus important, et c’est celui que l’on oublie le plus souvent. Chaque jour, des milliers de mots de passe, clés d’API et jetons d’accès se retrouvent publiés par erreur dans des dépôts publics. Des robots parcourent GitHub en permanence pour les récupérer. Ce guide t’explique comment utiliser un fichier .env proprement, dans les trois langages les plus courants, et comment réagir si un secret a déjà fuité.

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

Un fichier .env est un simple fichier texte qui contient des variables d’environnement, une par ligne, sous la forme NOM=valeur. Au démarrage, ton application lit ce fichier et rend ces valeurs disponibles dans le code, sans qu’elles soient écrites en dur dans tes sources.

# .env : configuration locale, JAMAIS versionnée
APP_ENV=local
APP_DEBUG=true

DB_HOST=127.0.0.1
DB_NAME=boutique
DB_USER=root
DB_PASSWORD=MotDePasseLocal!2026

STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxx
MAIL_PASSWORD=xxxxxxxxxxxxxxxx

Ce fichier répond à deux besoins différents :

• La configuration par environnement : ta base locale, celle de préproduction et celle de production n’ont pas les mêmes identifiants. Le code reste identique, seul le fichier .env change.
• La protection des secrets : mots de passe, clés d’API, jetons. Ils ne doivent apparaître ni dans le code, ni dans l’historique Git.

Ce principe vient de la méthode Twelve-Factor App, qui recommande de stocker la configuration dans l’environnement plutôt que dans le code. Le fichier .env est simplement la façon la plus pratique de remplir cet environnement pendant le développement.

Pourquoi tes secrets ne doivent jamais aller dans Git

Un dépôt Git garde tout l’historique. Un mot de passe ajouté puis supprimé dans le commit suivant reste lisible dans l’historique, pour toujours, par toute personne qui a accès au dépôt. Sur un dépôt public, cela veut dire : par n’importe qui sur Internet.

Situation	Risque
—	—
Clé d’API d’un service de paiement publiée	Transactions frauduleuses, remboursements, accès aux données clients
Clé d’un fournisseur cloud publiée	Serveurs lancés pour miner des cryptomonnaies, facture de plusieurs milliers d’euros
Mot de passe de base de données publié	Vol ou suppression des données si la base est accessible depuis Internet
Jeton d’accès GitHub publié	Modification de ton code, injection de code malveillant dans tes projets

Les plateformes ont réagi : GitHub analyse les dépôts publics à la recherche de secrets connus et bloque désormais de nombreux envois contenant des clés détectées. Mais ces protections ne reconnaissent pas tout, en particulier tes mots de passe maison. La seule vraie protection, c’est de ne jamais laisser un secret entrer dans Git.

Mettre en place un fichier .env proprement

La mise en place tient en trois fichiers. Fais-la avant le premier commit du projet : c’est le moment où l’erreur est la plus fréquente.

# 1. Ignorer le fichier .env (et ses variantes locales)
echo ".env" >> .gitignore
echo ".env.local" >> .gitignore
echo ".env.*.local" >> .gitignore

# 2. Vérifier que Git l'ignore bien
git check-ignore -v .env
# .gitignore:1:.env    .env

Le troisième fichier est le .env.example : une copie du fichier .env avec les mêmes clés, mais sans les valeurs sensibles. Lui, tu le versionnes. Il sert de documentation : un nouveau développeur sait immédiatement quelles variables configurer.

# .env.example : versionné, sans aucun secret
APP_ENV=local
APP_DEBUG=true

DB_HOST=127.0.0.1
DB_NAME=boutique
DB_USER=
DB_PASSWORD=

STRIPE_SECRET_KEY=
MAIL_PASSWORD=

Pour démarrer sur un projet existant, il suffit alors de copier ce modèle :

cp .env.example .env      # Linux, macOS, Git Bash
copy .env.example .env    # Invite de commandes Windows

Utiliser un fichier .env en PHP

En PHP, la bibliothèque de référence est vlucas/phpdotenv, utilisée notamment par Laravel. Installe-la avec Composer :

composer require vlucas/phpdotenv

<?php
// config.php
require __DIR__ . '/vendor/autoload.php';

$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

// Rendre certaines variables obligatoires
$dotenv->required(['DB_HOST', 'DB_NAME', 'DB_USER', 'DB_PASSWORD']);

$pdo = new PDO(
    sprintf('mysql:host=%s;dbname=%s;charset=utf8mb4', $_ENV['DB_HOST'], $_ENV['DB_NAME']),
    $_ENV['DB_USER'],
    $_ENV['DB_PASSWORD'],
    [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
);

La méthode required() fait échouer le démarrage avec un message clair si une variable manque, au lieu d’une erreur de connexion obscure plus loin dans le code. Si tu utilises Laravel, le fichier .env est déjà en place et se lit avec env('DB_PASSWORD') dans les fichiers de configuration. Avec Symfony, le fichier .env versionné contient les valeurs par défaut, et tes secrets locaux vont dans .env.local, ignoré par Git.

Utiliser un fichier .env en Node.js

Depuis Node.js 20.6, plus besoin de bibliothèque : Node.js lit un fichier .env nativement avec l’option --env-file.

node --env-file=.env server.js

// server.js
const dbPassword = process.env.DB_PASSWORD;

if (!dbPassword) {
  throw new Error("La variable DB_PASSWORD est manquante dans le fichier .env");
}

Tu peux aussi charger le fichier depuis le code avec process.loadEnvFile(), disponible dans les versions récentes de Node.js. Sur des projets plus anciens, la bibliothèque dotenv reste très répandue :

// Avec la bibliothèque dotenv (npm install dotenv)
import "dotenv/config";

console.log(process.env.APP_ENV);

Utiliser un fichier .env en Python

En Python, la bibliothèque python-dotenv fait le travail. Installe-la dans ton environnement virtuel Python :

pip install python-dotenv

# app.py
import os
from dotenv import load_dotenv

load_dotenv()  # lit le fichier .env du dossier courant

db_password = os.getenv("DB_PASSWORD")
if db_password is None:
    raise RuntimeError("DB_PASSWORD manquant dans le fichier .env")

Avec Docker Compose, tu peux aussi transmettre un fichier .env à un service avec la clé env_file, sans rien changer à ton code. Notre antisèche des commandes Docker rappelle d’ailleurs pourquoi ce fichier ne doit jamais être copié dans une image.

services:
  app:
    image: php:8.4-apache
    env_file:
      - .env

Empêcher le serveur web de servir le fichier .env

Un autre piège, souvent oublié : si ton fichier .env se trouve dans le dossier public de ton site, il peut être téléchargé directement à l’adresse https://ton-site.fr/.env. Des robots testent cette adresse sur des millions de sites chaque jour.

La meilleure solution est structurelle : placer le fichier .env en dehors du dossier public, comme le font Laravel (public/) ou Symfony (public/). Si ce n’est pas possible, bloque son accès au niveau du serveur web.

# .htaccess (Apache) : interdire l'accès aux fichiers commençant par .env
<FilesMatch "^\.env">
    Require all denied
</FilesMatch>

# Nginx : bloquer tous les fichiers cachés, dont .env et .git
location ~ /\. {
    deny all;
}

Après la mise en place, vérifie depuis ton navigateur que l’adresse /.env de ton site renvoie bien une erreur 403 ou 404.

Que faire si un secret a déjà été poussé sur Git ?

C’est la question la plus importante de ce guide, car la réaction instinctive est mauvaise. Supprimer le fichier .env et faire un nouveau commit ne retire pas le secret de l’historique. Et même en réécrivant l’historique, tu ne peux pas savoir si quelqu’un l’a déjà copié.

# 3. Arrêter de suivre le fichier .env sans le supprimer de ton disque
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Ne plus versionner le fichier .env"

# 4. Supprimer le fichier de tout l'historique (outil git-filter-repo)
git filter-repo --path .env --invert-paths
git push --force --all

Pour retrouver les bonnes commandes Git de nettoyage et de vérification, garde notre antisèche Git à portée de main.

Détecter automatiquement les secrets avant le commit

Le meilleur moyen de ne jamais pousser un secret, c’est d’être bloqué avant le commit. Plusieurs outils analysent ton code à la recherche de clés, de mots de passe et de jetons.

Outil	Où il agit	Point fort
—	—	—
gitleaks	Ton poste et ta CI	Rapide, gratuit, nombreux types de secrets reconnus
GitHub secret scanning	Les dépôts GitHub	Blocage des envois contenant des secrets connus
Hook pre-commit	Ton poste	Vérifie chaque commit avant sa création

# Analyser le dépôt et tout son historique avec gitleaks
gitleaks git -v

# Analyser uniquement les fichiers du dossier courant
gitleaks dir .

Intégrer ce type d’outil à ta chaîne d’intégration continue garantit qu’aucun membre de l’équipe ne pousse un secret par mégarde, même un jour de fatigue.

Organiser plusieurs environnements

Un projet sérieux passe par plusieurs environnements : ton poste de développement, un serveur de test ou de préproduction, puis la production. Chacun a sa propre base de données, ses propres clés d’API (souvent des clés « de test » chez les prestataires de paiement), et ses propres réglages de débogage.

Variable	Développement	Préproduction	Production
—	—	—	—
APP_ENV	local	staging	production
APP_DEBUG	true	true ou false	false
DB_HOST	127.0.0.1 ou nom du service Docker	serveur de test	serveur de production
Clés de paiement	clés de test	clés de test	clés réelles
Envoi d’e-mails	capturés par un outil local	adresses de test	envoi réel

Cette séparation a un avantage énorme : une erreur dans ton environnement local ne touche jamais les vraies données, et une clé de test qui fuiterait n’aurait aucune conséquence financière. Garde toujours des valeurs différentes dans chaque environnement, même si c’est plus pratique de réutiliser le même mot de passe partout.

Dernier conseil d’organisation : nomme tes variables de façon explicite et regroupe-les par service, avec un préfixe commun (DB_, MAIL_, STRIPE_). Ton fichier de configuration reste lisible même avec cinquante variables, et le modèle versionné devient une véritable documentation de ton application.

Fichier .env en production

En production, le fichier .env n’est pas toujours la meilleure solution. Les hébergeurs et plateformes modernes proposent souvent de définir les variables d’environnement directement dans leur interface (panneau d’hébergement, réglages du projet, secrets du serveur d’intégration continue). Les valeurs sont alors injectées au démarrage, sans fichier sur le disque.

Si tu utilises quand même un fichier .env sur ton serveur, applique ces règles :

• Des droits de lecture restreints : seul l’utilisateur qui exécute l’application doit pouvoir le lire (chmod 600 .env).
• Des valeurs propres à la production : jamais les mêmes mots de passe qu’en local ou en préproduction.
• Le débogage désactivé : APP_DEBUG=false, pour ne jamais afficher de configuration dans un message d’erreur.
• Une sauvegarde chiffrée des secrets, en dehors du serveur, dans un gestionnaire de mots de passe d’équipe.

FAQ

Le fichier .env est-il sécurisé ?

Le fichier .env n’est pas chiffré : c’est un simple fichier texte. Sa sécurité repose sur trois conditions : ne jamais être versionné dans Git, ne pas être accessible depuis le web, et n’être lisible que par l’application sur le serveur.

Faut-il versionner le fichier .env.example ?

Oui. Le fichier .env.example liste toutes les variables nécessaires, avec des valeurs vides ou fictives. Il sert de documentation et permet à chaque développeur de créer son propre fichier .env en quelques secondes.

J’ai supprimé le fichier .env dans un nouveau commit, est-ce suffisant ?

Non. Le fichier reste lisible dans l’historique Git. Révoque immédiatement chaque secret qu’il contenait, puis nettoie l’historique avec git filter-repo si nécessaire. La révocation est la seule mesure vraiment efficace.

Peut-on avoir plusieurs fichiers .env ?

Oui, c’est même courant : .env pour les valeurs par défaut, .env.local pour les surcharges locales, .env.test pour les tests. Chaque framework a ses conventions, mais la règle reste la même : tout fichier contenant de vrais secrets est ignoré par Git.

Ces cinq règles se résument en une habitude : à chaque nouveau projet, crée le fichier .env, le modèle .env.example et la ligne du .gitignore avant même d’écrire la première ligne de code. C’est le moment où la mise en place prend trente secondes, et où l’oubli est le plus fréquent. Beaucoup de fuites de secrets viennent d’un premier commit fait à la hâte, avec un « git add . » qui embarque tout le dossier.

Dans une équipe, ajoute une étape de vérification à la revue de code : aucun mot de passe, aucune clé d’API, aucune URL de base de données avec identifiants ne doit apparaître dans le code proposé. Un outil comme gitleaks, lancé automatiquement dans la chaîne d’intégration continue, fait ce contrôle à ta place et bloque la fusion si un secret est détecté.

Enfin, prévois un endroit sûr pour partager les vraies valeurs entre collègues : un gestionnaire de mots de passe d’équipe, jamais un e-mail, une messagerie instantanée ou un document partagé. Les secrets d’un fichier .env sont aussi sensibles que les clés de tes locaux : ils méritent le même soin, à chaque étape de leur vie.

Et si tu reprends un ancien projet, commence par vérifier son historique Git avec gitleaks : tu découvriras peut-être un secret oublié depuis longtemps. Mieux vaut le trouver toi-même, le révoquer et le remplacer, que de laisser quelqu’un d’autre le découvrir à ta place.

La sécurité de tes secrets ne dépend pas d’un outil miracle, mais de ces quelques réflexes répétés à chaque projet, sans exception, même pour un petit prototype personnel.

Prends cinq minutes aujourd’hui pour vérifier tes projets existants : ce sont souvent eux qui cachent les surprises.

Fichier .env : le résumé à retenir

• Le fichier .env regroupe la configuration et les secrets, séparés du code.
• Ajoute .env au .gitignore avant le premier commit, et versionne un .env.example sans secret.
• PHP utilise vlucas/phpdotenv, Node.js lit le fichier .env nativement avec --env-file, Python utilise python-dotenv.
• Le fichier .env ne doit jamais être accessible depuis le web ni copié dans une image Docker.
• Un secret poussé sur Git est compromis : révoque-le d’abord, nettoie ensuite.

Mettre en place un fichier .env prend cinq minutes au début d’un projet. Réparer une fuite de secret peut prendre des jours, et coûter très cher.

Conclusion

Le fichier .env est l’un de ces petits réflexes qui distinguent un projet amateur d’un projet professionnel. Il protège tes secrets, simplifie le passage d’un environnement à l’autre et facilite l’arrivée de nouveaux développeurs. Prends l’habitude de le mettre en place dès la création de chaque projet, puis complète cette bonne pratique avec nos guides pour sécuriser un formulaire PHP et stocker les mots de passe avec password_hash().

Sources

• The Twelve-Factor App : la configuration
• vlucas/phpdotenv sur GitHub
• Documentation Node.js : option –env-file
• python-dotenv sur PyPI
• Documentation GitHub : secret scanning
• gitleaks sur GitHub