200 apps auditées, 9 sur 10 vulnérables : la dette du vibe coding

200 applications vibe-codées auditées au premier trimestre 2026. 91,5 % d’entre elles contiennent au moins une vulnérabilité traçable à une hallucination de l’IA. Pour dix fonctionnalités qui marchent, neuf sont exploitables. Et pendant ce temps, la plateforme Lovable a laissé une faille critique exposée pendant 48 jours avant de la reconnaître publiquement.

Si vous utilisez Lovable, Bolt, v0, Base44 ou Claude Code pour livrer des produits clients, ces chiffres ne sont plus une statistique abstraite. C’est votre prochaine due diligence.

Le chiffre choc : 91,5 % vulnérables

L’audit, mené sur plus de 200 applications déployées en production, est cohérent avec les autres mesures de l’industrie. La Cloud Security Alliance a publié le 4 avril 2026 sa research note sur la vague de vulnérabilités du code IA, qui cite une analyse Escape.tech sur 1 400 apps vibe-codées : 2 038 vulnérabilités critiques identifiées, plus de 400 secrets fuités, 175 cas de données personnelles exposées.

Veracode, sur 100 modèles de langage testés, trouve 45 % de code IA porteur d’une faille OWASP Top 10. DryRun Security, sur 30 pull requests générées par Claude Code, OpenAI Codex et Google Gemini, identifie 87 % de PR avec au moins une faille, 143 problèmes au total.

Le constat est convergent. Le vibe coding produit du code qui passe les tests fonctionnels et échoue les audits de sécurité.

Les quatre vulnérabilités qui reviennent toujours

Sur les 200 apps auditées, les classes de failles sont les mêmes que celles déjà documentées dans les 35 CVE de mars, mais à plus grande échelle :

• BOLA (Broken Object-Level Authorization) : un utilisateur authentifié peut accéder aux données d’un autre. Le bug numéro un des API REST mal pensées.
• Secrets exposés : 60 % des apps auditées laissent une clé API ou un mot de passe BDD dans le code public. L’IA a tendance à coder en dur ce qu’elle voit dans la doc.
• Injection SQL : 34 % des apps Q1 2026 contiennent une injection exploitable. Pas une vulnérabilité de 2010, une réalité de 2026.
• Row-level security désactivée : la couche d’autorisation au niveau base de données n’est pas activée par défaut. Un utilisateur peut requêter toute la table.

Ces failles ne sont pas des cas limites. Ce sont des fondamentaux ratés, à grande échelle.

Lovable, 48 jours d’exposition : le scénario à éviter

Le 3 mars 2026, un chercheur en sécurité signale une vulnérabilité BOLA à Lovable via son programme de bug bounty sur HackerOne. Le rapport est fermé sans escalade. Le 20 avril, le chercheur publie. La faille est restée ouverte 48 jours.

Selon The Next Web, tout possesseur d’un compte gratuit Lovable pouvait accéder, via cinq appels API, au code source des projets, aux credentials Supabase codés en dur, aux profils utilisateurs (nom, poste, LinkedIn, ID Stripe) et aux historiques de chat IA. Tous les projets créés avant novembre 2025 étaient exposés.

La réponse initiale de Lovable a été de nier toute fuite, qualifier les données exposées de “comportement intentionnel”, puis de blâmer la documentation et HackerOne pour la fermeture des rapports. La faille a été corrigée pour les nouveaux projets uniquement. Pas pour les anciens.

Trend Micro résume le vrai problème : “Le risque du vibe coding, ce n’est pas l’IA qui écrit du code peu sûr. Ce sont des humains qui livrent du code qu’ils n’ont jamais eu la chance de sécuriser.”

Pourquoi le vibe coding produit ces failles

L’IA livre ce qu’on lui demande. On lui demande un MVP qui marche. Pas un MVP sécurisé. Trois mécanismes alimentent la dette :

La vélocité brouille la revue. Une étude empirique sur des Fortune 50 montre que les développeurs assistés par IA committent à un rythme trois à quatre fois supérieur à leurs pairs, mais introduisent dix fois plus de problèmes de sécurité. Personne n’a le temps de relire à ce rythme.

Les hallucinations de packages. L’IA invente parfois des dépendances qui n’existent pas. Un attaquant publie le faux package sur npm ou PyPI, l’IA d’un autre développeur le suggérera demain. Le phénomène est déjà documenté dans le risque AI Slop sur l’open source.

Le copier-coller sans contexte

L’IA produit du code valide en isolation, mais ne voit pas l’architecture globale. Une validation de formulaire côté client sans miroir côté serveur. Une route privée sans middleware d’authentification. Une fonction admin accessible sans vérification de rôle.

La vraie question n’est pas “faut-il vibe-coder ?”

Les 91,5 % ne mesurent pas une faillite de l’IA. Ils mesurent l’absence de garde-fous chez ceux qui livrent. L’outil produit ce qu’on attend de lui : un prototype en 4 heures. Si vous le déployez sans audit, le déficit de sécurité n’est pas le problème de l’IA, c’est le vôtre.

La position LeCollectif : le vibe coding 2026 est viable, productif et adapté à beaucoup de cas d’usage PME. Mais il exige cinq garde-fous obligatoires, non négociables avant la production.

Cinq garde-fous obligatoires avant la prod

1. Revue de code humaine systématique

Chaque merge sur une branche de production doit passer sous les yeux d’une personne qualifiée, interne ou prestataire. Pas une lecture rapide : une revue annotée, qui valide la logique d’autorisation et les flux de données. C’est le garde-fou le moins technique et le plus efficace.

2. Tests de sécurité automatisés en CI/CD. Semgrep, gitleaks pour les secrets, OWASP ZAP pour les API. Ces outils tournent en quelques secondes et bloquent un déploiement si une faille connue est détectée. Coût marginal nul, valeur immédiate.

3. Sandbox d’exécution avant production

Un environnement de staging isolé, avec des données de test, qui permet de simuler un attaquant. Pour les apps qui manipulent des données sensibles, c’est l’étape qui transforme un audit théorique en validation réelle.

4. Audit des dépendances générées par l’IA. Toute librairie ajoutée par un agent doit être vérifiée : existe-t-elle ? Est-elle maintenue ? A-t-elle des CVE connues ? Un simple npm audit ou bundle audit couvre l’essentiel. Ne pas le faire, c’est ouvrir la porte aux hallucinations de packages.

5. Bug bounty ou pentest avant mise en ligne

Pour toute application qui touche aux données clients, paiements ou authentification, un test d’intrusion externe avant la prod est devenu un standard. Le coût d’un pentest (1 500-5 000 €) est une fraction du coût d’une fuite.

Le vibe coding 2026 : une responsabilité, pas une expérimentation

Les chiffres ont changé d’échelle. Le rapport CSA, les audits Q1, l’affaire Lovable convergent vers le même constat : le vibe coding est sorti de sa phase d’expérimentation. C’est désormais une méthode de production, avec les obligations qui vont avec.

Pour les PME qui livrent des produits, internes ou clients, la question n’est plus “puis-je utiliser l’IA pour coder ?”. La réponse est oui. La question devient : “ai-je le cadre pour livrer du code IA sans laisser une faille ouverte 48 jours ?”.

Les cinq garde-fous ci-dessus sont la base. Pour les projets sensibles, savoir quand faire appel à un professionnel reste la décision la plus rentable. Le vibe coding accélère le démarrage. Il ne dispense pas de la responsabilité du livrable.