Utiliser les secrets sur Replit, et ce qui est publié quand même

Quelque part entre la construction de votre application et sa publication, Replit vous a dit d’arrêter de mettre votre clé d’API dans le code. Vous avez donc cherché comment utiliser les secrets sur Replit, déplacé la clé dans l’outil Secrets, et l’avertissement a disparu. Puis on vous a dit que la clé restait visible dans votre application publiée, et les deux choses semblent vraies en même temps.

Elles le sont. Voici la partie que la plupart des conseils sur le sujet laissent de côté : l’outil Secrets décide où une valeur est rangée. Votre code décide où elle est emportée. Ce sont deux questions distinctes, et seule la première a quelque chose à voir avec l’outil.

C’est sur Replit que cela mord le plus fort, parce que la moitié de votre application qui tourne sur la machine de Replit et la moitié qui tourne sur le portable de votre visiteur vivent dans le même projet, souvent dans des fichiers voisins. Rien dans l’éditeur ne trace de ligne entre les deux.

Entre le 12 et le 14 août 2026, nous avons passé les mêmes neuf vérifications externes sur 30 998 applications en ligne, dont 3 042 publiées sur Replit. Dans 219 de ces applications Replit, quelque chose ayant la forme d’une clé se trouvait dans le code qu’un visiteur télécharge. Sur l’ensemble de l’échantillon, l’essentiel de ce que trouve cette vérification est une clé Google, qui ne pose en général pas de problème une fois restreinte. Celles qui en posent un sont précisément celles qu’un outil de secrets devait éviter. Les chiffres complets sont dans notre rapport de scan.

Comment utiliser les secrets sur Replit ?

Ouvrez l’outil Secrets, ajoutez un nom et une valeur, puis relisez cette valeur dans votre code comme variable d’environnement. Cela prend environ une minute.

1. Dans votre projet, ouvrez Secrets. C’est dans la liste des outils, et chercher le mot dans ce panneau le trouve.
2. Choisissez + New secret. Donnez-lui un nom en majuscules avec des tirets bas, par exemple OPENAI_API_KEY. C’est ce nom que votre code utilisera, il compte donc plus qu’il n’en a l’air.
3. Collez la valeur dans le second champ et enregistrez. Replit la chiffre et la garde hors des fichiers de votre projet.
4. Relisez-la dans votre code. En JavaScript c’est process.env.OPENAI_API_KEY, et en Python os.getenv("OPENAI_API_KEY").
5. Revenez en arrière et supprimez la valeur là où elle se trouvait avant.

L’étape cinq est celle qu’on saute, et celle dont dépend l’utilité de tout le reste. Créer un secret ne supprime pas la copie que vous aviez déjà. Une clé collée dans un fichier la semaine dernière est toujours dans ce fichier, toujours dans l’historique de votre projet, et toujours dans chaque copie de votre application publiée depuis.

Un fichier .env fait le même travail que l’outil Secrets, avec une différence qui compte : c’est un fichier, donc il voyage avec le projet quand quelqu’un le duplique ou le relie à un dépôt.

Les secrets Replit sont-ils sûrs ?

Pour ce qu’ils font, oui. La valeur est chiffrée, elle reste hors de votre code source, et les trois façons les plus courantes de laisser filer une clé sont toutes fermées par là : vous partagez votre projet avec quelqu’un, vous le reliez à un dépôt, ou quelqu’un vous regarde travailler.

Voyez-le comme un tiroir fermé à clé. Ce qui est dans le tiroir échappe au regard de quiconque lit vos fichiers. Ce que le tiroir ne peut pas décider, c’est ce que votre application fait du contenu une fois que votre propre code l’a ouvert et est parti avec.

Et une application Replit publiée part avec pas mal de choses. Chaque visiteur qui charge votre site reçoit toute la moitié avant, car un navigateur ne peut pas dessiner une page qu’on ne lui a pas envoyée. Si le code qui ouvre le tiroir fait partie de ce qu’on envoie aux visiteurs, la valeur qu’il en a sortie voyage avec.

Quelle moitié de votre application lit la clé ?

La moitié qui tourne sur la machine de Replit peut lire un secret sans risque. La moitié qui tourne dans le navigateur de votre visiteur ne le peut pas, et la manière habituelle de la faire marcher est aussi celle par laquelle la clé devient publique.

Votre code serveur est la partie que Replit exécute : une route Express, un gestionnaire Python, une fonction qui parle à OpenAI ou à Stripe et renvoie une réponse à votre application. Elle lit un secret, s’en sert, et la valeur ne quitte jamais la machine.

Votre code navigateur est tout ce qu’exécute le portable de votre visiteur. Dans un projet React, c’est l’essentiel de ce que vous avez édité. Il est compilé en un paquet de JavaScript et téléchargé en entier par tous ceux qui ouvrent votre site.

