Analyseur et validateur .env

Collez un fichier .env — ou déposez-le sur la zone — et récupérez-le analysé, vérifié et expliqué : chaque clé dans un tableau avec sa valeur masquée, chaque problème listé avec son numéro de ligne. Clés en double, noms invalides, lignes qui ne sont même pas des affectations, valeurs vides qui écrasent silencieusement les valeurs par défaut. Tout s’exécute dans votre navigateur et le fichier n’est jamais téléversé, parce qu’un .env de production est un paquet de secrets et doit être traité comme tel.

Ce qui est vérifié, et pourquoi

Le format .env est une convention, pas une norme, et c’est pourquoi les fichiers pourrissent en silence. Tous les chargeurs s’accordent sur KEY=VALUE et divergent sur tout le reste : si les préfixes export sont supprimés, si les guillemets sont respectés, si un commentaire en ligne termine une valeur et — le plus dangereux — laquelle de deux définitions d’une même clé l’emporte. Ce validateur applique les règles du plus petit dénominateur commun et signale les endroits où les chargeurs divergent : une clé définie deux fois avec ses deux numéros de ligne, un nom qu’aucun shell n’accepterait, un guillemet qui s’ouvre et ne se ferme jamais, une ligne sans aucun signe égal. Les valeurs vides sont signalées plutôt que rejetées, parce que KEY= est légal — mais il écrase toute valeur par défaut de l’application par une chaîne vide, ce qui est la raison la plus fréquente pour laquelle un service fonctionne sur une machine et pas sur une autre.

La conception de la confidentialité est la fonctionnalité. Un .env de production concentre mots de passe de bases de données, clés d’API et secrets de session dans un petit fichier, et le réflexe naturel de débogage — le coller quelque part et demander de l’aide — est aussi la fuite. Les discussions avec des IA, les systèmes de tickets et les canaux d’équipe conservent des copies, souvent consultables, souvent pour toujours. Cet outil suit donc la même règle que l’analyseur de journaux et le générateur de certificats : l’entrée sensible ne quitte jamais le navigateur, les valeurs sont masquées à l’écran et les seuls exports sont des fichiers que vous téléchargez délibérément. L’article compagnon, les fichiers env sont l’endroit où les secrets partent en fuite, couvre l’hygiène autour du fichier lui-même — ce qui y a sa place, ce qui n’y a pas sa place, et quoi faire quand l’un d’eux s’échappe.

Questions fréquentes

Est-il sûr de coller ici un .env de production ?

Oui — c’est précisément le but de cet outil. L’analyse s’exécute entièrement dans votre navigateur : aucun téléversement, aucun aller-retour vers un serveur, et rien de ce que vous collez n’est transmis ni stocké où que ce soit. Les valeurs sont masquées à l’écran par défaut, donc un partage d’écran ou une capture ne les divulgue pas non plus. On ne peut pas en dire autant d’un .env collé dans une discussion avec une IA, un ticket ou un message d’équipe, qui tous conservent des copies — l’article sur les fichiers env et la fuite de secrets explique les habitudes plus sûres.

Pourquoi une clé en double importe-t-elle si la dernière gagne ?

Parce que la personne qui modifie le fichier ne sait pas laquelle gagne. Elle change la valeur à la ligne 4, redéploie, et constate que rien ne se passe — le chargeur a silencieusement utilisé la ligne 41. Pire, certains frameworks prennent la première définition et d’autres la dernière, de sorte que le même fichier se comporte différemment au sein d’une même pile. Une clé, une ligne, une valeur : le validateur liste chaque doublon avec ses deux numéros de ligne pour que la ligne morte puisse être supprimée.

Mon application lit une variable qui n’est pas dans le .env. Comment les trouver ?

Collez votre code ou votre configuration dans la zone d’utilisation. L’analyseur extrait chaque nom référencé — process.env.X, process.env[’X’], import.meta.env.X, ${X} et $X — et signale les deux directions : les noms que le code référence et que le fichier ne définit jamais (ils deviennent undefined à l’exécution, généralement au pire moment), et les clés que le fichier définit et que rien ne référence (une configuration morte qui, étonnamment souvent, contient encore des secrets actifs).

Qu’est-ce qui compte comme une clé invalide ?

Tout ce qui n’est pas une lettre ou un trait de soulignement suivi de lettres, de chiffres et de traits de soulignement. Les clés commençant par un chiffre, contenant des tirets ou des points, ou portant des espaces parasites sont rejetées ou déformées par de nombreux chargeurs et shells — un fichier qui se charge proprement dans bash peut échouer dans un chargeur Node pour exactement cette raison. Le validateur les signale avec le numéro de ligne ; le tableau des entrées affiche quand même la ligne pour que vous voyiez ce qui serait perdu.

Les exports contiennent-ils les valeurs réelles ?

Oui. Les téléchargements JSON et YAML et le JSON copié sont la configuration réelle — le masquage est une protection d’affichage, pas une expurgation de vos propres données. Traitez les fichiers exportés exactement comme le .env lui-même : ne les commitez jamais dans un dépôt public, ne les joignez jamais à un ticket. Si vous avez besoin d’une version partageable et sûre, partagez plutôt la capture masquée ou la liste des clés.