Le vibe coding consiste à écrire des logiciels en décrivant ce que l'on souhaite en langage naturel et en acceptant ce que le modèle produit, sans inspecter ou presque le code sous-jacent. L'ingénieur pilote à l'instinct plutôt qu'en lisant et en raisonnant sur le résultat.
Origine du terme
Andrej Karpathy a inventé cette expression début 2025 pour décrire un mode de travail où l'on « se laisse totalement porter par l'ambiance » et cesse de se préoccuper du code lui-même. L'intention était en partie descriptive, en partie ironique. L'expression s'est imposée parce qu'elle nommait quelque chose qui se pratiquait déjà.
À quoi cela ressemble en pratique
Un développeur soumet une invite à un modèle, exécute ce qui en résulte, décrit l'erreur si quelque chose plante, puis itère. Sans lire le diff. Sans chercher à comprendre pourquoi le modèle a fait tel choix. Le code est traité comme un artefact opaque. Ça fonctionne jusqu'au moment où ça ne fonctionne plus.
C'est différent du codage agentique, où un agent de codage effectue des actions en plusieurs étapes dans une base de code et où un humain examine tout de même le résultat. Le vibe coding, c'est l'absence de cette révision, et non la présence de l'automatisation.
Pourquoi cela produit des prototypes rapidement
Pour une preuve de concept jetable, cette approche est vraiment rapide. Le modèle gère le code répétitif, le câblage et la structure évidente. L'humain se concentre sur une seule question : le résultat se comporte-t-il comme prévu ? Les boucles de retour sont courtes.
Pour cet usage, la contrepartie en vaut souvent la peine.
Pourquoi le prototype survit rarement au contact de la production
Les problèmes s'accumulent dans les parties qui n'ont pas été inspectées.
Sécurité. Les modèles reproduisent des patterns courants, y compris des vulnérabilités courantes. Si vous n'avez pas lu le code, vous ne savez pas si les entrées sont validées, si les secrets sont correctement gérés ou si des contrôles d'accès existent. L'injection de prompt est un risque spécifique ; il en existe bien d'autres.
Maintenabilité. Un code que personne n'a compris au moment où il a été écrit est difficile à modifier ultérieurement. L'ingénieur suivant, ou le même ingénieur trois mois plus tard, n'a aucun modèle mental sur lequel s'appuyer.
Exactitude aux limites. Les modèles sont confiants. Ils produisent du code qui semble correct et qui gère le cas évident. Les cas limites, les contraintes spécifiques au domaine et les interactions entre composants sont là où se cachent les erreurs. Ce sont précisément les éléments qui ne se manifestent pas lors d'une démonstration rapide.
Débogage. Lorsque quelque chose plante en production, vous devez raisonner sur le code. Si vous ne l'avez jamais lu, vous n'avez rien sur quoi vous appuyer pour raisonner.
Le problème de transition
Passer un prototype vibe-codé en production n'est pas une question de « mise en ordre ». Cela signifie généralement lire chaque ligne, comprendre ce qu'elle fait réellement plutôt que ce que vous aviez l'intention de faire, repérer les endroits où le modèle a fait un choix plausible mais erroné, et décider de ce qu'il faut réécrire. En pratique, cela prend souvent plus de temps que de l'écrire correctement dès le départ.
Ce n'est pas une critique de l'utilisation de l'IA pour accélérer le développement. C'est une description de ce que la génération sans révision vous coûtera plus tard.
À quoi ressemble un développement AI-native compétent à la place
Un ingénieur senior utilisant bien les outils d'IA lit tout de même le résultat. Il traite le code généré comme une première ébauche de qualité, et non comme un produit fini. Il repère les endroits où le modèle était confiant et dans l'erreur. Il comprend la fenêtre de contexte dans laquelle le modèle travaillait et là où il a pu dérailler.
Il s'agit d'une compétence distincte du vibe coding comme de la rédaction traditionnelle ligne par ligne. C'est également la compétence qui rend le développement assisté par IA suffisamment fiable pour être proposé aux utilisateurs. Consultez comment relire du code généré par IA pour comprendre ce que ce processus implique.
Ce que nous évaluons
Le comportement de « vibe coding » est précisément ce que notre processus de sélection est conçu à mettre en évidence. Lors de l'évaluation AI-native, les candidats travaillent sur des tickets en utilisant les outils qu'ils emploient habituellement, et nous observons s'ils lisent ce qui leur est retourné. Les critères de scorecard les plus directement pertinents sont la vérification des sorties de l'IA, qui teste si quelqu'un détecte des API hallucinées ou une logique subtilement incorrecte avant la mise en production, et le jugement par le risque, qui teste si le code généré fait l'objet du même niveau de vérification quelle que soit l'assurance affichée par l'outil. Les détails complets se trouvent sur notre processus de sélection.
Réponses courtes
Le vibe coding est-il toujours une mauvaise pratique ?
Pas toujours. Pour un prototype jetable ou un script personnel que vous n'avez pas l'intention de maintenir, les compromis sont acceptables. Le problème survient lorsque l'on traite le résultat d'un vibe coding comme prêt pour la production, sans l'étape de relecture qui permettrait de le rendre tel.
Comment transformer un prototype issu du vibe coding en code de production ?
Lisez chaque ligne avec le même niveau d'examen que vous appliqueriez à du code provenant d'une source inconnue. Vérifiez les hypothèses de sécurité, les cas limites et la maintenabilité. Attendez-vous à réécrire des portions significatives. Il s'agit rarement d'une simple retouche rapide.
Quelle est la différence entre le vibe coding et l'utilisation d'outils de codage IA ?
La différence réside dans la relecture. Bien utiliser les outils IA, c'est lire et raisonner sur le résultat produit. Le vibe coding, c'est l'accepter à l'intuition. Les outils peuvent être identiques ; le comportement et les résultats diffèrent substantiellement.
