Le vibe coding a changé la donne. En quelques heures, n'importe qui peut générer une application fonctionnelle avec l'aide d'une IA, sans écrire une ligne de code soi-même. Mais voilà le problème : « fonctionnelle » ne veut pas dire « sécurisée ». Une application qui marche en démo peut être une passoire en production. Et contrairement aux bugs visuels, les failles de sécurité ne se voient pas — jusqu'au jour où quelqu'un les exploite.
La bonne nouvelle, c'est que l'IA qui a généré votre code peut aussi vous aider à le sécuriser. Encore faut-il savoir quoi lui demander. Voici le guide des vérifications essentielles à exiger de votre assistant IA avant de cliquer sur « Deploy ».
Pourquoi le code généré par IA est particulièrement vulnérable
L'IA optimise pour ce que vous demandez. Si vous demandez « une page de connexion », vous obtenez une page de connexion qui fonctionne — pas nécessairement une page de connexion qui résiste à une attaque par force brute, qui hache correctement les mots de passe ou qui protège contre les injections.
Trois facteurs aggravent le risque en vibe coding :
Le développeur ne lit pas (ou ne comprend pas) le code généré, donc personne ne repère les raccourcis dangereux. L'IA reproduit parfois des patterns obsolètes ou des exemples simplifiés issus de tutoriels, conçus pour la pédagogie et non pour la production. Enfin, l'enthousiasme du prototype qui marche pousse à déployer vite, en sautant l'étape de revue.
Le remède : transformer l'IA en auditeur de son propre code, avec des demandes précises.
1. Demandez un audit des secrets et des clés API
C'est l'erreur numéro un du vibe coding : des clés API, des mots de passe de base de données ou des tokens codés en dur dans le code source, puis poussés sur un dépôt GitHub public. Des bots scannent GitHub en permanence pour récolter ces secrets — une clé exposée peut être exploitée en quelques minutes.
Ce qu'il faut demander à l'IA :
« Analyse tout mon code et identifie chaque secret, clé API, token ou identifiant codé en dur. Déplace-les tous dans des variables d'environnement et vérifie que mon fichier .env est bien dans le .gitignore. »
Pour un projet Next.js, demandez aussi de vérifier la distinction entre les variables préfixées NEXT_PUBLIC_ (exposées au navigateur) et les autres (côté serveur uniquement). Une clé secrète préfixée NEXT_PUBLIC_ par erreur se retrouve dans le bundle JavaScript envoyé à tous les visiteurs — autant la publier sur Twitter.
Si un secret a déjà été commité, le retirer du code ne suffit pas : il reste dans l'historique Git. Demandez à l'IA de vous guider pour révoquer et régénérer la clé compromise.
2. Exigez une validation des entrées côté serveur
Règle d'or : ne jamais faire confiance à ce qui vient du client. Toute donnée envoyée par un utilisateur — formulaire, paramètre d'URL, en-tête HTTP, corps de requête — peut être manipulée. La validation côté client (dans le navigateur) améliore l'expérience utilisateur, mais ne protège rien : elle se contourne en quelques secondes avec les outils de développement.
Ce qu'il faut demander à l'IA :
« Liste tous mes points d'entrée (API routes, server actions, formulaires) et vérifie que chaque donnée reçue est validée côté serveur : type, format, longueur, valeurs autorisées. Ajoute une validation avec Zod là où elle manque. »
En Next.js, les Server Actions et les Route Handlers sont vos points d'entrée critiques. Un schéma Zod à l'entrée de chacun constitue une première ligne de défense simple et robuste.
3. Faites vérifier l'authentification ET l'autorisation
Ce sont deux choses différentes, et l'IA confond souvent les deux. L'authentification répond à « qui êtes-vous ? ». L'autorisation répond à « avez-vous le droit de faire ça ? ». Beaucoup d'applications vibe-codées vérifient que l'utilisateur est connecté, mais pas qu'il a le droit d'accéder à la ressource demandée.
L'exemple classique : une route /api/factures/42 qui vérifie que vous êtes connecté, mais pas que la facture 42 vous appartient. Il suffit de changer le numéro dans l'URL pour lire les factures des autres. Cette faille porte un nom — IDOR (Insecure Direct Object Reference) — et elle est partout dans le code généré rapidement.
Ce qu'il faut demander à l'IA :
« Pour chaque route et chaque action qui accède à des données, vérifie deux choses : 1) que l'utilisateur est authentifié, et 2) que la ressource demandée lui appartient bien ou qu'il a le rôle requis. Montre-moi chaque endroit où la vérification de propriété manque. »
Attention au piège spécifique de Next.js : le middleware ne suffit pas comme unique barrière d'authentification. La vérification doit se faire au plus près de la donnée, dans chaque Server Action et Route Handler.
4. Demandez une protection contre les injections
Les injections SQL restent dans le top des vulnérabilités mondiales, des décennies après leur découverte. Le principe : un utilisateur glisse du code malveillant dans un champ de saisie, et votre application l'exécute. Résultat possible : lecture, modification ou suppression de toute votre base de données.
Ce qu'il faut demander à l'IA :
« Vérifie que toutes mes requêtes vers la base de données utilisent des requêtes paramétrées ou un ORM, et qu'aucune requête n'est construite par concaténation de chaînes avec des données utilisateur. Vérifie aussi les risques d'injection dans les commandes shell et les chemins de fichiers. »
Si vous utilisez Prisma ou Drizzle avec Next.js, le risque est largement réduit par défaut — mais demandez quand même à l'IA de traquer les usages de $queryRaw ou de SQL brut, où le danger réapparaît.
5. Faites auditer les failles XSS
Le Cross-Site Scripting (XSS) consiste à injecter du JavaScript malveillant qui s'exécutera dans le navigateur de vos autres utilisateurs : vol de session, redirection vers des sites de phishing, actions effectuées à leur insu.
React et Next.js échappent le contenu par défaut, ce qui protège contre la majorité des cas. Mais il existe une porte dérobée au nom explicite : dangerouslySetInnerHTML. L'IA l'utilise volontiers pour afficher du contenu riche (Markdown converti en HTML, contenu de CMS, commentaires formatés).
Ce qu'il faut demander à l'IA :
« Trouve tous les usages de dangerouslySetInnerHTML dans mon projet. Pour chacun, vérifie si le contenu peut provenir d'un utilisateur, et si oui, ajoute une sanitisation avec DOMPurify. Vérifie aussi les attributs href construits dynamiquement (risque de javascript:). »
6. Exigez la configuration des en-têtes de sécurité et du rate limiting
Deux protections souvent absentes du code généré, parce qu'elles ne changent rien au fonctionnement visible de l'application.
Les en-têtes de sécurité HTTP (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security…) sont des instructions données au navigateur pour limiter les attaques. Le rate limiting, lui, empêche un attaquant de marteler vos endpoints : essais de mots de passe en boucle, scraping massif, ou simplement épuisement de votre quota d'API payante — particulièrement douloureux si votre application appelle une API d'IA facturée à l'usage.
Ce qu'il faut demander à l'IA :
« Configure les en-têtes de sécurité recommandés dans mon next.config.js et explique-moi chacun. Ajoute ensuite un rate limiting sur mes routes sensibles : connexion, inscription, réinitialisation de mot de passe, et toute route qui appelle une API externe payante. »
7. Demandez une revue des dépendances
Votre code peut être irréprochable, ses dépendances non. Un package npm vulnérable ou malveillant compromet toute l'application. Et l'IA a deux travers connus : suggérer des versions obsolètes de bibliothèques, et parfois « halluciner » des noms de packages qui n'existent pas — noms que des attaquants enregistrent ensuite avec du code malveillant (une technique appelée slopsquatting).
Ce qu'il faut demander à l'IA :
« Liste toutes les dépendances de mon package.json. Vérifie que chacune existe réellement, est activement maintenue et ne fait pas l'objet de vulnérabilités connues. Identifie celles qui sont inutilisées et peuvent être supprimées. »
Complétez par un npm audit avant chaque déploiement, et activez Dependabot sur votre dépôt GitHub pour être alerté automatiquement.
8. Faites la chasse aux fuites d'informations
Les messages d'erreur trop bavards sont une mine d'or pour un attaquant : stack traces qui révèlent la structure du code, messages de base de données qui exposent le schéma, ou réponses d'API qui renvoient des objets entiers avec des champs sensibles (mots de passe hachés, tokens, données personnelles d'autres utilisateurs).
Ce qu'il faut demander à l'IA :
« Vérifie que mes réponses d'API ne renvoient que les champs strictement nécessaires au client, jamais l'objet complet de la base de données. Vérifie aussi que les erreurs renvoyées en production sont des messages génériques, et que les détails techniques partent uniquement dans les logs serveur. »
Vérifiez aussi les console.log oubliés : en Next.js, ceux des composants client s'exécutent dans le navigateur de l'utilisateur, visibles par tous.
Le prompt d'audit final avant déploiement
Une fois ces points traités individuellement, terminez par un audit global. Voici un prompt complet à adapter :
« Agis comme un expert en sécurité applicative effectuant un audit avant mise en production. Analyse l'ensemble de mon projet et vérifie systématiquement : les secrets exposés ou mal gérés, la validation des entrées côté serveur, l'authentification et l'autorisation sur chaque route (y compris les failles IDOR), les risques d'injection (SQL, commandes, chemins), les failles XSS, la configuration des en-têtes de sécurité, le rate limiting des routes sensibles, les fuites d'informations dans les erreurs et les réponses d'API, et les dépendances vulnérables. Pour chaque problème trouvé, indique : le fichier et la ligne concernés, le niveau de gravité (critique, élevé, moyen, faible), une explication du risque en termes simples, et le correctif à appliquer. Classe les résultats par gravité décroissante. »
Astuce : lancez cet audit dans une nouvelle conversation, avec une IA qui n'a pas généré le code. Un modèle qui vient d'écrire du code a tendance à le défendre ; un regard neuf est plus critique. Faire auditer par un second outil (Claude Code, par exemple, qui peut parcourir tout le dépôt) donne souvent les meilleurs résultats.
Les limites : ce que l'IA ne remplacera pas
Soyons honnêtes : demander à l'IA d'auditer son propre code améliore considérablement la situation, mais ne garantit rien. L'IA peut manquer des failles, notamment les problèmes de logique métier propres à votre application, qu'aucun pattern générique ne détecte.
Quelques garde-fous complémentaires selon les enjeux : des outils d'analyse automatisée (Semgrep, Snyk, CodeQL — souvent gratuits pour les projets open source), les protections natives de votre hébergeur (Vercel et consorts gèrent déjà le HTTPS et offrent des protections DDoS de base), et pour toute application manipulant des paiements ou des données personnelles sensibles, un audit par un professionnel humain. Le RGPD ne fait pas de distinction entre une application vibe-codée et une autre : en cas de fuite de données, votre responsabilité est la même.
En résumé : la checklist avant de déployer
Avant chaque mise en production, demandez à votre IA de vérifier ces huit points : secrets et variables d'environnement, validation des entrées côté serveur, authentification et autorisation (y compris IDOR), injections, XSS, en-têtes de sécurité et rate limiting, fuites d'informations, dépendances. Puis lancez l'audit global avec un regard neuf.
Le vibe coding démocratise la création d'applications, et c'est une excellente chose. Mais déployer une application, c'est accepter une responsabilité envers ses utilisateurs et leurs données. La sécurité ne demande pas de devenir expert : elle demande de poser les bonnes questions. Maintenant, vous les avez.