Aller au contenu

Env Example Checker · Config

Repérez les variables d’environnement absentes de votre .env.example.

Collez votre code et votre .env.example pour trouver les variables d’environnement que votre code lit mais que l’exemple omet — plus les clés que rien ne lit — entièrement dans votre navigateur.

Fonctionne dans votre navigateur Sans inscription Gratuit et ouvert Mis à jour le 22 juil. 2026

Bac à sable de l’Env Example Checker

Processed entirely in your browser — contents are never uploaded.

your-code
.env.example

Tip: press Esc to release focus.

Drift Report

No share links on this tool — inputs may be secrets.

Load an example or paste your own code and .env.example, then check to see which variables drifted.

L’écart

Le .env.example dérive toujours.

Une nouvelle variable arrive dans le code et dans votre .env local — et le .env.example, le fichier réellement validé dans le dépôt et copié par chaque coéquipier, est discrètement laissé de côté. Le .env est ignoré par git, donc rien ne vous avertit. Cette dérive des variables d’environnement entre le code et la configuration reste invisible jusqu’à ce que quelqu’un clone le projet et que l’application plante sur une clé manquante, ou que des variables d’environnement manquantes cassent un pipeline de CI parce qu’une variable requise n’a jamais été documentée.

La vérifier à l’œil nu à travers une base de code tentaculaire est exactement le genre de comparaison mécanique qu’un outil devrait faire. Ce vérificateur lit dans les deux sens à la fois : il liste les variables que votre code utilise mais que l’exemple omet — celles qui cassent une récupération neuve — et les clés que l’exemple déclare encore mais que rien ne lit, afin que vous puissiez élaguer les obsolètes en toute confiance.

Vous voulez le voir d’abord ? Passez aux deux entrées ou essayez le bac à sable interactif ci-dessus.

Le pipeline

Comment ça marche.

Cinq étapes déterministes comparent votre code à votre exemple — le tout dans l’onglet de votre navigateur, à chaque fois.

  1. Analyser le code.

    Votre source est passée au crible pour chaque lecture de variable d’environnement — process.env, os.environ, $NAME et le reste.

  2. Analyser l’exemple.

    Votre .env.example est lu comme des lignes KEY=value, les commentaires et les lignes vides étant ignorés, pour former un ensemble de clés.

  3. Comparer les deux ensembles.

    Les noms utilisés dans le code sont comparés aux clés déclarées dans l’exemple, dans les deux sens à la fois.

  4. Faire remonter les écarts.

    Les variables utilisées mais non déclarées sont signalées comme manquantes ; les clés déclarées mais non lues sont signalées comme inutilisées.

  5. Corriger et revérifier.

    Ajoutez les clés manquantes à votre exemple, élaguez les obsolètes, puis relancez jusqu’à ce que le rapport soit propre.

Les entrées

Deux entrées, toutes deux familières.

Le vérificateur lit exactement deux choses : le code de votre application et votre .env.example. Si vous avez déjà écrit l’un ou l’autre, vous serez en terrain connu.

Le code

N’importe quelle source qui lit des variables d’environnement. Le scanner reconnaît process.env.NAME et import.meta.env.NAME dans Node / Vite, os.environ["NAME"] / os.getenv("NAME") en Python, os.Getenv("NAME") en Go, et le simple $NAME en shell.

server.ts 
// server.ts
const port = process.env.PORT ?? '3000';
const dbUrl = process.env.DATABASE_URL;
const apiKey = process.env["STRIPE_SECRET_KEY"];

if (!dbUrl) {
  throw new Error('DATABASE_URL is required');
}

Le .env.example

Lignes dotenv standard — KEY=value par ligne, avec les commentaires # et les lignes vides ignorés. Seuls les noms de clés comptent pour la comparaison, donc des valeurs d’espace réservé conviennent. C’est le fichier que vos coéquipiers copient dans un vrai .env.

