Variables d'environnement et secrets : le guide simple

Une variable d'environnement est un réglage nommé — comme DATABASE_URL ou STRIPE_SECRET_KEY — qui est transmis à votre application au moment de son exécution, au lieu d'être écrit dans le code. Un secret est une variable d'environnement dont la valeur doit rester privée : une clé API, un mot de passe, une clé de signature. Garder ces valeurs en dehors du code vous permet de les changer sans modifier l'application, d'utiliser des valeurs différentes pour les tests et pour les vrais clients, et d'éviter qu'elles fuient lorsque vous partagez ou publiez votre code.

Pourquoi c'est important quand on construit avec l'IA

Dès que votre application fait quelque chose d'utile avec un autre service — encaisser un paiement, envoyer un e-mail, appeler un modèle d'IA — elle a besoin d'une clé. Les créateurs d'applications par IA demandent ces clés régulièrement, et l'endroit où la clé finit détermine si votre application est sûre.

Deux erreurs fréquentes arrivent dans les applications créées avec l'IA :

• La clé est collée dans le chat ou dans le code. Elle se retrouve alors dans l'historique du chat, les fichiers du projet et tout export ou dépôt. Quiconque la voit peut utiliser votre compte.
• La clé est utilisée dans le navigateur. Si le code qui appelle Stripe ou OpenAI s'exécute dans la page, la clé est envoyée à chaque visiteur. Les gens regardent — et des scanners automatiques cherchent en permanence les clés exposées.

Comprendre les variables d'environnement vous permet de repérer les deux problèmes et de demander la correction.

Une analogie du quotidien : le coffre-fort de l'hôtel

Le code de votre application ressemble à une chambre d'hôtel. Les clients (et le personnel d'entretien, et toute personne à qui vous donnez une carte) y circulent. On ne laisse pas son passeport sur le bureau.

Les variables d'environnement sont le coffre-fort de la chambre. La chambre sait qu'il existe un coffre et comment l'ouvrir au besoin, mais le passeport ne traîne pas. Et si vous changez de chambre — de votre configuration de test vers votre site en production — vous mettez un autre passeport dans le coffre de cette chambre, sans refaire la décoration.

Comment ça marche

Votre code fait référence à un nom, pas à une valeur. En JavaScript côté serveur, cela ressemble à process.env.STRIPE_SECRET_KEY. Au démarrage de l'application, la plateforme sur laquelle elle tourne remplit la valeur correspondant à ce nom. Changez la valeur dans les réglages de la plateforme, redémarrez ou redéployez, et l'application utilise la nouvelle valeur — sans modification du code.

L'origine des valeurs dépend de l'endroit où l'application tourne :

Variables publiques ou secrètes

Toutes les variables d'environnement ne sont pas secrètes. Il est utile de les classer en deux groupes :

Les frameworks web rendent cette séparation explicite. Avec Vite, seules les variables dont le nom commence par VITE_ sont incluses dans le code du navigateur ; avec Next.js, le préfixe est NEXT_PUBLIC_. C'est une protection : tout ce qui porte ces préfixes finit dans les fichiers que chaque visiteur télécharge, donc un secret ne doit jamais en recevoir un.

Un exemple concret : un bouton de résumé par IA

Vous voulez un bouton « Résumer cette note » qui appelle un modèle d'IA.

La version dangereuse : le code du bouton, exécuté dans le navigateur, appelle directement le fournisseur d'IA avec la clé API écrite dedans. Ça marche dans l'aperçu. Mais n'importe qui peut ouvrir les outils de développement du navigateur, copier la clé et faire grimper la facture de votre compte.

La version sûre :

1. Vous créez la clé chez le fournisseur d'IA et la stockez comme secret nommé OPENAI_API_KEY (ou similaire) dans les réglages de votre projet.
2. Le backend dispose d'une route, POST /api/summarise, qui lit process.env.OPENAI_API_KEY, vérifie que l'utilisateur est connecté et appelle le fournisseur.
3. Le bouton appelle votre route, pas le fournisseur. Le navigateur ne voit jamais la clé.
4. Vous ajoutez le même secret dans les réglages de l'application publiée et redéployez, pour que le site en ligne l'ait aussi.

