- Une nouvelle catégorie de services, le « nettoyage du vibe coding », a récemment émergé dans l’industrie IT :
Vibe Coding Cleanup as a Service
- Alors que la réalité s’impose selon laquelle la majorité du code généré par IA n’est pas adapté à la production, un nouveau marché de services dédiés à sa remise en ordre et à sa correction est en train d’apparaître
- Depuis qu’Andrej Karpathy a défini le « vibe coding » au début de 2025, 92 % des développeurs utilisent des outils d’IA, mais une baisse de la qualité du code et de sérieux problèmes de failles de sécurité sont également apparus
- En pratique, des développeurs se spécialisent déjà dans la résolution des incohérences, duplications et logiques absurdes produites par l’IA, tandis que des marketplaces et services de conseil dédiés se multiplient
- L’IA excelle sur les petites tâches, mais comme elle ne prend pas en compte le contexte système, elle génère de la dette structurelle et des problèmes de sécurité, ce qui fait émerger une nouvelle opportunité industrielle : une véritable « économie du nettoyage »
- Pour réussir à utiliser le code généré par IA, les entreprises doivent confier le prototypage à l’IA, mais investir dans des experts pour l’architecture, la sécurité et la mise au propre des tests
L’apparition et la diffusion du vibe coding
- Au début de 2025, Andrej Karpathy a employé le terme « vibe coding », ce qui a contribué à installer le concept
- Une méthode consistant à générer des fonctions entières via une conversation en langage naturel
- L’idée s’est rapidement diffusée avec la promesse d’un gain de productivité multiplié par 10
- Selon GitHub, 92 % des développeurs utilisent des outils de codage par IA
- Copilot génère chaque mois des milliards de lignes de code
- Mais selon une analyse de GitClear, l’usage de code IA entraîne un taux de churn du code supérieur de 41 %
- Le volume de code annulé ou réécrit dans les deux semaines augmente fortement
- Une étude de Stanford montre que les développeurs assistés par IA écrivent davantage de code moins sûr, tout en ayant tendance à le croire plus sûr
- Les outils d’IA amplifient plusieurs antipatterns à cause de l’absence de validation des entrées, de l’usage de dépendances obsolètes ou de décisions de conception ambiguës
La réalité de l’économie du nettoyage
- Dans l’industrie IT, le nettoyage du vibe coding constitue désormais discrètement un nouveau domaine de services
- Au départ, cela relevait de la blague — « réparer le code chaotique produit par l’IA » — mais cela devient aujourd’hui une véritable opportunité business
- Selon une enquête de 404 Media, certains développeurs bâtissent déjà leur carrière uniquement sur le nettoyage de code IA
- Ils démontent ce qu’on appelle parfois des « spaghettis IA » faits d’incohérences, de duplications et de logiques aberrantes
- Ulam Labs met en avant Vibe Coding Cleanup comme service principal
- Une marketplace dédiée, VibeCodeFixers.com, a également vu le jour
- Plus de 300 experts s’y sont inscrits en quelques semaines, avec des dizaines de projets mis en relation
- Client type : une startup ayant consommé des milliers de dollars de crédits OpenAI et disposant d’un prototype à moitié fonctionnel
Pourquoi le code IA échoue
- Le problème n’est pas que l’IA écrive intrinsèquement du mauvais code, mais qu’elle produit un code optimisé localement sans comprendre le contexte système
- Il en résulte une accumulation de motifs incohérents, logique dupliquée et failles de sécurité, qui génère de la dette technique
- Selon une étude de Georgetown University, au moins 48 % du code généré par IA comporte des vulnérabilités de sécurité
- Exposition de secrets, utilisation de bibliothèques anciennes, conditions de concurrence en situation de charge, etc.
- Plus grave encore, les développeurs eux-mêmes ne comprennent pas toujours suffisamment le code généré par l’IA pour détecter correctement les problèmes
- Thoughtworks qualifie cela de « dette de compétence »
- Un phénomène où l’équipe perd sa capacité à maintenir le code et devient dépendante de l’IA
Opportunité de marché
- Le marché du nettoyage connaît une croissance rapide, même s’il reste difficile à mesurer précisément
- Gartner prévoit que 75 % des développeurs en entreprise utiliseront une assistance IA au code d’ici 2028
- La plupart des projets devraient donc générer un besoin de remise en ordre
- Même si seule une partie nécessite un nettoyage, cela représente à l’échelle un marché émergent considérable
- L’aspect économique est également attractif
- Les startups créent rapidement un MVP avec l’IA, puis consacrent ensuite autant de temps et de budget au nettoyage
- Malgré cela, le processus reste plus rapide que le développement traditionnel
- Les spécialistes du nettoyage facturent 200 à 400 dollars de l’heure
- Des offres packagées, des audits de code IA et des services de type « Vibe-to-Production » se développent aussi
- Selon Thoughtworks, dans les projets utilisant l’IA, la part du refactoring diminue, le churn du code augmente, et une vaste phase de nettoyage est indispensable avant toute mise en production réelle
- De nombreux cabinets de conseil commencent à recruter des profils dédiés au nettoyage ou à la remédiation du code IA
- En conclusion, le marché du nettoyage existe bel et bien, il croît rapidement et reste encore largement inexploité
Impact sur l’ingénierie
- Un changement fondamental est en cours dans les méthodes de développement logiciel
- Le processus de développement se réorganise en une division du travail où l’IA implémente et les humains prennent en charge l’architecture, les tests et le nettoyage
- Gergely Orosz compare les outils d’IA à « un développeur junior très motivé », capable d’écrire du code rapidement mais nécessitant toujours une supervision
- Mais comme l’IA reste en permanence au niveau d’un junior et ne progresse pas vers un niveau senior, le rôle des spécialistes du nettoyage reste indispensable
- De nouvelles trajectoires de carrière s’ouvrent également
- Un développeur junior qui maîtrise les techniques de nettoyage peut atteindre en deux ans un salaire de niveau senior
- Les seniors qui comprennent les forces et les limites de l’IA créent une forte valeur
- Les entreprises qui réussissent ne sont pas celles qui utilisent le plus l’IA, mais celles qui mettent en place un processus de nettoyage structuré
- Les organisations qui construisent un processus de nettoyage robuste peuvent obtenir un avantage concurrentiel sur le marché
La position de Donado Labs
- Fort de nombreuses expériences de nettoyage de vibe code, Donado Labs souligne que l’IA est utile pour accélérer le travail, mais qu’un passage par des experts reste indispensable
- L’IA pour le prototypage et les tâches répétitives, les humains pour l’architecture centrale, la sécurité et les tests
- Avec son service « Vibe to Production », l’entreprise fait monter les prototypes IA au niveau des standards d’entreprise
- Cela inclut les tests, le renforcement de la sécurité et la documentation
- Les entreprises qui réussissent avec le code IA ne sont pas celles qui utilisent le plus l’IA, mais celles qui l’utilisent intelligemment et investissent dans le nettoyage
- L’essentiel est de mener ce nettoyage avant l’accumulation de dette technique
- À l’idée que l’IA remplacera les programmeurs, la vraie question business devient : « Qui va nettoyer ce code ? »
4 commentaires
Au début de GPT, il y avait des gens qui allaient voir des freelances en développement en disant qu’ils avaient fait un prototype avec l’IA et qu’il ne restait qu’à le finaliser un peu, pour ensuite tirer les prix vers le bas.
Mais honnêtement, est-ce qu’il y a vraiment des gens qui font ça ?
Avant même l’arrivée du vibe coding, je me disais déjà qu’un service capable de remettre en ordre du code complètement chaotique serait une bonne idée ; et voilà que quelqu’un l’a créé. Mais je ne pense pas que notre entreprise l’adoptera un jour T_T
Les prestations en freelance pour corriger les doigts sur les images générées par l’IA étaient à la mode… mais aujourd’hui, même ça, on ne le fait plus.
Le nettoyage par IA semble bien parti pour suivre la même trajectoire.
Avis Hacker News
Je reprends depuis assez longtemps des projets « structurés » via mon activité.
Autrefois, je récupérais surtout du code qui fonctionnait à peine en provenance d’agences de sous-traitance, mais aujourd’hui j’ai l’impression que la source s’est déplacée vers les LLM.
Au final, on dirait que ce sont toujours les mêmes problèmes qui se répètent.
Seule la méthode de réduction des coûts a changé.
Il y a évidemment des raisons de prendre des raccourcis, mais le vrai problème apparaît quand on n’a pas pleinement conscience que cela peut aussi engendrer des coûts.
Que cela vienne d’un manager, d’un employé ou d’un prestataire externe, le résultat est similaire.
Je n’ai pas encore vraiment fait la promotion d’un service dédié d’amélioration d’architecture pour les plateformes de vibe coding, mais c’est peut-être le moment de m’y mettre.
Le marché logiciel australien est petit, donc on entend rarement parler des résultats de ce genre d’expériences.
Je pense que la différence entre le vibe coding et le développement externalisé se voit surtout dans le volume de code produit.
J’ai déjà créé un petit script utilitaire en vibe coding, et si je l’avais écrit moi-même, il n’aurait probablement fait qu’un tiers de la taille actuelle, avec la plupart des edge cases non traités du tout (il y avait de la gestion d’exceptions inutile, mais aussi des choses vraiment utiles).
Tout ce que j’ai fait, c’est parcourir le code et supprimer une ligne d’effacement de fichiers temporaires parce qu’elle risquait d’effacer par erreur mon répertoire personnel.
Mais plus tard, en faisant un travail de données plus poussé, je me suis rendu compte qu’une partie des fichiers temporaires avait disparu et qu’il y avait encore deux autres blocs de suppression ailleurs.
En réalité, il y a trop de code pour qu’un humain puisse tout lire de manière réaliste.
En revanche, côté vitesse, l’efficacité est clairement énorme.
À l’avenir, au lieu de lire le code en détail, je compte plutôt faire tourner des tests avec l’IA dans un sandbox.
Il y a une grande différence, surtout avec des outils comme Claude Code qui ont un « mode plan ».
En ce moment, j’utilise beaucoup Claude Code au travail, et je commence toujours par le mode plan pour discuter de « comment l’implémenter », puis j’affine un plan détaillé à travers plusieurs échanges pour aboutir à une bonne conception.
Ensuite, l’IA m’indique précisément quel code elle va générer (avec le diff du code), et ce n’est qu’après mon approbation finale qu’elle génère réellement le code.
À l’inverse, quand je relisais autrefois le code produit par des équipes externalisées, c’était un spaghetti code totalement illisible.
Je pense que c’est une bonne idée d’ajouter au moins quelques termes liés au vibe-coding sur son site, ne serait-ce que pour le SEO.
J’ai eu une réflexion similaire.
Mais quand un projet a été vibe-coded et se retrouve bourré de bugs, est-ce que mon intervention pour corriger les bugs et remettre de l’ordre dans la structure suffit ?
Je me demande surtout comment une entreprise qui n’avait pas l’expertise nécessaire au départ peut ensuite assurer la maintenance.
Je pense qu’au fond, la sous-traitance et le développement basé sur les LLM demandent des compétences assez similaires.
Autrement dit, il faut toujours de solides fondamentaux d’ingénierie : cadrage des besoins, communication, gestion des parties prenantes, définition des spécifications, tests et documentation.
Je trouve un peu étrange que le concept de « vibe coding » de Karpathy ait pris cette ampleur.
J’ai l’impression que c’est surtout populaire chez des gens qui ont peu d’expérience réelle du développement.
Si je me souviens bien, le vibe coding, c’était plutôt une sorte d’état de flow où l’on discute avec une IA et où l’on avance en faisant confiance au résultat généré sans vraiment le vérifier, sans presque jamais revenir sur le code.
Si la qualité du logiciel que l’on construit a la moindre importance, c’est une approche vraiment horrible.
Ça peut convenir à un mème sur Twitter, à une expérimentation pour le plaisir, ou à un petit script perso à la maison, mais pour développer un vrai produit, ça me paraît absurde.
Si le terme a autant circulé, c’est parce qu’une personnalité connue comme Karpathy lui a donné un nom accrocheur ; si quelqu’un d’autre l’avait dit, ce serait probablement passé inaperçu.
Avant même l’IA, les développeurs juniors ou peu expérimentés codaient déjà parfois de cette manière.
Ils copient-collent des choses trouvées ailleurs, vérifient seulement que ça tourne, puis quand un bug absurde ou un core dump apparaît, ils réorganisent vaguement l’ordre du code jusqu’à ce que ça disparaisse.
Dans une entreprise, ce style peut au minimum vous valoir un avertissement, un plan d’amélioration des performances, voire une mise à l’écart.
Les non-spécialistes ont souvent eu du mal à obtenir de bons résultats dans leurs échanges avec des ingénieurs logiciel.
L’apparition du vibe coding ressemble à une remise en question de ce que nous avons livré comme logiciel jusqu’ici.
En pratique, la qualité des logiciels des startups vibe-coded que je connais est désastreuse, mais tant qu’ils font ce que leurs créateurs veulent, la qualité importe peu à ce stade.
Tant que la qualité logicielle n’inflige pas de « vrai dommage » à l’entreprise, ils ne voudront probablement pas prendre le risque d’embaucher des développeurs susceptibles de déformer leur idée.
Au final, même si c’est mauvais, disposer immédiatement de ce qu’ils veulent est pour eux une meilleure option qu’un logiciel parfait dont ils ne veulent pas.
Qu’on aime ou non l’idée, le vibe coding ne va pas disparaître.
Personnellement, je n’adhère pas vraiment au concept, mais au sein de mon organisation, il m’arrive souvent de dire à mes collègues « ça, je l’ai fait en vibe coding ».
Pour nous, cela veut simplement dire « le code a été majoritairement généré automatiquement par l’IA ».
Mais je n’envisagerais jamais de déployer ce type de code en production sans review.
C’est juste pour des essais légers, du genre « j’ai bricolé une appli sympa en vibe coding ».
J’ai l’impression que Karpathy voulait dire que le vibe coding était une « expérience possible » qui mérite d’être tentée pour voir jusqu’où ça peut aller, pas qu’il recommandait de construire de vrais produits en entreprise uniquement comme ça.
Les gens ont interprété l’expression de façon bien trop libre.
D’ailleurs, Karpathy a expliqué dans une vidéo YouTube ce qu’il entendait vraiment par là.
Article lié
YouTube de Karpathy : Software Is Changing (Again)
Je pense que le malentendu a grossi parce que les gens veulent croire qu’il devient enfin facile de faire des choses difficiles.
Je continue de penser que le tweet lui-même relevait surtout de la blague ou d’une célébration de la liberté du « YOLO coding », pas d’une recommandation de processus pour un usage professionnel.
C’était juste une manière légère d’exprimer le sentiment de libération ressenti à ce moment-là.
Aujourd’hui, vibe coding est pratiquement devenu un terme utilisé pour rabaisser ou tourner en dérision toute forme d’assistance IA au développement.
On peut bien ou mal utiliser n’importe quel outil, mais en ce moment, le mème « regardez à quel point le vibe coding est stupide » récolte très vite des points en ligne.
Ça devient fatigant.
L’idée centrale de l’article est que « si une startup construit plus vite son MVP grâce au vibe coding, puis nettoie plus tard en y consacrant finalement un temps et un coût comparables, cela reste quand même plus rapide que le développement traditionnel ».
Je me demande si c’est réellement vrai.
D’après ce que j’ai vu, si un développeur construit lui-même avec assistance IA, l’écart de vitesse n’est pas forcément énorme.
Surtout si l’on sait qu’un MVP ou un prototype finira directement en production, il me semble préférable de poser une architecture correcte dès le départ sur le long terme.
Mais la plupart des équipes produit et des dirigeants considèrent ce temps comme du gaspillage.
Le vrai avantage du vibe coding, c’est que l’équipe produit peut construire directement ce qu’elle veut sans avoir à l’expliquer à des développeurs.
Il y a peut-être un marché pour des outils produit fondés sur le vibe coding qui servent moins à générer du code qu’à clarifier les spécifications et les prototypes.
Ce type d’outils pourrait fournir de meilleures specs aux développeurs tout en donnant plus de contribution et de contrôle au côté business.
Dans une startup, le time-to-market est tellement crucial qu’il peut être parfaitement rationnel d’accepter de la dette technique si cela permet de sortir plus vite, même si au total cela coûte plus cher et prend plus de temps.
C’est d’ailleurs pour cela que les gens accumulent de la dette technique.
Twitter aussi a commencé comme une web app Ruby on Rails, et les serveurs tombaient régulièrement à chaque tweet de Justin Bieber avec le fail-whale à l’écran.
Mais avec la croissance, ils ont fini par embaucher des spécialistes et tout reconstruire correctement avec une architecture plus robuste et scalable.
Je pense que ça peut servir pour un prototype plutôt que pour un MVP,
mais si une organisation n’a pas la discipline collective et individuelle nécessaire pour éviter de mettre un prototype en prod, mieux vaut éviter le vibe coding.
Tout le monde sait à quel point il est difficile de convaincre la direction que « ce code génial qu’on utilise maintenant est en réalité un désastre intérieur et qu’il faut tout refaire ».
Dans ce genre de cas, les outils no-code sont bien plus sûrs.
En pratique, la plupart des MVP et prototypes finissent très vite en production.
Je me souviens que quelqu’un disait : « si le code du MVP n’est pas si sale qu’il en donne la nausée, c’est qu’on passe trop de temps sur sa qualité ».
Au final, ces solutions temporaires deviennent l’ossature de l’entreprise.
On pourrait appeler un service de simple remise en état « C-Suite cleanup as a Service », mais si on le vendait ainsi, personne ne l’achèterait sans doute.
Dès que j’ai lu le texte, il m’a semblé évident qu’il avait été écrit par Claude, même sans em-dash.
Bien sûr, l’OP a probablement fourni ses propres idées et sources dans le prompt, mais certaines tournures et nuances de phrases étaient exactement celles qu’on retrouve souvent chez les LLM, au point que la lecture m’a paru forcée.
Je me demande si ce style ne va pas finir par paraître daté, comme une véritable « prose LLM ».
On dirait que le prochain créneau porteur sera le vibe-writing cleanup as a service.
J’utilise beaucoup les em-dash depuis longtemps, mais on dirait qu’on arrive à une époque où il va falloir que je me force à en réduire l’usage.
Microsoft Word remplace automatiquement les tirets par des em-dash.
Je vois le vibe coding comme l’équivalent du bricolage en plomberie.
On essaye soi-même, puis quand la salle de bain fuit de partout, on finit par appeler un plombier d’urgence en payant cher.
Et au passage, on apprend un peu plus pour la fois suivante.
L’analogie tient, mais un plombier professionnel sait lui aussi bien utiliser les outils qui aident les bricoleurs.
La différence, c’est que les professionnels savent où et jusqu’où les utiliser.
J’ai l’impression que c’est encore pire.
En plomberie, on voit ce qu’on fait, alors qu’avec du vibe code, un jour quelque chose cesse soudain de fonctionner sans qu’on sache pourquoi.
Sur YouTube, on voit aussi beaucoup de plombiers amateurs qui travaillent parfois plus soigneusement que des pros.
Tout dépendra de la capacité du vibe coder à réellement apprendre de ce type d’expérience.
Il faudra voir avec le temps.
Je trouve cette analogie vraiment pertinente.
Comme un agent immobilier sous pression qui s’improvise plombier à la hâte pour vendre une maison, un fondateur de startup bricole quelque chose rapidement pour capter l’attention d’investisseurs ou de clients, puis fait venir de vrais experts plus tard pour nettoyer.
Avec un peu de chance, il évite la catastrophe majeure avant cela.
J’ai été surpris d’apprendre que le terme Janitor Engineer existait déjà dans le secteur.
Au passage, après « Why AI code fails at scale », tous les liens de l’article étaient cassés, ce qui est d’autant plus étrange pour un texte récent.
J’espère que personne ne le prendra mal.
Depuis que le vibe coding est devenu à la mode, je fantasme moi aussi à moitié pour rire sur un plan de retraite comme consultant en « all-organic-code », chargé de démêler et remettre en ordre des tas de code produits par l’IA.
Ce qui est vraiment rare, au contraire, ce sont les projets greenfield.
Le vibe coding dégrade rapidement la documentation et la clarté de l’architecture.
Les entreprises ne regardent plus que le volume de tokens de code générés et la vitesse de prototypage, en ignorant les coûts cachés de maintenance et de nettoyage.
Désormais, la vraie compétence n’est plus la génération, mais le nettoyage.
La vraie compétence, c’est d’abord de bien guider le processus pour obtenir un bon logiciel dès le départ.
J’en vois qui pensent que Claude Code, c’est « la pointe de la technologie », alors qu’en pratique cela demande beaucoup plus d’implication si l’on veut faire les choses correctement.
En réalité, ce n’est pas si différent de l’ingénierie classique.
L’essentiel est de minimiser les coûts tout en répondant au besoin.
Si la maintenabilité n’est pas explicitement demandée, on obtient exactement le résultat attendu, pour ainsi dire.
Pourquoi parler de mort de la documentation ?
On peut très bien commencer par rédiger la documentation, puis développer en vérifiant que le code reste conforme à cette documentation.
Ou bien générer la documentation depuis le code et en faire ensuite une revue manuelle pour vérifier qu’elle est pertinente.
Notre entreprise intervient depuis des décennies dans la récupération d’urgence des systèmes critiques de nos clients (panne entraînant de lourdes pertes financières et impossibilité de résoudre le problème en interne).
Ces dernières années, ce type de cas augmente à un rythme assez rapide.
Le vibe code ressemble au legacy code à bien des égards.
On n’a pas confiance dans le code, donc on hésite à le modifier, et sa qualité interne comme externe est faible.
Mais il y a aussi des différences.
Le volume de code est faible au regard de son âge, la pression sur les délais est forte, et les attentes sont exagérées.
La stratégie la plus rentable consiste à déplacer le plus d’erreurs possible non pas jusqu’au runtime, mais vers la phase de design ou avant le temps de compilation.
Le problème, c’est qu’avec l’IA, tout le monde file beaucoup trop vite jusqu’au runtime.
À ce propos, le texte « Vibe code is legacy code (val.town) » vaut le détour.
Post HN lié
Le legacy code n’est pas toujours mauvais.
Il est souvent complexe ou mal documenté, et a accumulé pendant longtemps des correctifs d’exploitation, petits et grands.
Il intègre beaucoup de problèmes de production réels et de nouvelles exigences, ce qui fait qu’il peut très bien tourner en conditions réelles.
Le vrai problème apparaît quand les personnes familières du code disparaissent, et qu’il n’y a même plus personne qui connaisse le langage ou les outils utilisés à l’époque.
Je me demande si le vibe coding est applicable aussi aux langages fortement typés.
Je suis d’accord avec l’idée qu’on peut traiter du code généré en vibe comme du legacy code.
Mais je me demande si les gens hésitent vraiment autant à modifier du vibe code.
Je me dis que la génération de code par LLM pourrait finir par disparaître.
L’article suppose toujours qu’un LLM génère du code et qu’un nettoyage est ensuite nécessaire, mais si le coût du LLM plus le coût du nettoyage reste toujours supérieur au salaire d’un développeur, ne finira-t-on pas par revenir à une écriture entièrement humaine ?
Générer du code avec un LLM puis le vérifier avant usage, ce n’est pas la même chose que le vibe coding.
Le vibe coding, c’est utiliser le code fini sans vérification.
À mon avis, aucune des deux approches ne va disparaître.
Le vibe coding basé sur l’IA, tel qu’on le connaît aujourd’hui, est déjà en train de perdre de son élan.
Parce qu’une IA encore meilleure arrivera bientôt.
À faire du vibe coding toute la journée, on risque peut-être d’aboutir à un modèle de coûts intenable.
L’enthousiasme général a pu être en partie une illusion créée par un excès d’assistance, avant un retour au réel plus douloureux.
En revanche, la tendance vers des outils d’aide par prédiction et génération automatique, nourris de tous les cas de code existants, ne disparaîtra absolument pas.
C’est comme le syntax highlighting : autrefois on codait sans, mais aujourd’hui plus personne n’a envie de revenir en arrière.
Retaper un DFS pour la 80e fois n’augmente pas mon estime de moi en tant que programmeur.