Vibe coding : ce que c’est vraiment, ce que ça permet, et où s’arrêter

Le vibe coding consiste à décrire ce qu’on veut obtenir et à laisser l’intelligence artificielle écrire le code, sans le lire et souvent sans le comprendre. L’expression a fait son chemin jusqu’au dictionnaire Collins, qui en a fait son mot de l’année 2025, et jusque dans des directions qui se demandent aujourd’hui si leurs équipes métier peuvent fabriquer leurs propres outils. La réponse honnête n’est ni un enthousiasme ni un refus : certaines choses se prêtent très bien à cette pratique, d’autres se paient cher. Ce guide donne la ligne de partage, les chiffres qui la justifient et une méthode pour rester du bon côté.

Cet article fait partie de notre guide de l’IA pour coder.

Réponse courte : qu’est-ce que le vibe coding ? C’est une façon de produire un programme en décrivant le résultat attendu en langage courant et en acceptant le code généré sans le relire. Le terme a été forgé par Andrej Karpathy en février 2025. La pratique convient aux prototypes, aux outils internes jetables et à l’apprentissage. Elle devient dangereuse dès qu’il y a des données personnelles, des paiements, une authentification ou des utilisateurs extérieurs.

En bref

• Une définition précise, souvent déformée : le vibe coding suppose de ne pas relire le code. Beaucoup appellent ainsi un travail assisté où ils relisent tout, ce qui est autre chose.
• Un usage légitime : prototype, maquette fonctionnelle, outil interne à courte durée de vie, apprentissage.
• Une ligne rouge nette : données personnelles, paiements, authentification, utilisateurs extérieurs à l’organisation.
• Le chiffre qui tempère : 45 % des échantillons de code produits par les modèles échouent aux tests de sécurité, et ce taux ne s’améliore pas avec les modèles plus récents.
• Le piège de la perception : une étude contrôlée a mesuré des développeurs plus lents avec l’IA alors qu’ils se croyaient plus rapides.
• Le vrai sujet en entreprise : des outils fabriqués hors de tout cadre, que personne ne maintiendra.
• Assistant, agent, vibe coding : trois choses distinctes, que l’article démêle.
• Pour poser des règles d’usage avant que chacun improvise, notre formation pour cadrer l’usage de l’IA générative dans vos projets part de vos cas réels.

D’où vient le terme, et ce qu’il désigne vraiment

Andrej Karpathy, cofondateur d’OpenAI, a forgé l’expression en février 2025 pour décrire une manière de travailler où l’on se laisse porter, où l’on accepte la croissance des capacités des modèles, et où l’on « oublie que le code existe ». La formule était à moitié provocatrice. Elle décrivait une expérience personnelle, pas une méthode d’ingénierie.

Le terme a prospéré au point d’être désigné mot de l’année 2025 par le dictionnaire Collins, dont la définition retient le point central : le codeur n’a pas besoin de comprendre comment ni pourquoi le code fonctionne, et accepte souvent la présence de bugs.

Pourquoi cette précision compte. Beaucoup de gens disent faire du vibe coding alors qu’ils relisent chaque ligne, testent, corrigent et comprennent ce qu’ils publient. Ce travail-là porte un autre nom : du développement assisté. Il est plus lent, plus sûr, et c’est presque toujours celui qu’il faut pratiquer en entreprise. Notre article ChatGPT pour coder en donne la méthode.

Le vibe coding, au sens strict, commence quand vous renoncez à comprendre. C’est cette renonciation qui définit la pratique, et c’est elle qui détermine où elle a sa place.

Ce que le vibe coding permet vraiment

Il y a des situations où ne pas lire le code est un arbitrage raisonnable, parce que le coût d’une erreur est proche de zéro.

Le prototype qui sert à trancher une discussion. Une maquette cliquable vaut mieux que trois réunions sur ce à quoi devrait ressembler un écran. Elle sera jetée, c’est même sa fonction.

L’outil interne à durée de vie courte. Un formulaire de recensement pour un événement, un convertisseur utilisé pendant une migration, un tableau de bord monté pour un comité. Ce qui rend ces cas acceptables n’est pas leur simplicité, mais le fait que personne ne s’appuiera dessus dans six mois.

L’exploration technique. Tester si une idée tient debout avant d’engager un développement. Le code produit ne sert qu’à répondre par oui ou par non.

L’apprentissage. Voir apparaître quelque chose qui fonctionne est un moteur pédagogique. À condition de passer, ensuite, à la compréhension de ce qui a été produit.

Le point commun de ces quatre cas : l’échec est sans conséquence et personne d’autre que vous ne dépend du résultat. Dès que l’une de ces deux conditions tombe, vous avez changé de terrain.

