Le 2 février, Andrej Karpathy a publié une courte note qui donnait un nom à une pratique que de nombreuses personnes avaient déjà adoptée. Il l'appelle le « vibe coding ». Karpathy a fait partie de l'équipe fondatrice d'OpenAI et a dirigé l'IA chez Tesla; les termes qu'il propose sont donc largement repris. Il décrit une façon de travailler où l'on « s'abandonne complètement aux vibes » et où l'on « oublie que le code existe ». On indique à l'IA ce que l'on souhaite, on accepte ce qu'elle produit, on colle le message d'erreur lorsqu'un problème survient, et l'on poursuit.
Onze jours plus tard, l'expression est omniprésente dans nos fils d'actualité. Parmi les développeurs que nous suivons, environ la moitié réagit avec agacement et l'autre moitié avec enthousiasme.
À notre avis, il ne s'agit pas d'une percée soudaine. Nous travaillons avec les modèles de langage depuis GPT-3. Il s'agit plutôt d'un seuil franchi discrètement au cours des derniers mois, que Karpathy a été le premier à nommer publiquement.
En quoi consiste le vibe coding, concrètement?
La personne ouvre l'un des nouveaux outils : Lovable, Bolt, l'agent de Replit ou un éditeur comme Cursor. Elle décrit ce dont elle a besoin, par exemple « une page où les clients peuvent réserver une table le vendredi ou le samedi, avec un courriel de confirmation ». L'outil écrit le code. La personne évalue le résultat à l'écran, et non le code lui-même. Si le résultat ne convient pas, elle le signale. Si une erreur s'affiche, elle la recopie dans la conversation.
Cette dernière étape constitue le véritable changement. La personne ne débogue plus; elle décrit le problème, et c'est la machine qui effectue le débogage.
Notre équipe a consacré des années à concevoir des sites Drupal et WordPress à la main chez Raincity Studios, à Vancouver, et cette évolution est frappante de ce point de vue. Une grande partie de ce qu'une agence Web facturait correspondait à la couche lente et minutieuse du travail : mettre en place le projet, relier les formulaires, corriger la mise en page pour qu'elle tienne dans Internet Explorer. Cette couche devient rapidement peu coûteuse.
Il reste à voir si le terme s'imposera durablement. Il peut sembler passager, mais le mot « blogue » a d'abord produit la même impression. Il est probable qu'il dispose bientôt de sa propre page Wikipédia sur le vibe coding (en anglais), si elle n'a pas déjà été créée.
Peut-on vraiment obtenir un prototype en un après-midi plutôt qu'en quelques semaines?
Oui. C'est précisément là que l'approche est la plus efficace : la première version d'une idée.
Prenons un couvreur qui souhaite un petit calculateur de soumission sur son site, un restaurant qui veut voir à quoi ressemblerait la commande en ligne avant d'engager qui que ce soit, ou un petit exploitant touristique qui teste un parcours de réservation. Jusqu'à tout récemment, chacun de ces projets exigeait une rencontre, une soumission, quelques semaines de travail et une facture qui amenait la plupart des propriétaires à reporter le projet à l'année suivante. Aujourd'hui, une version cliquable peut être prête le jour même.
Selon notre évaluation, l'un des usages les plus utiles consiste à écarter les idées qui ne tiennent pas. L'outil est conçu en deux heures et présenté à trois clients; s'ils ne manifestent pas d'intérêt, l'entreprise vient d'économiser quelques milliers de dollars et d'éviter un investissement dans la mauvaise direction.
Cette approche améliore aussi la communication entre un propriétaire et un développeur. Montrer un écran sommaire qui fonctionne en précisant « comme ceci, mais avec cela » est nettement plus efficace que de décrire un besoin dans un long courriel. Notre expérience de ces courriels, rédigés comme reçus, montre que deux personnes ne les lisent jamais de la même façon.
Faut-il encore comprendre ce que l'on met en ligne?
Oui. La note de Karpathy précise elle-même que l'approche n'est « pas si mal pour des projets de fin de semaine qu'on jette ». Cette partie du message est beaucoup moins relayée.
Le code s'exécute, qu'on l'ait lu ou non. De nombreux outils relient une base de données en deux clics, ce qui est pratique, jusqu'au moment où se pose la question de savoir qui d'autre peut en consulter le contenu. Les règles d'accès ne sont prises en compte que par ceux qui savent qu'elles existent. Si la personne qui conçoit l'application n'en a jamais entendu parler, l'IA ne les mentionnera pas toujours d'elle-même.
Pour une petite entreprise, les zones à risque sont faciles à cerner : tout ce qui conserve des noms, des courriels ou des numéros de téléphone de clients; tout ce qui traite des paiements; tout ce qui exige une connexion. Si votre application fait l'une de ces choses, le fait qu'elle semble fonctionner ne suffit pas. Une personne doit comprendre où vont les données et qui peut les consulter. Les lois sur la protection des renseignements personnels en font aussi une question juridique, et un client dont les données ont été exposées ne sera pas rassuré d'apprendre que c'est une machine qui a écrit la partie défaillante.
Un site vitrine ou une page de menu constitue un cas différent. Le risque et les enjeux sont faibles, et le vibe coding y est tout à fait approprié.
Il en va de même pour un petit outil que vous serez seul à utiliser : classer vos factures, renommer un dossier de photos, transformer un tableur en liste imprimable. C'est exactement le projet de fin de semaine que décrivait Karpathy, et une excellente façon d'employer une soirée.
Quelles précautions prendre avant la mise en ligne?
Les pratiques qui permettent d'éviter les problèmes sont simples et bien établies.
- Conservez une copie du code à un endroit que l'outil ne contrôle pas. La plupart de ces outils permettent d'envoyer le code sur GitHub; nous recommandons de le faire dès le premier jour.
- Testez l'application comme le ferait un client : sur un téléphone, avec une adresse courriel erronée, avec un formulaire à moitié rempli, en appuyant sur « retour » en cours de route.
- Consignez ce que vous avez demandé. Si l'outil disparaît ou modifie ses prix, vos requêtes constituent ce qui se rapproche le plus d'un cahier des charges.
- Sachez qui est propriétaire du nom de domaine et du compte d'hébergement. Ce devrait être vous.
- Pour tout ce qui touche des renseignements personnels ou des paiements, faites examiner le code par une personne qui sait le lire avant la mise en ligne.
Rien de tout cela n'est nouveau; ce sont les mêmes pratiques qui s'appliquaient aux sites Web il y a vingt ans. La différence tient au fait que la conception est devenue si rapide que la vérification paraît lente en comparaison, et que bien des gens l'omettent. Nous nous attendons à ce que cette année apporte des incidents sérieux attribuables précisément à cette omission.
Si vous dirigez une entreprise locale et hésitez entre un véritable site Web de petite entreprise et une page produite rapidement avec l'IA, la réponse dépend de ce que le site doit gérer. Une page qui affiche vos heures d'ouverture est une chose; une page qui encaisse des dépôts en est une autre.
Comment le vibe coding est-il appelé à évoluer?
Nous prévoyons que la pratique se divisera en deux approches. Certaines personnes décriront sans jamais examiner le résultat. D'autres décriront, puis liront, testeront et corrigeront. Le second groupe devrait produire une quantité considérable de logiciels cette année; le premier risque davantage de faire les manchettes.
Les compétences déterminantes se déplacent également. Taper du code perd de l'importance chaque mois, tandis que savoir reconnaître un travail de qualité, et repérer ce qui cloche, en gagne.
C'était déjà la partie la plus exigeante du travail. Elle était simplement masquée par le temps consacré à la saisie du code.