Une application vibe-codée peut fonctionner parfaitement sous vos yeux tout en étant grande ouverte en dessous. C’est la partie inconfortable de la génération d’applications par l’IA : la démo fonctionne, le client est impressionné, et rien de tout cela ne vous dit si l’écran de connexion peut être contourné ou si la base de données est exposée à quiconque inspecte une requête réseau.
Les modèles d’IA sont entraînés à produire quelque chose qui a l’air fini. Ils ne sont pas entraînés à se demander « qui d’autre pourrait atteindre ce endpoint ». Cet écart est là où vit la majeure partie du risque réel dans les logiciels générés par l’IA, et il apparaît rarement avant que quelqu’un n’aille le chercher.
Les chiffres sont pires que ce que la plupart des créateurs pensent
Une recherche indépendante sur le code généré par les LLM confirme cela avec une statistique précise et inconfortable : les modèles compilent avec succès du code fonctionnel dans environ 90 % des cas, mais environ 45 % de ce code comporte au moins une vulnérabilité du OWASP Top 10 - comme des vérifications de connexion contournables ou des failles d’injection permettant à un attaquant de manipuler une requête.
Ce n’est pas un cas isolé. Cela signifie que près de la moitié de ce qu’un outil comme Lovable, Bolt ou Base44 génère pour vous à partir d’un prompt donné comporte une faiblesse réelle et exploitable, présente dès le départ. L’application « fonctionne » toujours en apparence. La vulnérabilité ne se manifeste tout simplement pas avant qu’un utilisateur (ou un attaquant) ne la découvre.
D’où vient réellement le risque
Les failles de sécurité dans les applications générées par l’IA ont tendance à se regrouper autour de quelques schémas récurrents :
- Vérifications d’authentification côté client. L’IA implémente « cet utilisateur est-il autorisé à voir cette page » dans le navigateur plutôt que sur le serveur. Comme le code du navigateur est entièrement visible et modifiable, n’importe qui peut ouvrir les outils de développement, inverser la vérification, et entrer.
- Secrets codés en dur. Les créateurs non techniques qui testent en local ne savent souvent pas gérer correctement les fichiers
.env, si bien que les clés API et les chaînes de connexion à la base de données sont tapées directement dans le code. Ces fichiers finissent ensuite poussés vers un dépôt GitHub public sans que personne ne le remarque. - Règles de base de données trop permissives. Pour faire fonctionner un prompt rapidement, l’IA configure l’accès à la base de données largement plutôt que finement. Si une autre partie de l’application est compromise, cette configuration grande ouverte transforme un petit bug en une fuite de données complète.
- Connexions OAuth trop permissives. Configurer une intégration comme Google Calendar ou Slack nécessite de définir les scopes OAuth à la main. Demander trop d’accès crée une responsabilité ; oublier un scope casse l’intégration en silence. Dans les deux cas, le créateur prend une décision de sécurité dont il n’a généralement pas conscience.
Rien de tout cela ne se voit dans une démo. Cela apparaît lors d’un audit de sécurité, dans la console du navigateur d’un utilisateur curieux, ou dans une notification de violation de données des mois plus tard.
Pourquoi « ça marche » est le mauvais test
Le piège, c’est que les générateurs d’applications IA vous récompensent pour la rapidité, et les boucles de retour rapides vous entraînent à ne tester que le chemin nominal. Vous parcourez le flux d’inscription, le tableau de bord se charge, le formulaire s’envoie, tout semble correct. Rien de tout cela ne vous dit si l’action CRUD derrière ce formulaire vérifie qui fait la demande.
Bien tester la sécurité, c’est poser d’autres questions :
- Un utilisateur déconnecté peut-il atteindre directement cette URL ?
- L’utilisateur A peut-il voir ou modifier les enregistrements de l’utilisateur B en changeant un ID dans la barre d’adresse ?
- Les vérifications de rôle sont-elles appliquées côté serveur, ou seulement cachées dans l’interface ?
- Les intégrations connectées via OAuth ne demandent-elles que les scopes qu’elles utilisent réellement ?
La plupart des créateurs non techniques ne pensent pas à poser ces questions, et la plupart des assistants de code IA ne les soulèveront pas spontanément, sauf si vous dites explicitement « vérifie les problèmes de sécurité » ; et même là, le correctif reste un autre patch généré, pas une garantie structurelle.
L’alternative : une infrastructure que vous n’avez pas à auditer
C’est le véritable argument en faveur de la construction d’applications métier sur une plateforme où la sécurité est intégrée dès la fondation plutôt que générée à chaque projet. Softr est un bon exemple de l’approche inverse : l’authentification, les permissions par rôle et les règles d’accès aux données sont des fonctionnalités natives de la plateforme, pas du code que l’IA réécrit à chaque application.
Concrètement, cela signifie :
- CRUD côté serveur par défaut. Les actions de lecture/écriture en base de données s’exécutent sur les serveurs de Softr, pas dans le navigateur, donc il n’y a pas de vérification côté client à contourner en premier lieu.
- Permissions de rôle visuelles plutôt que RLS écrit à la main. Les groupes d’utilisateurs et les restrictions de données contrôlent qui voit et modifie quels enregistrements, configurés visuellement et vérifiés par simulation en aperçu, plutôt qu’enfouis dans du code de politique de base de données facile à mal configurer.
- Connecteurs OAuth pré-vérifiés. Les intégrations avec des outils comme Google Calendar, HubSpot et Stripe utilisent les applications développeur déjà approuvées de Softr, si bien que les créateurs ne touchent jamais aux scopes OAuth bruts ni ne stockent eux-mêmes des identifiants tiers.
- Flux d’authentification utilitaires livrés dès le départ. Connexion, réinitialisation de mot de passe, OTP et inscription restreinte par domaine sont préconstruits, donc il n’y a pas de logique d’authentification personnalisée que l’IA puisse subtilement mal implémenter.
Cela ne veut pas dire que les outils générés par l’IA sont inadaptés à tout. Pour un projet personnel, un prototype interne que personne en dehors de votre équipe ne touchera, ou une simple landing page statique, le profil de risque est faible et le vibe coding est réellement la voie la plus rapide. Le calcul change dès que de vrais utilisateurs, de vraies données clients ou des connexions externes entrent en jeu.
Ce qu’il faut vérifier avant de lancer
Si vous construisez malgré tout avec un outil d’IA générant du code, une courte liste vaut mieux que rien :
- Cherchez dans le code (grep) les clés API et chaînes de connexion codées en dur avant tout commit.
- Confirmez que les vérifications de contrôle d’accès sont dupliquées côté serveur, et pas seulement cachées côté frontend.
- Passez en revue les scopes OAuth accordés à chaque intégration connectée et supprimez tout ce qui n’est pas utilisé.
- Demandez à une deuxième personne, idéalement technique, d’essayer d’accéder aux données d’un autre utilisateur en devinant ou en modifiant un ID dans l’URL.
Cette liste ne rendra pas le code généré aussi sûr qu’une infrastructure qui n’a jamais été générée, mais elle attrape les failles les plus fréquentes. Pour un portail, un CRM ou un outil interne où de vraies personnes se connecteront avec de vraies données, la solution la plus durable est de choisir une fondation où le travail de sécurité a déjà été fait, pour que ce ne soit pas un pile ou face à chaque prompt.