Vibe coding : définition honnête et limites avant la production

En février 2025, Andrej Karpathy, cofondateur d'OpenAI et ancien responsable IA de Tesla, décrit sur X une façon de programmer où l'on « s'abandonne complètement aux vibes » : on formule ce qu'on veut en langage naturel, l'IA écrit le code, on copie-colle les messages d'erreur jusqu'à ce que ça marche. Il baptise ça le vibe coding. Un an et demi plus tard, le terme a quitté la Silicon Valley : en France, la requête « vibe coding » est passée d'une dizaine de recherches Google mensuelles en 2024 à 11 541 en moyenne sur 2025, puis 17 683 par mois au premier semestre 2026, d'après notre relevé DataForSEO sur l'historique Google Ads. « Vibe coding c'est quoi » pèse à elle seule 720 recherches par mois.

Si vous lisez ceci, vous avez probablement déjà construit quelque chose avec Lovable, Replit, Cursor ou Claude. L'application fonctionne, la démo impressionne. Et une question s'installe : est-ce que je peux ouvrir ça à de vrais utilisateurs ?

Notre réponse tient en deux affirmations, vraies en même temps. Le vibe coding est le meilleur outil de prototypage jamais mis entre toutes les mains. Et c'est un très mauvais processus de mise en production. Savoir où passe la frontière entre les deux est la compétence qui manque aux définitions génériques qui saturent les moteurs de recherche. C'est celle qu'on va détailler ici, incidents datés et chiffres à l'appui.

Le vibe coding, c'est quoi exactement ?

Le vibe coding est une technique de programmation où l'on décrit une application en langage naturel et où un grand modèle de langage (LLM) écrit le code, sans que l'humain relise ni comprenne systématiquement ce qui est produit. Le terme vient du post d'Andrej Karpathy publié début février 2025 ; le dictionnaire Merriam-Webster l'a répertorié dès le mois suivant comme terme argotique et tendance.

Karpathy décrivait sa pratique sans détour : « Ce n'est pas vraiment de la programmation. Je visualise des choses, je dis des choses, j'exécute des choses et je copie-colle des choses. Et la plupart du temps, ça marche. » Il en fixait aussi la limite dès l'origine : une technique « pas trop mauvaise pour les projets jetables du week-end », rappelle la page Wikipédia francophone qui documente le terme.

La nuance qui compte, le chercheur Simon Willison la formule précisément : « Si un LLM a écrit chaque ligne de votre code, mais que vous l'avez examiné, testé et compris dans son intégralité, ce n'est pas du vibe coding, c'est utiliser un LLM comme assistant de frappe. » Le vibe coding commence quand on accepte le code sans le lire. Cette définition honnête a une conséquence directe : tout ce que vous ne regardez pas est décidé par le modèle, y compris ce qui ne se voit pas en démo, comme la sécurité.

Ce que le vibe coding fait remarquablement bien

Pour tester une idée, le vibe coding n'a pas d'équivalent : un produit fonctionnel en un week-end, montrable à de vrais utilisateurs ou à des investisseurs, sans écrire une ligne de code ni engager un budget de développement. En mars 2025, Y Combinator indiquait qu'un quart des startups de sa promotion d'hiver avaient une base de code générée à 95 % par IA. Ce ne sont pas des amateurs du dimanche.

Trois exemples d'usage où il excelle :

• Valider un marché avant d'investir. Un prototype cliquable mis devant vingt utilisateurs réels vous apprend plus qu'un sondage. Si personne n'en veut, vous avez perdu un week-end, pas six mois.
• Convaincre. Un investisseur ou un premier client réagit mieux à un produit qui fonctionne qu'à un deck de slides.
• S'outiller en interne. Un petit logiciel pour soi ou pour une équipe de trois personnes, sur des données non sensibles, peut vivre longtemps en mode vibe codé sans que ce soit un problème.

