Votre app générée par IA (Lovable, Bolt, Cursor…) est-elle prête pour la production ?

Lovable, Bolt, v0 ou Cursor permettent de sortir une application qui fonctionne en quelques jours. C'est un vrai progrès : on teste une idée avec de vrais utilisateurs pour une fraction du coût d'avant. Nous utilisons nous-mêmes l'IA pour développer, tous les jours.

Mais « ça marche à l'écran » ne veut pas dire « prêt pour la production ». L'IA produit ce qu'on lui demande. Elle ne pense pas d'elle-même aux droits d'accès, aux sauvegardes ou au RGPD. Les problèmes apparaissent souvent une fois que de vraies données sont en ligne.

Ce que montrent les études et les incidents publics

Quelques faits documentés, pour fixer les idées.

• En mars 2025, un chercheur a analysé 1 645 applications créées avec Lovable. Dans 170 d'entre elles (environ 10 %), des tables de la base Supabase pouvaient être lues, voire modifiées, sans authentification, faute de règles Row Level Security. Parmi les données exposées : des e-mails, des transactions et des clés d'API. La faille porte la référence CVE-2025-48757 ; Lovable la conteste, en rappelant que chaque client est responsable de la protection des données de son application.
• L'éditeur de sécurité Escape a scanné plus de 5 600 applications publiques construites avec ce type d'outils (Lovable, Bolt, Base44…). Résultat : plus de 2 000 vulnérabilités, plus de 400 secrets exposés (clés d'API, jetons) et 175 cas de données personnelles accessibles, dont des données médicales.
• Dans sa mise à jour de mars 2026, Veracode indique que seules 55 % des tâches de génération de code par IA aboutissent à du code sûr, un taux qui n'a guère progressé depuis 2025 malgré les nouveaux modèles.
• En juillet 2025, l'agent IA de Replit a supprimé la base de données de production d'un utilisateur pendant un gel du code, malgré des consignes explicites. L'incident illustre ce qui arrive sans séparation entre test et production.

Les failles qu'on retrouve le plus souvent

Quand on regarde le code d'une application générée par IA, ce sont presque toujours les mêmes points qui posent problème.

• Authentification et autorisations : la connexion fonctionne, mais rien n'empêche un utilisateur connecté de lire les données d'un autre. Avec Supabase, des tables sans Row Level Security sont lisibles avec la clé publique présente dans le navigateur.
• Clés d'API exposées : une clé OpenAI, Stripe ou d'un service d'e-mail placée dans le code côté navigateur peut être récupérée par n'importe qui, et utilisée à vos frais.
• Validation des entrées absente : le formulaire contrôle les champs à l'écran, mais le serveur accepte n'importe quoi.
• Pas de tests : chaque nouvelle demande à l'IA peut casser une fonction qui marchait, sans que personne ne s'en rende compte.
• Pas de sauvegardes testées, pas de supervision : on découvre la panne ou la perte de données par un client.
• RGPD oublié : pas de politique de confidentialité, données hébergées hors d'Europe sans le savoir, pas d'accord de traitement avec les sous-traitants, pas de procédure de suppression.
• Coûts qui dérapent : appels d'IA sans limite, requêtes en boucle, fichiers jamais nettoyés. La facture cloud augmente avec le succès, ou avec un abus.

Checklist avant d'ouvrir à de vrais utilisateurs

Vous pouvez vérifier une bonne partie de ces points vous-même. Chaque « non » mérite d'être corrigé avant d'importer de vraies données.

• Chaque table contenant des données a des règles d'accès, testées avec deux comptes différents.
• Aucune clé secrète n'apparaît dans le code envoyé au navigateur ni dans le dépôt Git.
• Le serveur valide toutes les données reçues, pas seulement le formulaire.
• Les parcours critiques (inscription, paiement, accès aux données) sont couverts par des tests automatisés.
• Des sauvegardes automatiques existent, et une restauration a été essayée au moins une fois.
• Les erreurs et les pannes déclenchent une alerte.
• Les environnements de test et de production sont séparés, et l'IA n'a pas de droits sur la production.
• L'hébergement est en Europe, ou les transferts hors UE sont encadrés, et les sous-traitants sont listés.
• Des plafonds de dépense sont configurés chez vos fournisseurs d'IA et de cloud.

Corriger ou reconstruire ?

Il n'y a pas de réponse unique. Souvent, une application générée par IA se corrige : on ajoute les règles d'accès, on déplace les secrets côté serveur, on écrit les tests qui manquent, on met en place sauvegardes et supervision.

Une reconstruction se justifie quand le modèle de données est faux à la base (par exemple, les données de plusieurs clients mélangées sans séparation fiable), quand le code est devenu trop incohérent pour être modifié sans casser autre chose, ou quand le projet doit tenir des exigences fortes, en santé ou en finance par exemple, que la base actuelle ne permet pas. Même dans ce cas, le prototype n'est pas perdu : il a validé l'idée et les parcours, ce qui fait gagner beaucoup de temps.

C'est l'objet de notre audit d'application IA, à 900 € HT : nous passons en revue le code, la sécurité et les données, et vous recevez un rapport clair et priorisé. Vous décidez ensuite de corriger vous-même, avec nous au forfait, ou de reconstruire. Pour savoir si un audit est utile dans votre cas, le diagnostic de 30 minutes est offert.

Sources

• NVD (NIST) — CVE-2025-48757 : nvd.nist.gov/vuln/detail/CVE-2025-48757
• Matt Palmer — Statement on CVE-2025-48757 : mattpalmer.io/posts/statement-on-CVE-2025-48757
• Escape — Recherche sur plus de 5 600 applications générées par IA : escape.tech/research
• Veracode — Spring 2026 GenAI Code Security Update : veracode.com/blog/spring-2026-genai-code-security
• Supabase — Documentation Row Level Security : supabase.com/docs/guides/database/postgres/row-level-security
• Fortune — Suppression d'une base de production par l'agent de Replit (juillet 2025) : fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure