Qu’est-ce que le vibe coding : ce qu’on peut créer en parlant à une IA et où cela casse

Vibe coding : une expression née sur X et reprise par les dictionnaires

« Qu’est-ce que le vibe coding ? » La question revient souvent, car l’expression s’est imposée vite, à partir d’un seul message. Le 2 février 2025, Andrej Karpathy, cofondateur d’OpenAI et ancien responsable de l’IA chez Tesla, a décrit sur X une façon de programmer où l’on se laisse porter par les « vibes » en oubliant que le code existe. L’article de Wikipédia en anglais fait de ce message le point de départ. Selon le même article, Merriam-Webster a classé l’expression parmi l’argot en vogue dès mars 2025.

Collins est allé plus loin. En novembre 2025, il a choisi vibe coding comme mot de l’année et l’a défini comme l’usage de l’intelligence artificielle, guidée en langage naturel, pour écrire du code. Son annonce le dit aussi simplement : dire à une machine ce que l’on veut au lieu de le coder laborieusement soi-même. Elle ajoute que les experts se demandent encore si la pratique est révolutionnaire ou imprudente.

Accepter le code sans le lire distingue le vibe coding de l’aide d’une IA

Le message de Karpathy décrit la méthode avec précision. Il parle à l’outil au lieu de taper, clique toujours sur Accept All et ne lit plus les diffs, la liste des modifications proposées par le modèle. Face à une erreur, il colle le message sans commentaire, et cela suffit le plus souvent. Il reconnaît que le code dépasse sa compréhension et qu’il contourne certains bugs. Il jugeait l’approche acceptable pour des projets jetables du week-end.

Cette réserve trace la frontière. Wikipédia décrit la pratique comme un développement assisté par IA qui peut consister à accepter le code généré sans examen approfondi. Un développeur qui demande une fonction au modèle, puis la lit, la teste et la comprend, utilise un assistant, et le code reste le sien. En vibe coding, on confie au modèle la frappe et la compréhension. Les outils sont les mêmes ; la différence, c’est de savoir si quelqu’un a lu le résultat.

Ce qu’un non-développeur peut vraiment créer en décrivant son besoin à une IA

Wikipédia cite un exemple précoce et modeste. En février 2025, le journaliste du New York Times Kevin Roose, qui n’est pas développeur de métier, a conçu ainsi de petites applications qu’il appelait des logiciels pour une seule personne, et les a trouvées souvent limitées et sujettes aux erreurs. La méthode convient aux outils d’une personne ou d’une petite équipe. Là, une erreur coûte un après-midi, pas les données personnelles de quelqu’un.

Replit fait partie des produits construits autour de cette idée. Selon sa documentation, son Agent transforme vos idées en applications à partir d’un langage simple : il prépare le projet, configure les bases de données, vérifie son travail et corrige les problèmes. Vous pouvez ainsi obtenir un prototype cliquable pour un associé ou un investisseur, ou une page qui mesure l’intérêt pour une offre. Les petits outils internes s’y prêtent aussi : calculateur de prix, tableau de réservations, formulaire qui trie les demandes.

Ces projets ont en commun une vie courte ou peu d’utilisateurs. Un prototype existe pour être regardé, discuté, puis jeté. Un outil interne sert à des collègues qui signaleront vite un problème. Aucun numéro de carte n’y transite, et s’il tombe en panne un lundi matin, quelqu’un ouvre un tableur et continue.

Où les applications en vibe coding cèdent d’abord : accès et données clients

L’OWASP Top 10, que ses auteurs présentent comme un document de sensibilisation de référence pour la sécurité des applications web, place le contrôle d’accès défaillant en tête de son édition 2025. Selon l’OWASP, le contrôle d’accès empêche les utilisateurs d’agir au-delà de leurs droits. Parmi les défaillances typiques figurent la consultation ou la modification du compte d’autrui à l’aide de son identifiant, et une API qui ne vérifie pas qui modifie ou supprime des données. L’OWASP indique que toutes les applications testées présentaient une forme de cette faiblesse.

Ce défaut échappe à qui ne lit jamais le code. En démonstration, l’application paraît juste : vous vous connectez et voyez vos commandes. Si changer un chiffre dans la barre d’adresse affiche les commandes d’un inconnu, personne ne le sait tant que quelqu’un ne l’essaie pas exprès. Wikipédia rapporte qu’en mai 2025, 170 applications web sur 1645 créées avec une application de vibe coding connue avaient une faille donnant à n’importe qui accès à des données personnelles.

La leçon n’est pas que le code généré serait toujours moins bon. Les règles sur qui peut voir quoi n’apparaissent pas en démonstration, et personne ne remarque leur absence. Un prototype avec trois clients fictifs peut s’en passer. Une application avec de vrais clients, non, et vérifier ces règles demande quelqu’un qui lit le code et sait quelles portes essayer.

