Une application a besoin de savoir à quelle base se connecter, quelle clé utiliser pour envoyer des emails et si elle tourne en test ou en production. Écrire ces informations dans le code oblige à modifier le code à chaque changement, et expose les clés à toute personne qui lit le dépôt. Les variables d'environnement règlent ces deux problèmes : le code demande une valeur par son nom, et chaque environnement fournit la sienne.
Comment ça marche
Une variable d'environnement est une paire nom et valeur, par exemple
STRIPE_SECRET_KEY=sk_live_.... Le code ne contient que le nom. Au démarrage ou au
build, l'hébergeur ou le fichier .env fournit la valeur.
Le même code peut alors tourner à trois endroits avec trois configurations :
| Environnement | Base de données | Paiement |
|---|---|---|
| Poste du développeur | Base locale | Clé de test Stripe |
| Préproduction | Base de test | Clé de test Stripe |
| Production | Base réelle | Clé live Stripe |
C'est ce découpage qui rend possible un environnement de préproduction sérieux, où l'on teste une modification sans toucher aux vraies données ni aux vrais paiements.
La distinction qui compte : navigateur ou serveur
Dans une app moderne, il existe deux catégories de variables, et la confusion entre les deux est l'une des causes les plus courantes de secret exposé.
Les variables du navigateur sont lues au moment du build et copiées dans le code
JavaScript envoyé à chaque visiteur. Avec Vite, ce sont celles qui commencent par
VITE_. La documentation de Vite précise qu'elles ne doivent pas contenir
d'informations sensibles comme des clés d'API. Elles conviennent à l'adresse publique
de Supabase, à sa clé publishable ou à un identifiant d'analytics.
Les variables du serveur restent sur le serveur et ne sont jamais envoyées au
navigateur. Sur Supabase, ce sont les secrets des Edge Functions, définis dans le
tableau de bord ou avec supabase secrets set, puis lus dans le code avec
Deno.env.get. C'est là que doivent vivre la clé secrète Supabase,
les clés de paiement, d'email ou de modèles d'IA. Supabase précise que les fonctions
déployées prennent en compte un nouveau secret sans nouveau déploiement.
Pourquoi c'est un point clé lors d'une reprise
Le code part avec l'export GitHub. Les valeurs des variables, non. C'est voulu, puisque les secrets ne doivent pas être dans le dépôt, mais cela crée un angle mort au moment d'une reprise ou d'un changement d'hébergeur : l'app migrée démarre, puis les paiements, les emails ou la connexion échouent un par un, faute de configuration.
Notre guide sur l'export et la propriété du code détaille ce qui voyage avec le dépôt. Les variables font partie de ce qui doit être inventorié à part, avec le propriétaire du compte de chaque service.
Comment vérifier ton app
- Cherche un fichier
.env.exampleou une liste documentée des variables nécessaires. S'il n'existe pas, la reprise commencera par une enquête - Liste les variables
VITE_ouNEXT_PUBLIC_et vérifie qu'aucune ne contient de secret - Vérifie le
.gitignore:.env,.env.localet*.localdoivent être exclus du dépôt, comme le recommande Vite - Inventorie les secrets côté serveur dans le tableau de bord Supabase ou de la plateforme, avec le service concerné et le compte propriétaire
- Contrôle la séparation test et production : des clés différentes, une base différente, et aucune clé live sur le poste d'un développeur
Un exemple concret
Une startup reprend en interne une app construite avec Replit. Le code est sur GitHub, le nouvel hébergeur est prêt. Au premier lancement, la page d'accueil s'affiche. Les inscriptions échouent : la clé du service d'email n'a jamais été notée nulle part. Les paiements échouent aussi : la clé Stripe était enregistrée sur le compte du freelance qui avait lancé le projet.
Il a fallu deux jours pour retrouver les comptes, régénérer les clés et rétablir le service. Un inventaire de quinze lignes, préparé avant la migration, aurait ramené ce délai à une heure.
Les erreurs les plus fréquentes
- Un secret dans une variable
VITE_ouNEXT_PUBLIC_, donc publié - Un
.envversionné, parfois depuis le premier commit - Aucune documentation des variables, connues seulement de l'outil ou du freelance
- Les mêmes valeurs en test et en production
- Des secrets enregistrés sur un compte personnel plutôt que sur celui de l'entreprise
Ce qu'il faut retenir
Les variables d'environnement sont une bonne pratique simple, qui ne demande qu'une discipline : savoir lesquelles sont publiques, lesquelles sont secrètes, et où chacune est enregistrée. Le Scan de vibebusters produit cet inventaire, et la checklist le replace parmi les points à vérifier avant une reprise.