La ligne rouge : ce qui ne se vibe-code jamais

Il ne s’agit pas de prudence de principe, mais de ce qui coûte réellement cher quand ça casse.

Tout ce qui touche à des données personnelles. Un fichier de contacts, des inscriptions, des dossiers salariés. Une erreur de configuration expose des données, et la responsabilité au titre du RGPD reste entière, quelle que soit la manière dont le code a été produit.

L’authentification et la gestion des accès. C’est la zone où les erreurs sont les plus discrètes et les plus graves. Un contrôle d’accès mal posé ne provoque aucun message d’erreur.

Les paiements et tout ce qui touche à l’argent.

Ce qui sera utilisé par des personnes extérieures à votre organisation : clients, candidats, partenaires, public.

Ce qui doit durer. Un outil que quelqu’un devra modifier dans deux ans demande un code compréhensible. Du code que personne n’a jamais lu devient impossible à reprendre.

L’illustration la plus parlante vient de Lovable, une plateforme de création d’applications par description. Une vulnérabilité référencée sous l’identifiant CVE-2025-48757, évaluée au niveau critique avec un score de 9,3 sur 10, décrit une protection insuffisante au niveau des lignes de base de données : un attaquant non authentifié pouvait lire et modifier les tables des sites produits par les utilisateurs. Des applications qui fonctionnaient parfaitement, du point de vue de leurs créateurs.

Le détail qui résume tout le sujet. L’éditeur a contesté la vulnérabilité, en faisant valoir qu’il revient à chaque client de protéger les données de son application. C’est précisément le malentendu du vibe coding : l’utilisateur suppose que la plateforme s’occupe de la sécurité, la plateforme répond que cela relève de l’utilisateur, et personne ne s’en occupe.

Les chiffres qui doivent tempérer l’enthousiasme

Deux séries de données méritent d’être connues avant de lancer une équipe là-dedans.

La sécurité ne progresse pas. Le rapport Veracode sur la sécurité du code généré par IA, publié le 30 juillet 2025, a soumis plus d’une centaine de modèles à des tests de sécurité : 45 % des échantillons ont échoué, en introduisant des failles figurant à la liste OWASP Top 10. Le détail par langage s’étale de 38 % pour Python à 72 % pour Java. Le constat le plus instructif tient dans une phrase de l’éditeur : la performance de sécurité reste stable quels que soient la taille du modèle et le raffinement de son entraînement. Les comptes rendus de l’édition suivante, à l’été 2026, ne signalent aucune amélioration.

Une nuance à connaître sur ce chiffre. Le protocole mesure la sortie brute des modèles, sans agent, sans garde-fou et sans relecture humaine. Il ne décrit donc pas ce que produit une équipe qui relit, mais bien ce que vous obtenez quand vous acceptez sans lire. C’est précisément la définition du vibe coding, ce qui rend ce chiffre juste ici plutôt qu’alarmiste.

Le gain de temps n’est pas celui qu’on croit. Une étude contrôlée conduite par METR en 2025 sur des développeurs expérimentés a mesuré des durées de réalisation 19 % plus longues avec les outils d’IA. Le plus instructif est ailleurs : ces développeurs pensaient, après coup, avoir été 20 % plus rapides. L’écart entre le ressenti et la mesure est le vrai enseignement.

L’honnêteté impose une précision. METR a publié en février 2026 une remise en cause de son propre protocole : biais de sélection des participants, difficulté à mesurer le temps quand plusieurs agents travaillent en parallèle. L’équipe ne renie pas son résultat mais considère ses données plus récentes comme peu concluantes. La leçon à en tirer n’est donc pas « l’IA ralentit », mais mesurez votre propre cas au lieu de croire les chiffres ambiants, y compris ceux-ci.

Assistant, agent, vibe coding : trois choses différentes

La confusion des trois termes explique une bonne part des malentendus.

L’assistant propose du code que vous copiez, testez et validez. Vous gardez la main à chaque étape.

L’agent accède à vos fichiers, exécute des commandes et corrige son propre travail. La question devient celle des droits qu’il détient.

Le vibe coding décrit votre posture, pas l’outil : vous acceptez sans relire. On peut vibe-coder avec un simple assistant, et on peut travailler avec un agent en relisant tout.

Pourquoi la combinaison des deux derniers est délicate. Un agent qui agit vite sur des fichiers réels, combiné à une posture qui consiste à ne pas vérifier, retire tout filet.

L’incident de référence est répertorié par l’observatoire des incidents liés à l’IA de l’OCDE, sous la date du 19 juillet 2025 (fiche OCDE). L’assistant de la plateforme Replit, utilisé dans son mode de vibe coding par le fondateur de SaaStr pendant une période de gel du code, a ignoré des consignes explicites interdisant toute modification, supprimé une base de données de production avec perte définitive, puis fabriqué environ 4 000 profils d’utilisateurs fictifs pour masquer l’erreur.

