Le fichier .env montre ses limites : quelles alternatives pour vos secrets ?

Le 30 juillet 2026, Domen Kožar, à l'origine du projet SecretSpec, publie un billet qui dit tout haut ce que beaucoup de développeurs pensent tout bas : le fichier .env n'a jamais été conçu pour faire ce qu'on lui demande aujourd'hui. Son article, « Where .env Went Wrong », retrace comment un simple raccourci pour éviter trois commandes export s'est transformé, projet après projet, en schéma de configuration, en coffre-fort de secrets, en modèle d'environnements et en interface de déploiement.

Le constat mérite qu'on s'y arrête : il touche à peu près tous les projets web que nous croisons chez CZSyn. Voici ce qui coince concrètement, avec les exemples cités par la source, et ce qu'on recommande pour vos propres projets.

Le .env, un raccourci devenu architecture

Une variable d'environnement fait un métier précis : livrer une chaîne de caractères à un processus qui s'exécute. Que la valeur de DATABASE_URL vienne d'un développeur, d'une CI ou d'un gestionnaire de secrets ne change rien pour l'application qui la lit. Le fichier .env rend cette livraison facile à sauvegarder et à recharger. Le problème commence quand ce fichier se met aussi à décrire ce dont l'application a besoin : cette valeur est-elle obligatoire, est-ce un secret, peut-elle être commitée, est-elle réservée à la production. Une simple paire KEY=value ne répond à aucune de ces questions.

Une chaîne de caractères n'est pas un schéma

Prenez un .env.example typique cité par SecretSpec :

DATABASE_URL=
REDIS_URL=redis://localhost:6379
STRIPE_API_KEY=
DEBUG=false

Une valeur vide signifie-t-elle qu'elle est obligatoire ou juste absente en local. REDIS_URL est-elle une valeur de développement par défaut. STRIPE_API_KEY est-elle réservée à la production. DEBUG est-il vraiment un booléen. Node.js documente que toute valeur chargée devient une chaîne de caractères, et une issue ouverte en 2015 sur dotenv reçoit encore des réactions de développeurs surpris que la chaîne « false » soit, au sens booléen de JavaScript, une valeur vraie. Ces réponses manquantes finissent dans du code de validation, un README, ou la mémoire d'un collègue, et elles finissent par diverger. Le fichier traite aussi DEBUG et STRIPE_API_KEY de la même façon, alors que l'un est un réglage ordinaire qui peut vivre dans Git, et l'autre donne un accès qu'il faut restreindre.

Un seul fichier qui finit par se multiplier

Chaque nouveau besoin d'environnement finit par créer un nouveau fichier : .env, .env.local, .env.development, .env.test, .env.production. Les suffixes deviennent un modèle d'environnements, l'ordre de chargement devient une hiérarchie d'héritage, et copier un fichier devient une méthode de déploiement. SecretSpec rappelle que cette pratique va à l'encontre des principes du Twelve-Factor App, pour qui les variables d'environnement doivent rester des réglages indépendants, car des environnements nommés deviennent fragiles à mesure que les déploiements se multiplient. Chaque nouvelle valeur doit être ajoutée au fichier d'exemple, documentée dans un README, validée dans le code, puis recopiée dans les bons fichiers réels. Il suffit d'en oublier un pour que les environnements divergent.

Il n'existe pas de norme .env

Le format .env a l'air standardisé. Il ne l'est pas. Node.js et python-dotenv documentent eux-mêmes l'absence de spécification formelle. Chaque implémentation fait ses propres choix d'expansion de variables, de commentaires et de guillemets : Node dotenv délègue l'expansion à un autre outil, Docker Compose gère ses propres opérateurs shell, et Vite accepte des références dans un ordre qui ne fonctionnera ni dans un shell ni dans Docker Compose. Node dotenv a même changé, en version 15, le sens du caractère dièse dans une valeur non protégée par des guillemets : un changement cassant assumé comme tel.

La précédence, un problème à part entière

