Lancer ton produit en vibe coding : jusqu'où ça tient, et les 3 endroits où ça casse
Par Anis Hammouche·3 novembre 2026
Le vibe coding permet de lancer un prototype sans savoir coder : tu décris ce que tu veux à une IA, elle écrit l'application, tu testes et tu recommences. Ça tient pour une page de présentation, un test auprès de clients ou un outil interne que cinq personnes utilisent. Ça casse dès que ton produit stocke des données de clients, prend des paiements ou doit tourner plusieurs mois sans que tu le touches.
Ce que le vibe coding fait bien
Le vibe coding est efficace pour répondre à une question simple : est-ce que quelqu'un veut ce produit ? En quelques jours, tu obtiens une maquette qui fonctionne, tu la montres à dix prospects et tu vois ce qui les intéresse. Pour cet usage, la qualité du code importe peu, parce que tu jettes probablement la version une fois la question tranchée.
Il est aussi bien adapté à un outil interne limité à quelques personnes de confiance, par exemple un tableau de suivi ou un générateur de devis. Le périmètre est petit, les utilisateurs sont identifiés, et une erreur se corrige vite.
Où ça casse : la sécurité
C'est le point le plus sensible. Un code généré par IA peut sembler fonctionnel alors qu'il laisse des portes ouvertes.
Le rapport Veracode 2025 sur la sécurité du code généré par IA a testé 80 tâches de codage confiées à plus de 100 modèles. Dans 45 % des cas, le code produit contenait une faille de sécurité. Le résultat ne dit pas que 45 % de tout le code généré est dangereux, mais il montre qu'une IA choisit régulièrement l'option la moins sûre, sans le signaler (communiqué Veracode).
Le cas le plus souvent cité concerne des applications générées avec une plateforme de vibe coding reliée à une base Supabase. Selon une analyse publiée en mars 2026 par Superblocks, un éditeur de plateformes low-code, une faille (CVE-2025-48757) a exposé plus de 170 applications construites avec Lovable. La cause : des règles d'accès, la « Row Level Security », absentes sur 303 points d'accès.
Ces chiffres viennent d'une source intéressée : retiens le mécanisme, pas le détail (analyse Superblocks).
Le mécanisme est simple. L'application marche : les écrans s'affichent, les formulaires enregistrent. Mais la règle qui dit « seul l'utilisateur connecté voit ses données » n'a jamais été vérifiée. Personne ne le voit tant qu'un inconnu ne tente pas l'accès.
Où ça casse : la maintenance
Le deuxième point de rupture arrive après le lancement. Quand tu demandes une modification, l'IA réécrit parfois des parties qui marchaient. Quand un bug apparaît, tu ne sais pas où il se trouve, donc tu redemandes à l'IA de « corriger », et le bug change de forme.
L'étude METR de l'été 2025 illustre un autre risque. Seize développeurs expérimentés ont travaillé sur 246 tâches réelles dans des dépôts open source. Avec des outils d'IA, ils ont mis 19 % de temps en plus. Avant l'étude, ils prévoyaient un gain de 24 %, et après, ils estimaient encore avoir gagné environ 20 %.
Ce résultat concerne des outils de début 2025. Il pose quand même une question utile : si des développeurs se trompent sur leur propre gain de temps, comment un non-développeur saurait-il si son code tient ? (étude METR)
Où ça casse : les bugs en production
Un bug en production est un bug que personne n'a vu. Sans tests automatiques, sans journal des erreurs et sans sauvegarde, tu découvres la panne par un client qui se plaint. Et comme tu ne lis pas le code, tu passes plus de temps à diagnostiquer qu'à corriger.
Le vibe coding n'ajoute pas ces protections toutes seules. Il faut les demander, les vérifier, et savoir ce qu'elles couvrent.
Ce que disent les recommandations sérieuses
L'ANSSI et l'homologue allemand, le BSI, ont publié en 2024 un document conjoint sur les assistants de codage IA. Il ne parle pas spécifiquement de vibe coding, mais il détaille les risques de ces outils et donne des recommandations de sécurité aux responsables et aux développeurs (document ANSSI-BSI).
Pour un projet personnel, ce n'est pas toujours réalisable. Le principe reste le même : une personne compétente doit regarder ce qui touche aux données et aux accès avant de les confier à un public réel.
La grille à passer avant de mettre des données réelles en ligne
Ces questions se vérifient en une heure, sans être développeur :
- Tes données sont-elles protégées côté serveur ? Crée deux comptes, connecte-toi avec le second et essaie d'afficher les données du premier, y compris en modifiant l'adresse ou l'identifiant dans l'URL.
- Tes clés et mots de passe sont-ils absents du code visible ? Une clé d'API placée dans le code du navigateur est une clé publique.
- As-tu une sauvegarde utilisable ? Une sauvegarde qu'on n'a jamais restaurée ne compte pas vraiment.
- Qui répond si ça casse un samedi ? Si la réponse est « personne », le produit n'est pas prêt pour de vrais clients.
Tu peux aussi demander à l'IA une relecture de sécurité, avec un prompt précis :
Relis ce projet comme un attaquant. Liste chaque endroit où une donnée
d'un utilisateur pourrait être lue ou modifiée par un autre utilisateur,
ou sans connexion. Pour chaque point, indique le fichier, la ligne
et la correction proposée. Ne propose pas de correction sans l'expliquer.
Attention : une relecture par IA ne remplace pas un test réel. Elle trouve des pistes, pas la preuve que le problème est réglé. Le test avec deux comptes reste la vérification la plus fiable.
Quand passer à un développeur
Le signal d'alarme est clair : tes utilisateurs saisissent des données personnelles, tu prends des paiements, ou tu dois intégrer ton produit à d'autres logiciels. À ce stade, un développeur doit relire l'architecture, et de préférence le code des accès aux données. Le prototype devient alors un produit, et il mérite le regard d'un professionnel.
Questions fréquentes
Le vibe coding est-il dangereux en soi ? Non. Le risque vient de la mise en production sans contrôle, surtout avec de vraies données. Un prototype testé sur des données fictives présente peu de risque.
Une plateforme de vibe coding protège-t-elle mes données par défaut ? Il ne faut pas le supposer. Les protections dépendent de la configuration de la base et des règles d'accès. Vérifie-les toi-même avec la grille ci-dessus, et lis la documentation de la plateforme sur ce qui est public.
Peut-on faire confiance à une relecture de code par IA ? Pour trouver des pistes, oui. Pour garantir la sécurité, non. Une faille se prouve par un test, pas par une lecture.
Faut-il éviter le vibe coding pour un produit sérieux ? Non. Il est très utile pour explorer et valider. Mais pour un produit qui reçoit des données réelles, prévois une relecture humaine et des tests avant le lancement.
Pour aller plus loin sur le coût réel d'un outil IA, lis le vrai coût de l'IA et les trois coûts cachés.
