Variables d’environnement Vite exposées : le préfixe dit publier

Quelqu’un a ouvert votre appli Lovable, appuyé sur F12, et trouvé dans le code une valeur que vous êtes certain d’avoir mise dans un fichier .env. Ou vous avez demandé une fonctionnalité au builder, il a écrit une ligne commençant par VITE_, et quelque chose que vous avez lu depuis dit que ce préfixe est par là que les clés fuient. Le fichier a .env dans son nom et tous les tutoriels disent de ne jamais le partager. Des variables d’environnement Vite exposées à chaque visiteur, cela ressemble à un bug de Vite.

Voici la partie que guide après guide explique de travers : rien n’a échoué à cacher cette valeur. VITE_ et NEXT_PUBLIC_ sont une instruction pour votre outil de build, et l’instruction est de mettre la valeur dans l’appli que chaque visiteur télécharge. L’outil a lu l’étiquette et a fait ce qu’elle disait.

Un build emballe votre appli dans une boîte, et chaque visiteur reçoit une copie de la boîte. Le préfixe est une étiquette sur une valeur qui dit : emballe celle-ci aussi. Le reste de cet article porte sur les valeurs pour lesquelles cette étiquette est juste, sur la raison pour laquelle l’IA la colle sur les mauvaises, et sur la façon de voir ce qu’il y a dans votre propre boîte.

Les variables d’environnement Vite sont-elles exposées aux visiteurs ?

Celles qui commencent par VITE_, oui, et c’est à cela que sert le préfixe.

Vite, l’outil de build derrière la plupart des applis Lovable et Bolt, lit votre fichier .env à chaque build. Une variable nommée VITE_SUPABASE_URL est copiée dans le bundle, le fichier JavaScript compressé que chaque visiteur télécharge, où votre code la lit sous la forme import.meta.env.VITE_SUPABASE_URL. Une variable nommée DB_PASSWORD, sans préfixe, arrive vide dans le navigateur. La documentation de Vite elle-même dit que les valeurs préfixées sont intégrées à votre code source au moment du build et ne doivent pas contenir de clés d’API.

Next.js, avec lequel v0 construit, a la même règle sous un autre nom : NEXT_PUBLIC_. Sa documentation décrit la valeur comme inlined, une chaîne figée écrite dans le bundle du navigateur au moment du build. Expo utilise EXPO_PUBLIC_ et prévient avec les mêmes mots. Les anciens projets Create React App utilisent REACT_APP_. Chaque préfixe dit la même chose à son outil de build : celle-ci va dans la boîte.

Pourquoi un fichier .env semble privé et ne l’est pas

Parce que l’habitude de garder une clé dans un fichier .env vient des serveurs, où elle fonctionne.

Sur un serveur, le fichier et le code qui le lit sont sur une machine que vous contrôlez. Un visiteur reçoit une réponse de cette machine et ne voit jamais le fichier. Sortir la clé du code et la mettre dans un fichier que le serveur lit au démarrage est une bonne pratique là-bas, et c’est là qu’a été écrit chaque tutoriel qui dit « mettez-la dans .env ».

Votre fichier .env a deux lecteurs, et les tutoriels parlent d’un seul. Le premier, c’est quiconque peut voir votre projet : un collaborateur, un dépôt GitHub public, la vue des fichiers du builder lui-même. Une entrée dans .gitignore, qui est une liste de fichiers que git laisse de côté, tient .env à l’écart de ce lecteur. Le second lecteur est le build, qui ouvre le fichier à chaque publication et en copie tout ce qui porte le préfixe. .gitignore ne lui dit rien.

Donc « mon .env est dans gitignore » est vrai, et répond à une autre question. Le fichier est resté hors de votre dépôt. Les valeurs préfixées sont quand même entrées dans l’appli, parce que c’est la route que le préfixe ouvre, et dans un projet Lovable, Bolt ou v0, la plus grande partie du code que vous avez modifié tourne dans le navigateur, où il n’y a aucun serveur derrière lequel le fichier pourrait rester.

