L'hésitation du premier jour
J'ai la clé copiée dans le presse-papier. Le fichier de code est ouvert devant moi. Et je me demande : là, concrètement, où est-ce qu'on la colle ?
C'est une question bête, en apparence. La clé sert à connecter mon app à Anthropic. Le code doit parler à Anthropic. Logique de la mettre dans le code, non ?
Sauf que non. Et cette hésitation, je suis contente de l'avoir eue, parce qu'elle m'a forcée à chercher la bonne réponse avant de faire la mauvaise chose.
Une clé API, c'est un mot de passe. Pas une configuration, pas un paramètre, pas une préférence. Un mot de passe. Celui qui l'a peut facturer sur ton compte Anthropic, accéder à tes données Supabase, consommer ton quota image sur Nano Banana. La question de où on la met n'est pas une question d'organisation. C'est une question d'accès.
Le mauvais réflexe, et pourquoi il est tentant
Le mauvais réflexe, c'est de coller la clé directement dans le fichier. Juste là, en clair, entre guillemets, à côté du nom du service. Ça fonctionne immédiatement. L'app tourne. Et on se dit qu'on verra plus tard pour ranger ça proprement.
J'ai failli le faire. La clé était dans le presse-papier, le fichier était ouvert, Claude Code venait de me générer exactement le bout de code dont j'avais besoin avec un emplacement marqué VOTRE_CLE_ICI. Un copier-coller et c'était réglé.
Le problème, c'est l'article 5.
Si tu as suivi la série depuis le début, tu sais que ton code vit sur GitHub, la plateforme qui sauvegarde et synchronise ton projet. GitHub, c'est ce qui te permet de ne jamais perdre une version de ton travail, de revenir en arrière si quelque chose casse, et plus tard de déployer ton app. Tout ce que tu pousses sur GitHub est potentiellement lisible. Par toi, par des collaborateurs, et selon la visibilité de ton dépôt, par n'importe qui.
Une clé collée dans un fichier de code, c'est une clé qui part sur GitHub à la prochaine synchronisation. Et une clé qui est passée sur GitHub, même une seule fois, même si tu l'effaces ensuite, elle est dehors. Les services de surveillance automatique qui scannent GitHub en permanence à la recherche de clés exposées sont rapides. Très rapides. Anthropic en a un. Stripe en a un. La plupart des grands fournisseurs aussi. La clé est révoquée avant que tu aies eu le temps de réaliser ce qui s'est passé.
Donc non, pas dans le code. Même pour tester. Surtout pour tester, en fait, parce que les fichiers de test sont souvent les premiers à partir sur GitHub sans qu'on y pense.
Le coffre et le code : deux endroits, deux rôles
La règle tient en une phrase : le coffre contient les valeurs, le code contient les noms.
Le coffre, c'est l'espace sécurisé qui vit côté serveur, jamais dans les fichiers de ton projet. Dans la console Supabase, tu l'as croisé à l'article 10 : c'est l'onglet qui s'appelle Secrets, dans les paramètres de ton projet. C'est là que vivent les clés. Elles y sont chiffrées, elles ne partent jamais sur GitHub, et seul ton app peut y accéder au moment où elle en a besoin.
Dans le code, à la place de la valeur réelle, tu mets un nom. ANTHROPIC_API_KEY. NANO_BANANA_API_KEY. SUPABASE_URL. Ces noms sont des variables d'environnement, c'est le terme que tu entendras souvent dans ce contexte. Le code dit : va chercher la clé qui s'appelle ANTHROPIC_API_KEY. Le coffre répond avec la valeur. La valeur ne passe jamais par le code.
Le code peut être lu par tout le monde. Le coffre, non.
C'est tout. C'est vraiment tout.
La config de Pimpela, pour de vrai
Pour rendre ça concret, voilà comment Pimpela est câblée.
Quand tu prends une photo de ton salon et que tu demandes à l'app de te montrer à quoi il pourrait ressembler avec une déco scandinave et un budget bricolage raisonnable, trois choses se passent en parallèle.
Anthropic pour le texte
Anthropix génère le plan d'action : quoi repeindre, quoi chiner, quoi fabriquer soi-même, dans quel ordre. C'est un appel au modèle Claude via l'API Anthropic. Pour que cet appel fonctionne, le code a besoin d'une clé Anthropic.
Dans le code de Pimpela, on voit ça :
const anthropicKey = process.env.ANTHROPIC_API_KEY
Le code dit : va chercher la valeur qui s'appelle ANTHROPIC_API_KEY dans l'environnement. Dans le coffre, cette valeur existe. Elle ressemble à une longue chaîne de caractères qui commence par sk-ant-. Elle n'apparaît nulle part dans le code.
Nano Banana pour l'image
Nano Banana est le service qui produit le rendu visuel : la photo transformée de ton salon, avec les nouvelles couleurs, le nouveau mobilier, la nouvelle ambiance. C'est un service d'image par IA, accessible via une clé API.
Dans le code :
const nanoBananaKey = process.env.NANO_BANANA_API_KEY
Même logique. Le nom est dans le code. La valeur est dans le coffre.
Supabase pour le stockage
Supabase stocke les photos, les rendus générés, les données utilisateur. C'est la base de données et le stockage de fichiers de Pimpela. Pour que le code puisse y écrire et y lire, il a besoin d'une URL et d'une clé d'accès.
Dans le code :
const supabaseUrl = process.env.SUPABASE_URL const supabaseKey = process.env.SUPABASE_ANON_KEY
Trois services. Quatre noms dans le code. Zéro valeur.
Dans le coffre Supabase de Pimpela, il y a quatre entrées. Chacune a un nom qui correspond exactement à ce que le code va chercher. Quand l'app tourne, elle lit le coffre, récupère les valeurs, les utilise en mémoire, et ne les écrit nulle part.
Quand Claude Code propose une clé en dur
Ça arrive. Claude Code génère un bout de code et il met une clé directement dedans, ou il laisse un emplacement du type YOUR_API_KEY_HERE en supposant que tu vas compléter.
C'est normal. Claude Code produit du code qui fonctionne, et parfois il prend le chemin le plus court pour te montrer comment ça marche. Ce n'est pas une erreur de sa part, c'est une invitation à faire le bon geste.
Le réflexe que j'ai installé : dès que je vois une clé en dur ou un emplacement de clé dans le code généré, je dis à Claude de la sortir dans Secrets. Littéralement, je lui écris : "Cette clé doit vivre dans les Secrets du projet, pas dans le code. Modifie pour appeler la variable d'environnement."
Claude comprend immédiatement. Il remplace la valeur par process.env.NOM_DE_LA_CLE, il me dit quel nom créer dans le coffre, et parfois il me donne les étapes pour l'y ajouter si c'est un service qu'on n'a pas encore configuré.
Ça prend trente secondes. C'est le genre de trente secondes qui évitent une révocation de clé en plein test, un quota consommé par quelqu'un d'autre, ou un accès non voulu à ta base de données.
Le bon réflexe n'est pas de vérifier si Claude a mis la clé en dur. C'est de supposer qu'il l'a fait et de lui demander de corriger avant de continuer. Au bout de quelques articles, ça devient automatique.
Ce que le coffre rendra possible à l'article suivant
À l'article 13, on parle de MCP, le protocole qui permet à Claude de parler directement à tes outils : ton agenda, ta boîte mail, ta base de données, tes services métier. Pour que Claude puisse y accéder, il a besoin de clés. Ces clés, c'est le coffre qui les lui fournira.
Si les clés de Pimpela vivent dans le code, cette architecture ne fonctionne pas. Si elles vivent dans le coffre, Claude peut y accéder de façon contrôlée, sans que les valeurs transitent par des endroits qu'elles ne devraient pas traverser.
L'infrastructure propre n'est pas une fin en soi. C'est ce qui rend la suite possible.