Qu'est-ce que le vibe coding ? Définition et risques

Qu'est-ce que le vibe coding ? C'est la pratique de construire du logiciel en décrivant ce que vous voulez en langage naturel, puis en laissant un modèle IA écrire le code avec un minimum de relecture ligne par ligne de votre part. Andrej Karpathy a popularisé ce terme en février 2025. Depuis mi-2026, 92 % des développeurs américains utilisent quotidiennement des outils de codage IA, et 41 % de tout le code écrit mondialement est maintenant généré par l'IA. La vraie question n'est plus si le vibe coding fonctionne. C'est ce qui se passe à un codebase six mois après que votre équipe ait commencé à viber.

La définition originale, sans le battage médiatique

Karpathy a décrit le vibe coding comme un workflow où vous « voyez des choses, dites des choses, exécutez des choses, et copiez-collez des choses ». Vous tapez une description dans Cursor ou Claude Code, acceptez le bloc généré, exécutez les tests, réparez ce qui casse avec un nouveau prompt. Vous ne lisez pas chaque ligne. Vous dirigez.

C'est une description honnête de la façon dont beaucoup de prototypage fonctionne en 2026. Où cela devient compliqué, c'est l'hypothèse implicite que comprendre le code est optionnel. Pour un projet jetable de fin de semaine, d'accord. Pour un codebase en production à 2 heures du matin un mardi, cette hypothèse s'effondre.

Karpathy lui-même l'a reconnu. En décembre 2025, il notait que 80 % de son code personnel était généré par l'IA, et il identifiait ce mois comme un point d'inflexion pour le codage agentique, quand les chunks générés par l'IA sont devenus assez volumineux pour que la question pratique passe de « l'agent peut-il gérer cette tâche ? » à « comment vérifier sa sortie à l'échelle que je délègue ? »

Comment ça marche vraiment en pratique

Une session de vibe coding a une forme reconnaissable. Vous décrivez l'intention en langage naturel : « Ajoute un endpoint qui retourne les 10 derniers commits d'un repo, paginé avec pagination par curseur, retournant 401 si l'appelant n'est pas authentifié. » Plus la description est spécifique, moins la relecture a de travail à faire.

L'IA génère un bloc de code. Vous le lisez, ou plutôt vous le survolez. Vous exécutez les tests. Si quelque chose casse, vous collez le message d'erreur dans le chat et vous itérez. Si ça passe, vous shippez.

Les gains de temps sont réels. Les équipes rapportent une réduction de 40 à 60 pour cent du temps de première version pour les nouvelles fonctionnalités sur du greenfield. Pour la génération de boilerplate, l'échafaudage et les patterns répétitifs, les gains sont assez significatifs pour que toute équipe n'utilisant pas les outils IA soit de facto en train de concourir avec des équipes qui ont un ingénieur supplémentaire sur chaque PR.

La partie dont personne ne parle : lire du code généré par l'IA

Voici ce que les statistiques de productivité oublient. Écrire du code, c'est à peu près 30 à 40 pour cent du temps d'un développeur senior. Les 60 à 70 pour cent restants sont passés à lire du code : comprendre comment le système d'authentification est câblé dans un repo de 80 000 lignes, figurer pourquoi un job de fond a commencé à échouer, démêler une dépendance de données à trois voies avant de pouvoir ajouter une fonctionnalité en toute sécurité.

Quand 41 pour cent du codebase a été écrit par une IA que personne n'a profondément relue, lire ce code devient plus difficile. Le code généré par l'IA tend à être verbeux. Il ajoute des couches d'abstraction qui paraissent propres au premier regard mais qui obscurcissent le flux de données réel. Il introduit parfois des patterns qui sont idiomatiques dans ses données d'entraînement mais pas dans votre stack d'équipe.

Vous pouvez grep un nom de fonction. Vous pouvez exécuter git blame sur un fichier. Mais ni l'un ni l'autre ne vous dit pourquoi le code est structuré de cette façon, ou ce que les systèmes adjacents attendent de lui. C'est cet écart qui compte quand vous êtes trois niveaux profonds dans une session de débogage à minuit.

Où le vibe coding fonctionne bien

La recherche est cohérente sur les cas d'usage où le vibe coding ajoute de la vraie valeur, et où il crée des problèmes en aval.

Bons cas d'usage :

• Les prototypes greenfield et MVPs où la vitesse compte plus que la maintenabilité à long terme

• Les scripts jetables et les transformations de données ponctuelles

• La génération de boilerplate (migrations de bases de données, endpoints CRUD, stubs de tests) dans un stack bien connu

• Le codage exploratoire pour valider si une approche est viable avant de consacrer des heures d'ingénierie

Cas d'usage où ça crée des problèmes plus tard :

• Les chemins de code sensibles à la sécurité : authentification, autorisation, paiement, gestion de session

• Le code qui interface avec des APIs externes avec des exigences de conformité ou des conséquences de rate-limiting

• Les systèmes maintenus par plusieurs ingénieurs sur plus de 12 mois

• Toute logique où un edge case qui échoue silencieusement pourrait causer une perte de données ou une facturation incorrecte

Le taux de vulnérabilité de 45 pour cent dans le code généré par l'IA n'est pas une anomalie statistique. C'est ce qui se passe quand vous demandez à un modèle de générer du code qui « fonctionne » sans fournir un contexte explicite sur votre modèle de menace. Le modèle optimise pour le chemin heureux que vous avez décrit. Il ne sait pas ce que vous ne lui avez pas dit.

Le pattern d'accumulation de dette technique

