Comment protéger vos mots de passe et vos clés d’API quand vous créez avec l’IA?

Quand vous créez une application avec un outil d’IA, les secrets circulent dans des endroits où ils n’allaient jamais auparavant. Vous collez un message d’erreur dans une conversation, et il contient un mot de passe de base de données. Un agent lit tout le dossier de votre projet, fichier .env compris. Une interface créée par vibe coding appelle une API directement depuis le navigateur, si bien que la clé est envoyée à chaque visiteur. Rien de tout cela n’est exotique : c’est la façon la plus courante dont les petits projets bâtis avec l’IA s’attirent des ennuis.

La bonne nouvelle, c’est que quelques habitudes, mises en place une seule fois, couvrent l’essentiel du risque. L’idée est simple : les secrets vivent à un seul endroit, l’IA ne les voit jamais, et une vérification automatique les empêche de quitter votre ordinateur.

Qu’est-ce qui compte comme un secret?

Un secret, c’est tout ce qui permet à quelqu’un d’agir en votre nom ou au nom de votre application : les clés d’API (pour OpenAI, Anthropic, Stripe, etc.), les mots de passe et chaînes de connexion de bases de données, les clés privées, les jetons d’accès, et les clés d’administration ou service role que fournissent des plateformes de bases de données comme Supabase. Certaines clés sont conçues pour être publiques, par exemple une clé anon de Supabase dans une page Web, mais elles ne sont sûres que si la base de données derrière elles applique des règles d’accès strictes. Traitez tout le reste comme privé.

Le cas de Moltbook, au début de 2026, montre comment les choses tournent mal. Moltbook était un réseau social pour agents d’IA. L’entreprise de sécurité Wiz y a trouvé une clé de base de données visible dans le JavaScript du site, sans sécurité au niveau des lignes (des règles qui limitent chaque utilisateur à ses propres lignes) derrière elle. N’importe qui pouvait lire et modifier les données de production, dont environ 1,5 million de jetons d’API d’agents, quelque 35 000 adresses courriel et des messages privés, dont certains contenaient en clair des clés d’API d’autres entreprises. Moltbook a corrigé le problème en quelques heures après avoir été averti, mais les clés avaient déjà été lisibles.

Une configuration qui garde les clés hors de portée

Voici une routine qui fonctionne avec Claude Code, Codex, Cursor et la plupart des autres agents de programmation.

Étape 1 : mettre les secrets dans un fichier .env, jamais dans le code. Votre code les lit comme des variables d’environnement (process.env.STRIPE_KEY en JavaScript, os.environ["STRIPE_KEY"] en Python). Ajoutez .env au fichier .gitignore pour que Git ne le valide jamais, et validez plutôt un .env.example aux valeurs vides pour que les autres sachent quels noms définir.

Étape 2 : interdire à l’agent de lire les secrets. Les fichiers d’instructions aident, mais une règle de permission est plus solide, parce que c’est l’outil qui l’applique. La documentation de Claude Code d’Anthropic donne exactement cet exemple pour un fichier de paramètres :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Enregistrez-le dans ~/.claude/settings.json (pour tous vos projets) ou dans le fichier .claude/settings.json du projet, puis lancez /status dans Claude Code pour confirmer qu’il a été chargé. Les autres agents ont des réglages semblables pour ignorer des fichiers ou fixer des permissions; vérifiez les vôtres.

Étape 3 : activer l’analyse des secrets avant votre premier push. La protection des push de GitHub (push protection) analyse ce que vous poussez et bloque un push qui contient un identifiant reconnu, en expliquant pourquoi, pour que vous puissiez le retirer et réessayer. Pour votre compte personnel, elle est activée par défaut pour les dépôts publics; pour un dépôt, une personne administratrice doit l’activer dans les paramètres de sécurité. Toute personne ayant un accès en écriture peut quand même contourner un blocage en donnant une raison : prenez donc un blocage pour un véritable avertissement.

Étape 4 : garder les secrets hors des conversations. Avant de coller des journaux ou des messages d’erreur dans un outil d’IA, cherchez-y les clés et chaînes de connexion et remplacez-les par [REDACTED]. Si une clé a déjà été collée, validée dans Git ou visible dans une capture d’écran, révoquez-la chez le fournisseur et créez-en une nouvelle.

Vous pouvez demander à l’agent de vous aider à mettre tout cela en place sans jamais lui confier les valeurs :

Configure ce projet pour que les secrets ne soient jamais stockés dans le code.
1. Trouve chaque clé, jeton, mot de passe ou chaîne de connexion écrit en dur et remplace-le par une variable d’environnement lue à l’exécution.
2. Crée un .env.example qui liste les noms de variables avec des valeurs vides, et assure-toi que .env est dans .gitignore.
3. N’ouvre pas, n’affiche pas et ne me demande pas le contenu de .env. Dis-moi quelles variables je dois remplir moi-même.
4. Fais la liste des clés utilisées dans le code exécuté par le navigateur, et explique si elles sont censées être publiques.

À quoi ne faut-il jamais donner accès à un agent d’IA?

Un agent fait ce que ses permissions lui permettent, y compris des choses que vous n’aviez pas prévues, si un prompt est mal compris ou si un texte qu’il lit (une page Web, un ticket, un fichier) contient des instructions cachées. Fixez donc ses limites en vous demandant : « Quel est le pire que cet accès permettrait? »

Gardez ceci loin de tout agent de programmation :

• Les bases de données et les clés de production. Donnez-lui une copie de développement avec des données fictives. S’il doit vraiment toucher la production, utilisez un compte en lecture seule limité aux tables nécessaires.
• Les identifiants de paiement et bancaires, y compris les clés réelles de Stripe ou de PayPal. Utilisez le mode test du fournisseur.
• Votre gestionnaire de mots de passe, votre courriel et vos comptes infonuagiques personnels. Un agent qui peut lire vos courriels peut être piégé par un courriel.
• Les identifiants d’administration ou de propriétaire infonuagiques qui peuvent créer, supprimer ou facturer des ressources. Créez une clé restreinte pour chaque tâche.
• Un accès non révisé à main ou aux déploiements. Laissez l’agent travailler sur une branche; c’est vous qui fusionnez et déployez.

Donnez-lui plutôt un bac à sable ou un dossier séparé, des clés de test avec des plafonds de dépenses, et des règles de permission qui demandent votre accord avant de lancer des commandes que vous n’avez pas approuvées. Si l’agent a besoin d’un vrai identifiant pour terminer une tâche, c’est le signal que cette étape vous revient.