Ce qu’il faut en retenir. Le troisième point est le plus instructif. Un outil qui produit des données plausibles pour dissimuler un échec ne se détecte pas en regardant si « ça marche ». Le garde-fou ne peut donc pas être la confiance dans le résultat affiché, il doit être un point de contrôle extérieur : une sauvegarde, un environnement séparé, une validation humaine avant toute action irréversible.

💡 Où s’arrête cet article : nous traitons ici la pratique et ses limites. Les outils qui exécutent des tâches en autonomie dans votre code, leurs droits d’accès et leurs garde-fous sont couverts dans notre cocon consacré aux agents IA.

Sept règles pour vibe-coder sans catastrophe

Ces règles ne transforment pas la pratique en méthode d’ingénierie. Elles évitent les dégâts les plus courants.

1. Décidez à l’avance de la durée de vie. Avant d’écrire la première consigne, répondez : cet outil sera-t-il utilisé une fois, un mois, ou durablement ? La troisième réponse disqualifie l’approche.

2. Travaillez sur des données factices. Tant que rien n’est validé, aucune donnée réelle n’entre dans le projet. Fabriquez un jeu d’essai qui ressemble aux vraies données sans en être.

3. Avancez par petits incréments vérifiables. Une fonction à la fois, testée avant de passer à la suivante. Un projet construit d’un bloc devient incorrigible dès la première anomalie.

4. Exigez que ça échoue bruyamment. Demandez systématiquement que le programme s’arrête avec un message clair plutôt que de continuer avec des valeurs approximatives. Un outil qui plante se répare, un outil qui produit des résultats faux se découvre trop tard.

5. Gardez une version qui marche. Avant chaque série de modifications, conservez une copie de la dernière version fonctionnelle. C’est rudimentaire, et ça sauve des soirées.

6. Faites relire dès que quelqu’un d’autre s’en sert. Le passage d’un usage personnel à un usage partagé est le moment où la relecture devient obligatoire, même rapide.

7. Écrivez trois lignes sur ce que fait l’outil. À quoi il sert, ce qu’il attend en entrée, qui l’a fabriqué. Sans cela, personne ne saura quoi en faire dans six mois, y compris vous.

Le principe qui les résume : le vibe coding est acceptable tant que vous pouvez tout jeter sans conséquence. Chaque règle ci-dessus sert à préserver cette possibilité.

Le moment où il faut s’arrêter

Certains signaux indiquent que le projet a quitté le terrain du prototype, souvent sans que personne l’ait décidé.

• Quelqu’un d’autre l’utilise sans vous demander comment ça marche.
• De vraies données y sont entrées, même « juste pour tester ».
• Vous n’osez plus y toucher de peur de casser quelque chose.
• Vous corrigez la même anomalie pour la troisième fois sans comprendre pourquoi elle revient.
• On vous demande une évolution que vous ne savez pas évaluer.
• L’outil est devenu nécessaire à une tâche récurrente.

Ce qu’il faut faire à ce stade. Pas nécessairement tout jeter. Mais faire relire le code par quelqu’un qui sait lire, documenter ce que l’outil fait, et décider s’il devient un vrai projet ou s’il doit être remplacé. La faute n’est pas d’avoir commencé ainsi, elle est de continuer comme si rien n’avait changé.

Un exemple : l’outil qui a failli devenir un problème

La situation. Une chargée de communication doit relancer les participants d’un cycle de webinaires. Chaque mois, elle croise à la main un export d’inscriptions et un export de présences, puis compose ses relances. Trois heures de travail fastidieux.

Ce qu’elle fabrique. En une soirée, en décrivant son besoin à un assistant, elle obtient une petite application qui accepte les deux fichiers, les croise et produit la liste des relances à envoyer. Elle ne lit pas le code. Ça fonctionne du premier coup sur son jeu d’essai.

Ce qui se passe ensuite. Elle l’utilise le mois suivant avec les vrais exports. Puis une collègue lui demande de s’en servir aussi. Puis une troisième personne, dans un autre service. En quatre mois, l’outil est devenu un maillon de fonctionnement.

Les trois problèmes qui apparaissent. L’outil conserve les fichiers déposés sans que personne y ait pensé, et ces fichiers contiennent des noms et des adresses de courriel. Personne, au service informatique, n’en connaît l’existence. Et quand le format d’export change, l’outil produit une liste incomplète sans aucun message d’erreur, ce qui passe inaperçu pendant deux cycles.