Pourquoi l’IA a pris le préfixe

Parce que c’est ainsi qu’on fait fonctionner une valeur dans du code de navigateur, et que le modèle n’a aucune idée de ce que la valeur coûte.

Vous avez demandé une carte, ou un chat qui répond aux questions sur votre produit. Le code que le builder a écrit pour cela tourne dans le navigateur du visiteur, et du code de navigateur qui lit process.env.OPENAI_API_KEY ne reçoit rien du tout. Le moyen de faire arriver la valeur, c’est le préfixe. Le builder renomme la variable VITE_OPENAI_API_KEY, la fonctionnalité marche dans l’aperçu, et aucune erreur n’est levée nulle part, parce que du côté de l’outil de build rien ne s’est mal passé.

Le préfixe ne juge pas. C’est la même instruction pour une clé Google Maps, qui est censée être publique une fois restreinte, et pour une clé secrète Stripe, qui peut rembourser chacun de vos clients. Une personne qui saurait que la seconde débite votre carte s’arrêterait. Le modèle sait que la fonctionnalité ne marchait pas tant que la ligne n’était pas là, et qu’ensuite elle a marché.

C’est pour cela que cela apparaît sur des applis dont les propriétaires ont fait tout ce qu’on leur a dit. La valeur a été sortie du code, gardée dans .env, le fichier a été mis dans gitignore, et l’appli la livre quand même, parce que la seule étape qui la publie ressemble à l’étape qui la fait marcher.

Quelles valeurs vont derrière le préfixe

Une adresse et une clé publiable. Tout ce qui dépense de l’argent ou ignore les règles de votre base de données, non.

Si votre appli a VITE_SUPABASE_URL et une clé publiable à côté, c’est la paire que Supabase a prévue pour un navigateur, et notre scan la marque comme étant à sa place. L’adresse et la clé publiable sont la raison d’être du préfixe.

Le test pour tout le reste, c’est de savoir si cela vous gênerait de voir la valeur imprimée sur votre page d’accueil. Le préfixe la met un clic plus loin que cela, dans un fichier au lieu de la page, et quiconque veut le fichier l’a. Distinguer les deux familles, par le préfixe et, sur une ancienne clé Supabase, par le rôle qu’elle contient, est un article à part.

Ce que 30 998 applis livraient derrière le préfixe

Surtout des clés d’API Google. 52 applis livraient une clé qui dépense de l’argent ou lit tout.

En août 2026, nous avons lancé les neuf mêmes vérifications sur 30 998 applis vibe-codées en ligne. 1 332 d’entre elles, soit 4 %, livraient quelque chose qui ressemble à une clé dans le code que chaque visiteur télécharge. 1 142 de celles-ci étaient des clés d’API Google, qui ont en général besoin d’une restriction définie dans Google Cloud et pas d’une rotation. 204 livraient une valeur d’allure aléatoire à côté d’un nom comme secret ou password, qui peut être un vrai identifiant ou non.

Les coûteuses étaient rares. 33 applis livraient une clé OpenAI, 9 une clé d’accès AWS, 5 une clé Anthropic, 3 une clé secrète Stripe et 3 une clé service_role Supabase : 52 applis en tout, puisque l’une d’elles en portait deux. La valeur derrière le préfixe est donc en général une clé Google, et le remède pour cela est un réglage. Le cas rare est celui où se trouvent les dégâts, et ce que coûte une clé OpenAI qui a fui est l’article pour celui-là.

Comment vérifier ce que votre propre appli livre

Ouvrez l’appli en ligne, appuyez sur F12, et cherchez la valeur dans chaque fichier chargé.

