Le vibecoding, sans le marketing

Le vibecoding, c'est décrire ce qu'on veut en langage courant et laisser une IA écrire le code. Pas relire chaque ligne. Pas comprendre chaque fonction. Décrire, regarder le résultat, corriger la description, recommencer. C'est là qu'est la rupture : le développeur cesse d'écrire du code pour devenir celui qui décrit une intention et juge un résultat.

Le terme fascine autant qu'il agace. Il promet à certains la fin de la programmation, il évoque à d'autres une génération de logiciels que personne ne saura maintenir. Les deux camps ont partiellement raison, et c'est précisément ce qui rend le sujet intéressant.

D'où vient le terme

Andrej Karpathy, ancien directeur de l'IA chez Tesla et membre fondateur d'OpenAI, publie en février 2025 un message qui popularise l'expression. Il y décrit une façon de programmer où l'on s'abandonne aux vibes, où l'on oublie que le code existe, où l'on accepte des suggestions sans même les lire. Il parle de projets jetables, de week-ends, de choses sans enjeu.

Cette nuance a disparu en quelques semaines. Le terme a été repris pour désigner tout développement assisté par IA, y compris en production, y compris sur des systèmes qui manipulent de l'argent ou des données personnelles. C'est ce glissement qui pose problème, bien plus que la pratique elle-même.

Ce n'est pas vraiment du code — je vois des choses, je dis des choses, je lance des choses, et ça marche à peu près.

Ce que ça change vraiment

L'effet le plus mesurable n'est pas la vitesse d'écriture. Écrire du code n'a jamais été le goulot d'étranglement d'un projet logiciel : comprendre le besoin, décider de l'architecture, corriger les malentendus et maintenir l'ensemble représentent l'essentiel du temps. Le vibecoding accélère la partie qui était déjà la plus rapide.

Ce qu'il change réellement, c'est le coût d'un essai. Avant, tester une idée d'interface coûtait une demi-journée, donc on en testait une. Aujourd'hui ça coûte vingt minutes, donc on en teste cinq et on garde la meilleure. Ce n'est pas la même chose que d'aller plus vite : c'est explorer plus large avant de s'engager.

Le deuxième effet est un déplacement de compétence. La valeur ne se situe plus dans le fait de savoir écrire une boucle, mais dans la capacité à repérer que le code produit est subtilement faux. Un développeur expérimenté et un débutant obtiennent le même code de l'IA ; seul le premier voit que la gestion d'erreur est absente.

Les trois niveaux de vibecoding

Parler du vibecoding comme d'une pratique unique est la source de la plupart des désaccords. Il en existe au moins trois usages, dont les risques n'ont rien de comparable.

1. Le jetable

Un script qui renomme trois cents fichiers, une maquette pour illustrer une idée en réunion, un outil interne utilisé deux fois. Ici le vibecoding pur se justifie entièrement : le code n'a pas vocation à vivre, personne ne le maintiendra, et sa qualité n'a pas d'importance tant que le résultat est correct. C'est exactement l'usage décrit à l'origine.

2. Le prototype destiné à durer

C'est le cas le plus fréquent et le plus dangereux. On génère rapidement quelque chose qui fonctionne pour valider une idée, puis ça plaît, puis ça part en production « en attendant », puis trois ans passent. Le piège n'est pas technique, il est organisationnel : rien ne distingue visuellement un prototype d'un produit fini quand les deux ont une belle interface.

3. La production assumée

L'IA génère, mais tout passe par une relecture, des tests, une revue de sécurité. Ce n'est plus du vibecoding au sens strict — on lit le code — mais c'est là que la majorité des équipes sérieuses ont atterri. Le gain de vitesse est réel, moindre qu'annoncé, et durable.

Ce que le vibecoding ne remplace pas

Une IA générative produit ce qui ressemble statistiquement à du code correct. La ressemblance est excellente sur les problèmes déjà résolus mille fois, et trompeuse sur tout le reste. Trois domaines résistent particulièrement.

• Les décisions d'architecture. L'IA propose toujours une réponse plausible à « comment structurer ça ? », mais elle ne connaît ni vos contraintes de charge, ni votre équipe, ni ce que vous comptez faire dans deux ans.
• Les règles métier implicites. Ce que personne n'a écrit mais que tout le monde sait dans votre secteur ne se trouve dans aucun corpus d'entraînement.
• La sécurité. Le code généré est fonctionnel avant d'être sûr, parce qu'il est entraîné sur du code public dont une bonne partie est vulnérable.

Ce dernier point est suffisamment sérieux pour mériter son propre guide, avec les vulnérabilités précises à chercher et comment les détecter.

Par où commencer

Si vous démarrez, la progression qui marche le mieux consiste à commencer par des choses sans enjeu, puis à durcir progressivement les exigences plutôt qu'à viser la production tout de suite.

1. Choisissez un outil interne réel dont vous avez besoin — pas un tutoriel. L'enjeu doit être assez faible pour se permettre de rater, assez réel pour que la qualité du résultat se remarque.
2. Versionnez dès la première ligne. Le vibecoding produit beaucoup de code vite ; sans historique, revenir en arrière devient impossible et vous accepterez des régressions par lassitude.
3. Faites relire par quelqu'un, ou demandez à un second modèle de critiquer le code du premier. Une IA relit très correctement du code qu'elle n'a pas écrit.
4. Ajoutez des tests sur ce que vous ne voulez pas voir casser. Pas partout : sur les trois ou quatre comportements dont dépend l'utilité de l'outil.
5. Ne mettez en production que ce que vous savez expliquer. Si vous ne pouvez pas dire ce que fait un fichier, vous ne pourrez pas le réparer un dimanche soir.

Aller plus loin

Six guides détaillent les points qui posent le plus de problèmes en pratique : écrire des prompts qui produisent du code utilisable, la sécurité du code généré, la cohérence visuelle quand l'IA dessine les interfaces, la dette technique qui apparaît six mois plus tard, la façon de reconnaître du code écrit par une machine, et la question de vibecoder ses propres outils plutôt que de les acheter.