Le Vibe Coding est justement une raison d'avoir besoin de devs
Vibe Coding … l’expression n’existe que depuis quelque mois1 et on a déjà l’impression de l’entendre partout. Il faut dire que la promesse est belle : permettre à tout un chacun de devenir développeur.
Enfin non… pas tout à fait…
Ce que promet le Vibe Coding, c’est de produire du code, sans savoir coder. Et c’est une nuance qui est loin d’être neutre. D’ailleurs, produire du code sans savoir coder, c’est un rêve qui n’est pas nouveau.
Quand j'ai commencé à m’intéresser à la création de sites à la fin des années 90, la suite Office contenait un éditeur de pages web, FrontPage, dont le principe de fonctionnement porte le doux acronyme de WYSIWYG : What You See Is What You Get. Par un habile jeu de glisser/déposer dans une interface visuelle, on était en mesure de sortir un page web. Le code généré était dégueulasse et sous-optimisé au possible, mais ça fonctionnait, le projet sera abandonné en 2003.
J’ai aussi ce souvenir d’un chef de projet qui m’annonçait la fin proche du métier de dev au début des années 2010, quand Microsoft sortait son éditeur visuel LightSwitch. En 2016, Microsoft recommandait officiellement de ne plus utiliser cette technologie.
Il n’y a pas si longtemps, on entendait partout que le NoCode viendrait résoudre la pénurie de développeurs. Aujourd’hui, des leaders comme Bubble et Make restent des outils niches pour solo-preneurs férus d’automatisation.
Et voilà que débarque le Vibe Coding. Même promesse, encore et encore. On ne va pas se mentir, je vois le truc avec beaucoup de scepticisme.
En bientôt 30 ans passés à développer (de façon plus ou moins intense et plus ou moins professionnelle), ce que je constate surtout, c’est que les non-développeurs ont une tendance à jeter rapidement l’éponge pour confier in fine le boulot à des gens dont c’est le métier.
Et c’est normal, c’est dû à une mauvaise compréhension du métier de dev.
Ça fait des années que je tiens le même discours : le métier de dev, ce n’est pas de produire du code. C’est une vision aussi simpliste que de penser que le métier de plombier est d’emboiter des tuyaux, que celui d’avocat est de rédiger des contrats, que celui d’Eric Clapton est de frotter des cordes de guitare…
Je vois deux barrières à la réussite à grande échelle du Vibe Coding. Deux composantes du métier de dev pour lesquels ma compréhension du fonctionnement des LLM m’empêche de penser qu’elles seront franchies.
Le discernement, la sagesse de celui qui s’est pris les murs
Le cabinet OX Research a récemment sorti une étude sur le Vibe Coding2, montrant comme défaut principal chez les modèles actuels, l’absence de discernement. Après avoir analysé plus de 300 dépôts de code, les chercheurs ont remarqué de manière quasi systématique la présence d’une dizaine d’anti-patterns : prolifération de commentaires sans valeur, absence de refactorisation au fil de l’eau, réinvention de la roue, couverture de code trompeuse ou encore mauvaise gestion du multi-environnement (le fameux “sur mon ordi ça marche” …).
Si ces patterns sont bien connus et documentés, c’est qu’il y a une raison. Ce sont des erreurs d’appréciation que l’on retrouve beaucoup chez des profils juniors. Comme les juniors, les IA manquent de sagesse et de recul. On retrouve dans le code des LLM les mêmes problèmes de scalabilités, de sécurité, de maintenabilité, que l’on retrouve dans celui des juniors. Pas forcément plus, mais pas moins.
Là où c’est problématique, c’est dans le nombre et la rapidité. OX Research a titré son étude “An army of juniors” et souligne que ces erreurs liées au manque d’expérience sont généralement endiguées par des process d’accompagnement et particulièrement de revue de code. D’une part, on voit difficilement comment faire une revue de code efficace quand un système agentique est capable de pondre le code d’une application entière en quelques minutes. D’autre part, l’intérêt de la revue de code pour le junior, c’est l’apprentissage, la capacité de gagner en expérience. Les LLM sont dits “apprenants”, ça ne veut pas pour autant dire qu’ils développent cette maturité dans l’architecture logicielle.
Et puis bon, même si c’était le cas, si des devs expérimenté·e·s prennent le temps de faire des revues complètes à l’IA, on relativise le bénéfice de rapidité du Vibe Coding.
La communication, la glu essentielle d’un projet
En 1971, Jerry Weinberg écrivait dans The Psychology of Computer Programming le commandement suivant :
Don’t be “the guy in the room”
L’une des qualités primordiales dans le développement, c’est la communication. On pense beaucoup que la programmation est un métier qui demande plus d’interaction avec les machines qu’avec les êtres humains et le cliché du geek qui se promène sur le spectre de l’autisme est encore bien ancré.
Pourtant, les meilleur·es devs que j’ai rencontré sont celles et ceux qui savaient poser les meilleures questions.
Ce qui fait que les dev contribuent à la réussite d’un projet, ce n’est pas d’avoir parfaitement compris le schéma d’exécution du compilateur (ça aide pour les perfs).
Non, leur valeur ajoutée, c’est par exemple une architecture qui permet d’évoluer dans le sens de l’ambition que le porteur de projet a présenté en kickoff, c’est un délai dans le comportement d’un bouton ajouté après avoir discuté avec un utilisateur de ses irritants, ce sont les points de vue échangés en pair programming sur la meilleure façon de répondre techniquement à une spécification fonctionnelle (parmi les 200 solutions possibles).
Quand on lit La dette technique, de Bastien Jaillot, on se rend vite compte que les problèmes liés à une base de code peuvent être ramenées de manière quasi systématique à un écueil dans la communication.
On met le Vibe Coding à la poubelle ?
Vous l’aurez compris, je ne suis pas le plus grand partisan du Vibe Coding et j’ai même tendance à le voir d’un mauvais œil. C'est peut-être un réflexe de vieux con, mais j’ai quand même l’impression d’avoir une compréhension suffisante des sous-jacents pour voir que ce n’est pas la magie que ça promet d’être.
En vrai, j’essaye de penser contre moi-même (et d’avoir des conversations en ce sens) et ça m’amène à considérer qu’il y a du bon dans le Vibe Coding, si on l’utilise en connaissance de cause.
Je suis assez sensible à l’idée que le Vibe Coding est optimal pour ce qu’on peut appeler des “petits périmètres”. Sa rapidité d’exécution est assez incroyable pour prototyper une idée, un concept, et la valider ou l’invalider. On peut l’utiliser pour spécifier de façon visuelle une brique fonctionnelle qui sera intégrée plus tard dans un périmètre plus large.
On m’a récemment soumis l’idée de l’utiliser pour construire des micro-services avec une approche jetable. Peu importe que ce ne soit des services optimisés ou maintenables, la rapidité de génération d’un nouveau service fait qu’on peut les remplace par un autre plutôt que de le faire évoluer. Ceci dit, les architectures micro-services sont complexes et demandent pour leur construction une bonne maitrise de l’ingénierie logicielle et en écriture de contrat d’interface (donc des devs).
Finalement, le Vibe Coding n’est pas une baguette magique, mais n’est pas une plaie non plus. Je suis quand même d’avis qu’il faut rester vigilant à ce que ça ne le devienne pas, vu l’engouement. N’oublions pas que les plus grands promoteurs du Vibe Coding (et de l’IA en général) sont ceux qui le vendent.
Comme avec beaucoup d’outil, de solution, on est ramené à cette finalité : solliciter son intelligence (réelle) et se renseigner correctement sur les bénéfices et les risques, pour faire des choix éclairés.
En espérant que ces quelques lignes auront servi à éclairer vos choix futurs, je vous laisse avec ce CommitStrip qui va bientôt fêter ses 10 ans, et qui est finalement toujours aussi d’actualité pour nos prompteurs en herbe.
Vous avez peut-être pensé à quelqu’un en lisant cet article. Si c’est le cas, envoyez-le-lui avec le bouton de partage ci-dessous, c’est le meilleur soutien que vous puissiez m’apporter. 🫶
Quant à moi, je vous donne rendez-vous dans deux semaines pour de nouvelles réflexions. D’ici là, n’hésitez pas à réagir, mettre des ❤️ si le sujet vous a plu et vous abonner si ce n’est pas encore fait.
À propos de moi
Je m’appelle Cédric Spalvieri. Blogueur et conférencier, j’ai accompagné ces 20 dernières années la transformation digitale d’entreprises allant de la PME au groupe international. Curieux des mutations que subit notre société, je m’intéresse à la manière dont les évolutions du numérique impactent le monde dans lequel nous vivons.
Les liens vers les pages Amazon sont des liens d’affiliation. En tant que Partenaire Amazon, je réalise un bénéfice sur les achats remplissant les conditions requises. Par honnêteté intellectuelle, je vous renvoie majoritairement vers des livres que j’ai moi-même déjà lus.
Le Vibe Coding est une belle porte d’entree pour augmenter l’intérêt pour le code et lancer des vocations.
Il permet aussi de décloisonner nos métiers : un PM peut donner vie rapidement à son idée (cela n’en fait pas encore un produit scalable, on est d’accord). Bcp de PME ont besoin de petites app très simples parfois, et ça fait le job.
J’essaye de trouver des usages nouveaux, par exemple au lieu de livrer un PowerPoint classique pour une proposition ou une restitution, je fais un mini-site interactif en React à mon client. Si on pense « usage jetable », le vibe coding est absolument génial.