.env.example 
# .env.example
PORT=3000
DATABASE_URL=postgres://localhost:5432/app

# STRIPE_SECRET_KEY is used in server.ts but
# was never added here — the checker flags it.

# Declared below but nothing reads it — flagged as unused.
LEGACY_FEATURE_FLAG=false

Bientôt disponible

Faites échouer le build en cas de dérive.

Le vérificateur dans le navigateur est la première étape. Une CLI prête à l’emploi exécutera la comparaison identique sur votre dépôt en CI, de sorte qu’une entrée .env.example oubliée fasse échouer le build au lieu de casser le premier git clone d’un coéquipier.

Une GitHub Action propriétaire qui encapsule la CLI est prévue en parallèle. Les deux arrivent bientôt — le vérificateur dans le navigateur ci-dessus fonctionne dès aujourd’hui.

ci.sh 
# Coming soon — the same check in CI
$ envcheck ./src --example .env.example

  ✗ Missing from .env.example (1)
      STRIPE_SECRET_KEY   used in src/server.ts

  ! Unused in .env.example (1)
      LEGACY_FEATURE_FLAG

  1 missing, 1 unused

Une note sur la portée

Comment fonctionne la détection : le vérificateur fait correspondre les lectures de variables d’environnement selon leurs schémas d’accès littéraux et courants — process.env.NAME, os.environ["NAME"], $NAME et autres. Les noms construits dynamiquement à l’exécution (par exemple process.env[someVariable]) ne peuvent pas être résolus statiquement, donc ils n’apparaîtront pas dans l’ensemble des variables utilisées. Considérez un rapport propre comme une forte assurance que votre configuration documentée correspond à votre code — et parcourez tout de même à la main toute recherche calculée.

FAQ

Vos questions, nos réponses.

Appuyez sur une question pour afficher la réponse.

Que fait l’Env Example Checker ?

Il compare les variables d’environnement que votre code lit réellement aux clés déclarées dans votre .env.example. Collez les deux, appuyez sur Vérifier, et il signale deux écarts : les variables utilisées dans le code mais absentes de l’exemple (celles qui piègent un nouveau développeur ou un déploiement neuf), et les clés déclarées dans l’exemple que rien ne lit (entrées obsolètes à élaguer). Tout est calculé dans votre navigateur.

Mon code ou mon .env.example quitte-t-il jamais mon navigateur ?

Non. Le vérificateur fonctionne à 100 % côté client. Votre source et votre fichier d’exemple sont analysés et comparés dans l’onglet de votre navigateur — rien n’est envoyé à un serveur, et il n’y a ni compte ni inscription. Vous pouvez coller en toute sécurité du code interne et des clés de configuration.

Quels langages et schémas d’accès détecte-t-il ?

Il reconnaît les façons courantes dont le code lit les variables d’environnement dans les écosystèmes populaires — process.env.NAME et process.env["NAME"] dans Node et TypeScript, import.meta.env.NAME dans Vite, Deno.env.get("NAME") dans Deno, os.environ["NAME"] / os.getenv("NAME") en Python, ENV["NAME"] / ENV.fetch("NAME") en Ruby, os.Getenv("NAME") en Go, System.getenv("NAME") en Java, et getenv / $_ENV["NAME"] en PHP. Le côté .env.example est analysé comme des lignes KEY=value standard, en ignorant les commentaires et les lignes vides.

Pourquoi le .env.example dérive-t-il du code au départ ?

Une nouvelle variable est ajoutée au code et au .env local, mais le .env.example — c’est-à-dire le fichier validé dans le dépôt et celui que les coéquipiers copient — est oublié. La dérive reste invisible jusqu’à ce que quelqu’un clone le projet, copie l’exemple et que l’application plante sur une clé manquante, ou jusqu’à ce qu’un déploiement échoue parce qu’une variable requise n’a jamais été documentée. Cet outil fait remonter cette dérive avant la mise en production.

