Où sont vos clés API dans le code généré par l'IA ?

Une clé API est un jeton d'authentification unique permettant à votre application de communiquer avec un service externe (Stripe, OpenAI, Resend).

La règle d'or : distinguez toujours les clés publiques (ex. pk_test_... chez Stripe, conçues pour être chargées dans le navigateur) des clés secrètes (ex. sk_live_..., qui confèrent un accès administrateur complet et ne doivent jamais quitter le serveur).

Le vibe coding est une approche où le développeur pilote la création de fonctionnalités en langage naturel avec un agent IA (Cursor, Windsurf, Claude Code, GitHub Copilot). L'humain formule l'intention et supervise, tandis que le modèle génère, refactore et assemble le code.

Plateformes de développement assisté par IA qui permettent de générer et déployer des applications complètes directement depuis votre navigateur.

Le point d'attention : bien que ces environnements simplifient la création, ils génèrent majoritairement du code frontend. Sans configuration serveur explicite, toute clé API injectée par l'IA dans ces outils se retrouve exposée dans le navigateur des utilisateurs.

La distinction physique fondamentale du web :

• Client-side (Frontend) : Tout le code qui s'exécute sur la machine ou le smartphone du visiteur (dans Chrome, Safari). Tout y est public et inspectable.
• Server-side (Backend) : Le code qui s'exécute sur un serveur distant privé (Node.js, Vercel, Supabase). C'est le seul endroit où vos secrets sont protégés.

Fichier texte placé à la racine d'un projet Git qui liste tous les fichiers et dossiers que Git doit ignorer et ne jamais suivre.

Le piège de l'historique : si vous commitez un fichier .env une seule fois sur GitHub, la clé est enregistrée dans l'historique permanent. Même si vous supprimez le fichier lors du commit suivant ou l'ajoutez au .gitignore plus tard, la clé reste visible dans l'historique des versions !

Un fichier texte caché (comme .env.local) placé à la racine de votre projet, utilisé pour stocker vos clés et secrets sous forme de paires clé-valeur sans les écrire en dur dans le code source.

Un proxy backend léger est une barrière intermédiaire minimale (comme une Server Action Next.js ou une Edge Function serverless). Il reçoit les requêtes du navigateur, y injecte les clés secrètes côté serveur à l'abri du client, puis appelle l'API distante. Le navigateur n'a ainsi jamais connaissance de la clé.

Le Row Level Security est une barrière de protection intégrée directement au moteur de base de données (comme Supabase / PostgreSQL). Même si une requête cliente parvient à interroger la table avec la clé publique anon, le RLS garantit que chaque utilisateur ne peut lire et modifier que ses propres données.

Fichiers de configuration déposés à la racine du projet qui dictent des consignes strictes et persistantes à l'agent IA (par exemple : interdire la lecture des fichiers .env, forcer l'usage de Server Actions, refuser l'installation de dépendances non auditées).

Le VibeOps regroupe les pratiques, outils et protocoles de gouvernance opérationnelle appliqués au code généré par IA. Il combine pare-feu de prompt en temps réel, linters de sécurité et revues automatiques pour sécuriser le cycle de vie du vibe coding.

Technique de cyberattaque consistant à surveiller les noms de bibliothèques logicielles inventés (hallucinés) de manière récurrente par les modèles d'IA, puis à créer ces faux paquets sur npm ou PyPI avec un script malveillant pour infecter les développeurs qui exécutent la commande suggérée.