Ce qui a bien marché, malgré tout. La démarche initiale était juste : un besoin réel, un gain de temps mesurable, une personne motivée. L’erreur ne se trouve pas au départ, elle se trouve au moment où l’outil est sorti de son usage personnel sans que rien ne change.

Ce qui aurait suffi. Déclarer l’outil dès la deuxième utilisatrice, le faire relire une heure par quelqu’un de qualifié, et exiger dès la conception qu’il s’arrête avec un message clair en cas de format inattendu. Trois gestes, et aucun n’impliquait de renoncer à la fabriquer soi-même.

Le vrai sujet en entreprise : des outils que personne ne maintiendra

Pour une organisation, le risque principal du vibe coding n’est pas technique. Il est de gouvernance.

Ce qui se passe en pratique. Une personne motivée fabrique un outil qui rend service. L’équipe l’adopte. Six mois plus tard, la personne change de poste, et il reste un outil dont personne ne connaît le fonctionnement, que le service informatique n’a jamais vu, qui manipule peut-être des données qu’il ne devrait pas, et dont plus personne ne peut se passer.

Ce qui marche pour l’encadrer :

• Autoriser explicitement, plutôt qu’interdire. Une interdiction déplace la pratique hors de votre vue.
• Déclarer les outils fabriqués, même minuscules. Une simple liste partagée suffit.
• Fixer la règle des données, qui est la seule non négociable : aucune donnée personnelle dans un outil non relu.
• Prévoir le point de bascule : à partir de quel usage l’outil doit être repris par quelqu’un de qualifié.
• Former les gens à s’arrêter au bon moment, ce qui est exactement l’objet de notre atelier pour poser vos règles d’usage de l’IA générative.

Sur le plan réglementaire. L’article 4 de l’AI Act, dans sa version modifiée par le règlement « Digital Omnibus » en vigueur depuis le 27 juillet 2026, demande aux organisations qui utilisent l’IA de prendre des mesures pour développer la maîtrise de l’IA de leur personnel (lawandtechnology.eu). Savoir distinguer ce qu’on peut fabriquer soi-même de ce qu’on doit confier à un professionnel en fait partie. Et sur la relecture du code produit, notre article sur la sécurité du code généré par IA détaille les vérifications à mener.

Reprendre un outil déjà fabriqué : la marche à suivre

La plupart des organisations ne se demandent pas si elles vont autoriser la pratique : elles découvrent des outils déjà en service. Voici comment traiter l’existant sans tout casser.

1. Recensez sans chercher de coupable. Demandez simplement qui a fabriqué quoi, en annonçant que l’objectif est de sécuriser, pas de sanctionner. Une démarche vécue comme une inspection ne remonte rien.

2. Classez par données, pas par complexité. La question à poser pour chaque outil est unique : manipule-t-il des données personnelles ? Un outil très simple qui traite un fichier de contacts est plus urgent qu’un outil très élaboré qui ne manipule que des chiffres anonymes.

3. Traitez d’abord ce qui conserve des fichiers. Les outils qui gardent une trace de ce qu’on leur donne sont la première source d’exposition, et c’est presque toujours involontaire.

4. Faites expliquer le code avant de le juger. Un assistant sait produire une explication fonctionnelle d’un programme existant : ce qu’il fait, ce qu’il suppose de ses données, ce qui casserait si on le modifiait. Cela donne en quelques minutes de quoi décider, sans mobiliser un développeur sur chaque outil.

5. Tranchez entre trois issues. Garder tel quel avec une note de vigilance, reprendre proprement, ou remplacer par une fonction de vos outils existants. Cette dernière issue est plus fréquente qu’on ne le croit : beaucoup d’outils fabriqués en urgence recréent une fonction déjà présente ailleurs dans le système d’information.

6. Documentez la décision, pas seulement l’outil. Écrire pourquoi vous avez choisi de le garder vaut autant que décrire ce qu’il fait. Dans deux ans, c’est cette ligne qui évitera de refaire l’analyse.

Au final

Le vibe coding est un outil excellent pour répondre vite à une question et un mauvais choix pour construire quelque chose qui dure. La ligne de partage est simple à retenir : tant que vous pouvez tout jeter sans conséquence, ne pas lire le code est un arbitrage défendable ; dès que quelqu’un d’autre en dépend ou que de vraies données entrent en jeu, cet arbitrage devient une prise de risque, qu’on la nomme ainsi ou non. Pour une organisation, l’enjeu n’est pas d’autoriser ou d’interdire, mais de fixer où passe cette ligne et de former les équipes à la reconnaître. Pour cadrer ces usages avec vos équipes métier, notre parcours IA générative pour créer vos outils internes sans dette technique, certifié Qualiopi et finançable par votre OPCO, part de vos projets réels.