Ce schéma — le navigateur appelle votre serveur, qui détient la clé et appelle le service — s'applique aux paiements, à l'e-mail, aux cartes et à toute autre API payante. Le guide sur l'utilisation des API de LLM traite le cas de l'IA plus en profondeur.

Termes clés

• Fichier .env : un fichier texte contenant des lignes NOM=valeur, utilisé en développement local. Ajoutez-le à .gitignore pour qu'il ne soit pas versionné.
• .env.example : une copie qui contient les noms mais aucune vraie valeur, versionnée pour que les autres sachent quelles variables définir.
• Renouveler (rotate) : remplacer un secret par un nouveau et révoquer l'ancien.
• Portée / permissions : de nombreux fournisseurs permettent de créer des clés qui ne peuvent faire que certaines choses. Une clé qui ne sert qu'à envoyer des e-mails est moins dangereuse qu'une clé qui peut tout faire.
• Clés de test et clés live : des fournisseurs comme Stripe donnent des clés distinctes pour les tests et pour l'argent réel. Utilisez les clés de test jusqu'au lancement.
• Secret de signature : un secret qui permet de vérifier qu'un message, comme un webhook, vient bien de l'expéditeur.

Erreurs courantes et idées reçues

• « Mon dépôt est privé, donc y mettre des clés ne pose pas de problème. » Les dépôts privés sont partagés, forkés, exportés et clonés sur des ordinateurs portables. Les clés n'ont pas leur place là-dedans. Si vous reliez un projet à GitHub, vérifiez qu'aucun fichier .env n'est inclus.
• « Je l'ai supprimée, donc elle n'existe plus. » Git conserve l'historique et les journaux de chat conservent les messages. Si une clé a été exposée à un moment, renouvelez-la.
• Utiliser un préfixe public sur un secret. VITE_OPENAI_KEY place votre clé dans le bundle du navigateur.
• Oublier de redéployer. Modifier une variable dans les réglages ne prend souvent effet qu'après le redémarrage de l'application ou sa nouvelle publication.
• Une seule clé pour tout. Des clés séparées pour le test et le live, et par application, permettent de révoquer l'une sans casser les autres.
• Aucune limite de dépense. Pour les API payantes, fixez un budget ou une limite dans le tableau de bord du fournisseur, au cas où une clé fuirait.

Ce qu'il faut demander à votre créateur par IA

• « Lis la clé secrète Stripe depuis une variable d'environnement nommée STRIPE_SECRET_KEY. Utilise-la uniquement côté serveur. »
• « Assure-toi qu'aucun secret n'est utilisé dans le code côté client ni ne reçoit un préfixe VITE_ ou NEXT_PUBLIC_. »
• « Crée un .env.example qui liste chaque variable dont l'application a besoin, sans valeurs, et assure-toi que .env est ignoré par git. »
• « Vérifie dans les fichiers frontend compilés qu'aucune chaîne ressemblant à une clé API n'apparaît. »

Notre liste de contrôle de sécurité pour les applications créées avec l'IA couvre les secrets ainsi que les autres vérifications à faire avant le lancement.

Les secrets sur Mythex

Sur Mythex, les secrets sont des variables d'environnement du projet, injectées à la fois dans le bac à sable de l'aperçu et dans votre application publiée. Vous les ajoutez dans réglages du projet → Secrets ou avec /secrets dans le chat. Lorsque l'agent a besoin d'une clé, il affiche une carte de secrets dans le chat : la valeur est saisie dans un champ de formulaire et n'apparaît pas dans la transcription. Si vous modifiez un secret pour une application en ligne, publiez à nouveau pour que le déploiement le prenne en compte. Les exports de projet excluent les secrets, et les fichiers .env importés sont retirés : vous les ressaisissez dans les réglages. Voir variables d'environnement et secrets et secrets dans le chat dans la documentation.

Questions