Le vibe coding, vu par un développeur qui code depuis 2006

20 ans d’expertise en développement web, ça ne se prompte pas […]

Le vibe coding, littéralement programmation au ressenti, consiste à faire écrire un logiciel par une intelligence artificielle, en lui parlant, sans lire le code qu’elle produit. Le mot est né le 2 février 2025, dans un message d’Andrej Karpathy, cofondateur d’OpenAI, et le dictionnaire Collins en a fait son mot de l’année 2025. Le message d’origine :

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

Traduction : il existe une nouvelle façon de coder, que j’appelle le vibe coding, où l’on s’abandonne complètement aux vibes, où l’on embrasse les exponentielles et où l’on oublie que le code existe.

Plus loin dans le même message, il décrit sa méthode, et sa limite :

I "Accept All" always, I don't read the diffs anymore. […] It's not too bad for throwaway weekend projects, but still quite amusing.

Traduction : je clique toujours sur Accept All, je ne lis plus les modifications. […] Ce n’est pas si mal pour des projets jetables du week-end, et ça reste assez amusant.

Le vibe coding n’est donc pas coder avec l’IA : c’est coder avec l’IA sans regarder.

En 2006, à 15 ans, j’ai fait un clic droit sur la page d’accueil de Google, sous Opera 9, puis « Afficher le code source ». J’ai appris le PHP, le HTML et le CSS sur le Site du Zéro et sur les forums, et le Visual Basic dans un livre.

Mon premier assistant de code était donc un livre de Visual Basic. Il ne m’a jamais proposé d’appuyer sur Tab.

Pendant quinze ans, jusqu’à GitHub Copilot, chaque ligne de mon code est passée par ma tête et par mes mains. C’est ce métier-là qui me permet aujourd’hui de juger ce qu’écrit une IA. Le reste de l’histoire est sur la page mon parcours.

Oui, tous les jours, sur mes projets comme au travail. Mon premier vrai usage remonte à 2021-2022, avec GitHub Copilot ; aujourd’hui, j’utilise Claude Code, un agent qui travaille dans le terminal, et qui figure sur ma page Uses.

Je lui confie quatre sortes de travail : écrire du code neuf, déboguer et comprendre un code que je ne connais pas, le répétitif, et des tickets entiers, confiés à des agents. Je dirige l’équipe d’agents d’IA qui construit ce site.

Le partage du travail entre l’IA et moi

Ce que je confie à l’IA	Ce que je garde
Écrire du code neuf, sous ma direction	Le sens du détail : ce que voit et ressent l’utilisateur
Déboguer, comprendre un code inconnu	La responsabilité : la sécurité, les données, la mise en production
Le répétitif : refactorisations, montées de version, tests	La relecture : rien n’est commité sans avoir été lu
Des tickets entiers, confiés à des agents	Le dernier mot : je ne garde que ce que je comprends

Ce qui a changé ? Je lance plus de projets, parce que mes idées passent plus vite au prototype. J’écris moins et je relis plus. Le répétitif ne me coûte presque plus rien, et j’ose des technologies que je ne connaissais pas, parce que l’IA m’aide à démarrer.

Les limites du vibe coding sont celles de l’IA, quand personne ne relit derrière elle. Or l’IA se trompe, et toujours de la même façon : elle invente une API, une option ou une fonction qui n’existe pas, ou elle livre un code qui marche, mais trop compliqué, dupliqué ou fragile.

Elle oublie aussi le contexte : les conventions du projet, les décisions déjà prises. Et sur un bug, il lui arrive de tourner en rond, en proposant des correctifs au hasard. Brian Kernighan et P. J. Plauger avaient prévenu, en 1978 :

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?

Traduction : tout le monde sait que déboguer est deux fois plus difficile qu’écrire le programme. Alors, si vous êtes aussi astucieux que possible en l’écrivant, comment ferez-vous pour le déboguer ?

Un code que personne n’a lu, il faudra pourtant bien que quelqu’un le débogue un jour.

