Gestion du fichier .env : protéger ses secrets

Un fichier env est le moyen le plus courant de stocker les secrets dont votre projet a besoin pour fonctionner mais qui ne doivent jamais entrer dans le dépôt de code : clés API, mots de passe de base de données, jetons. L'idée est simple : on sépare la configuration du code. La même base de code s'exécute avec des valeurs différentes sur votre machine de développement, dans un environnement de test et sur le serveur de production ; la seule chose qui change est le fichier .env de cet environnement. Dans cet article, je présente les règles pratiques pour gérer les fichiers .env en toute sécurité, les erreurs les plus fréquentes et la marche à suivre lorsqu'un secret fuit.

Pourquoi utiliser un fichier .env ?

Écrire des secrets directement dans le code source (hardcoding) est l'une des failles de sécurité les plus répandues. Dès que vous intégrez une clé API dans config.php et que vous la poussez sur Git, cette clé est gravée dans tout l'historique du dépôt ; même après l'avoir supprimée, elle reste dans le journal des commits. Un fichier .env résout ce problème en gardant les données secrètes totalement en dehors du contrôle de version.

• Séparation : le code peut être public, les secrets non.
• Valeurs par environnement : local, staging et production se connectent à des bases de données et des clés différentes.
• Rotation facile : changer une clé revient à modifier une seule ligne, sans aucun déploiement de code.

La structure d'un fichier .env

Le format est une simple liste CLÉ=valeur ; chaque ligne est une variable. La plupart des bibliothèques acceptent les lignes de commentaire commençant par #.

# Application
APP_ENV=production
APP_DEBUG=false

# Base de données
DB_HOST=127.0.0.1
DB_DATABASE=portfolio
DB_USERNAME=app_user
DB_PASSWORD=un-mot-de-passe-tres-secret

# Services tiers
STRIPE_SECRET=sk_live_xxx
MAIL_PASSWORD="une valeur avec des espaces a besoin de guillemets"

Quelques points pratiques : si une valeur contient des espaces ou des caractères spéciaux, mettez-la entre guillemets doubles ; ne placez pas d'espaces superflus autour du signe égal ; et les valeurs sont toujours lues comme une chaîne de caractères. Autrement dit, APP_DEBUG=false est en réalité le texte "false", et non le booléen false de votre langage. Le convertir dans le bon type vous incombe ; par exemple, l'assistant env() de Laravel convertit automatiquement des valeurs comme true/false/null, alors qu'un simple getenv() ne le fait pas.

La règle la plus importante : le .env n'entre jamais dans Git

Committer un fichier .env par accident est la première cause de fuite de secrets. Pour l'éviter, ajoutez une ligne à un .gitignore à la racine du projet :

# .gitignore
.env
.env.*
!.env.example

La ligne !.env.example exempte de la liste noire le fichier d'exemple (que j'explique juste après). Si vous avez déjà committé le fichier par erreur, l'ajouter au .gitignore ne suffit pas — Git le suit déjà. Pour arrêter de le suivre :

git rm --cached .env
git commit -m "stop tracking .env"

Gardez à l'esprit que cette commande n'efface pas le fichier de l'historique, elle cesse seulement de le suivre dans les futurs commits. Si le secret est réellement entré dans un historique public, voyez la section sur les fuites ci-dessous.

Garder l'équipe synchronisée avec .env.example

Puisque le vrai .env n'est pas dans le dépôt, comment un nouveau développeur qui clone le projet saura-t-il quelles variables sont nécessaires ? La réponse est le fichier .env.example (parfois .env.sample) : il contient les mêmes clés mais les valeurs sont vides ou factices. Ce fichier, lui, entre dans le dépôt et fait office de documentation.

# .env.example
APP_ENV=local
APP_DEBUG=true
DB_HOST=127.0.0.1
DB_DATABASE=
DB_USERNAME=
DB_PASSWORD=
STRIPE_SECRET=