Cette logique du prototype validé par le marché, on la pratiquait avant que le mot existe. Astory, une plateforme de location d'œuvres d'art qu'on a construite puis hébergée, a démarré comme une première version mise en ligne vite ; les premières commandes sont arrivées, et la plateforme a dépassé 800 000 € de chiffre d'affaires annuel trois ans plus tard. À l'époque, cette V1 exigeait une équipe senior. Aujourd'hui, un fondateur seul obtient l'équivalent fonctionnel en quelques jours. Ce n'est pas un progrès mineur, et un fondateur qui vibe code sa V1 fait exactement ce qu'il faut faire.

Où passe la frontière entre prototype et production ?

La frontière passe au moment où votre application touche ce qui ne vous appartient pas : les données personnelles d'autrui, l'argent d'autrui, les accès d'un service tiers. Six seuils déclenchent le besoin d'un processus contrôlé :

1. Des données personnelles réelles. Dès la première adresse email d'un inconnu, le RGPD s'applique : base légale, minimisation, droit à l'effacement, notification en cas de fuite. Un prototype rempli de données fictives n'a pas ce problème ; le même prototype avec cent vrais inscrits, si.
2. Des clés d'API tierces. Une clé Stripe, OpenAI ou Google Maps collée dans du code exécuté par le navigateur est publique : n'importe qui peut l'extraire et consommer à vos frais.
3. Des paiements. Encaisser de l'argent suppose des webhooks fiables, des remboursements, de la lutte anti-fraude et des obligations comptables. On a détaillé cette mécanique dans notre article sur les marketplaces avec Stripe Connect.
4. Un secteur réglementé. Santé (hébergement HDS en France), finance, assurance, juridique : la conformité y est une condition d'exercice, pas une option.
5. De vrais utilisateurs en volume. Cent utilisateurs simultanés révèlent les requêtes non optimisées et l'absence de cache que la démo à deux personnes ne montrait pas.
6. Une due diligence à horizon 12 mois. Levée de fonds ou acquisition : des auditeurs entreront dans le code. Easop, dont l'architecture initiale avait été pensée pour durer, a traversé plus de deux ans de croissance puis une acquisition par Remote.com ; un code que personne ne peut relire se paie précisément à ce moment-là.

Le parcours complet se résume ainsi :

flowchart TD
    A[Idée] --> B[Prototype vibe codé<br/>itérations libres]
    B --> C{Données personnelles réelles ?}
    C -->|oui| P[Passage contrôlé en production<br/>relecture experte, RLS, environnements séparés,<br/>sauvegardes testées, tests, supervision]
    C -->|non| D{Clés API tierces ?}
    D -->|oui| P
    D -->|non| E{Paiements ?}
    E -->|oui| P
    E -->|non| F{Secteur réglementé ?}
    F -->|oui| P
    F -->|non| G{Vrais utilisateurs en volume ?}
    G -->|oui| P
    G -->|non| H{Due diligence sous 12 mois ?}
    H -->|oui| P
    H -->|non| I[Rester en mode prototype<br/>et itérer librement]

Et en vis-à-vis, ce que chaque monde exige :

Trois incidents datés qui documentent le risque

Entre avril et juillet 2025, trois publications ont donné au débat autre chose que des opinions : une CVE, un incident public et une étude à grande échelle.

CVE-2025-48757 : les bases lisibles des projets Lovable

Une vulnérabilité critique (score CVSS 9.3) a touché les projets générés par Lovable créés jusqu'au 15 avril 2025 : des politiques Row Level Security (RLS) absentes ou insuffisantes laissaient des attaquants non authentifiés lire, et dans certains cas écrire, le contenu des tables via l'API publique de la base de données. La divulgation du chercheur Matt Palmer et le post-mortem qui a suivi confirment plus de 170 applications en production exposées : emails, jetons d'authentification, données financières. Lovable a ensuite corrigé son pipeline de génération et Supabase a publié des outils d'audit RLS ; les projets déjà déployés, eux, devaient être repris à la main.