Peut-il indiquer quelles variables manquantes sont requises plutôt qu’optionnelles ?

Il signale chaque variable que le code lit mais que l’exemple ne déclare pas ; savoir si une variable donnée est strictement requise est un jugement que seul votre code peut porter (une valeur par défaut peut la rendre optionnelle). Considérez la liste des manquantes comme l’ensemble à examiner et à documenter — ajoutez chacune au .env.example avec un espace réservé sûr ou un commentaire indiquant qu’elle est optionnelle.

Comment trouver les variables d’environnement utilisées dans le code mais absentes du .env.example ?

Collez votre code source dans le panneau de code et votre .env.example dans le panneau de modèle, puis appuyez sur Vérifier. Le vérificateur parcourt le code à la recherche de toutes les références à des variables d’environnement — process.env.X, os.getenv("X"), import.meta.env.X et schémas similaires — et compare cet ensemble aux clés de votre .env.example, en listant chaque variable que le code lit mais que le fichier d’exemple ne déclare pas.

Comment trouver les clés inutilisées dans mon fichier .env.example ?

Le vérificateur effectue la comparaison dans les deux sens à la fois. À côté du rapport des clés manquantes, il liste aussi chaque clé déclarée par votre .env.example qui n’apparaît pas dans le code collé, afin que vous puissiez supprimer en toute sécurité les variables obsolètes ou résiduelles et garder le modèle léger et exact.

Comment empêcher les variables d’environnement manquantes de casser la CI ou les déploiements ?

Exécutez ce vérificateur avant de valider afin que toute variable que votre code lit mais que l’exemple omet soit détectée tôt. Maintenir le .env.example synchronisé avec le code donne aux pipelines de CI et aux coéquipiers un modèle complet, ce qui signifie que l’application échoue rapidement au moment de la configuration plutôt que de planter à l’exécution avec une erreur de variable indéfinie. Une version CLI pour les vérifications automatisées en CI est prévue.

Quelle est la différence entre comparer deux fichiers .env et vérifier par rapport au code ?

Comparer .env à .env.example confronte deux fichiers de configuration l’un à l’autre — cela ne sait que quelles clés chaque fichier déclare. Ce vérificateur lit plutôt le code source réel pour apprendre quelles variables sont vraiment utilisées, de sorte qu’il détecte les variables dont le code a besoin mais qui sont absentes de tous les fichiers de configuration, et signale les clés d’exemple que le code ne touche jamais. C’est cette distinction qui le rend utile pour détecter la dérive des variables d’environnement entre le code et la configuration, et pas seulement entre deux fichiers de configuration.

Est-ce un outil officiel pour un framework ?

Non. Il s’agit d’un utilitaire communautaire indépendant, qui n’est ni affilié ni approuvé par un quelconque framework, runtime ou bibliothèque dotenv. Il modélise la convention .env / .env.example largement utilisée et les schémas d’accès aux variables d’environnement courants uniquement pour décrire ce qu’il vérifie.

More free, private DevOps tools.

L’Env Example Checker est l’un des outils de OpsCanopy — une canopée grandissante de validateurs, convertisseurs et testeurs basés sur le navigateur qui ne touchent jamais à un serveur.

En savoir plus

Vous débutez avec Docker ?  Lire le guide Docker →

Browse All Tools Back to OpsCanopy

29 outils gratuits, tous utilisables hors ligne — opscanopy.com fonctionne sans inscription et sans rien téléverser.

Vous validez de la configuration et des pipelines ? Associez-le au GitHub Actions Validator pour détecter les problèmes de workflow avant le push, ou parcourez le répertoire d’outils complet.

Non affilié à un quelconque framework, runtime ou bibliothèque dotenv, ni approuvé par eux. La convention .env / .env.example et les schémas d’accès aux variables d’environnement sont référencés uniquement pour décrire ce que cet outil vérifie.