Oui, une application construite en vibe coding peut aller en production. Mais pas telle qu'elle sort de l'outil. Le code généré par l'IA fonctionne souvent du premier coup à l'écran, et cela donne une impression de solidité trompeuse. Ce qui manque, en général, ce n'est pas une fonctionnalité, c'est tout ce qui ne se voit pas : qui a le droit de lire quelles données, où sont rangés les mots de passe et les clés d'accès aux services, ce qui se passe quand le serveur tombe.
Si vous vous demandez comment réussir la mise en production d'une application vibe coding sans prendre de risque inconsidéré, voici la réponse courte : faites relire les points sensibles par quelqu'un qui sait où chercher, avant l'ouverture au public puis à chaque évolution importante. Cet article vous donne la liste de ces points et ce que disent les études récentes. Il explique aussi comment organiser cette relecture sans recruter un développeur à plein temps.
Pour rappel, le vibe coding consiste à décrire en langage courant ce que l'on veut à un outil d'IA (Lovable, Replit, Cursor, Claude Code…) et à accepter le code produit sans le relire en détail. C'est une excellente façon de tester une idée. C'est une façon risquée de gérer les données de vos clients.
Application vibe coding et mise en production : où est le risque ?
Un prototype et une application en production n'ont pas les mêmes exigences. Le prototype doit montrer que l'idée tient. L'application en production doit tenir face à des utilisateurs réels, dont certains feront des erreurs et quelques-uns chercheront délibérément les failles.
Les outils d'IA sont très bons pour la première partie. Pour la seconde, trois difficultés reviennent sans cesse :
- Le contrôle d'accès. L'écran de connexion existe, mais la base de données derrière peut rester lisible par n'importe qui connaissant l'adresse technique de l'application. L'interface cache les données, elle ne les protège pas.
- Les secrets. Les clés d'API sont les identifiants qui donnent accès à un service payant, à un outil d'emailing ou à un moyen de paiement. Elles se retrouvent parfois, avec les mots de passe de base de données, directement dans le code envoyé au navigateur. N'importe quel visiteur un peu curieux peut alors les lire.
- Les réglages par défaut. Une application peut être publique simplement parce que c'est le réglage de départ de la plateforme, et que personne n'a pensé à le changer.
Aucun de ces problèmes ne se voit en utilisant l'application normalement. C'est justement pour cela qu'ils passent inaperçus quand la personne qui teste est aussi celle qui a écrit les prompts : elle utilise l'application comme prévu, pas comme un attaquant.
Ce que disent les études récentes sur le code généré par l'IA
Ce n'est pas une intuition de développeur méfiant. Plusieurs travaux publiés ces derniers mois vont dans le même sens.
En juillet 2025, l'éditeur Veracode a testé plus de 100 modèles d'IA sur 80 tâches de programmation. Résultat, publié dans son GenAI Code Security Report : dans 45 % des cas, le code produit contenait une faille figurant dans l'OWASP Top 10, la liste de référence des risques les plus critiques pour les applications web. Un point mérite l'attention d'un dirigeant : selon Veracode, les modèles plus gros ne font pas significativement mieux sur la sécurité, et ce résultat n'a pas progressé dans le temps. Le code généré est de plus en plus correct, pas de plus en plus sûr.
En mai 2026, la société de cybersécurité RedAccess a révélé avoir trouvé environ 380 000 applications accessibles publiquement, créées avec Lovable, Base44, Netlify et Replit. Environ 5 000 d'entre elles contenaient des informations d'entreprise sensibles : conversations de service client, données financières internes, échanges entre soignants et patients. Selon le dirigeant de RedAccess, certains outils rendaient les applications accessibles par défaut, et c'était à l'utilisateur de les passer en privé.
Enfin, une faille référencée CVE-2025-48757 concerne des applications générées par Lovable. Une politique de sécurité insuffisante au niveau de la base de données permettait à un attaquant non authentifié de lire ou de modifier des tables. Lovable conteste ce classement en rappelant que chaque client est responsable de la protection des données de son application. Retenez surtout ce dernier point : en pratique, la responsabilité reste chez vous, pas chez l'outil.
La liste de vérifications avant d'ouvrir l'application au public
Voici ce que je regarde en priorité sur une application générée par IA avant sa mise en ligne. Vous n'avez pas besoin de savoir le faire vous-même. En revanche, vous devez savoir que ces questions existent et exiger une réponse claire à chacune.
- Chaque donnée est-elle protégée côté serveur ? Un utilisateur connecté ne doit pouvoir lire et modifier que ce qui le concerne. Le test de base : se connecter avec un compte A, puis essayer d'accéder à une donnée du compte B en changeant un identifiant dans l'adresse ou dans la requête envoyée au serveur.
- Aucun secret dans le code visible ? Les clés d'API et les mots de passe doivent être stockés côté serveur, dans des variables d'environnement. Jamais dans le code envoyé au navigateur, ni dans l'historique du dépôt de code.
- Les saisies des utilisateurs sont-elles filtrées ? Ce que tape un visiteur ne doit jamais être exécuté tel quel par la base de données, ni réaffiché sans filtrage. Le rapport Veracode cite justement le cross-site scripting (l'injection de code malveillant dans une page) parmi les failles que les modèles gèrent le plus mal.
- Qui peut voir l'application ? Vérifiez les réglages de visibilité de la plateforme, les pages d'administration et les environnements de test restés en ligne.
- Les dépendances sont-elles connues et à jour ? L'IA ajoute volontiers des bibliothèques externes. Chacune est du code que vous n'avez pas écrit, qui peut contenir des failles et qu'il faudra maintenir.
- Y a-t-il des sauvegardes, et ont-elles déjà été restaurées ? Une erreur de manipulation, y compris par l'agent d'IA lui-même, peut effacer des données. Tant qu'une sauvegarde n'a pas été testée, rien ne prouve qu'elle fonctionne.
- Serez-vous prévenu si l'application tombe ? Sans surveillance automatique, ce sont vos clients qui vous l'apprendront.
Ces points ne demandent pas de réécrire l'application. Ce sont en général des corrections ciblées. Encore faut-il les trouver, et un outil d'IA à qui l'on demande « est-ce que mon code est sécurisé ? » a une fâcheuse tendance à répondre oui.
Ce que l'outil d'IA ne fera pas à votre place
Les outils progressent, et il serait absurde de s'en priver. Claude Code, par exemple, propose une commande /security-review qui passe en revue les modifications en cours. C'est utile. Mais la documentation d'Anthropic est explicite : « Claude Code only has the permissions you grant it. You're responsible for reviewing proposed code and commands for safety before approval » (documentation sécurité de Claude Code). Autrement dit, c'est à vous de relire ce que l'outil propose avant de l'accepter.
Ce qu'une IA fait mal aujourd'hui, c'est juger ce qui compte pour votre activité. Elle ne sait pas que telle table contient des données de santé, ni que tel client impose des exigences de confidentialité dans son contrat. Elle ne sait pas non plus que telle fonctionnalité servira à une poignée de personnes et telle autre à tous vos clients. Et elle ne voit pas ce qu'on ne lui montre pas : un réglage de la plateforme, une clé restée dans un ancien fichier, un environnement de test oublié.
La bonne méthode associe donc deux rôles. L'IA produit vite. Un humain expérimenté décide de ce qui part en production et pose des garde-fous durables : des tests automatiques sur les parcours critiques, une relecture des changements sensibles et un contrôle qualité à chaque mise en ligne.
Qui peut faire cette relecture, et à quel rythme ?
Vous avez trois options réalistes.
Recruter un développeur senior
C'est la bonne réponse si votre application est votre produit principal et qu'elle évolue tous les jours. C'est souvent surdimensionné pour une PME qui a construit un outil interne ou un premier produit, et qui ajoute quelques fonctionnalités par mois.
Commander un audit ponctuel
Un audit avant la mise en ligne règle les problèmes présents à ce moment-là. Mais une application construite avec l'IA évolue vite : chaque nouveau prompt peut réintroduire un problème corrigé la semaine précédente. Un audit unique vieillit mal.
Un regard senior régulier
Entre les deux, un développeur senior passe régulièrement sur le projet. Il relit ce qui a changé et vérifie les points sensibles. Il vous aide aussi à formuler vos demandes à l'IA et vous dit quand une fonctionnalité mérite d'être construite autrement. C'est le principe de l'offre Copilote : une journée de développeur senior par mois. Vous gardez la main sur votre application, et quelqu'un surveille ce que vous ne pouvez pas voir.
Quelle que soit l'option retenue, la régularité compte plus que l'ampleur : mieux vaut une relecture courte et régulière qu'un grand audit tous les deux ans.
Questions fréquentes
Peut-on vraiment mettre en production une application codée avec Lovable ou Claude Code ?
Oui. L'outil n'est pas le problème, l'absence de relecture l'est. Ce qui fait la différence, ce sont les vérifications faites avant l'ouverture au public, puis à chaque évolution.
Faut-il tout réécrire avant la mise en ligne ?
Pas forcément. Les corrections habituelles sont ciblées : protéger l'accès aux données côté serveur, déplacer les secrets, ajouter des sauvegardes et une surveillance. Une réécriture ne se justifie que si la structure même de l'application empêche de protéger correctement les données.
Qui est responsable en cas de fuite de données ?
En pratique, vous, en tant qu'éditeur de l'application. Le cas de la CVE-2025-48757 l'illustre bien : la plateforme considère que la protection des données relève de chacun de ses clients.
Vous avez peut-être une application construite avec l'IA et vous hésitez à l'ouvrir à vos clients. Ou bien elle est déjà en ligne et vous n'êtes pas sûr de ce qu'elle expose. Dans les deux cas, on peut en parler simplement. Décrivez-moi ce que fait l'application et avec quel outil elle a été construite. Je vous dirai par où je commencerais, et si vous avez besoin de moi ou non.