Sommaire
Vibe coding : ce qu'il vaut en production, mesures 2025-2026
Sur 1 645 applications créées avec Lovable et exposées dans sa vitrine publique, 170 laissaient une partie de leurs données lisibles par n'importe quelle requête anonyme. Soit 10,3 %, mesuré en mars 2025 par un salarié de Replit, concurrent de Lovable. Le vibe coding promet une application en quelques instructions. Ce qu'il y a derrière est une autre question.
Les enquêtes sur le sujet portent surtout sur l'adoption et la vitesse. Cet article rassemble les mesures publiées sur ce qui arrive après la démonstration : sécurité, fiabilité, temps réellement gagné, et le moment où un audit devient nécessaire.
10,3 %des projets Lovable scannés (170 sur 1 645) exposaient des données sans authentification, en mars 2025
Son auteur, Matt Palmer, travaille chez Replit : lecture à garder en tête, même si la méthode est décrite en détail. Le scan chargeait la page d'accueil de chaque projet, repérait les requêtes vers la base de données et les rejouait en demandant toutes les lignes. Il n'a pas regardé derrière les pages avec connexion : le chiffre est un plancher, pas un plafond. Il a plus d'un an et demi, et rien dans la source consultée ne permet de dire que la proportion a changé depuis.
Vibe coding : du code relu ou du code ignoré ?
Le vibe coding désigne la création d'un logiciel par une IA sans que personne ne relise le code. Andrej Karpathy l'a lancé en février 2025 : on s'abandonne aux « vibes » et on oublie que le code existe. En mars, le développeur Simon Willison fixe la frontière : si une IA a écrit le code et qu'on l'a relu, testé et compris, c'est du développement, pas du vibe coding.
Le dictionnaire Collins, qui en a fait son mot de l'année 2025, retient une définition plus large : « l'usage d'une intelligence artificielle sollicitée en langage naturel pour aider à écrire du code ».
Cette différence n'est pas un détail. Stack Overflow pose sa question avec une définition proche de celle de Collins (générer du logiciel à partir de requêtes à un modèle) : même ainsi, 15,1 % des répondants disent en faire dans leur travail. Au sens strict, du code que personne n'a relu, la proportion ne peut être que plus faible ou égale. Le 90 % cité plus bas par le rapport DORA mesure autre chose : l'usage de l'IA par des professionnels du développement logiciel, pas le vibe coding. Dans la suite, le terme garde le sens strict.
Qui fait vraiment du vibe coding, et qui lui fait confiance ?
Peu de développeurs, selon l'enquête Stack Overflow 2025. Elle a demandé à 26 564 répondants si cette pratique faisait partie de leur travail, en la définissant comme la génération de logiciel à partir de requêtes à un modèle.
- « Non » : 72,2 %, auxquels s'ajoutent 5,3 % de « non, catégoriquement », soit 77,5 %
- « Oui » : 11,9 %, plus 2,8 % de « oui, un peu » et 0,4 % de « oui, catégoriquement », soit 15,1 %
- « Essayé » : 2,1 % ; « pas sûr » : 1,2 % ; réponses non classées : 4 %
Les pages de l'édition 2026 (30 903 réponses), consultées le même jour, ne mentionnent pas de question sur cette pratique : le chiffre le plus récent trouvé reste celui de 2025. L'échantillon est celui d'une communauté de développeurs, pas de créateurs d'applications sans formation : il décrit les professionnels, pas les porteurs de projet qui utilisent Lovable ou Bolt seuls.
La confiance ne suit pas l'usage. Dans l'enquête 2025, 3,1 % des répondants font « tout à fait confiance » à l'exactitude des outils d'IA et 29,6 % « plutôt confiance », soit 32,7 %. Ils sont 26,1 % à se méfier un peu et 19,6 % à se méfier fortement, soit 45,7 %. Et 66 % citent comme frustration des solutions « presque justes, mais pas tout à fait ». L'édition 2026 pose la question autrement : 48 % disent faire confiance à l'IA quand ils peuvent vérifier facilement le résultat, ce qui revient au même constat.
Le rapport DORA 2025 de Google Cloud, bâti sur près de 5 000 professionnels, donne 90 % d'adoption de l'IA et plus de 80 % qui disent y avoir gagné en productivité, mais 30 % ne lui font que peu ou pas confiance. Il mesure l'usage de l'IA en général : il ne dit rien du code laissé sans relecture.
Que laisse le vibe coding dans une application en production ?
Des failles que l'écran ne montre pas : le vibe coding en production expose des données que personne n'a vérifiées. Deux mesures le documentent, avec des méthodes différentes.
Le rapport 2026 de Veracode, éditeur d'outils de sécurité, a été publié le 28 juillet 2026. Sur quatre séries de tests et plus de 100 modèles suivis depuis le lancement du programme, le taux moyen de réussite aux tests de sécurité est de 56 %, quasi identique à l'année précédente. Les modèles réussissent la syntaxe à peu près à 100 %, mais échouent près de 44 % du temps quand aucune consigne de sécurité ne leur est donnée. Python obtient 63 %, Java 30 % (soit environ 70 % d'échec).
Le calcul est simple : 100 − 56 = 44, soit 44 échecs sur 100 tests quand personne n'a demandé de sécurité. L'édition 2025, publiée le 30 juillet 2025, portait sur 80 tâches de programmation et plus de 100 modèles : le code généré introduisait une faille de l'OWASP Top 10 (la liste des dix failles web les plus courantes) dans 45 % des cas de test, plus de 70 % pour Java.
Source : Veracode, GenAI Code Security Report 2025, 30 juillet 2025, consulté le 12 octobre 2026
Deux réserves. Ces tests mesurent des modèles sur des tâches calibrées, pas des applications livrées. Et Veracode vend de l'analyse de sécurité : il a un intérêt à ce que le sujet inquiète. Le scan de Palmer porte, lui, sur de vraies applications publiées, avec la réserve de son employeur citée plus haut.
Le mécanisme est banal. Les projets s'appuyaient sur Supabase, un service de base de données hébergée, dont les clés publiques sont visibles par conception. Ce sont les règles d'accès au niveau des lignes, ou RLS, qui décident qui lit quoi. Palmer attribue la faille à leur absence ou à leur mauvaise configuration, pas à la clé. L'entrée CVE-2025-48757 (un identifiant public de faille), publiée le 30 mai 2025, ajoute que Lovable conteste la faille, chaque client étant selon lui responsable des données de son application.
Source : CVE-2025-48757, enregistrement publié le 30 mai 2025, consulté le 12 octobre 2026
Le choix de la base de données est détaillé dans Supabase ou Firebase, les outils dans Lovable et Claude Code.
Sur un scan de 100 projets comparable, le taux de 10,3 % donnerait environ dix projets exposés. C'est une extrapolation d'un échantillon précis, pas une prévision pour votre application.
Les stores ajoutent leurs propres contrôles, qui ne dépendent pas de la manière dont le code a été écrit. Apple rejette les binaires (les applications compilées soumises au store) qui plantent ou qui présentent des problèmes techniques évidents (règle 2.1(a)) et exige que toute application permettant de créer un compte propose de le supprimer depuis l'application. La procédure complète est dans publier une application sur l'App Store et Google Play.
Source : Apple, App Store Review Guidelines, règles 2.1(a) et 5.1.1(v), consulté le 12 octobre 2026
Le vibe coding fait-il vraiment gagner du temps ?
Sur un prototype, la vitesse est réelle et personne ne la conteste. Sur du code maintenu, la mesure est moins nette.
En juillet 2025, METR a fait travailler 16 développeurs expérimentés sur 246 tâches réelles de leurs propres projets open source, avec ou sans IA, tirées au sort. Avec l'IA, ils ont mis 19 % de temps en plus. Avant l'essai, ils prévoyaient un gain de 24 % ; après, ils pensaient encore en avoir gagné 20 %. L'écart entre la mesure et la perception est le vrai résultat.
Source : METR, essai contrôlé sur 16 développeurs et 246 tâches, 10 juillet 2025, consulté le 12 octobre 2026
Cette étude est datée. Le 24 février 2026, METR a publié une mise à jour sur des outils plus récents : −18 % de temps pour 10 des développeurs de la première étude et −4 % pour les nouveaux recrutés, donc des gains, mais avec des intervalles de confiance (la fourchette où se situe probablement la vraie valeur) qui incluent zéro. METR juge ces données peu fiables : de plus en plus de développeurs refusent de travailler sans IA et ne participent pas, ce qui, selon METR, fait probablement sous-estimer l'effet réel (« lower-bound »). Ni l'une ni l'autre n'a été conçue pour mesurer du code généré par IA et jamais relu.
Une autre frustration de l'enquête Stack Overflow 2025 rejoint ce constat : 45,2 % des répondants trouvent que déboguer le code généré par l'IA prend plus de temps. Sans relecture, c'est exactement le travail que personne n'a fait en amont, et c'est ce qui alimente la dette technique d'une application.
Trois erreurs que ces chiffres rendent évidentes
Juger l'application à son interface. Les projets du scan venaient de la vitrine publique de Lovable, présentée par Palmer comme un ensemble de projets « présumés soignés » ; 170 d'entre eux, sur 1 645, avaient pourtant des données lisibles sans connexion, sur 303 points d'accès à la base. Une démonstration réussie ne dit rien de l'accès aux données.
Confondre prototype et produit. Un MVP sert à tester une demande auprès de quelques utilisateurs. Dès qu'il stocke des données personnelles, encaisse des paiements ou passe la revue des stores, il change de catégorie et les règles de la production s'appliquent.
Traiter le vibe coding comme du no-code. Le no-code fournit une plateforme, le vibe coding fournit du code qu'il faut ensuite pouvoir maintenir. Aucun des deux ne dispense de savoir ce qui tourne en arrière-plan.
Quand faire auditer une application générée par IA ?
Dès qu'une application stocke des données d'autres personnes, encaisse de l'argent ou doit passer une revue de store. Ce sont les trois situations où les mesures ci-dessus cessent d'être théoriques.
Deux contrôles découlent directement des mesures citées, les deux autres s'y ajoutent par prudence :
- L'accès aux données (mesuré par le scan de Palmer) : un compte utilisateur peut-il lire les lignes d'un autre ? C'est le contrôle que reproduisait le scan de Palmer.
- Les secrets (recommandation, hors mesures citées) : aucune clé privée dans le code livré à l'utilisateur, seule la clé publique prévue pour cela.
- Les règles des stores (règles Apple citées) : plantages, suppression de compte, métadonnées, comme dans les règles d'Apple citées plus haut.
- La maintenabilité (recommandation, hors mesures citées) : de quoi dépend le projet, qui peut le modifier, ce qu'il en coûte de le réparer plutôt que de le recommencer, selon les critères de la dette technique.
Si un prototype passe ces quatre contrôles, il peut rester tel quel. S'il échoue au premier, il faut le corriger avant tout lancement. Pour cadrer ce qui doit exister avant de générer quoi que ce soit, le cahier des charges d'une application mobile évite de laisser l'IA décider du périmètre, et le pilier créer une application mobile remet chaque étape dans l'ordre. Pour choisir qui reprend le code, freelance ou agence compare les deux options.
Questions fréquentes
Qu'est-ce que le vibe coding ?
C'est la création d'un logiciel en décrivant ce qu'on veut à une IA, sans relire le code produit. Le terme vient d'Andrej Karpathy, février 2025. Pour le développeur Simon Willison, du code écrit par une IA mais relu, testé et compris relève du développement classique assisté, pas du vibe coding.
Le vibe coding est-il fiable pour une application en production ?
Les données disponibles invitent à la prudence. Veracode mesure un taux moyen de réussite de 56 % aux tests de sécurité du code généré par les modèles seuls, et un scan de 2025, réalisé par un employé d'un concurrent, a trouvé des données lisibles sans authentification dans 170 projets Lovable sur 1 645. Un prototype se juge à l'écran, une application en production se juge sur ses données et sa tenue dans le temps.
Peut-on publier sur l'App Store une application créée en vibe coding ?
Les règles d'Apple s'appliquent au binaire, pas à la façon dont le code a été écrit. Une application qui plante ou qui a des défauts évidents est refusée, et toute application qui permet de créer un compte doit proposer sa suppression depuis l'application. Ce sont ces points, et non l'outil utilisé, qu'une soumission doit satisfaire.
Faut-il savoir coder pour faire du vibe coding ?
Non pour obtenir un prototype qui s'affiche. Oui pour juger ce qu'il contient : dans l'enquête Stack Overflow 2025, 66 % des répondants citent comme frustration des solutions d'IA presque justes, mais pas tout à fait. Sans personne capable de lire le résultat, ces écarts partent en production.