Vibe coding : le code généré par IA est-il sûr ?

Qu’est-ce que le vibe coding ?

Le terme a été forgé début 2025 par le chercheur en IA Andrej Karpathy : vous décrivez ce que vous voulez, l’IA écrit le code, et vous ne le lisez presque plus. Ce qui fonctionne reste. Avec des outils comme Cursor, Claude Code, GitHub Copilot, Lovable ou Bolt, des applications voient le jour en quelques heures, là où une équipe mettait des semaines.

C’est un vrai progrès. Le risque ne vient pas de l’IA, mais de l’absence d’un second regard. Un code que personne n’a lu, personne ne l’a vérifié.

Ce que montrent les études

Veracode fait résoudre à des modèles de langage 80 tâches de programmation qui admettent chacune une solution sûre et une solution vulnérable. Dans le premier rapport, en 2025, portant sur plus de 100 modèles, ceux-ci ont choisi la variante vulnérable dans 45 % des cas et introduit une faille connue de l’OWASP Top 10. L’édition de juillet 2026 ne montre guère de progrès : en moyenne, seuls 56 % du code généré par IA passent les tests de sécurité, et 44 % contiennent une faille connue. Même le meilleur modèle plafonne à 68 %. Les grands modèles ne sont guère plus sûrs que les petits.

Les modèles sont optimisés pour produire du code qui fonctionne, pas du code sûr. Et ils apprennent à partir de code public dans lequel les mêmes erreurs se répètent des millions de fois.

Les cinq failles typiques du code IA

Nous retrouvons ces schémas encore et encore dans les applications générées par IA :

1. Absence de contrôle d’accès. L’endpoint /api/factures/123 renvoie la facture. En remplaçant le numéro par 124, on obtient la facture d’un autre client. L’IA a construit un endpoint qui fonctionne, mais qui ne vérifie pas à qui appartient l’enregistrement. C’est la première place de l’OWASP Top 10:2025.
2. Secrets dans le code. Clés d’API, mots de passe de base de données ou jetons figurent en clair dans le code source, ou le fichier .env finit dans le dépôt. Ce qui entre dans l’historique Git y reste. Changez donc immédiatement les clés concernées.
3. Configurations par défaut non sécurisées. CORS ouvert à tous les domaines, mode debug actif, en-têtes de sécurité manquants, règles Supabase ou Firebase sans Row Level Security.
4. Injection. Les requêtes SQL sont construites à partir des saisies utilisateur, le HTML est affiché sans filtrage. Résultat : injection SQL et cross-site scripting.
5. Paquets inventés ou obsolètes. Les modèles proposent des bibliothèques qui n’existent pas. Des attaquants peuvent enregistrer précisément ces noms et y déposer du code malveillant (« slopsquatting »). S’y ajoutent des versions obsolètes avec des CVE connues. L’OWASP Top 10:2025 a donc élargi l’ancienne catégorie des composants obsolètes en A03 Software Supply Chain Failures.

Pourquoi vos tests ne les détectent pas

Les tests fonctionnels vérifient que l’application fait ce qu’elle doit faire. Les failles naissent là où elle fait ce qu’elle ne devrait pas faire. Si l’utilisateur B voit les données de l’utilisateur A, aucun test n’échoue : la page se charge, les données sont bien formatées, tout est au vert.

C’est pourquoi le code IA a besoin d’une étape de contrôle qui raisonne autrement que le code qui l’a produit.

Utiliser le code IA en toute sécurité

Inutile de renoncer à l’IA. Il vous faut quelques garde-fous fixes :

• La sécurité dans le prompt. Exigez explicitement : contrôle des droits sur chaque endpoint, requêtes paramétrées, aucun secret dans le code, validation des saisies.
• Un scanner de secrets avant chaque commit. Des outils comme gitleaks tournent en hook pre-commit et bloquent les clés avant qu’elles n’atteignent le dépôt.
• Vérifier les dépendances. Contrôler chaque nouveau paquet dans le registre officiel et face aux vulnérabilités connues, par exemple avec osv-scanner. Figer les versions avec un fichier de verrouillage (lockfile).
• Analyse statique dans la CI. semgrep ou un outil comparable détecte automatiquement les motifs à risque à chaque pull request.
• Tester l’accès avec deux comptes. Connectez-vous en tant qu’utilisateur A et essayez d’ouvrir les données de l’utilisateur B. Ce test simple révèle de nombreux cas de la faille la plus fréquente.
• Une revue indépendante avant la mise en ligne. Quelqu’un qui n’a pas écrit le code, humain ou agent de contrôle autonome, le relit avec une question : comment peut-on en abuser ?

Quand un audit s’impose

Un audit externe a du sens dès que votre application construite avec l’IA gère des connexions, des données clients ou des paiements. Moments typiques : juste avant le lancement, avant un rendez-vous avec des investisseurs ou lorsqu’un client exige une preuve de sécurité.

Notre audit de code lit votre dépôt en lecture seule, analyse le code selon l’OWASP Top 10:2025 et documente chaque constat avec son emplacement, sa note CVSS et une recommandation concrète. Au forfait de 890 € HT, en 2 jours ouvrés. Le fournisseur d’IA ne s’entraîne pas sur votre code. Un audit de code n’est ni un test d’intrusion ni un test de charge. La différence est expliquée dans notre article audit de code ou test d’intrusion.

Cet article a été rédigé avec l’aide de recherches automatisées et de l’IA. David Kreutzer l’a relu et validé le 1 novembre 2026.