Qu'est-ce que les variables d'environnement et les secrets? Guide simple

Une variable d'environnement est un réglage nommé — comme DATABASE_URL ou STRIPE_SECRET_KEY — qui est transmis à votre app 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é d'API, un mot de passe, une clé de signature. Garder ces valeurs hors du code vous permet de les changer sans modifier l'app, 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 crée avec l'IA

Dès que votre app fait quelque chose d'utile avec un autre service — traiter un paiement, envoyer un courriel, appeler un modèle d'IA — elle a besoin d'une clé. Les créateurs d'apps par IA demandent ces clés régulièrement, et l'endroit où la clé se retrouve détermine si votre app est sécuritaire.

Deux erreurs reviennent souvent dans les apps créées par IA :

• La clé est collée dans le clavardage ou dans le code. Elle se retrouve alors dans l'historique de conversation, les fichiers du projet et toute exportation ou tout dépôt de code. 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 outils automatisés cherchent constamment les clés exposées.

Comprendre les variables d'environnement vous permet de repérer ces deux erreurs et de demander la correction.

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

Le code de votre app ressemble à la chambre d'hôtel. Les clients (et le personnel d'entretien, et toute personne à qui vous donnez une carte-clé) y circulent. Vous ne laisseriez pas votre passeport sur le bureau.

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

Comment ça fonctionne

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

L'origine des valeurs dépend de l'endroit où l'app s'exécute :

Variables publiques et secrètes

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

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

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é d'API écrite à l'intérieur. Ça fonctionne 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écuritaire :

1. Vous créez la clé chez le fournisseur d'IA et la conservez comme secret nommé OPENAI_API_KEY (ou similaire) dans les paramètres de votre projet.
2. Le backend possède 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, et non le fournisseur. Le navigateur ne voit jamais la clé.
4. Vous ajoutez le même secret dans les paramètres de l'app publiée, puis redéployez afin que le site en direct en dispose aussi.

Ce modèle — le navigateur appelle votre serveur, qui détient la clé et appelle le service — s'applique aux paiements, aux courriels, aux cartes et à toute autre API payante. Le guide sur l'utilisation des API de LLM approfondit le cas de l'IA.

Termes clés

• Fichier .env : un fichier texte de lignes NOM=valeur utilisé en développement local. Inscrivez-le dans .gitignore pour qu'il ne soit pas versionné.
• .env.example : une copie qui contient les noms mais aucune valeur réelle, versionnée pour que les autres sachent quelles variables définir.
• Renouveler (rotation) : 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 peut seulement envoyer des courriels est moins dangereuse qu'une clé qui peut tout faire.
• Clés de test et clés en production : des fournisseurs comme Stripe vous 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 utilisé pour vérifier qu'un message, comme un webhook, provient bien de l'expéditeur.

Erreurs courantes et idées fausses

• « Mon dépôt est privé, donc les clés qui s'y trouvent sont correctes. » Les dépôts privés sont partagés, bifurqués, exportés et clonés sur des ordinateurs portables. Les clés n'y ont pas leur place. Si vous connectez 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 clavardage conservent les messages. Si une clé a déjà été exposée, renouvelez-la.
• Utiliser un préfixe public sur un secret. VITE_OPENAI_KEY place votre clé dans le paquet du navigateur.
• Oublier de redéployer. Modifier une variable dans les paramètres n'a généralement d'effet qu'après le redémarrage de l'app ou une nouvelle publication.
• Une seule clé pour tout. Des clés distinctes pour les tests et la production, et par app, permettent de révoquer une clé sans casser le reste.
• Aucune limite de dépenses. 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 d'apps par IA

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

Notre liste de vérification de sécurité pour les apps créées par IA traite des secrets avec les autres contrôles à effectuer 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 app publiée. Vous les ajoutez sous paramètres du projet → Secrets ou avec /secrets dans le clavardage. Quand l'agent a besoin d'une clé, il affiche une carte de secrets dans le clavardage, de sorte que la valeur est saisie dans un champ de formulaire plutôt que dans la transcription des messages. Si vous modifiez un secret pour une app en direct, publiez de nouveau pour que le déploiement en tienne compte. Les exportations de projet excluent les secrets, et les fichiers .env importés sont épurés, de sorte que vous les ajoutez de nouveau dans les paramètres. Voir variables d'environnement et secrets et secrets dans le clavardage dans la documentation.

Questions