Ce que sont les variables d'environnement
Les variables d'environnement sont des valeurs de configuration stockées en dehors du code source d'une application et injectées dans l'environnement d'exécution au moment du démarrage. Elles permettent de configurer une application différemment selon le contexte dans lequel elle s'exécute, sans modifier le code lui-même.
Le nom "variable d'environnement" vient du concept d'environnement d'exécution : l'ensemble des conditions dans lesquelles un programme fonctionne. Une application web peut s'exécuter dans plusieurs environnements distincts : l'environnement local du développeur, un environnement de staging pour les tests, et l'environnement de production accessible aux utilisateurs. Ces trois environnements ont des configurations différentes : des bases de données distinctes, des clés API différentes, des niveaux de journalisation différents.
Plutôt que de hardcoder ces valeurs directement dans le code (ce qui nécessiterait de modifier le code pour chaque environnement et exposerait des informations sensibles dans le dépôt de code), on les stocke dans des variables d'environnement qui sont lues par l'application au moment de son démarrage.
Pourquoi les variables d'environnement sont indispensables
La sécurité des informations sensibles. C'est la raison principale. Les clés API, les mots de passe de base de données, les tokens d'authentification, les clés secrètes de chiffrement : ces informations ne doivent jamais être incluses directement dans le code source. Le code source est souvent versionné dans un dépôt Git, potentiellement partagé avec plusieurs développeurs, et parfois accessible publiquement sur GitHub.
Une clé API Stripe ou une clé secrète JWT exposée dans un dépôt public peut être découverte par des robots qui scannent GitHub en permanence à la recherche de ces fuites. Les conséquences peuvent être graves : fraude financière, accès non autorisé aux données, utilisation abusive de services facturés à la consommation. Les variables d'environnement résolvent ce problème en gardant ces informations hors du code.
La flexibilité entre les environnements. Une application a généralement besoin de se connecter à des ressources différentes selon l'environnement. En développement local, on pointe vers une base de données locale. En staging, vers une base de données de test. En production, vers la base de données de production. Gérer ces différences via des variables d'environnement évite de modifier le code entre les déploiements et réduit le risque d'erreurs.
La séparation de la configuration et du code. Un principe fondamental du développement logiciel propre est de séparer ce qui change (la configuration) de ce qui ne change pas (la logique). Les variables d'environnement matérialisent cette séparation : le code est le même dans tous les environnements, seule la configuration change.
Comment les variables d'environnement fonctionnent en pratique
Le fichier .env. Dans les projets JavaScript et Next.js notamment, les variables d'environnement sont généralement définies dans un fichier .env à la racine du projet. Ce fichier liste les variables sous la forme NOM_VARIABLE=valeur. Par convention, les noms de variables d'environnement sont en majuscules avec des underscores.
DATABASE_URL=postgresql://user:password@localhost:5432/mydb
STRIPE_SECRET_KEY=sk_test_...
NEXTAUTH_SECRET=une_chaine_secrete_longue
NEXT_PUBLIC_API_URL=https://api.monsite.fr
Le fichier .env lui-même ne doit jamais être commité dans le dépôt Git. Un fichier .env.example sans les valeurs réelles est commité à la place, pour documenter les variables nécessaires sans exposer leurs valeurs.
Le fichier .gitignore. Pour s'assurer que le fichier .env n'est jamais accidentellement commité dans le dépôt, on l'ajoute au fichier .gitignore. C'est une mesure de sécurité fondamentale que tout projet avec des variables d'environnement doit mettre en place.
Les variables publiques et privées. Dans Next.js, les variables d'environnement préfixées par NEXT_PUBLIC_ sont exposées côté client (dans le navigateur). Les variables sans ce préfixe ne sont accessibles que côté serveur. Cette distinction est importante pour la sécurité : les clés secrètes ne doivent jamais être préfixées NEXT_PUBLIC_ car elles seraient visibles dans le JavaScript envoyé au navigateur.
La gestion des variables d'environnement en production
En production, les variables d'environnement ne sont pas définies dans un fichier .env (qui n'existe pas sur le serveur de production) mais via l'interface de la plateforme d'hébergement ou des variables d'environnement système.
Sur Vercel. La plateforme d'hébergement de référence pour les projets Next.js propose une interface dédiée à la gestion des variables d'environnement. On peut définir des variables différentes pour les environnements de production, de preview (branches de développement) et de développement. Les variables sont chiffrées et ne sont jamais exposées dans les logs.
Sur Coolify ou d'autres plateformes d'auto-hébergement. La gestion des variables d'environnement se fait via l'interface de la plateforme ou directement sur le serveur. Studio Seja utilise Coolify pour le déploiement de certains projets, avec une gestion des secrets intégrée.
Les secrets managers. Pour les projets avec de nombreuses variables sensibles ou des exigences de conformité élevées, des outils dédiés comme HashiCorp Vault, AWS Secrets Manager ou Doppler centralisent la gestion des secrets et permettent de les injecter automatiquement dans les applications sans les stocker dans des fichiers de configuration.
Les erreurs fréquentes à éviter
Committer le fichier .env. C'est l'erreur la plus grave et la plus fréquente. Elle peut exposer des clés API, des mots de passe et des tokens à quiconque a accès au dépôt. Si un fichier .env avec des valeurs réelles est accidentellement commité, il faut considérer toutes les valeurs exposées comme compromises et les régénérer immédiatement.
Exposer des variables sensibles côté client. Préfixer une variable secrète avec NEXT_PUBLIC_ dans un projet Next.js l'expose dans le bundle JavaScript envoyé au navigateur. N'importe qui peut l'inspecter avec les outils de développement du navigateur.
Utiliser les mêmes valeurs en développement et en production. Utiliser les mêmes clés API en développement et en production signifie que les erreurs de développement (requêtes de test, données incorrectes) se mélangent avec les données de production. Les plateformes comme Stripe proposent des environnements séparés (test/live) avec des clés distinctes pour éviter exactement ce problème.
Ne pas documenter les variables nécessaires. Un développeur qui rejoint le projet doit savoir quelles variables d'environnement configurer pour démarrer l'application. Le fichier .env.example avec des valeurs d'exemple et des commentaires explicatifs est la façon standard de documenter cette information.
FAQ
Les variables d'environnement sont-elles uniquement pour les projets JavaScript ?
Non. Les variables d'environnement sont un concept universel présent dans tous les langages et environnements de développement. Python, PHP, Ruby, Go : tous les langages peuvent lire les variables d'environnement système. Le mécanisme exact varie selon le langage et le framework, mais le principe est le même.
Peut-on stocker n'importe quelle valeur dans une variable d'environnement ?
Les variables d'environnement sont des chaînes de caractères (strings). Pour stocker des structures de données plus complexes (objets JSON, tableaux), il faut les sérialiser en chaîne de caractères et les désérialiser dans le code. La taille des valeurs peut également être limitée selon le système.
Comment partager les variables d'environnement en équipe sans les exposer ?
Plusieurs approches selon les besoins. Un gestionnaire de mots de passe d'équipe (1Password, Bitwarden) peut stocker et partager les fichiers .env de façon sécurisée. Des outils dédiés comme Doppler ou Infisical centralisent la gestion des secrets et les synchronisent automatiquement avec les environnements d'exécution. Pour les petites équipes, partager le fichier .env via un canal sécurisé et chiffré est une solution pragmatique.
Une variable d'environnement peut-elle être vide ?
Oui. Une variable peut être définie mais vide (NOM_VARIABLE=). Le code doit gérer ce cas pour éviter des comportements inattendus. Une bonne pratique est de valider au démarrage de l'application que toutes les variables obligatoires sont définies et non vides, avec un message d'erreur explicite si ce n'est pas le cas.
