Variables d'environnement et fichiers .env

Les variables d'environnement portent la configuration qui change d'une machine à l'autre : mots de passe, adresses de base, clés d'API. Le piège est qu'elles n'existent que là où on les a définies — et rarement là où on croit.

Pour votre session seulement

export MA_CLE="valeur"     # disparaît à la déconnexion
echo $MA_CLE
printenv | sort | head        # tout ce qui est défini

Pour un service systemd

C'est ici que se joue la moitié des « ça marche quand je le lance à la main, pas en service ». systemd ne lit ni votre .bashrc, ni le .env de votre application : il faut le lui dire.

# Une par une
Environment=NODE_ENV=production
Environment=PORT=3000

# Ou depuis un fichier
EnvironmentFile=/etc/mon-appli.env

systemctl show mon-appli --property=Environment
sudo cat /proc/$(pgrep -f mon-appli | head -1)/environ | tr '\0' '\n'

Ne pas publier ses secrets

• Le fichier .env ne doit jamais être versionné : ajoutez-le à .gitignore dès le premier commit.
• Il ne doit pas être servi par le serveur web — la règle nginx qui refuse tout ce qui commence par un point y pourvoit.
• Ses droits sont 600, propriétaire l'utilisateur du service : chmod 600 .env.
• Un secret qui a fuité doit être changé, pas caché. Le retirer d'un dépôt Git ne l'efface pas de l'historique.

curl -I https://monsite.fr/.env

Une réponse 200 signifie que n'importe qui peut télécharger vos identifiants. Ça doit être 403 ou 404.