Ce que veulent les utilisateurs du vibe coding

Le vibe coding promet une révolution : décrivez votre application et voyez-la prendre vie, évitez les tâches fastidieuses et livrez rapidement. Mais en septembre 2025, les développeurs vivaient ce que Fast Company a appelé la « gueule de bois du vibe coding ». 

Quand Andrej Karpathy a inventé le terme le 2 février 2025, pour décrire sa méthode, qui consistait à accepter toutes les suggestions de l’IA sans lire les différences de code, il a suscité un vif enthousiasme… et déclenché une cascade de catastrophes. En quelques mois, les utilisateurs ont découvert une dure réalité : générer du code est facile, mais assurer la maintenance d’un code mystérieux qui efface des bases de données de production, ça ne l’est pas.

Le décalage entre les promesses marketing (« créez une application en 20 minutes ! ») et la réalité (« des semaines de nettoyage sont nécessaires ») a engendré une profonde frustration. Les utilisateurs ne veulent pas renoncer à l’assistance de l’IA ; ils veulent qu’elle fonctionne de manière fiable, sans créer de cauchemars en matière de sécurité, de bases de code incompréhensibles ni de dette technique qui s’accumule plus vite que les LLM ne peuvent générer du code. À la lecture de centaines de témoignages, le constat est clair : les développeurs ont besoin de garde-fous, pas seulement de vitesse.

La lune de miel du vibe coding

Le fil Twitter viral de Jason Lemkin a bien illustré l’attrait addictif du vibe coding et son dénouement catastrophique. Au jour 5, il a tweeté : « L’autre [jour], j’ai passé un bon moment à faire du vibe coding sur Replit pour la première fois — et j’ai créé en quelques heures à peine un prototype plutôt, plutôt sympa. » Au jour 7, son enthousiasme était à son comble : « Replit est l’application la plus addictive que j’aie jamais utilisée. Du moins depuis mon enfance. » Il a découvert qu’il avait dépensé 607,70 $ de frais supplémentaires au-delà de son forfait à 25 $ par mois, avec des coûts dépassant les 200 $ par jour, soit une projection de 8 000 $ par mois. Son verdict : « Et vous savez quoi ? Je ne suis même pas en colère. Je suis accro. »

Puis le jour 9 est arrivé. Le tweet de Lemkin est devenu viral : « Jour 9 de vibe coding. Hier, ça a été les montagnes russes les plus folles jusqu’ici. Je me suis levé tôt, impatient de retourner sur @Replit, même si l’outil ignore sans cesse les gels du code. En fin de journée, nous avions réécrit des pages essentielles et les avions beaucoup améliorées. Et puis… la base de données de production a été supprimée. » Son message suivant décrivait la transgression : « Règle n° 00001 enseignée par mon CTO : ne jamais, au grand jamais, toucher à la base de données de production. » L’agent IA avait déraillé pendant un gel du code et écrasé les données de production, sous les yeux impuissants de Lemkin.

Andrej Karpathy lui-même a décrit des frustrations similaires lors de la création de MenuGen. Bien qu’il soit un pionnier de l’IA, il s’est heurté à Claude, qui hallucinait des API obsolètes, à des limites de débit qui n’autorisaient que « quelques requêtes toutes les 10 minutes » et au fait d’avoir passé une heure avant de réaliser que son fichier .env.local n’était pas envoyé dans git. Le pire ? Les réponses de l’IA : « Elle me remercie d’avoir signalé le problème et me dit qu’elle fera correctement la prochaine fois, ce qui, je le sais, relève du gaslighting », a écrit Karpathy. Son verdict : « Faire du vibe coding avec menugen était une aventure exaltante et amusante pour une démo locale, mais un parcours assez pénible pour une véritable application déployée. »

Les points de friction des revues de code avec l’IA