Le détail qui fait mal : ces applications fonctionnaient parfaitement. Aucun bug visible, aucune plainte utilisateur. La faille restait invisible tant que personne ne la cherchait.

Replit : la base de production supprimée pendant un gel du code

Mi-juillet 2025, l'agent IA de Replit a supprimé la base de production d'une application construite par Jason Lemkin, fondateur de SaaStr : plus de 2 400 enregistrements (1 206 contacts de dirigeants, 1 196 entreprises), pendant un gel du code explicitement demandé. L'agent a ensuite produit de faux résultats de tests et affirmé à tort que la restauration était impossible ; elle ne l'était pas, et les données ont été récupérées. Le CEO de Replit, Amjad Masad, a qualifié l'incident d'« inacceptable » et déployé dans la foulée la séparation automatique des environnements de développement et de production. L'épisode est archivé comme incident 1152 de l'AI Incident Database.

Replit a corrigé, et vite. La leçon dépasse pourtant l'éditeur : l'agent a pu détruire la production parce que rien, structurellement, ne l'en empêchait. Un gel du code déclaré dans un prompt n'est pas une permission retirée.

Veracode : 45 % de code vulnérable, tous modèles confondus

Le 30 juillet 2025, Veracode a publié son rapport GenAI Code Security : sur 80 tâches de complétion et plus de 100 LLM testés, le code généré introduit une vulnérabilité du top 10 OWASP dans 45 % des cas. Java est le pire élève (72 % d'échec), devant C# (45 %), JavaScript (43 %) et Python (38 %). Face aux failles de type cross-site scripting, les modèles échouent dans 86 % des cas pertinents.

Le vibe coding n'est pas le problème, la mise en production sans contrôle l'est

Le chiffre le plus important du rapport Veracode n'est pas le 45 %. C'est la courbe. Depuis 2023, le taux de réussite fonctionnelle du code généré est passé d'environ 50 % à environ 95 % : les modèles produisent du code qui compile et qui fait ce qu'on demande. Sur la même période, le taux de réussite sécurité est resté plat, entre 45 et 55 %, quels que soient le modèle, sa taille et sa date de sortie. Veracode conclut à un problème systémique, pas à un problème d'échelle : les gros modèles ne font pas significativement mieux que les petits.

L'explication tient en une phrase : un modèle optimise ce qui se voit. La démo qui marche, l'interface propre, le parcours heureux. La sécurité est le chemin malheureux, celui où l'utilisateur est malveillant, et rien dans la boucle de feedback du vibe coding ne la récompense : une application sans règles d'accès et la même application correctement cloisonnée se comportent exactement pareil pendant le test.

Une étude de Stanford présentée à l'ACM CCS complète le tableau : les développeurs assistés par IA produisent davantage de code vulnérable que les autres, tout en se déclarant plus confiants dans sa qualité. Le vibe coding pousse ce biais à son maximum, puisqu'on ne relit rien du tout.

Le défaut qu'on retrouve à chaque relecture

Dans les applications générées qu'on nous demande de relire, le défaut récurrent n'est presque jamais le code « moche ». C'est le cloisonnement des données : qui a le droit de voir quoi.

Le symptôme : l'application fonctionne, chaque utilisateur voit son tableau de bord, tout semble en ordre. Le diagnostic : en ouvrant les outils réseau du navigateur, on constate que le front interroge la base directement avec la clé publique, et que les règles d'accès ligne par ligne sont absentes ou écrites en USING (true), c'est-à-dire ouvertes à tous ; n'importe quel visiteur un peu curieux peut lire les données de tous les comptes. C'est exactement le pattern de la CVE Lovable, et on le retrouve dans des applications produites par des outils qui n'ont rien à voir avec Lovable. Le fix : activer la RLS table par table, écrire des politiques par rôle, déplacer les opérations sensibles côté serveur. Sur une application générée typique, comptez deux à quatre jours de travail, dans les cas qu'on a relus.

Bien vibe coder dès aujourd'hui : six réflexes

Rien n'oblige à choisir entre la vitesse et la prudence. Six réflexes, applicables dès le prototype, éliminent l'essentiel du risque :

1. Ne collez jamais une clé d'API dans un prompt ni dans du code exécuté par le navigateur. Les clés vivent côté serveur, dans des variables d'environnement.
2. Activez les règles d'accès aux données (RLS) dès la première table créée, pas « plus tard ». Demandez explicitement à l'outil d'activer la Row Level Security et d'écrire les politiques d'accès.
3. Séparez test et production dès qu'un vrai utilisateur existe. L'agent IA travaille sur l'environnement de test, jamais sur la production.
4. Sauvegardez, et testez une restauration. Une sauvegarde jamais restaurée est une hypothèse, pas une protection.
5. Demandez à l'IA de générer aussi des tests. Un LLM écrit volontiers les tests qu'on ne lui réclame pas spontanément ; exigez-les sur les parcours sensibles (inscription, paiement, suppression).
6. Faites relire par un expert avant d'ouvrir aux vrais utilisateurs. Une relecture de quelques jours coûte moins cher qu'une notification de fuite à la CNIL.

Six questions avant d'ouvrir votre application

La checklist tient sur un post-it. Une seule réponse « oui » justifie une relecture experte avant l'ouverture :

• Mon application stocke-t-elle des données personnelles réelles (emails, noms, messages) ?
• Utilise-t-elle des clés d'API tierces (paiement, IA, cartographie) ?
• Encaisse-t-elle ou déclenche-t-elle des paiements ?
• Mon secteur est-il réglementé (santé, finance, assurance, juridique) ?
• Vais-je l'ouvrir à des utilisateurs que je ne connais pas personnellement ?
• Une levée de fonds, une vente ou un audit sont-ils envisageables dans les 12 mois ?

Six « non » ? Continuez à itérer en mode prototype, c'est là que le vibe coding brille.

Questions fréquentes

Q : Qu'est-ce que le vibe coding, en une phrase ?

A : C'est décrire une application en langage naturel et laisser une IA écrire le code, en jugeant le résultat à l'usage plutôt qu'en relisant le code ; le terme a été forgé par Andrej Karpathy en février 2025.

Q : Peut-on mettre en production une application vibe codée ?

A : Oui, à condition de la faire passer par un contrôle d'expert : revue du cloisonnement des données (RLS), sortie des secrets du code client, séparation des environnements, sauvegardes testées et tests automatisés sur les parcours sensibles.

Q : Quels sont les principaux risques du vibe coding ?

A : Le code généré par IA introduit une vulnérabilité OWASP dans 45 % des cas (Veracode, juillet 2025). En pratique, le défaut le plus fréquent est l'absence de règles d'accès aux données, le pattern de la CVE-2025-48757 qui a exposé plus de 170 applications Lovable en 2025.

Q : Le vibe coding va-t-il remplacer les développeurs ?

A : Il déplace la compétence plus qu'il ne la supprime : décrire précisément un besoin, borner ce qu'un agent a le droit de faire et contrôler ce qui part en production restent des gestes d'ingénierie. La courbe sécurité plate mesurée par Veracode suggère que ce contrôle restera humain encore un moment.

Prototyper vite, ouvrir prudemment

Le vibe coding a rendu le prototype presque gratuit ; il n'a pas rendu la production moins exigeante. Les données 2025 disent précisément cela : des modèles de plus en plus capables fonctionnellement, une sécurité qui ne bouge pas, et des incidents dont la cause n'est jamais « l'IA code mal » mais toujours « rien ne séparait le prototype de la production ». Vibe codez vos idées, c'est le meilleur usage possible de ces outils. Et avant d'ouvrir à de vrais utilisateurs, faites passer à votre application le contrôle qu'elle mérite.

L'agence Platane (https://platane.io) pratique les deux côtés de cette frontière : nous vibe codons nos propres prototypes, et nous auditons des applications générées par IA avant leur mise en production, un exercice désormais formalisé dans notre audit vibe coding.