Pour ceux qui ne sont pas développeurs, le vibe coding est une vraie porte d’entrée : il leur permet de construire un outil qu’ils n’auraient jamais construit autrement. Mais ce n’est pas un métier. Karpathy lui-même le réservait aux projets jetables du week-end.

Le rêve de programmer en langue naturelle n’a rien de neuf. Vers 1978, Edsger Dijkstra s’en méfiait déjà :

When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

Traduction : tout bien considéré, le naturel avec lequel nous parlons nos langues maternelles se résume à la facilité qu’elles nous donnent de formuler des énoncés dont l’absurdité ne saute pas aux yeux.

Quand je décris ce que je veux à une IA, elle comble à sa façon tout ce que je n’ai pas précisé. Ce que je n’ai pas dit, c’est souvent le détail qui compte pour l’utilisateur : c’est pour ça que le sens du détail reste mon travail.

Simon Willison, cocréateur du framework Django, a tracé la frontière qui me convient :

If an LLM wrote every line of your code but you've reviewed, tested and understood it all, that's not vibe coding in my book - that's using an LLM as a typing assistant.

Traduction : si un LLM a écrit chaque ligne de votre code, mais que vous l’avez entièrement relu, testé et compris, ce n’est pas du vibe coding à mes yeux : c’est utiliser un LLM comme assistant de frappe.

C’est ma pratique : l’IA écrit, je relis, je teste, je comprends. Je suis enthousiaste, mais vigilant.

Les miens tiennent en quatre règles, celles que je m’impose :

1. Je relis avant de committer : rien ne part sans que je l’aie lu.
2. Je ne garde que ce que je comprends : si je ne sais pas l’expliquer, ça ne reste pas.
3. L’IA passe par les mêmes contrôles que moi : les tests et le linter sont obligatoires.
4. Je ne lui donne ni secret ni donnée sensible.

Je ne suis pas le seul à vérifier : dans l’enquête 2026 de Stack Overflow, publiée le 6 octobre 2026, 48 % des répondants disent faire confiance à l’IA quand ils peuvent facilement vérifier ses réponses. La sécurité, les données, la mise en production : c’est moi qui en réponds, pas l’outil.

Oui, au moins les bases. J’ai appris sur le Site du Zéro, sur les forums et dans un livre, et c’est ce qui me permet aujourd’hui de voir quand une IA se trompe.

Mon conseil à un développeur qui débute : apprenez les fondamentaux, HTTP, les bases de données, la sécurité. C’est ce que l’IA suppose acquis, et c’est ce qui vous permettra de la diriger au lieu de la suivre.

Ma réponse tient en une image : dans cinq ans, les développeurs seront des chefs d’orchestre. On dirigera et on relira des agents plus qu’on n’écrira de code.

C’est déjà un peu mon quotidien. Mais un chef d’orchestre sait lire une partition : c’est pour ça que les fondamentaux comptent encore.

L’IA écrit plus vite que moi. Elle ne signe pas à ma place.

• Andrej Karpathy, message sur X, 2 février 2025 : https://x.com/karpathy/status/1886192184808149383 (site externe)
• Simon Willison, « Will the future of software development run on vibes? », 6 mars 2025 : https://simonwillison.net/2025/Mar/6/vibe-coding/ (site externe)
• Edsger W. Dijkstra, « On the foolishness of "natural language programming" » (EWD 667) : https://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html (site externe)
• Brian W. Kernighan et P. J. Plauger, The Elements of Programming Style, 2ᵉ édition, McGraw-Hill, 1978.
• Collins Dictionary, mot de l’année 2025, 6 novembre 2025 : https://blog.collinsdictionary.com/language-lovers/collins-word-of-the-year-2025-ai-meets-authenticity-as-society-shifts/ (site externe)
• Stack Overflow, Developer Survey 2026, section IA : https://survey.stackoverflow.co/2026/ai (site externe)