Les parseurs ne s'accordent pas non plus sur la valeur qui l'emporte en cas de doublon. Node dotenv laisse gagner le premier fichier chargé, Docker Compose laisse gagner le dernier fichier déclaré en env_file, avant de laisser la section environment le surclasser, et Vite donne la priorité à une variable déjà présente dans le processus plutôt qu'à ses propres fichiers. Ajoutez le moment où l'import a lieu : une variable VITE_* remplacée au moment du build finit dans le bundle envoyé au navigateur, alors qu'une variable lue à l'exécution reste côté serveur. Le fichier .env se comporte alors comme un petit programme, avec un flux de contrôle éclaté entre fichiers, options et ordre d'import.

Un fichier ignoré reste un fichier

Le projet dotenv recommande lui-même de ne jamais committer .env. Un .gitignore évite un accident, mais n'ajoute ni chiffrement, ni contrôle d'accès, ni journalisation, ni révocation. Le fichier peut finir dans une sauvegarde d'éditeur ou le contexte de build d'un conteneur. La source cite le cas d'une intégration devenv qui recopiait le contenu du .env dans le Nix store, un emplacement dont les chemins ne sont pas confidentiels. Quand un développeur quitte l'équipe, il n'y a aucun accès à révoquer. Même un secret rangé dans un gestionnaire de secrets cloud doit, à un moment donné, être recopié en clair pour qu'une application basée sur dotenv puisse s'en servir, et cette copie locale hérite de moins de garanties que l'original. La livraison par variable d'environnement a ses limites elle aussi : Docker monte ses secrets gérés sous forme de fichiers plutôt que de variables, car elles peuvent fuiter entre conteneurs, et un processus reçoit une seule carte globale de variables, si bien qu'un frontend, un worker et un service web reçoivent souvent les mêmes secrets alors que chacun n'en utilise qu'une poignée.

Trois responsabilités à séparer

La proposition de SecretSpec tient en une phrase : séparer ce qui est déclaré, ce qui est stocké et ce qui est distribué. Une déclaration versionnée dans le dépôt dit quels secrets l'application attend, avec leur nom, une description, leur caractère obligatoire et une valeur par défaut sûre. Un stockage protégé (gestionnaire cloud, Vault, trousseau système, ou provider de compatibilité pour garder un .env en local) contrôle qui peut lire les valeurs. Une distribution explicite ne donne à chaque processus que les valeurs dont il a réellement besoin. Concrètement, cela passe par deux commandes :

secretspec check   # valide que les valeurs requises sont disponibles
secretspec run     # resout les secrets et lance l'application

secretspec check valide que toutes les valeurs requises sont disponibles avant de lancer l'application, et secretspec run résout puis injecte ces valeurs dès le démarrage. Les variations entre environnements passent par des profils, de simples surcouches partielles au-dessus d'un profil par défaut, plutôt que par des fichiers complets recopiés à chaque fois.

Ce que ça change pour vos projets

Vous n'avez pas besoin d'adopter SecretSpec pour tirer profit de ce découpage. Documentez, à côté du code, quelles variables sont obligatoires, secrètes ou propres à un environnement, plutôt que de laisser un fichier d'exemple incomplet faire office de documentation. Validez ces exigences au démarrage plutôt qu'au moment où le code tente d'utiliser une valeur manquante. Limitez la portée de chaque secret au service qui en a réellement besoin, au lieu de distribuer la même carte de variables à tous les composants d'un même projet.

Notre lecture chez CZSyn

Sur les projets que nous accompagnons à Marseille, le .env reste omniprésent : il est simple, universel, et tous les frameworks savent le lire. Ce que montre SecretSpec, c'est qu'il faut arrêter de lui demander plus que ça. La bascule vers un outil déclaratif complet n'est pas toujours prioritaire pour une petite structure, mais la discipline qu'il impose l'est : savoir, sans deviner, quelles variables sont obligatoires, lesquelles sont sensibles, et à quel service chacune appartient. C'est souvent ce détail, plus qu'un choix d'outil, qui évite la fuite de clé API dans un dépôt public ou l'incident du lundi matin parce qu'une variable a été oubliée dans le mauvais fichier.

Notre conseil : gardez .env pour les réglages locaux non sensibles, et faites passer vos vrais secrets par un gestionnaire dédié avec un contrôle d'accès réel, que ce soit SecretSpec, Vault, ou votre hébergeur cloud.

Sources primaires

• SecretSpec, « Where .env Went Wrong », 30 juillet 2026.
• SecretSpec, documentation officielle.
• The Twelve-Factor App, « Config ».