process.env n’existe pas dans un navigateur : le code navigateur qui le lit n’obtient donc rien du tout. Pour que la valeur arrive, quelqu’un la renomme, VITE_OPENAI_API_KEY dans un projet Vite ou NEXT_PUBLIC_OPENAI_API_KEY dans un projet Next.js. Cela marche tout de suite, parce que ce préfixe est une instruction donnée à l’outil de build d’écrire la valeur dans le paquet. La documentation de Vite le dit en toutes lettres et déconseille d’y mettre des clés d’API pour exactement cette raison.

La vérification la plus rapide de cet article est donc une recherche. Ouvrez votre projet et cherchez VITE_ et NEXT_PUBLIC_. Chaque résultat est une valeur que votre outil de build a pour consigne de publier.

Pour certaines, c’est correct. Une clé publiable Supabase est conçue pour vivre dans un navigateur, et une clé Google Maps avec une restriction de référent aussi. C’est incorrect pour tout ce qui dépense de l’argent ou lit une base de données sans demander qui frappe, et distinguer les deux prend environ une minute par clé.

Si vous préférez voir ce que votre application publiée distribue avant d’y aller fichier par fichier, notre scan gratuit lit votre site depuis l’extérieur et vous dit ce qu’il y trouve. Il prend environ 20 secondes et ne demande aucun compte : scanner votre application.

Pourquoi mon secret Replit ne fonctionne-t-il pas ?

Deux raisons, et de là où vous êtes elles produisent le même symptôme : une valeur vide et une application qui ne marche pas.

Le code qui le lit tourne dans le navigateur. Il n’y a aucun environnement à lire là-bas, donc process.env.VOTRE_CLE est vide et le restera. Ce n’est pas un problème de configuration, et recréer le secret autant de fois qu’on veut n’y change rien. L’appel qui a besoin de la clé doit déménager vers la moitié serveur de votre application.

Votre application publiée tourne dans une version plus ancienne. Replit garde deux jeux de valeurs, celles de votre espace de travail et celles avec lesquelles tourne votre application publiée. Elles se synchronisent, donc un secret que vous ajoutez atteint normalement le déploiement. Ce que l’application en ligne utilise réellement, en revanche, c’est ce qui était là la dernière fois que vous l’avez publiée. Ajoutez un secret après, et l’application en marche n’en saura rien jusqu’à votre prochaine publication.

Le guide de dépannage de Replit pour une application qui marche dans l’éditeur et casse une fois publiée commence exactement à cet endroit : cela vaut donc la peine d’ouvrir les secrets de déploiement et d’en lire les noms avant de conclure que quoi que ce soit est cassé. Un nom écrit OPENAI_KEY d’un côté et OPENAI_API_KEY de l’autre produit la même valeur vide qu’un secret absent.

Un déploiement qui échoue à minuit, c’est le moment où l’on prend le raccourci. Coller la valeur directement dans le code débloque la situation en quelques secondes, l’application revient, et la clé est dans votre paquet publié à partir de cet instant.

La clé est déjà dans mon application publiée. Et maintenant ?

Faites-la tourner, avant de changer la moindre ligne de code. Dans le tableau de bord du fournisseur, générez une nouvelle clé et révoquez l’ancienne.

Cet ordre compte, parce que la rotation est la seule étape qui rend inopérante la valeur exposée. Modifier votre code la retire de la version actuelle et la laisse dans l’historique de votre projet, et cela ne fait absolument rien contre les copies de votre paquet déjà téléchargées, mises en cache et parcourues. Que votre application soit petite n’aide pas non plus : des robots lisent en continu les sites publics à la recherche de chaînes ayant la forme d’une clé, sans la moindre idée de qui vous êtes.

Ensuite, dans cet ordre :

1. Mettez la nouvelle clé dans Secrets et lisez-la uniquement depuis du code serveur.
2. Déplacez l’appel qui en avait besoin. Tout ce qui parle à OpenAI, Anthropic, Stripe ou à votre base de données avec une clé d’administration a sa place derrière une route que votre application appelle, pour que le navigateur interroge votre serveur et que votre serveur détienne la clé.
3. Regardez les pages d’usage et de facturation du fournisseur pour la période où l’ancienne clé était publique. La rotation arrête ce qui va se passer et ne dit rien de ce qui s’est déjà passé.

Les clés de fournisseurs de modèles sont les premières à vérifier sur Replit. OPENAI_API_KEY est l’exemple auquel recourt la documentation de Replit quand elle vous montre comment ajouter un secret, et il n’existe pas de variante publiable d’une clé OpenAI ou Anthropic. Chacune facture directement votre compte.

Un endroit de plus à regarder pendant que vous y êtes : si votre projet publie des source maps, un visiteur peut lire ce paquet comme les fichiers d’origine que vous avez écrits, avec vos propres noms de variables encore dessus.

Ce qu’il faut faire cette semaine

Faites la recherche d’abord. Elle prend une minute, ne demande rien à installer et vous dit lesquelles des clés de votre projet sont déjà publiques. La checklist de sécurité en 10 minutes couvre le reste de ce qu’il vaut la peine de vérifier sur une application fraîchement lancée, et le guide en langage clair pour cette plateforme est votre application Replit est-elle sûre ?.