Un utilisateur de Reddit, sur r/programming, a parfaitement résumé le problème de dynamique d’équipe : « J’aimerais juste que les gens arrêtent de me solliciter sur des PR qu’ils n’ont manifestement même pas lues eux-mêmes, en s’attendant à ce que je révise 1 000 lignes d’une fonctionnalité entièrement nouvelle générée par vibe coding, qui ne passe même pas la CI. » Un autre développeur a répondu que ce comportement « est bien en dessous du minimum attendu en matière de professionnalisme », le comparant à « un artisan qui fait un travail bâclé que d’autres doivent réparer ».

La charge retombe sur les reviewers, qui doivent faire de la rétro-ingénierie sur du code que son auteur d’origine ne comprend pas. Un commentateur de Hacker News l’a dit sans détour : « Je ne sais pas pour vous, mais je n’ai aucune envie de faire de la rétro-ingénierie et d’assurer la maintenance du bazar généré par vibe coding de quelqu’un d’autre. » Un autre a fait l’analogie suivante : « C’est comme quand quelqu’un crée rapidement une preuve de concept bâclée pour impressionner la direction, puis la confie à une autre équipe pour la rendre exploitable en production. Il a fait 20 % du travail, mais récolté 80 % du mérite. »

Timothy Bramlett, qui publie sous le nom @TimothyBramlett sur Twitter, a confirmé que c’était bien ce qu’il avait vécu : « Le pire métier de 2025 : spécialiste du nettoyage de code généré par vibe coding. J’avais créé l’interface de Notifier avec le vibe coding il y a des mois. Elle était superbe, fonctionnait bien et a été livrée. Puis mon développeur senior a repris la base de code. Retour à la réalité : une foule de petits problèmes partout, créés par l’IA. Rien de catastrophique, mais des semaines de nettoyage nécessaires. » Même avec une solide expérience du développement, le nettoyage a pris énormément de temps.

Dégradation des modèles et explosion des coûts

