Le « vibe coding » est un piège

Aujourd'hui, je change un peu de registre : pour une fois je ne vais pas vous expliquer un concept technique mais partager mon avis sur un sujet qui me tient à cœur. Inutile de ménager le suspense, le titre est assez transparent.

Pour ceux qui ne connaitraient pas, le « vibe coding » (qu'on peut franciser en « programmation au ressenti ») est une manière d'écrire des programmes informatiques en se servant principalement des IA génératives, c'est-à-dire des LLM comme ChatGPT, Claude, etc. Le terme de « vibe coding » a été popularisé par Andrej Karpathy en février 2025 sur X.

Il est important de souligner qu'on parle de « vibe coding » lorsque le développeur ne relit pas, ou seulement superficiellement, le code généré par l'IA qu'il copie-​colle. Toute modification du programme passe alors par un nouveau prompt que le développeur envoie à l'IA. Pour peu que l'IA soit directement intégrée à l'interface de programmation avec un mode vocal, vous pouvez « programmer » sans avoir à toucher le clavier ou la souris, et sans avoir à lire le code, juste en parlant, en regardant le résultat, et en parlant à nouveau jusqu'à obtenir le résultat souhaité.

Vous avez compris que je m'apprête à critiquer cette pratique, mais je ne condamnerai pas pour autant l'utilisation de l'IA en général pour coder. Je vais cibler ici les pièges bien spécifiques au « vibe coding ».

1. Ça va plus vite… oui et non

Sur des tâches simples et répétitives il est indéniable que le « vibe coding » ça va plus vite. Par exemple, une expérience contrôlée sur GitHub Copilot (implémenter un serveur HTTP en JavaScript) rapporte un temps de réalisation plus court de 55,8 % dans le groupe avec Copilot. Des essais randomisés en entreprise existent aussi : une étude (Microsoft, Accenture, et une entreprise anonyme) rapporte, en moyenne, une hausse d'environ 26 % du nombre de tâches complétées chez les développeurs qui utilisent l'outil, avec des gains plus marqués chez les profils juniors/​moins expérimentés.

Jusque-​là rien d'étonnant. Mais beaucoup de démos et de benchmarks testent des fonctions isolées : une entrée, une sortie, un petit contexte. Un logiciel réel, lui, demande de gérer des codes parfois très longs, divisés en plusieurs fichiers, des dépendances, des conventions de projet, des effets de bord, des contraintes de performance, de sécurité, de maintenance, etc.

Une étude de 2025 illustre très bien ce saut d’échelle : des LLM peuvent afficher 84-​89 % de réussite sur des benchmarks synthétiques, mais tombent à 25-​34 % sur des tâches de génération de classes issues de vrais dépôts open source, donc avec du vrai contexte, des dépendances, des patterns locaux. Reprendre après coup les erreurs et les diverses maladresses présentes dans le code généré par l'IA fait alors perdre un temps considérable.

2. Des bugs subtils non détectés par les tests

Avec le « vibe coding », on finit par faire le raccourci suivant : si les tests passent, alors le problème est réglé. Mais ce raisonnement est faux. Un test ne prouve pas qu'un code est bon en général. Il montre seulement qu'il se comporte correctement dans les cas précis que le test vérifie. Autrement dit, un code peut être mauvais, fragile, mal conçu, ou même partiellement faux… tout en passant tous les tests disponibles.

Il suffit que ces tests soient incomplets, trop permissifs, ou qu'ils ne couvrent pas les vrais cas difficiles. C'est un point important, parce que les IA sont très bonnes pour produire des correctifs qui ont l'air convaincants à court terme. Le code semble résoudre le problème. Les tests passent. Donc on valide. Mais il est possible qu'en réalité le correctif ne fasse que satisfaire les tests existants.

Le danger n'est pas forcément que l'IA « triche » volontairement contre les tests, mais qu'elle produise un correctif plausible, localement satisfaisant, qui passe les vérifications disponibles sans résoudre correctement le problème de fond.

Des travaux récents vont dans ce sens, même s'il faut rester prudent sur les chiffres exacts selon les conditions des études et les versions des benchmarks. Wang, Pradel et Liu ont étudié SWE-​bench Verified, un benchmark où des outils d'IA doivent corriger de vraies issues provenant de dépôts logiciels.

Dans SWE-​bench, un patch est considéré comme correct lorsqu'il passe les tests prévus par le benchmark. Or, les auteurs montrent que cette validation reste insuffisante : en lançant tous les tests développeurs disponibles, ils trouvent qu'en moyenne 7,8 % des patchs pourtant comptés comme corrects sont en réalité incorrects.

Les auteurs vont plus loin avec une méthode appelée PatchDiff, qui génère des tests différentiels pour comparer le comportement d'un patch produit par l'IA avec celui du patch humain de référence. Résultat : 29,6 % des patchs plausibles produisent un comportement différent de celui du correctif humain. Cela ne signifie pas automatiquement qu'ils sont tous faux, mais cela montre que le simple fait de passer les tests du benchmark ne suffit pas à garantir que le comportement obtenu est bien celui qui était attendu.

Après inspection manuelle d'un échantillon de 77 patchs suspects, les auteurs classent 28,6 % d'entre eux comme certainement incorrects, tandis que 66,2 % restent d'une correction incertaine, notamment parce que les issues sont parfois sous-​spécifiées. En extrapolant prudemment, ils estiment qu'environ 11 % des patchs plausibles pourraient être incorrects.

Ainsi, plus on se repose sur l'impression que « ça a l'air de marcher », plus on risque d'envoyer en production un code qui ne tient pas réellement la route. Un logiciel sérieux a au contraire besoin d'un code compréhensible, robuste, et défendable quand il faudra le modifier ou répondre d'un problème.

3. De gros problèmes de sécurité

Des bugs inattendus ou mal résolus peuvent être gênants pour l'utilisateur, mais le vrai danger concerne surtout la vulnérabilité du code produit par l'IA et non évalué par le « vibe coder ».

En matière de sécurité, le « ça marche » ne suffit jamais. Une application peut sembler fonctionner pour l'utilisateur tout en contenant des faiblesses exploitables par un attaquant. Le cas classique est celui de l'injection où des données fournies par l'utilisateur sont utilisées sans contrôle suffisant, ce qui peut permettre d'exécuter des actions non prévues et malveillantes.

Le « vibe coding » est donc dangereux dans ce contexte. Quand on ne sait pas bien lire le code qu'on a généré, on ne peut pas vérifier les endroits où la sécurité se joue : validation des entrées, échappement des données affichées, gestion des permissions, manipulation des secrets, appels réseau, dépendances externes, etc. Or ce sont rarement les tests fonctionnels ordinaires qui vont révéler ces failles. Ils diront que le bouton marche, que la page s'affiche, que la requête renvoie bien une réponse. Ils ne diront pas forcément qu'un attaquant peut détourner le comportement prévu.

Dans une étude expérimentale sur des tâches de programmation liées à la sécurité, Perry et ses collègues montrent que les participants ayant accès à un assistant IA ont produit un code significativement moins sûr que celui du groupe témoin. Plus inquiétant encore, ces participants avaient aussi davantage tendance à croire que leur solution était sûre. Autrement dit, l'outil ne crée pas seulement du risque dans le code, il peut aussi créer une surconfiance chez celui qui l'utilise.

Le rapport 2025 de Veracode aboutit à un constat similaire. L'entreprise a testé plus de 100 modèles sur des tâches de génération de code en Java, Python, JavaScript et C#. Résultat : 45 % des échantillons ont échoué aux tests de sécurité et ont introduit des vulnérabilités relevant de l'OWASP Top 10.

Le problème du « vibe coding » n'est donc pas qu'il produit un code imparfait, mais qu'il pousse à valider trop vite un code fonctionnel mais vulnérable. En matière de sécurité, ce genre d'illusions peut coûter très cher. Franchement, vous iriez taper un mot de passe dans une application web qui a été vibe-​codée ?

4. Qui est responsable ?

On présente parfois la relecture du code comme une vieille habitude vouée à disparaître. C'est une grave erreur. Dans un projet sérieux, la revue du code n'est pas un rituel bureaucratique, c'est le moment où l'on vérifie ce qui a été fait, mais aussi où l'on comprend pourquoi cela a été fait ainsi. Autrement dit, relire du code ne sert pas seulement à traquer les bugs, mais aussi à construire une compréhension partagée du programme.

Dans une étude devenue classique, Bacchelli et Bird concluent que la compréhension du code et des changements est un aspect central de la revue. Ils soulignent aussi que la revue apporte d'autres bénéfices essentiels : transfert de connaissances, conscience partagée de l'état du projet, recherche de solutions alternatives, et mise en commun de la responsabilité sur le code.

Le « vibe coding » court-​circuite toutes ces fonctions. Si le développeur se contente de valider parce que « ça marche », alors il n'y a plus de compréhension partagée, il n'y a pas d'appropriation réelle du projet, et surtout il n'y a plus de responsabilité. Le jour où il faudra débuguer, refactoriser, expliquer un choix technique, ou répondre à un incident, cette absence de compréhension et cette irresponsabilité chronique éclatent au grand jour.

Quelqu'un devra toujours répondre à des questions très simples comme : Est-​ce fiable ? Est-​ce maintenable ? Est-​ce assez sûr pour être mis en production ? Une réponse sérieuse ne pourra jamais être : « Je ne sais pas, c'est l'IA qui l'a codé ». Et si le logiciel provoque des dommages, qui doit payer ?

Au moment où j'écris ces lignes, j'apprends qu'une IA dérivée de Claude Opus a effacé toute la base de données de l'entreprise PocketOS, ainsi que tous ses backups. Vous imaginez le chaos ! Cette histoire n'est pas celle d'une application vibe-​codée, mais elle illustre bien les problèmes de sécurité et de responsabilité en matière d'usage des IA. Ceci est d'autant plus inquiétant que de nombreuses applications vibe-​codées utilisent des IA dans leur fonctionnement (via des clés API), et pas seulement lors de leur conception, ce qui amplifie les risques déjà soulignés.

5. S'enfermer dans l'incompétence

Un danger plus insidieux du « vibe coding » est l'absence d'apprentissage. Programmer ce n'est pas seulement produire un résultat, c'est aussi apprendre à lire et à écrire du code, à anticiper ses effets, à débuguer, à reconnaître et implémenter des structures logiques, à sentir quand une solution est fragile. Si ces compétences ne sont pas exercées, elles ne peuvent pas progresser. Un amateur ou un novice qui aborde la programmation par le biais du « vibe coding » ne peut pas apprendre à programmer. Pire, les programmeurs compétents qui délèguent de plus en plus la rédaction du code à des IA dégradent leurs compétences…

Le « vibe coding » nous fait donc troquer un gain de productivité à court terme contre un gain de compétence à long terme. C'est un très mauvais échange si vous voulez mon opinion…

La vie d'un logiciel ne s'arrête pas lorsque vous publiez sa version 1.0. Le métier de développeur ne consiste pas à écrire des fonctions neuves dans le vide. Il consiste surtout à reprendre un vieux code, comprendre ce qu'un collègue a écrit il y a deux ans, corriger un comportement inattendu sans tout casser… Si l'IA vous aide à produire du code sans renforcer votre compréhension, elle peut vous rendre plus rapide sur le moment en vous rendant plus dépendant ensuite.

Il faut aussi signaler que le gain apparent de productivité peut n'être qu'une illusion du fait du déplacement de la charge de travail. Une étude portant sur des projets open source a montré qu'après l'introduction de Copilot les contributeurs les moins expérimentés avaient un gain de productivité significatif, tandis que la charge de reprise du code généré retombe sur les développeurs les plus expérimentés. Ceux-​ci ont dû relire et corriger davantage de code généré par les autres, ce qui s'est soldé par une chute importante de leur propre productivité en écriture de code.

Les auteurs y voient un déplacement du travail. Les contributeurs novices produisent davantage de code maladroit avec l'IA, ce qui augmente la dette technique. Celle-​ci ne peut alors être absorbée que par les développeurs les plus compétents qui s'orientent alors de plus en plus vers la maintenance. Pendant ce temps, les contributeurs ayant recours au « vibe coding » ne progressent pas et ne passent donc jamais dans la catégorie des contributeurs expérimentés. Bientôt une pénurie ?

Cela est d'autant plus inquiétant qu'une étude à grande échelle réalisée sur des milliers de dépôts GitHub montre que le code généré par IA ajoute bien des coûts de maintenance à long terme. Ainsi, 22,8 % des problèmes introduits par l'IA sont toujours présents dans la dernière version du dépôt au moins neuf mois plus tard.

Les effets néfastes de l'IA sur l'apprentissage sont maintenant bien documentés. Une étude menée sur 1000 lycéens a montré que les élèves ayant recours à ChatGPT pendant leurs entrainements de mathématiques obtenaient +48 % de performance. Cependant, lors de l'examen sans IA, ils ont obtenu -17 % de performance. La leçon, c'est que quand on se sert de l'IA pour produire du résultat, on n'apprend pas et on en devient dépendant.

Cette incompétence et cette dépendance chroniques sont-​elles des conséquences malheureuses mais involontaires de l'utilisation de cette nouvelle technologie qu'est l'IA générative ? En tout cas, les entreprises qui nous vendent des IA les ont bien comprises et les ont intégrées à leur modèle économique :

We see a future where intelligence is a utility like electricity or water and people buy it from us on a meter and use it for whatever they want to use it for.

Conclusion

Ma motivation pour écrire ce billet vient en partie du fait que j'ai vu ces derniers temps pulluler des applications web générées avec des outils comme Lovable, Google AI Studio ou Bolt​.new qui sont dédiés au « vibe coding ». Je trouve cela d'autant plus dommageable que beaucoup de ces applications sont destinées aux enseignants et aux élèves, et qu'elles sont générées par des gens qui pensent bien faire. Contrairement aux enthousiastes du « vibe coding », je vous conseille 1) d'apprendre à coder plutôt que d'esquiver la difficulté, 2) et de ne pas utiliser d'applications qui ont été vibe-​codées pour ne pas encourager ces pratiques.

Je ne saurais dire exactement quel genre d'idéologie se cache derrière le « vibe coding », mais j'ai remarqué que lorsque cette pratique était critiquée, les gens qui la pratiquent ont tendance à rapidement taxer leur opposant d'être élitiste, d'être un gatekeeper, ou simplement d'être un conservateur qui rate le train d'une innovation incontournable. Il me semble qu'on peut y voir une sorte d'impératif technologique et un culte de l'innovation reposant en grande partie sur la peur d'être dépassé, mêlé à une version populiste du technosolutionnisme.

Certains des risques que j'ai pointés du doigt deviendront peut-​être moins importants à l'avenir. Les optimistes diront probablement que les risques liés à la sécurité par exemple, ou à la qualité du code en général, sont des points sur lesquels les prochaines générations d'IA vont forcément progresser. Mais je pense que le problème de la responsabilité humaine, et surtout celui de la dette cognitive et de l'apprentissage ne seront pas réglés par une amélioration technique des IA. Au contraire ces problèmes risquent de s'amplifier. J'aurais aussi pu aborder d'autres problèmes comme l'impact écologique ou le droit d'auteur, mais ils ne sont pas vraiment spécifiques au « vibe coding », ce sont des problèmes liés à l'IA en général.

J'avais presque fini d'écrire ce billet de blog lorsque Léopold Carron m'a suggéré cette vidéo de Micode. Elle développe bien cet aspect délétère de l'IA : l'atrophie des compétences intellectuelles qu'on n'utilise plus. Soulignons que ce n'est pas une condamnation de l'IA en général, mais de la manière souvent peu pertinente dont on s'en sert. Si vous voulez utiliser l'IA de manière intelligente, c'est-à-dire pour rester intelligent, alors vous devriez, par exemple, vous en servir comme un professeur particulier qui vous explique comment vous devez faire, et ensuite vous devez faire vous-​mêmes.

Transparence sur l'IA

Alors voici maintenant venu le moment de la question que tout le monde se pose. L'auteur de cet article est-​il un hypocrite qui a utilisé l'IA pour rédiger ce billet de blog ? De nos jours je crois qu'il est très important de mentionner la part de l'IA dans ce qu'on produit par souci de transparence et d'honnêteté intellectuelle.

L'IA a été utilisée pour une relecture de certaines parties du texte, ce qui a conduit à quelques corrections d'orthographe et reformulations. De plus, environ un tiers des sources ont été suggérées par une IA. La trame principale de l'article est de moi, mais certaines idées viennent de mes diverses lectures de billets de blog et d'articles de presse, ainsi que de vidéos YouTube que j'ai consultées au cours de l'année écoulée, mais que je serais aujourd'hui incapable de citer en intégralité, ne les ayant pas conservés dans mon historique. Je ne prétends donc pas avoir formulé ici un point de vue particulièrement original, mais j'espère avoir nourri vos réflexions sur le sujet.

Merci à Lee Mariault, marionp et azerin pour la relecture humaine.