1. Ouvrez votre appli publiée dans un navigateur, à sa vraie adresse. L’aperçu du builder est un autre build et peut avoir une version de retard.
2. Appuyez sur F12 pour ouvrir les outils de développement, puis choisissez l’onglet Sources.
3. Appuyez sur Ctrl+Maj+F, ou Cmd+Option+F sur un Mac. Cela ouvre une recherche dans chaque fichier que la page a chargé.
4. Collez les dix premiers caractères environ de la valeur qui vous inquiète, et ne la collez nulle part ailleurs.

Un résultat veut dire que la valeur est dans la boîte que reçoit chaque visiteur. Cherchez la valeur plutôt que le nom : le build remplace en général import.meta.env.VITE_OPENAI_API_KEY par la valeur elle-même, si bien qu’une recherche de VITE_ peut revenir vide alors que chaque valeur qu’il y avait derrière est là.

Si vous préférez ne pas parcourir votre appli valeur par valeur, notre scan gratuit lit votre site en ligne depuis l’extérieur, les neuf vérifications, en 20 secondes environ et sans compte. Il nomme chaque clé trouvée par son type, dit lesquelles ont leur place dans un navigateur, et écrit « Impossible à vérifier » pour tout ce à quoi il n’a pas pu répondre plutôt qu’une coche : scannez votre appli.

Où va un vrai secret à la place

Sur une machine depuis laquelle vos visiteurs ne téléchargent jamais rien. Dans un projet Supabase, c’est une Edge Function, un petit morceau de code serveur que Supabase exécute pour vous ; dans une appli Next.js, c’est une route serveur ; dans une appli Replit, c’est la moitié serveur.

La forme est la même partout. Votre code de navigateur demande à votre fonction de faire le travail. La fonction détient la clé, passe l’appel à OpenAI ou Stripe, et renvoie la réponse. La clé reste sur la machine et le visiteur reçoit un résultat. L’article sur OpenAI le dessine comme un objet qui se déplace d’une case vers la droite, et le changement se résume à cela.

Deux choses vous disent que le builder a fait ce que vous avez demandé. La variable a perdu son préfixe, donc c’est OPENAI_API_KEY, et elle vit dans les secrets propres à la fonction, définis dans le tableau de bord Supabase sous Edge Functions, sans rien dans le .env de l’appli. Et le fichier qui la lit se trouve sous supabase/functions/ ou app/api/, quelque part que le build n’emballe jamais, au lieu de sous src/.

Un ordre compte, et il est facile de l’inverser. Si une clé secrète a déjà été livrée derrière un préfixe, la déplacer ne fait rien pour les copies déjà téléchargées. Renouvelez-la d’abord chez le fournisseur, puis déplacez le travail. Renouveler d’abord ou fermer la fuite d’abord dépend de si la copie est déjà publique, et dès qu’elle a été dans un bundle publié, elle l’est.

Pour un projet Replit, la même séparation a son propre nom, Secrets, et ce que l’outil Secrets couvre et ce qu’il ne couvre pas est un article à part.

Quoi faire maintenant

Chaque publication emballe une nouvelle boîte. La prochaine fonctionnalité que vous demandez est une nouvelle occasion pour une valeur de recevoir le préfixe, et rien entre le builder et internet ne lit le bundle en sortie. Un scan du mois dernier a lu le bundle du mois dernier.

Reeve Monitor lit le bundle pour vous. Il relance les neuf vérifications toutes les heures sur trois applis au plus, vous prévient quand un résultat change, surveille la disponibilité toutes les 60 secondes, et envoie un rapport mensuel. Une clé qui atteint le bundle avec la publication de mardi figure dans le re-scan de cette heure-là, que vous ayez pensé à regarder ou non. Il coûte €12 par mois au tarif de base, avec sept jours gratuits avant de vous facturer ; la page des tarifs est parfois en dessous du chiffre donné ici et jamais au-dessus.

Si vous préférez traiter cela sous forme de liste, la checklist de sécurité en 10 minutes couvre ce point et les autres choses qu’il vaut la peine de désactiver dans une appli fraîchement lancée.