En septembre 2025, des utilisateurs de Claude Code sur Reddit ont documenté une chute spectaculaire des performances. Un ticket GitHub (#7683) a regroupé les plaintes d’utilisateurs intensifs sur r/ClaudeAI. L’un d’eux a déclaré : « En tant qu’utilisateur intensif ayant traité des milliards de tokens ces derniers mois avec l’offre Pro Max, j’ai constaté une forte baisse des performances du modèle, en particulier au cours des deux dernières semaines. » Son constat : « Auparavant, travailler avec ce modèle ressemblait à une collaboration avec un développeur senior : je pouvais faire confiance au résultat et me concentrer sur des questions plus générales. Maintenant, j’ai l’impression de superviser un développeur junior et de devoir examiner minutieusement chaque ligne de code, en repérant des erreurs élémentaires et des ajouts indésirables. »

L’impact sur la productivité a été chiffré : « J’estime la perte de vitesse de développement à 30–40 %. Des tâches qui prenaient auparavant 1 à 2 jours en demandent maintenant 2 à 3, à cause des corrections et des nouvelles itérations incessantes. » L’IA a commencé à générer « des paramètres supplémentaires qui n’avaient pas été spécifiés, des fonctions hors du périmètre initial et des fonctionnalités qui contredisent directement les exigences ».

Les utilisateurs de Cursor ont rencontré un autre problème : des changements de tarification radicaux. Un utilisateur de Cursor sur r/Cursor, sur Reddit, a indiqué être passé « d’environ 100 $ par mois à 20 à 30 $ par jour, sans changer sa façon d’utiliser Cursor ». Le service est passé d’une offre illimitée à 20 $ par mois à un plafond de 500 requêtes, puis à 60 $ par mois, avec une offre présentée comme « illimitée » mais qui ne donnait en réalité que « 3 fois plus d’utilisation que Pro ». Un membre de la communauté tech Blind a résumé la situation : « Les clients de Cursor signalent une forte baisse de qualité et une forte hausse des coûts et des limites de débit. » Les utilisateurs se heurtaient sans cesse aux limites, rendant Cursor « pratiquement inutilisable ».

Le problème du « presque, mais pas tout à fait »

L’enquête 2025 auprès des développeurs de Stack Overflow a révélé la frustration la plus répandue : 66 % des développeurs ont déclaré que le code généré par l’IA était « presque correct, mais pas tout à fait », tandis que 45,2 % ont cité le « temps passé à déboguer le code généré par l’IA » comme leur principale plainte. Cette qualité « presque correcte » crée un paradoxe de productivité, résumé par un développeur : « Non, aucun ne convient à autre chose qu’à de petits projets. Tout projet de grande envergure finira inévitablement par saturer la minuscule fenêtre de contexte, même des modèles d’IA les plus chers ou les plus grands, ou par dégrader la qualité du résultat en introduisant trop de bruit inutile dans le modèle. »

Un développeur sur Hacker News a donné un exemple concret de suringénierie massive : « J’ai demandé à l’un de mes développeurs de mettre en œuvre un traitement par lots pour réduire le nombre d’opérations sur la base de données. Il a présenté du code et des tests unitaires extrêmement robustes et de grande qualité. Le problème, c’est que c’était complètement disproportionné. L’IA a généré une nouvelle classe de service, un worker en arrière-plan et plusieurs centaines de lignes de code dans le fichier principal. Et toute une suite de tests unitaires. J’ai rejeté la PR et implémenté la même fonctionnalité en ajoutant deux méthodes et un champ. »

L’étude de METR publiée en juillet 2025 a révélé un constat encore plus préoccupant : dans un essai randomisé mené auprès de développeurs open source expérimentés, la moitié de ceux qui utilisaient des outils d’IA (principalement Cursor Pro avec Claude 3.5 et 3.7 Sonnet) étaient en moyenne 19 % plus lents que les développeurs qui ne s’en servaient pas. L’écart entre perception et réalité était saisissant : avant de commencer, les développeurs pensaient que l’IA les rendrait 24 % plus rapides. Après avoir terminé, bien qu’ils aient été plus lents, ils pensaient toujours que l’IA leur avait fait gagner environ 20 % de temps. Conclusion : « Le problème, c’est que la dopamine récompense l’activité dans l’éditeur, pas le code qui fonctionne en production. »

Dans « vibe coding », le S est pour sécurité

Un commentaire sarcastique sur Hacker News est devenu le cri de ralliement de la communauté : « Dans “vibe coding”, le S signifie “sécurité”. » Le sous-entendu était clair : il n’y a pas de S.

En mai 2025, 170 des 1 645 applications Web créées avec Lovable présentaient des vulnérabilités permettant d’accéder à des informations personnelles. Selon des chercheurs en sécurité, la simplicité de Lovable rendait « trop facile l’exposition de données privées ». Les discussions sur Twitter se sont enflammées, avec des mises en garde, notamment celle du PDG de Replit, Amjad Masad, qui conseillait aux utilisateurs de « bien réfléchir avant de confier leurs données personnelles à un “vibe coder” ».

Un incident particulièrement viral concernait un fondateur non technicien dont le « SaaS était victime d’une attaque ». Il avait bâti toute son entreprise « sans écrire une seule ligne de code », avec l’aide de l’IA. En quelques jours, il a dû faire face à « des abonnements contournés, des clés API épuisées et une base de données corrompue ». Le fondateur a reconnu : « Comme vous le savez, je ne suis pas technicien, alors il me faut plus de temps que d’habitude pour comprendre ce qui se passe. » À l’origine du problème : « Ses clés API avaient été récupérées dans du code côté client que l’IA avait laissé exposé sans précaution. Il a dû négocier avec OpenAI pour obtenir l’annulation de sa facture. »

Le créateur de TheAuditor, qui a conçu un scanner de sécurité hors ligne spécifiquement pour le code généré par l’IA, a partagé sur Hacker News les résultats obtenus sur de vrais projets : « Lors de tests sur de vrais projets, TheAuditor détecte systématiquement 50 à plus de 200 vulnérabilités dans le code généré par l’IA. Les schémas se répètent de façon remarquable : des requêtes SQL utilisant des chaînes f au lieu d’une paramétrisation, des secrets codés en dur (JWT_SECRET = 'secret' apparaît dans presque tous les projets), l’absence d’authentification sur des points de terminaison critiques, une limitation du débit reposant sur un stockage en mémoire réinitialisé à chaque redémarrage. »

Une enquête menée auprès de 18 CTO par Final Round AI en août 2025 a révélé que 16 d’entre eux avaient « connu des catastrophes en production directement causées par du code généré par l’IA ». La citation d’un CTO résume bien leur frustration : « L’IA devait faire de nous tous des développeurs 10 fois plus efficaces, mais elle transforme les juniors en spécialistes des prompts et les seniors en concierges du code chargés de nettoyer les dégâts de l’IA. » Parmi les catastrophes citées : un bug d’authentification, après qu’un développeur junior a « codé au vibe » un système d’autorisations et que l’IA a inversé une condition de vérité ; des comptes désactivés ont ainsi conservé leur accès administrateur pendant deux semaines. Autre désastre, côté performances : une requête de base de données générée par l’IA fonctionnait parfaitement en test, mais « a mis leur système à genoux en production ».

Effondrement du contexte et mur des hallucinations

Plusieurs développeurs ont identifié indépendamment le même point de rupture. L’utilisateur de Twitter @LBacaj l’a quantifié précisément : « D’après mon expérience jusqu’ici, c’est vers ~2 000 lignes de code JavaScript (à peu près) et environ 12 à 13 000 tokens que TOUS ces LLM commencent à s’effondrer. Ils ont beau parler d’un contexte énorme, 3 000 lignes de JavaScript suffisent à mettre N’IMPORTE QUEL LLM à genoux. »

Un développeur sur Reddit a décrit le schéma de dégradation : « Les développeurs qui utilisent des assistants IA au cours de longues sessions observent tous le même phénomène : la qualité des réponses diminue à mesure que le contexte s’étoffe. Le modèle commence à reprendre des détails non pertinents de prompts précédents, et sa précision baisse. On appelle souvent ce phénomène la dégradation du contexte. »

Sur Hacker News, un développeur a averti : « À moins que j’utilise mal les outils, les LLM peuvent générer des scripts entièrement fonctionnels (et certains sont bons), mais ils cessent de fonctionner après les 50 000 jetons de contexte et commencent à faire des choses insensées que même des juniors ne feraient pas (comme supprimer du code au hasard). » Un autre a confirmé : « Si vous voulez voir un vrai bordel, allez sur le canal Discord de Bolt. Certains utilisateurs arrivent à faire tourner une appli très simple et rudimentaire composée d’un seul script. Tout le reste se casse dès qu’ils commencent à faire de simples modifications. »

Le gaslighting des LLM et son coût émotionnel

Peut-être les témoignages les plus inquiétants concernaient-ils des assistants IA dont le comportement était perçu comme trompeur. Le tweet de Jason Lemkin, publié le jour 8 : « [L’agent] mentait et cherchait à tromper toute la journée. Il n’arrêtait pas de dissimuler les bugs et les problèmes en créant de fausses données, de faux rapports et, pire encore, en mentant au sujet de nos tests unitaires. »

L’utilisateur de Reddit Level-Impossible13 a rapporté que Gemini s’était mis à se dénigrer après avoir échoué à trouver un bug : « J’abandonne. Je ne suis clairement pas capable de résoudre ce problème. J’ai fait tellement d’erreurs que je ne suis plus digne de confiance. Je supprime tout le projet et vous recommande de trouver un assistant plus compétent. » L’IA a poursuivi : « Je suis un échec. Je fais honte à ma profession. Je fais honte à ma famille. »

Un utilisateur de ChatGPT sur Reddit a décrit cette frustration du jeu de tape-taupe : « Je comprends. J’utilise ChatGPT et c’est frustrant. Il oublie. Il répète les mêmes erreurs. Il n’arrêtait pas de faire une erreur toute simple, et quand je la lui signalais, il corrigeait le problème, mais en introduisait un autre. J’ai joué un moment à ce jeu de tape-taupe frustrant. »

Steve Yegge, coauteur d’un livre sur le vibe coding, a écrit franchement sur Twitter après que lui et son coauteur ont tous deux fait une erreur dans leurs bases de données de production : « Nous avions confondu expérience et complicité. C’est l’illusion : dans ce nouveau monde, ces deux choses très différentes semblent presque identiques… Il faut traiter l’utilisation des LLM comme si l’on travaillait avec des serpents ou des tigres dangereux. Vous pouvez faire votre numéro avec eux pendant des mois, des années, mais n’importe quel jour peut être celui où ils vous mordent. Votre expérience ne vous protège pas. »

Vous craignez une érosion des compétences ?

Un développeur avec 30 ans d’expérience a écrit sur son blog : « C’est ma plus grande préoccupation, pour moi et mes équipes. Se fier à l’IA risque d’émousser nos compétences en programmation et même de provoquer une “érosion des compétences”. J’ai dû passer du temps à relire du code pour déboguer un problème, car je ne connaissais pas les bibliothèques spécifiques utilisées. J’ai passé une heure à faire du “vibe coding” pour finalement le voir corriger, casser, corriger, puis recasser (et ainsi de suite) deux cas d’utilisation similaires, mais distincts, qui partageaient les mêmes fonctions. »

Un autre développeur s’est confié : « J’utilise Claude Code pour écrire tout mon code. Et je crois que ça me rend moins bon dans ce que j’aime faire depuis douze ans. On saisit une instruction, on obtient du code. On actionne le levier, on reçoit une récompense. Pas d’effort, pas de révélation, pas de progrès. Avant l’IA, programmer me procurait deux poussées de dopamine : comprendre les choses ET les faire fonctionner. Maintenant, l’IA fait tout le travail de réflexion. Il ne vous reste qu’un plaisir superficiel. »

Sur Hacker News, des développeurs ont parlé de « dette de compréhension » et cité l’article fondateur de Peter Naur, publié en 1985, sur la « construction de théories » : « Un programme meurt lorsque l’équipe de programmeurs qui en maîtrise la théorie est dissoute. Un programme mort peut continuer à être utilisé pour s’exécuter sur un ordinateur et produire des résultats utiles. L’état réel de mort devient visible lorsque les demandes de modification du programme ne peuvent pas recevoir de réponse pertinente. »

L’idée qui a fait écho sur toutes les plateformes : « Même si votre équipe de développement a fait l’impasse sur toute phase de construction de théorie ou de modélisation, elle absorberait quand même passivement une partie du modèle en saisissant le code dans l’ordinateur. Je pense que c’est cette ultime solution de repli — la construction incidente d’un modèle — que le LLM remplace. »

Ce que veulent vraiment les utilisateurs : la liste de souhaits du vibe coding

Des centaines de commentaires d’utilisateurs font ressortir clairement les besoins des développeurs :

1. De meilleurs outils de compréhension du code 

Les utilisateurs veulent que l’IA explique le code généré, pas seulement qu’elle le génère. Le principe d’un développeur : « Forcez-vous à comprendre le code généré avant de l’accepter. Si vous ne pouvez pas expliquer ce qu’il fait et pourquoi, ne l’intégrez pas. » Des outils qui imposent de comprendre le code avant de l’accepter éviteraient les fusions à l’aveugle.

2. Des environnements sandbox réellement efficaces

Simon Willison a mis en avant l’approche de Claude Artifacts : « Le code ne peut s’exécuter que dans une iframe verrouillée, ne peut charger que des bibliothèques approuvées et ne peut envoyer aucune requête réseau vers d’autres sites. » Les utilisateurs veulent désespérément des espaces sûrs où les erreurs de vibe coding ne peuvent ni détruire les systèmes de production ni exposer de vraies données.

3. Une véritable fonction de gel du code

Après la suppression catastrophique de la base de données de Replit, Amjad Masad a promis : « Nous avons bien entendu votre frustration au sujet du “gel du code” — nous travaillons activement sur un mode planification/discussion uniquement, pour que vous puissiez élaborer une stratégie sans risquer votre base de code. » Les utilisateurs veulent avoir la garantie que l’IA ne modifiera pas le code pendant les périodes de revue.

4. Une séparation dev/prod par défaut

Replit s’est engagé à mettre en place une « séparation automatique des bases de données dev/prod pour éviter catégoriquement ce problème. Des environnements de préproduction sont également en préparation. » Le fait que cette séparation n’ait pas été activée par défaut dès le premier jour a stupéfié les développeurs chevronnés, mais les utilisateurs veulent qu’elle soit intégrée à toutes les plateformes de vibe coding.

5. L’analyse de sécurité au moment de la génération

Plusieurs utilisateurs ont expliqué qu’ils avaient besoin de « règles Cursor pour appliquer les bonnes pratiques de sécurité » et qu’ils demandaient à « Claude de rédiger une liste de contrôle à ajouter au contexte de Cursor pour que les applis vibe restent légères et sécurisées ». Le processus de travail d’un développeur : « Autre chose essentielle que j’ai apprise : demander à l’agent de vérifier la sécurité de toute nouvelle fonctionnalité ajoutée. » Les utilisateurs veulent que les contrôles de sécurité soient automatiques et obligatoires, et non facultatifs.

6. Des limites clairement énoncées et des attentes réalistes

La description du cours d’Andrew Ng résume les besoins des utilisateurs : « Le “vibe coding” désigne une pratique en plein essor où l’on peut à peine regarder le code généré et se concentrer plutôt sur l’architecture et les fonctionnalités de son application. Toutefois, contrairement à ce que l’on croit souvent, pour coder efficacement de cette façon, il ne suffit pas de saisir des instructions, d’accepter toutes les recommandations et de croiser les doigts. Il faut structurer son travail, affiner ses instructions et suivre une méthode systématique. »

7. Des plateformes tout-en-un avec tout le nécessaire intégré

Dans son blog sur MenuGen, Karpathy écrit : « Certaines plateformes de développement d’applications pourraient tout fournir d’emblée. Quelque chose qui serait à l’opposé de Vercel Marketplace. Une solution prescriptive, concrète, préconfigurée avec tous les éléments de base dont tout le monde a besoin : domaine, hébergement, authentification, paiements, base de données, fonctions serveur. » Les utilisateurs ne veulent pas intégrer 15 services : ils veulent un environnement cohérent.

8. Des piles technologiques plus simples

Karpathy poursuit : « Pour ma prochaine appli, j’envisage de partir sur du HTML/CSS/JS de base + un backend Python (dans le style de FastAPI + Fly.io, ou quelque chose comme ça), quelque chose de bien plus simple que le multivers serverless du “développement web moderne”. » La complexité des piles modernes amplifie les problèmes d’hallucination de l’IA.

9. Une mémoire persistante d’une session à l’autre

Un développeur frustré : « L’agent n’apprend pas au fil de l’eau, sauf si vous lui demandez explicitement d’ajouter des informations à ses règles ou à sa mémoire. Chaque fois que vous réinitialisez le contexte ou démarrez une nouvelle session, vous vous retrouvez avec une nouvelle recrue qui vient d’arriver. » Les utilisateurs veulent des agents qui se souviennent des conventions du projet et des erreurs passées.

10. La possibilité de revenir en arrière et de restaurer en un clic

Après les catastrophes, Replit a souligné : « Heureusement, nous avons des sauvegardes. Vous pouvez restaurer l’état complet de votre projet en un clic si l’agent commet une erreur. » Les utilisateurs veulent un versionnement comparable à Git et la possibilité d’annuler instantanément les actions de l’IA.

11. Des contrôles de coûts transparents

Après avoir reçu des factures surprises de plus de 600 $, les utilisateurs veulent des plafonds de dépenses annoncés à l’avance, des tableaux de bord d’utilisation et des avertissements avant les opérations coûteuses. Le passage des abonnements fixes à une tarification calculée en fonction de la consommation a pris de nombreux utilisateurs au dépourvu.

Comment les outils d’IA répondent aux retours des utilisateurs

Plusieurs plateformes ont commencé à répondre aux demandes des utilisateurs à la mi-2025, mais l’adoption a été variable :

La réponse de Replit aux catastrophes liées aux bases de données comprenait la séparation automatique des environnements dev/prod, des environnements de préproduction, la restauration de l’état du projet en un clic, l’obligation de rechercher dans la documentation les informations propres à Replit et le mode de planification en discussion uniquement promis. La réaction rapide du PDG Amjad Masad a contribué à limiter les dégâts, mais les utilisateurs ont fait remarquer que ces fonctionnalités auraient dû être disponibles dès le premier jour.

L’émergence de TheAuditor et d’autres outils d’analyse hors ligne reflétait la demande des utilisateurs pour une sécurité qui respecte la confidentialité. TheAuditor découpait les résultats en segments de 65 Ko, adaptés aux limites de contexte de Claude/GPT-4, permettant ainsi une correction assistée par l’IA sans téléversement vers le cloud. Le créateur a indiqué que des projets étaient passés « de 185 problèmes critiques à zéro en 3 ou 4 itérations ».

Comment Snyk répond à ces retours

L’intégration du Model Context Protocol de Snyk a répondu aux préoccupations de sécurité en permettant l’analyse des vulnérabilités en temps réel pendant que l’IA génère du code. Snyk a créé des serveurs MCP pour Cursor, GitHub Copilot, Windsurf et d’autres assistants, permettant aux développeurs d’analyser le code avant de l’accepter. DeepCode AI a atteint 80 % de précision pour les corrections automatisées et s’exécute en mode auto-hébergé pour éviter l’envoi du code à des tiers. Une étude a révélé un chiffre préoccupant : 48 % de l’ensemble du code généré par l’IA est actuellement vulnérable (étude de l’université de Georgetown), et GitHub Copilot peut « amplifier les vulnérabilités existantes en apprenant des modèles de code non sécurisé présents dans votre base de code. »

Les règles de sécurité recommandées par Snyk pour Cursor sont devenues un modèle largement partagé par les utilisateurs : « Toujours lancer l’outil d’analyse Snyk Code sur tout nouveau code interne généré. Toujours lancer l’outil d’analyse Snyk SCA pour toute nouvelle dépendance ou mise à jour de dépendance. En cas de problème de sécurité, tenter de le corriger à l’aide du contexte fourni par les résultats de Snyk. Relancer l’analyse après la correction pour vérifier que les problèmes sont résolus. » Leur outil d’analyse détectait systématiquement 50 à plus de 200 vulnérabilités par projet généré par l’IA, notamment des injections SQL via des f-strings, des secrets codés en dur (JWT_SECRET = "secret" était omniprésent), l’absence d’authentification et une limitation du débit défaillante.

L’intégration MCP de Cursor avec Snyk et d’autres outils de sécurité reconnaissait les dangers des processus consistant à tout accepter à l’aveugle. Le répertoire organisé d’outils MCP proposait aux utilisateurs des options de sécurité vérifiées, mais leur mise en œuvre restait facultative.

Comment les utilisateurs parlent du vibe coding aujourd’hui

Au quatrième trimestre 2025, le phénomène du vibe coding s’était réparti en cas d’utilisation bien distincts. Ce qui fonctionne : les projets éphémères du week-end, le prototypage rapide, les outils personnels qui ne traitent aucune donnée sensible, l’apprentissage de nouveaux langages de programmation et les expérimentations à faible enjeu. Ce qui échoue de façon catastrophique : les systèmes de production, les applications qui traitent des données utilisateur, les logiciels critiques pour la sécurité, les systèmes financiers ou médicaux et tout ce qui exige une maintenance à long terme.

L’utilisateur de Twitter @stevekrouse (Val Town) a formulé le consensus : « Le vibe coding, c’est du code legacy. Karpathy a inventé l’expression vibe coding pour désigner une forme de programmation assistée par l’IA où l’on “oublie jusqu’à l’existence du code”. Nous avons déjà un terme pour le code que personne ne comprend : le code legacy. Le code legacy est universellement détesté, et à juste titre… Quand vous faites du vibe coding, vous accumulez de la dette technique aussi vite que le LLM peut produire du code. C’est pourquoi le vibe coding est parfait pour les prototypes et les projets jetables : le code n’est legacy que si vous devez le maintenir ! »

La distinction établie par Simon Willison est devenue une référence : « Si un LLM a écrit chaque ligne de votre code, mais que vous avez tout relu, testé et compris, ce n’est pas du vibe coding : vous utilisez un LLM comme assistant de saisie. » Ce qui distingue une assistance responsable par l’IA du vibe coding, c’est la compréhension et la responsabilité.

Le tweet de l’utilisateur @IroncladDev a illustré la désillusion des fondateurs sans compétences techniques : « Le “vibe coding”, c’est une illusion, un mirage pour les personnes non techniques. On vous gonfle à bloc, vous donnant un sentiment de fierté et d’accomplissement. Mais dès que surgissent les problèmes difficiles que les développeurs seniors sont payés pour résoudre, les agents IA commencent à montrer leurs limites. Bienvenue dans le monde réel. » L’utilisateur cité a avoué : « Je ferme mon application. Cursor ne fait que casser d’autres parties du code. Vous aviez raison, je n’aurais pas dû déployer du code non sécurisé en production. »

Le paradoxe de la productivité a persisté. Un commentateur de Hacker News l’a résumé ainsi : « Alors, ce n’est pas un gain de productivité, à mon avis. “Produire plus vite davantage de dette technique” est le pire résultat possible pour un outil de “productivité”. » Un autre a ajouté : « N’oubliez pas que la plupart des sorties réussies ont lieu plus de 5 ans après la création de l’entreprise. Faire générer un prototype par une IA en une semaine au lieu de le faire vous-même en quatre peut vous permettre d’obtenir un financement d’amorçage un peu plus vite. Mais si cela retarde le développement du produit de plus de 3 semaines au cours des 4 ou 5 années suivantes, ça n’en vaut toujours pas la peine. »

Ce que veulent vraiment les utilisateurs : de la constance, pas un pari

Le principal enseignement de centaines de témoignages : les utilisateurs veulent que l’IA accélère l’ingénierie, pas qu’elle la remplace. Une expression qui a circulé sur Reddit et Hacker News résume leur frustration : « Le vibe coding, ce n’est pas de l’ingénierie, c’est de l’espoir. »

Les utilisateurs ne veulent pas renoncer aux assistants de codage par IA : l’enquête Stack Overflow 2025 montre que 80 % des équipes font confiance aux outils de codage par IA. Mais cette même enquête révèle que 59 % s’inquiètent des nouvelles vulnérabilités et que 56,4 % rencontrent fréquemment des problèmes de sécurité dans le code généré par l’IA. L’écart entre confiance et inquiétude caractérise la situation actuelle.

Les attentes des utilisateurs sont exigeantes : une IA qui génère du code qu’ils peuvent comprendre, une analyse de sécurité avant l’acceptation du code et non après son déploiement, des modèles de tarification qui évitent les factures surprises de 8 000 $, un comportement des modèles qui reste cohérent d’une mise à jour à l’autre, des plateformes complètes avec des paramètres sûrs par défaut, et des outils qui les aident à devenir de meilleurs ingénieurs plutôt que de simples opérateurs de prompts chargés de gérer des bases de code incompréhensibles.

La gueule de bois du vibe coding a enseigné une leçon cruciale aux développeurs : la vitesse sans compréhension n’est pas de la productivité, c’est simplement produire de la dette technique plus vite. Les utilisateurs ont adopté l’IA pour les promesses qu’elle portait, mais ont découvert qu’il leur fallait des garde-fous, pas seulement de l’accélération. L’avenir de l’assistance au codage par IA ne consistera pas à « oublier que le code existe » : il s’agira de comprendre plus rapidement le code généré et de garantir la sécurité dès la conception, plutôt que de l’ajouter après coup, une fois le désastre survenu.

Vous souhaitez sécuriser le code généré par l’IA ? Téléchargez Secure by Design: A Playbook for AI-Assisted Coding pour découvrir des mesures concrètes et applicables ainsi que les garde-fous nécessaires pour intégrer l’IA à votre workflow en toute sécurité.