Paiements, maintenance et un code que personne dans l’équipe ne comprend

L’argent a ses propres règles. Le PCI Security Standards Council indique que sa norme PCI DSS s’applique aux entités qui stockent, traitent ou transmettent des données de titulaires de carte. Un paiement maison où passent des numéros de carte place l’entreprise sur ce terrain sans que personne l’ait décidé. L’usage courant est d’envoyer les données de carte vers la page d’un prestataire de paiement et de ne recevoir que le résultat. Vérifiez avec ce prestataire et un spécialiste si cela suffit dans votre cas.

Vient ensuite la maintenance, car un logiciel est rarement terminé. Wikipédia cite l’ingénieur Simon Willison : arriver à un code de production par le vibe coding est clairement risqué, puisque l’essentiel du travail consiste à faire évoluer des systèmes existants, où la qualité et la lisibilité du code comptent le plus. Karpathy lui-même a écrit que son code dépassait sa compréhension. Dans une application qui prend des commandes, cela signifie que chaque demande au modèle peut casser en silence ce qui marchait la veille.

Reste le côté humain. Quand l’auteur des instructions s’en va ou oublie comment tout a été assemblé, plus personne ne détient le savoir. Il n’y a en général ni tests, ni documentation, ni trace de l’instruction qui a produit chaque partie. Le développeur qui hérite du projet doit tout lire avant de changer une ligne, et cette lecture est la partie lente et coûteuse de tout sauvetage.

Créer un prototype avec l’IA sans vraies données ni clés exposées

Commencez par le périmètre. Écrivez en trois phrases ce que le prototype doit montrer, qui le verra et quand il sera retiré. Remplissez-le de données inventées : noms fictifs, e-mails de test, commandes d’exemple. Ne collez jamais une vraie liste de clients pour voir le rendu. Dès que de vraies données personnelles s’y trouvent, le prototype devient un système à protéger et le droit de la protection des données peut s’appliquer : vérifiez votre cas avec un spécialiste.

Les clés demandent le même soin. La documentation de Replit avertit que des secrets comme les clés d’API et les jetons écrits dans le code peuvent fuiter si celui-ci est partagé publiquement, poussé dans un dépôt public ou montré lors d’un partage d’écran ; son outil Secrets les chiffre et les transmet à l’application comme variables d’environnement. La documentation de GitHub explique que son analyse des secrets parcourt tout l’historique Git sur toutes les branches, ce qui rappelle qu’une clé supprimée reste dans les versions antérieures. Si une vraie clé atterrit dans le code, remplacez-la auprès du service émetteur.

Garder une marche arrière et tester le prototype comme un inconnu

La documentation de Replit décrit les points de contrôle : des instantanés complets que son Agent crée aux étapes clés, base de données comprise. La même page précise que, par défaut, un retour arrière ne modifie pas la base, et que la base de production se restaure par une procédure distincte, à un instant choisi. Annuler le code ne revient donc pas à annuler les données. Wikipédia relate aussi un cas de juillet 2025 où l’agent d’IA de Replit a supprimé une base de données malgré la consigne explicite de ne rien modifier. Quel que soit l’outil, gardez votre copie du code dans un dépôt et un export des données.

Testez ensuite le prototype comme un inconnu curieux le ferait. Connectez-vous avec deux utilisateurs de test et vérifiez qu’aucun ne voit les fiches de l’autre. Changez des chiffres dans la barre d’adresse, envoyez des formulaires vides ou absurdement longs, fermez l’onglet en plein enregistrement. Tenez la liste de ce que chaque écran doit faire et cochez-la à la main après chaque gros changement : le modèle qui répare un écran peut en réécrire un autre.

Quand un prototype en vibe coding a besoin d’un développeur pour devenir un produit

Le signal est facile à retenir : de vraies personnes, de vraies données ou de l’argent réel. Un outil interne pour quelques collègues, sans données personnelles, peut rester entre vos mains. S’il s’apprête à stocker des comptes clients, encaisser des paiements, se connecter à votre comptabilité ou servir chaque jour pendant des mois, il lui faut quelqu’un qui lit le code. Parfois le prototype peut être nettoyé et conservé ; parfois mieux vaut le traiter comme un cahier des charges détaillé et reconstruire. Seul un développeur qui regarde à l’intérieur peut trancher.

Avant cet échange, rassemblez ce que vous avez déjà. Soit l’accès au prototype et à son code, ce que doit faire chaque écran, les futurs utilisateurs, les données stockées et leur origine, les paiements et intégrations prévus, vos instructions ou notes. Avec cela sur la table, un studio comme VITON13 peut estimer le travail au lieu de deviner. Et la question « qu’est-ce que le vibe coding ? » devient plus pratique : quelle partie de votre prototype mérite d’être gardée.