L'étape d'installation est en général simple : copiez le fichier avec cp .env.example .env, puis renseignez les vraies valeurs. Prenez l'habitude de mettre à jour le fichier d'exemple chaque fois que vous ajoutez une variable ; sinon, l'installation d'un coéquipier échouera sur une clé manquante qu'il cherchera pendant des heures en se demandant « pourquoi ça ne marche pas ? ».

Usage sécurisé sur les serveurs et en CI/CD

Sur les serveurs de production, restreignez les permissions du fichier .env pour que seul l'utilisateur qui exécute l'application puisse le lire :

chmod 600 .env

Sur un hébergement mutualisé ou un VPS, assurez-vous que le fichier se trouve en dehors de la racine web (par exemple public/) ; sinon, un serveur mal configuré pourrait le servir en texte clair. Dans les pipelines CI/CD (GitHub Actions, GitLab CI), au lieu de placer un fichier .env dans le dépôt, utilisez la fonctionnalité secrets / variables d'environnement de la plateforme. Ces secrets sont stockés chiffrés, masqués dans les logs et injectés comme variables d'environnement uniquement pendant l'exécution du pipeline. Sur de plus grosses infrastructures, des gestionnaires de secrets dédiés comme HashiCorp Vault, AWS Secrets Manager ou Doppler entrent en jeu.

• Ne faites jamais d'echo de secrets dans les logs du pipeline.
• Ne distribuez pas les secrets de production sur les machines locales des développeurs ; utilisez des clés distinctes et moins privilégiées.
• Faites tourner (rotate) les clés à intervalles réguliers.

Que faire si un secret fuit ?

Supposons qu'une clé API se retrouve par accident dans un commit public. La première et plus importante étape n'est pas de nettoyer le fichier de l'historique — c'est de révoquer immédiatement la clé et d'en générer une nouvelle. Un secret divulgué peut survivre dans des clones et des caches que d'autres ont copiés, même après que vous l'avez retiré de l'historique ; la seule hypothèse sûre est qu'il doit désormais être considéré comme invalide.

Une fois la clé renouvelée, vous pouvez nettoyer l'historique avec git filter-repo (l'outil moderne recommandé par Git) ou le BFG Repo-Cleaner. Ensuite, un force-push est nécessaire et toute l'équipe doit recloner le dépôt. Pour éviter de tels accidents à l'avenir, vous pouvez ajouter des outils comme git-secrets ou gitleaks en tant que hook pre-commit ; ils détectent les motifs de secrets au moment du commit et vous avertissent.

Questions fréquentes

Dois-je chiffrer mon fichier .env ?

Pour le développement local, ce n'est généralement pas nécessaire ; les permissions de fichier et le .gitignore suffisent. Mais si vous devez partager des secrets dans le dépôt, la commande intégrée php artisan env:encrypt de Laravel, ou des outils comme git-crypt et sops, vous permettent de stocker un .env chiffré. La clé de déchiffrement doit malgré tout rester dans un endroit sûr.

Quelle est la différence entre .env et les vraies variables d'environnement ?

Le fichier .env est une commodité : il imite les variables d'environnement du système d'exploitation à partir d'un fichier. En production, de nombreuses plateformes préfèrent définir les variables directement au niveau système (panneau du serveur, environnement du conteneur, service de secrets) ; dans ce cas, vous n'avez plus du tout besoin d'un fichier .env, ce qui réduit encore le risque de fuite.

Puis-je conserver des fichiers distincts pour plusieurs environnements ?

Oui, c'est un modèle courant : .env.local, .env.staging, .env.production, etc. Le framework ou un outil (comme Vite, Next.js ou Laravel) choisit lequel charger selon l'environnement. N'oubliez pas pour autant d'ajouter au .gitignore toutes les variantes contenant de vraies valeurs.

Vos secrets sont-ils en sécurité ? Si vous avez besoin d'aide pour la gestion de configuration, le déploiement ou l'installation sécurisée d'un projet, contactez-moi — construisons ensemble des fondations solides.