Les codebases vibe-codées accumulent de la dette de façon spécifique et prévisible. La couverture de tests chute, souvent jusqu'à 12 pour cent ou moins, par rapport à une baseline d'industrie plus proche de 68 pour cent. Le code passe les tests que vous avez exécutés, mais les edge cases restent non couverts parce que vous n'aviez pas demandé explicitement de les tester. La gestion d'erreurs est superficielle. L'augmentation de 300 pour cent des coûts de maintenance en 18 mois, rapportée de façon cohérente à travers les recherches 2026, n'est pas surprenante une fois que vous avez vu ce pattern se dérouler.

Les signes d'alerte apparaissent tôt si vous savez quoi chercher :

• git log montre des commits répétés « fix for [quelque chose qui vient de casser] » en deux à trois semaines après qu'une fonctionnalité vibe-codée ait fusionné

• Les pull requests qui touchent un module vibe-codé prennent plus de temps à relire parce que personne n'est confiant sur sa surface

• Les incidents oncall qui remontent à des edge cases jamais testés parce que l'auteur original supposait que la sortie IA était correcte

Le problème n'est pas que l'IA a écrit le code. Le problème est que la discipline de relecture qui attrape normalement ces problèmes a été sautée parce que le code fonctionnait du premier coup.

Ce qui change quand vous utilisez un outil de chat sur codebase

L'écart de productivité ci-dessus est spécifiquement un problème de lecture. Le vibe coding a amélioré la vitesse d'écriture. Il n'a pas amélioré la vitesse de lecture.

Quand un nouvel ingénieur rejoint une équipe qui a fait du vibe coding pendant six mois, ses deux premières semaines sont plus difficiles qu'avant. Le code manque les commentaires contextuels qu'un humain aurait ajoutés en travaillant sur une décision de design. Les tests ne couvrent pas les cas où l'IA s'est trompée subtilement. Le document d'architecture, s'il existe, a été écrit avant que 40 pour cent du codebase change.

Les outils qui vous permettent de poser des questions sur un codebase en langage naturel remplissent cet écart directement. « Comment le token d'auth est-il validé sur cette route ? » « Quelles fonctions appellent cette méthode et d'où ? » « Y a-t-il quelque chose entre ce service et le processeur de paiement qui pourrait réessayer en cas d'échec ? » Vous ne remplacez pas grep ou git blame. Vous ajoutez une couche qui répond aux questions structurelles dans plusieurs fichiers à la fois, ancrée dans le code réel plutôt que dans ce que la documentation dit.

Cela compte davantage quand vous embarquez sur un repo vibe-codé que sur un traditionnel. L'intention contextuelle qu'un auteur humain intègre dans les noms de variables, les commentaires et les signatures de fonction est plus mince dans le code généré par l'IA. Un outil qui peut synthétiser les réponses à partir du graphe de code réel remplit cet écart sans exiger que quelqu'un documente manuellement ce qu'une IA a généré.

Le vibe coding et la relecture de code

Un changement pratique que les équipes d'ingénierie sérieuses font en 2026 : le code généré par l'IA reçoit une relecture de code plus rigoureuse, pas moins. C'est la bonne réponse.

La logique est directe. Quand un ingénieur senior écrit une fonction, il y a une hypothèse implicite qu'ils ont compris le contexte et fait des compromis délibérés. Quand une IA l'écrit, cette hypothèse ne s'applique pas. Le code peut être correct. Il peut être subtilement faux d'une façon qui ne fait surface que sous charge, avec une entrée inhabituelle, ou après une mise à jour de dépendance six mois plus tard.

Les équipes qui relisent bien les PRs vibe-codées posent des questions que l'IA n'avait pas en portée quand elle a généré le code : Que se passe-t-il ici si l'entrée est null ? Si le service en amont est lent ? Si cette fonction est appelée de façon concurrente par trois threads ? Ce sont des questions que le modèle n'avait pas en scope quand il a généré le code.

La bonne pratique est de mettre ces contraintes en avant dans le prompt original. « Écris un endpoint pour X. Il doit gérer les requêtes concurrentes en toute sécurité. Il ne doit pas logger les corps de requête. Il doit retourner 429 si l'appelant dépasse 10 requêtes par seconde. Il doit traiter un array vide comme une erreur de validation, pas une erreur serveur. » Plus le brief est spécifique, moins la relecture a à attraper.

L'état honnête du vibe coding en 2026

Le vibe coding n'est pas une tendance qui va s'inverser. Mi-2026, les outils sont assez bons pour que toute équipe ne les utilisant pas accepte un désavantage structurel de vitesse. L'accélération de première version de 40 à 60 pour cent est réelle. La question n'est pas l'adoption. C'est la discipline de relecture qui l'accompagne.

La faveur des développeurs envers les outils de codage IA a chuté de 77 pour cent en 2023 à 60 pour cent en 2026. Seuls 33 pour cent des développeurs font confiance à la précision du code généré par l'IA, en baisse par rapport aux 43 pour cent en 2024. Mais 92 pour cent utilisent ces outils quotidiennement, et la majorité vérifie manuellement la sortie avant de shippter. Les développeurs qui tirent de la valeur du vibe coding ne sautent pas la vérification. Ils utilisent l'IA pour écrire plus vite et le jugement humain pour shippter en toute sécurité.

Le vibe coding fonctionne comme une méthodologie de développement quand elle inclut une discipline de lecture. Les développeurs produisant du code solide avec elle ne sont pas ceux qui voient des choses, disent des choses, exécutent des choses. Ce sont ceux qui posent aussi cette question : est-ce du code que je pourrais expliquer à un coéquipier ? Est-ce du code que je pourrais déboguer à 2 heures du matin sans la session de chat originale ouverte ?

Si la réponse est non, le code n'est pas fini.