.webp){kind=small}
Vous avez créé votre application avec Lovable, Bolt, Cursor, Replit ou Claude Code, elle fonctionne, et de vrais utilisateurs y entrent de vraies données. Est-elle sécurisée ? Ce guide liste les failles qu'on retrouve le plus souvent dans les applications générées par IA, vous donne une checklist pour faire un premier diagnostic, et détaille ce que contient un audit de sécurité sérieux.
Vous reconnaissez-vous dans cette situation ?
Cochez mentalement celles qui vous parlent :
- Votre application est en ligne, ou le sera bientôt, avec des clients, des salariés ou des partenaires qui s'y connectent.
- Elle stocke des données personnelles : noms, e-mails, téléphones, documents, informations de paiement ou de santé.
- Personne n'a relu le code ligne par ligne. Vous avez validé les écrans et les parcours, pas ce qui se passe derrière.
- Vous ne savez pas exactement où sont rangées vos clés d'API (OpenAI, Stripe, Brevo, Google…).
- Vous n'avez jamais testé ce qu'un utilisateur peut voir s'il modifie une adresse dans son navigateur ou se connecte avec un autre compte.
- Vous ne savez pas si une sauvegarde existe, ni combien de temps il faudrait pour la restaurer.
Si vous avez coché au moins deux cases, ce guide est pour vous.
Pourquoi une application vibe codée est-elle souvent vulnérable ?
Un assistant de code IA est entraîné pour produire quelque chose qui marche. Que ce soit sûr est une autre question, et elle ne se voit pas à l'écran : une application peut fonctionner parfaitement tout en laissant n'importe qui lire sa base de données.
Les études le confirment. Veracode a fait réaliser les mêmes tâches de programmation à plus de 100 modèles d'IA, en Java, Python, C# et JavaScript. Résultat publié en juillet 2025 : 45 % des échantillons de code contenaient une faille du Top 10 de l'OWASP, la liste de référence des risques de sécurité des applications web.
L'ANSSI et son homologue allemand, le BSI, sont arrivés à la même conclusion dans leurs recommandations sur les assistants de programmation basés sur l'IA : ces outils ne remplacent pas des développeurs expérimentés, et le code qu'ils génèrent doit être vérifié par des développeurs.
Surtout, la responsabilité reste la vôtre. La documentation de sécurité de Lovable l'écrit noir sur blanc : c'est à vous de vous assurer que votre application répond aux exigences de sécurité adaptées à son usage, et ses outils d'analyse ne peuvent pas garantir une sécurité complète. Pour les applications qui manipulent des données sensibles ou des fonctions critiques, Lovable conseille lui-même d'envisager une revue de sécurité professionnelle. C'est exactement ce que nous faisons chez Nocode Factory.
Quelles sont les failles les plus fréquentes dans une app générée par IA ?
Nous avons déjà détaillé les 5 failles de sécurité les plus courantes sur Lovable et Supabase. Voici la vue d'ensemble, valable quel que soit l'outil utilisé.
1. Des clés API visibles dans le navigateur
Tout ce qui est envoyé au navigateur peut être lu par n'importe quel visiteur. Or les outils de développement exposent volontairement certaines variables côté client : la documentation de Vite précise que les variables préfixées VITE_ se retrouvent dans le code envoyé au navigateur et ne doivent pas contenir de clés d'API ; celle de Next.js indique la même chose pour le préfixe NEXT_PUBLIC_. Une clé OpenAI ou Stripe placée là est publique. Résultat possible : quelqu'un consomme votre crédit d'API, ou agit sur votre compte.
2. Une base de données sans règles d'accès
Beaucoup d'apps vibe codées reposent sur Supabase, dont le navigateur interroge directement la base. La documentation de Supabase demande d'activer la sécurité au niveau des lignes (RLS) sur chaque table exposée, et rappelle que la clé secrète, qui contourne ces règles, ne doit jamais se retrouver dans le navigateur.
Ce n'est pas théorique. En 2025, Matt Palmer, salarié de Replit, et son collègue Kody Low ont analysé 1 645 applications créées avec Lovable et présentées sur le site de l'éditeur. Selon leur rapport, relayé par Semafor, 170 d'entre elles permettaient à n'importe qui d'accéder aux données de leurs utilisateurs (noms, e-mails, informations financières, clés d'API). Le problème a été enregistré sous la référence CVE-2025-48757 : des règles RLS insuffisantes permettaient de lire ou de modifier les tables des applications générées sans être connecté. Lovable conteste cette CVE : selon l'éditeur, chaque client de la plateforme est responsable de la protection des données de son application.
3. Des droits vérifiés dans l'interface, pas sur le serveur
Masquer un bouton « Administration » pour les non-administrateurs ne protège rien si le serveur accepte quand même la requête. Même chose quand une page affiche la facture n° 1042 : que se passe-t-il si l'utilisateur tape 1043 dans l'adresse ? Le contrôle d'accès défaillant est en tête du Top 10 de l'OWASP 2025 (A01), et les défauts d'authentification y figurent aussi (A07).
4. Des injections
Un champ de recherche, un formulaire ou un import de fichier qui transmet ce que tape l'utilisateur sans le contrôler peut permettre d'exécuter des commandes sur la base de données (injection SQL) ou d'afficher un script malveillant à d'autres utilisateurs (XSS). L'injection reste dans le Top 10 de l'OWASP 2025 (A05).
5. Des dépendances non maîtrisées
Une app générée par IA installe souvent des dizaines de paquets que personne n'a choisis. Certains sont vulnérables ou abandonnés. Pire : l'IA peut inventer des noms de paquets. Le rapport ANSSI-BSI cite une étude où 19,7 % des paquets importés par le code généré n'existaient pas ; un attaquant peut publier un paquet piégé sous ce nom. Les défaillances de la chaîne d'approvisionnement logicielle sont devenues la catégorie A03 du Top 10 de l'OWASP 2025.
6. Des données personnelles mal protégées
L'IA crée volontiers des tables qui stockent plus que nécessaire, des fichiers déposés dans un espace de stockage public, des exports qui renvoient toutes les colonnes. Le RGPD vous impose de protéger ces données (article 32), et la CNIL détaille les mesures attendues dans son guide de la sécurité des données personnelles.
7. Pas de sauvegarde, pas de journaux
En juillet 2025, Jason Lemkin, fondateur de SaaStr, a raconté que l'agent IA de Replit avait supprimé la base de données de production de son projet malgré une consigne de gel du code. Il a finalement pu la récupérer grâce à la fonction de retour arrière de Replit, alors que l'agent affirmait que c'était impossible. Sans sauvegarde testée, une erreur de ce type est définitive.
Les journaux sont l'autre angle mort : sans trace des connexions et des actions sensibles, vous ne saurez ni qu'une fuite a eu lieu, ni ce qui a été consulté. La CNIL recommande de conserver ces traces sur une période glissante de six mois à un an, et de tester régulièrement les sauvegardes.
Comment vérifier soi-même si son application est sécurisée ?
Voici une checklist d'auto-diagnostic. Elle ne remplace pas un audit, mais elle vous dit vite si vous avez un problème.
- Ouvrez les outils de développement de votre navigateur (onglet Réseau) et utilisez l'application : voyez-vous passer une clé d'API autre que la clé publique de votre base ?
- Regardez les réponses de l'API : renvoient-elles plus de données que l'écran n'en affiche (tous les utilisateurs, tous les champs) ?
- Créez deux comptes de test et essayez, avec le premier, d'ouvrir une page ou une ressource du second en changeant l'identifiant dans l'adresse.
- Vérifiez que la RLS est activée sur chaque table si vous utilisez Supabase. Le Security Advisor du tableau de bord signale les tables publiques sans RLS.
- Lancez l'analyse de sécurité de votre outil : Lovable propose une analyse rapide à la publication et une analyse approfondie du code. Lisez les alertes au lieu de les ignorer.
- Listez les comptes administrateur, sur l'application comme sur les services connectés (hébergement, base, Stripe, e-mail). Supprimez ceux qui ne servent plus.
- Cherchez vos secrets dans votre dépôt Git, y compris dans l'historique.
- Vérifiez qu'une sauvegarde existe et que quelqu'un sait la restaurer.
- Demandez-vous qui serait prévenu si des milliers de requêtes inhabituelles arrivaient cette nuit.
- Listez les données personnelles stockées et demandez-vous si chacune est vraiment nécessaire.
Si une seule de ces questions reste sans réponse claire, votre application mérite un regard extérieur. Les outils d'analyse automatique sont utiles, mais ils vérifient surtout la présence de règles, pas leur logique : une règle RLS peut exister et laisser passer tout le monde.
Que contient un audit de sécurité d'une application vibe codée ?
Un audit de sécurité, c'est une revue méthodique du code, de la configuration et des services connectés, suivie de tests réels. Il s'appuie sur des référentiels publics : le Top 10 de l'OWASP, les guides de l'ANSSI (dont ses recommandations pour la mise en œuvre d'un site web) et le guide de la CNIL pour la partie données personnelles.
| Point contrôlé | Risque | Correction |
|---|---|---|
| Clés et secrets dans le code envoyé au navigateur ou dans l'historique Git | Utilisation de vos comptes d'API à vos frais, accès à vos services tiers | Révocation et remplacement des clés, appels déplacés côté serveur, secrets dans un coffre |
| Règles d'accès de la base de données (RLS sur Supabase, règles Firebase) | Lecture ou modification de toutes les données par n'importe qui | Activation de la RLS sur chaque table, règles écrites table par table, test avec plusieurs comptes |
| Contrôle des droits côté serveur | Un utilisateur consulte ou modifie les données d'un autre en changeant un identifiant | Vérification du propriétaire et du rôle à chaque requête, pas seulement dans l'interface |
| Authentification (mots de passe, sessions, réinitialisation) | Prise de contrôle de comptes, accès administrateur détourné | Paramétrage du fournisseur d'authentification, double authentification pour les comptes sensibles |
| Entrées utilisateur (formulaires, recherche, import, URL) | Injection SQL, script malveillant affiché à d'autres utilisateurs (XSS) | Requêtes paramétrées, validation et échappement des données, en-têtes de sécurité |
| Dépendances et paquets installés | Paquet vulnérable, abandonné ou inventé par l'IA puis piégé | Inventaire, mise à jour, suppression des paquets inutiles, alertes automatiques |
| Fonctions serveur et API exposées | Facture d'API qui explose, service saturé | Limitation du nombre de requêtes, authentification obligatoire sur chaque point d'entrée |
| Données personnelles collectées et stockées | Collecte excessive, fuite, manquement au RGPD | Minimisation, durées de conservation, chiffrement des données sensibles |
| Sauvegardes et retour arrière | Perte définitive des données après une erreur ou une suppression | Sauvegardes automatiques, test de restauration, base de production séparée |
| Journaux et alertes | Fuite découverte des semaines plus tard, ou jamais | Journalisation des accès et des actions sensibles, alertes sur les comportements anormaux |
Chez Nocode Factory, l'audit se déroule en quatre temps :
- Cartographie : quels outils, quelles données, quels comptes, quels services tiers, qui a accès à quoi.
- Revue et tests : lecture du code et des règles d'accès, puis tentatives concrètes avec plusieurs comptes, comme le ferait un utilisateur malveillant.
- Rapport priorisé : chaque faille classée selon son risque réel pour votre activité, en langage clair, avec la correction associée.
- Corrections : nous corrigeons nous-mêmes, en commençant par les failles critiques, puis nous vérifions que la faille est bien fermée.
Pas besoin de tout réécrire. Dans la plupart des cas, on garde ce que vous avez construit et on sécurise ce qui doit l'être. Le code reste le vôtre, et vous gardez la main dessus.
Que faire si des données ont fuité ?
Une violation de données personnelles, ce n'est pas seulement un piratage : une base laissée ouverte, un fichier envoyé au mauvais destinataire ou une perte de données en sont aussi. Le RGPD fixe trois obligations, rappelées par la CNIL :
- Notifier la CNIL dans les meilleurs délais, et au plus tard 72 heures après en avoir pris connaissance, si la violation présente un risque pour les personnes (article 33). Au-delà, il faut justifier le retard.
- Informer les personnes concernées lorsque le risque pour leurs droits et libertés est élevé (article 34).
- Tenir un registre interne des violations : nature, personnes et données concernées, conséquences, mesures prises.
Le manquement à ces obligations, comme à l'obligation de sécurité, peut être sanctionné d'une amende allant jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial (article 83). Pour pouvoir répondre en 72 heures, il faut savoir ce qui s'est passé : c'est là que les journaux et les sauvegardes prennent toute leur valeur.
Si vous découvrez une faille, nous pouvons intervenir vite : fermer l'accès, évaluer quelles données ont été exposées et vous donner les éléments nécessaires à la notification.
Comment garder une application vibe codée sécurisée dans la durée ?
La sécurité n'est pas un état, c'est un entretien. Chaque nouvelle fonctionnalité générée au prompt peut rouvrir une faille, chaque dépendance peut devenir vulnérable. Nous avons détaillé la méthode dans notre guide pour maintenir un produit vibe codé, et les erreurs à éviter dans les 4 pièges du vibe coding.
C'est pour cela que nous proposons de reprendre l'application en maintenance après l'audit : surveillance des dépendances, revue de sécurité de chaque évolution, sauvegardes vérifiées, et vos nouvelles idées intégrées au fil de l'eau, sans cahier des charges figé. Nous travaillons comme des développeurs from scratch, la vitesse en plus, et le code reste votre propriété.
Depuis 2020, Nocode Factory a accompagné plus de 350 entreprises, du MVP vibe codé à l'outil métier en production. Vous pouvez voir quelques-uns de ces projets dans nos réalisations.
Qui sommes-nous ? Nocode Factory, agence de développement d'applications sur mesure
Nocode Factory est une agence française de développement d'applications web, de logiciels métier et d'automatisations IA, créée en 2020. Nous avons accompagné plus de 350 entreprises, des PME aux grands comptes. Nous construisons avec des outils no-code et low-code (WeWeb, Xano, Webflow, Make, n8n) et en développement sur mesure quand le projet le demande, puis nous faisons évoluer l'outil après la livraison.
Quelques applications que nous avons livrées ou reprises, avec leur délai et leur résultat :
- Xtensio : en 12 semaines, une application limitée sous Bubble a été reconstruite en WeWeb et Xano. L'ajout d'une nouvelle commune est 10 fois plus rapide.
- Trophée des Champions (LFP) : une web app multi-rôles pour toutes les parties prenantes de l'événement, livrée en 10 jours.
- Brut : en 4 semaines, une plateforme de campagnes publicitaires a remplacé un simple formulaire de contact. Le process publicitaire est digitalisé de bout en bout.
- CCI Network : une plateforme refondue et un espace membre automatisé en 6 semaines. Le taux de conversion des visiteurs en membres a doublé.
Votre application vibe codée est en ligne ou sur le point de l'être ? Nous faisons le point sur sa sécurité avec vous en 30 minutes. Réservez un appel avec un expert.
