Vibe Coding
Le vibe coding consiste à créer des logiciels en les décrivant à un modèle d’IA et en acceptant le code généré sans le lire ; le terme a été inventé en 2025.
Le vibe coding consiste à créer des logiciels en décrivant ce que tu veux à un modèle d’IA en langage courant, puis à accepter le code qu’il écrit sans le lire et à juger le résultat uniquement d’après l’apparente capacité du programme à fonctionner. Andrej Karpathy, membre fondateur d’OpenAI et ancien directeur de l’IA chez Tesla, a donné un nom à cette pratique en février 2025, la qualifiant de « nouvelle forme de programmation » dans laquelle « tu te laisses complètement porter par les vibes, tu embrasses les exponentielles et tu oublies que le code existe ». Il a raconté qu’il parlait à Composer de Cursor par la voix, cliquait sur « Accept All » sans lire les différences et collait des messages d’erreur sans commentaire ; il a qualifié cette approche de « pas trop mauvaise pour des projets jetables du week-end ». En quelques mois, le terme a dépassé le cercle des programmeurs, et le Collins Dictionary a élu « vibe coding » mot de l’année 2025. Des agents de programmation comme Cursor, Claude Code et Replit Agent, ainsi que des générateurs d’applications comme Lovable, Bolt et v0, permettent à des personnes sans expérience en programmation de passer d’une consigne à une application web déployée.
Fonctionnement du vibe coding#
La personne décrit le comportement attendu et teste le résultat ; un agent d’IA écrit, modifie et débogue le code. À chaque étape, le résultat fonctionne, produit une erreur que la personne recopie ou ne semble pas correct et nécessite une nouvelle description :
Cette approche fonctionne parce que les grands modèles de langage (LLM), et en particulier les modèles de raisonnement entraînés sur du code, produisent désormais des programmes fonctionnels pour des piles courantes comme les interfaces web et les scripts Python, et parce que l’environnement d’exécution de l’agent d’un outil de programmation peut lancer le programme et lire ses erreurs sans aide. Cette méthode convient aux prototypes, aux outils internes et aux logiciels personnels dont l’auteur est le seul utilisateur, là où un bogue coûte peu et où la vitesse compte le plus.
Le vibe coding et les pratiques connexes#
- Programmation assistée par l’IA : Utiliser un LLM pour écrire du code qu’un développeur examine et comprend ensuite. Simon Willison a établi la distinction dans son article Toute programmation assistée par l’IA n’est pas du vibe coding : le code écrit par un LLM que tu as ensuite examiné, testé en profondeur et que tu pourrais expliquer à quelqu’un d’autre relève du développement logiciel.
- Programmation agentique : Des agents de programmation exécutent des tâches du début à la fin ; ce sont les mêmes outils que ceux qu’utilisent les adeptes du vibe coding. Les équipes professionnelles intègrent à leur processus les revues de code, les tests et l’intégration continue (CI).
- Plateformes low-code et no-code : Des éditeurs visuels qui permettent aux personnes sans compétences en programmation d’assembler des applications à partir de composants préconstruits. Le vibe coding produit plutôt du code source ordinaire dans n’importe quel langage ou framework.
- IA générative : La technologie plus large qui crée du texte, des images et du code. Le vibe coding est une façon de l’utiliser.
Applications de vision par ordinateur créées par vibe coding#
Les prototypes de vision par ordinateur sont des projets de vibe coding prisés, car un court script suffit déjà à détecter, compter ou suivre des objets dans le flux d’une webcam. Le code généré n’est à jour que dans la mesure où les données d’entraînement du modèle le sont ; un agent qui se fie à sa mémoire peut donc proposer des poids de modèle ou des arguments obsolètes. Les compétences d’agent Ultralytics fournissent à Claude Code, Codex, Cursor et aux autres agents compatibles des procédures pour choisir des modèles, préparer des jeux de données, effectuer l’entraînement, l’inférence et l’exportation. Ces procédures s’appuient sur des catalogues associés à une version ultralytics précise et indiquent à l’agent de se fier aux sorties yolo checks et yolo cfg du paquet installé lorsque les deux divergent. Une demande comme « entraîne un détecteur YOLO26 sur mon jeu de données et exporte-le en ONNX » suit alors les procédures d’entraînement et d’exportation documentées par les compétences plutôt que les souvenirs du modèle concernant d’anciennes versions.
Risques du code non révisé#
Karpathy a remarqué que le code « dépasse ce que je peux habituellement comprendre » ; les modifications et les correctifs ultérieurs dépendent donc eux aussi du modèle, et la dette technique s’accumule lorsque personne ne vérifie le code. Les agents ayant accès au shell peuvent supprimer des fichiers ou exécuter des commandes destructrices ; les outils de programmation les exécutent donc dans un bac à sable pour agents et demandent confirmation avant les actions risquées. Une dépendance ou une page web consultée par l’agent peut aussi contenir une injection de prompt. Les failles de sécurité passent elles aussi en production de cette façon : le test de Veracode mené en 2025 sur plus de 100 LLM et 80 tâches de programmation a révélé que le code généré introduisait une vulnérabilité de sécurité dans 45 % des cas, avec des taux d’échec supérieurs à 70 % pour Java et compris entre 38 % et 45 % pour Python, C# et JavaScript.










