Pré-vérification de portabilité .env
Collez le contenu d'un fichier .env pour repérer les valeurs interprétées différemment — ou qui échouent — avec le paquet dotenv de Node, Docker/Docker Compose et un shell POSIX chargeant directement le même fichier. Tout s'exécute dans votre navigateur : rien n'est téléversé, journalisé ni envoyé, ce qui importe car un vrai fichier .env contient souvent des secrets.
Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.
Comment utiliser cet outil outil
- Collez le contenu du fichier .env (ou un extrait représentatif) ; l'analyse se fait dans le navigateur, vos vrais secrets ne quittent donc pas la page.
- Sélectionnez « Vérifier le fichier .env ».
- Examinez chaque ligne signalée : ambiguïté ou risque, et divergences entre dotenv, Docker Compose et shell POSIX.
- Appliquez la réécriture proposée lorsqu'elle existe. Les guillemets non terminés, clés en double, références d'interpolation et noms de clés invalides sont laissés à résoudre manuellement, car une supposition erronée serait pire que l'absence de supposition.
Hypothèses
- Attend une affectation KEY=value par ligne, des commentaires préfixés par `#` et des lignes vides : forme .env conventionnelle de dotenv, env_file Docker Compose et chargement shell POSIX.
- Une valeur est considérée comme citée uniquement si elle commence et se termine par une paire concordante de guillemets simples ou doubles ; un guillemet isolé est précisément un cas de guillemet non terminé.
- Ne devine jamais le sens d'une clé dupliquée, référence d'interpolation ou clé invalide ; ces cas sont signalés sans résolution silencieuse.
Sources et données de référence
Méthodologie
Chaque ligne est séparée en clé, valeur brute et indicateur de citation, puis comparée aux divergences documentées de dotenv, Docker/Docker Compose et du shell POSIX : espaces et `#` non cités, préfixe `export` (accepté, supprimé ou rejeté), guillemets non terminés, interpolation `$VAR`/`${VAR}` (développée par le shell/Compose mais littérale dans dotenv sauf dotenv-expand), clés dupliquées (dernière occurrence conservée), espaces finaux (conservés par dotenv, supprimés par une exportation shell) et noms invalides comme identifiants shell POSIX. Une réécriture n'est proposée que pour les cas réellement sûrs : citer une valeur, retirer les espaces finaux ou le préfixe export ; aucune intention n'est devinée.
Exemple détaillé
Valeur qui référence une autre variable
Données d’entrée: API_URL=${BASE_URL}/api
Résultat: Par défaut, dotenv ne développe PAS `${BASE_URL}` : le texte littéral reste dans API_URL sauf si le paquet séparé dotenv-expand est utilisé. En revanche, un shell POSIX chargeant le fichier et Docker Compose le développent. Avertissement sans réécriture, car l'intention ne peut pas être déduite du fichier seul.
Préfixe export
Données d’entrée: export APP_NAME=My Example App
Résultat: Syntaxe shell POSIX valide, mais dotenv et Docker Compose divergent sur `export` : certains le rejettent, d'autres l'intègrent au nom de clé. Avertissement avec suppression sûre du préfixe, car dotenv, consommateur courant, attend la forme simple. L'espace non cité dans la valeur est signalé séparément comme problème plus grave.
Clé en double
Données d’entrée: TIMEOUT=30 TIMEOUT=60
Résultat: La plupart des analyseurs, y compris dotenv, ne conservent silencieusement que la dernière occurrence : TIMEOUT=30 est abandonnée. Avertissement sur la seconde occurrence, avec référence à la ligne remplacée.
Conseils pratiques
- Mettez entre guillemets toute valeur contenant un espace ou `#`, même si dotenv seul l'accepterait sans guillemets : cela rend le fichier compatible avec un shell qui le charge directement ou Docker Compose.
- Évitez les références $VAR / ${VAR} dans les fichiers .env sans avoir confirmé que tous leurs consommateurs les développent de la même façon : c'est une cause fréquente de problèmes de portabilité.
- Ne comptez pas sur le préfixe `export` avec les outils dotenv ; utilisez KEY=value sans préfixe et un script shell enveloppe si le chargement direct est aussi nécessaire.
Erreurs fréquentes
- Supposer qu'une valeur qui « fonctionne » au démarrage est portable : espace non cité, interpolation non développée ou clé dupliquée remplacée peuvent se charger tout en donnant une mauvaise valeur.
- Traiter les noms de clés .env comme des étiquettes libres : dotenv accepte parfois les tirets ou chiffres initiaux, mais le fichier échoue lorsqu'il est chargé par un vrai shell.
Questions fréquentes
Est-il sûr de coller ici de vrais secrets ?
L'analyse s'exécute dans votre navigateur : rien de ce que vous collez n'est téléversé, journalisé ou transmis, et cette page n'ajoute ni analytique ni télémétrie. Malgré cela, appliquez le même discernement qu'à tout outil : utilisez un marqueur de même forme (longueur et caractères spéciaux) si vous ne souhaitez pas coller une valeur réelle. Ces vérifications portent sur la syntaxe, pas sur le sens de la valeur.
Pourquoi un espace interne sans guillemets est-il une erreur, mais un espace final seulement une information ?
Un espace interne non cité casse l'affectation dans un shell POSIX ou un analyseur Docker Compose strict : c'est un échec fonctionnel. Un espace final risque seulement d'ajouter un caractère inattendu à la lecture dotenv ; c'est gênant mais rarement fatal et il peut être supprimé sûrement.
Pourquoi l'outil ne corrige-t-il pas une clé en double ou invalide ?
Il faudrait décider ce que vous vouliez : quelle valeur dupliquée garder ou quel nom de clé corrigé choisir. Modifier silencieusement le fichier en devinant serait pire que signaler le problème.
Pourquoi `${BASE_URL}` est-il développé par Compose mais reste-t-il littéral dans Node dotenv ?
Docker Compose effectue l'interpolation dans sa configuration, tandis que le paquet `dotenv` ne développe pas les références par défaut ; Node nécessite généralement un paquet supplémentaire tel que dotenv-expand. Le comportement précis dépend du fichier et du consommateur. Cette pré-vérification signale le risque de portabilité syntaxique ; elle n'exécute ni Compose ni dotenv.
Dernière vérification : 2026-09-25
Vérificateur de forme syntaxique, pas analyseur complet de shell ou Docker Compose : reconnaît la forme conventionnelle KEY=value/commentaire/ligne vide et les divergences citées, pas tous les cas limites des implémentations réelles. Ne peut pas connaître l'intention dans un cas ambigu (guillemet non terminé, interpolation, clé dupliquée) et signale l'ambiguïté sans la résoudre.
Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.