Vibe coding : ce que le terme veut vraiment dire, et pourquoi pas en production

Le vibe coding n’est pas une méthode de conception ni un synonyme de « développer avec l’IA ». C’est une pratique précise : décrire ce que l’on veut à un modèle, accepter le code sans le relire et juger au résultat. Voici la définition exacte, les cas où elle est utile, les risques documentés en production et la méthode que nous appliquons pour transformer un prototype vibe-codé en produit maintenable.

Vibe coding : la définition exacte

Le message de Karpathy du 2 février 2025

Le terme vient d’un message publié sur X le 2 février 2025 par Andrej Karpathy, cofondateur d’OpenAI et ancien directeur de l’IA chez Tesla. Il y décrit une nouvelle manière de programmer, permise par les assistants de l’époque (il cite Cursor Composer avec un modèle Sonnet) :

• il décrit ce qu’il veut, souvent à la voix ;
• il accepte toutes les modifications sans lire les différences (« Accept All ») ;
• il recolle les messages d’erreur sans commentaire et laisse le modèle corriger ;
• le code finit par dépasser sa propre compréhension ;
• cela convient, dit-il, à des projets jetables du week-end.

La formule la plus citée résume l’esprit : on finit par « forget that the code even exists », oublier que le code existe.

Le critère décisif : personne ne lit le code

Définition opérationnelle : le vibe coding consiste à produire un logiciel avec une IA en acceptant le code sans le lire en détail, et en jugeant uniquement au comportement observé. L’outil (Cursor, Claude Code, Lovable, Replit…) ou le profil de la personne importent peu : ce qui fait le vibe coding, c’est l’absence de relecture.

Le développeur Simon Willison l’a formulé dès le 19 mars 2025 : le vibe coding, c’est construire un logiciel avec un LLM sans relire le code qu’il écrit. Sa règle personnelle pour du code destiné à durer : ne rien committer qu’il ne serait pas capable d’expliquer à quelqu’un d’autre.

Du tweet au dictionnaire

Le dictionnaire Collins en a fait son mot de l’année 2025. Un an après, le 4 février 2026, Karpathy est revenu sur le sujet ; plusieurs comptes rendus rapportent qu’il propose l’expression « agentic engineering » pour la pratique professionnelle : orchestrer des agents qui écrivent le code, avec une vraie discipline d’ingénierie.

Ce que le vibe coding n’est pas

Vibe coding ou développement assisté par IA ?

Appeler « vibe coding » tout usage de l’IA dans le développement est faux, et cette confusion discrédite des pratiques sérieuses ou légitime des livraisons non contrôlées.

Trois confusions fréquentes

• « Vibe coding = no-code. » Non. Le no-code masque le code derrière une plateforme d’éditeur. Le vibe coding produit du vrai code source, dont vous héritez de tous les défauts.
• « Vibe coding = méthode de conception centrée utilisateur ou UX. » Non. Le terme ne décrit ni une démarche de design, ni une méthode agile. Il décrit uniquement la relation entre un humain et le code généré : il ne le lit pas.
• « Un développeur senior qui utilise l’IA fait du vibe coding. » Pas s’il relit, teste et comprend ce qu’il intègre. Ce n’est pas l’outil qui décide, c’est le niveau de contrôle.

Où le vibe coding est utile (et légitime)

Les bons cas d’usage

Le vibe coding a une vraie valeur : il réduit à presque rien le coût d’un essai. Nous l’utilisons nous-mêmes, dans un cadre précis.

Pour une startup, le MVP vibe-codé est un outil de validation, pas une fondation. Si l’hypothèse est validée, le produit se construit avec une architecture pensée pour durer : c’est la bascule que nous organisons dans notre accompagnement startups et MVP.

Le cadre minimal pour vibe-coder sans risque

• [ ] Environnement isolé (conteneur, bac à sable, compte cloud dédié sans accès au SI)
• [ ] Aucune donnée personnelle réelle, aucun secret de production dans le projet ni dans les invites
• [ ] Clés de test avec plafond de dépense si une API payante est appelée
• [ ] Date de fin de vie écrite dans le README, dépôt exclu des pipelines de déploiement
• [ ] Décision explicite à la fin : on jette, ou on lance la méthode de fiabilisation ci-dessous

Pourquoi on ne vibe-code pas en production

Un prototype sert à apprendre ; un logiciel en production sert des utilisateurs et engage votre responsabilité. Les risques du vibe coding en production sont mesurés.

Sécurité : du code qui marche n’est pas du code sûr

Le rapport GenAI Code Security 2025 de Veracode (30 juillet 2025) a testé plus de 100 modèles de langage : 45 % des échantillons ont échoué aux tests de sécurité et introduit des vulnérabilités du Top 10 OWASP. Le cross-site scripting n’était pas prévenu dans 86 % des cas concernés ; Java atteint 72 % d’échec. Et les modèles plus récents ou plus gros produisent du code plus souvent fonctionnel, mais pas plus sûr. Sans lecture, ces failles partent en production.

Secrets exposés

Les assistants reproduisent volontiers des clés en dur, des fichiers .env committés ou des jetons dans le code front. Dans une analyse publiée le 27 mars 2025, GitGuardian a relevé qu’environ 6,4 % d’un échantillon de 20 000 dépôts utilisant Copilot contenaient au moins un secret, contre 4,6 % pour l’ensemble des dépôts publics. C’est une corrélation, pas une preuve de causalité, mais elle rejoint ce que nous constatons en audit.

Dépendances hallucinées et slopsquatting

Les modèles inventent parfois des noms de bibliothèques. L’étude « We Have a Package for You! », présentée à USENIX Security en août 2025, a analysé 576 000 échantillons de code Python et JavaScript produits par 16 modèles : en moyenne, au moins 5,2 % des paquets suggérés par les modèles commerciaux et 21,7 % pour les modèles open source n’existaient pas, soit plus de 205 000 noms uniques inventés.

Le danger porte un nom, le slopsquatting, terme attribué à Seth Larson (Python Software Foundation) en avril 2025 : un attaquant publie sur npm ou PyPI un paquet malveillant sous un nom régulièrement halluciné. En vibe coding, personne ne vérifie le npm install. La chaîne d’approvisionnement figure d’ailleurs au Top 10 OWASP 2026 pour les applications LLM (LLM04, « Supply Chain »).

Tests absents et code « fonctionnel mais faux »

Un prototype vibe-codé n’a généralement aucun test, ou des tests générés par le même modèle, qui valident ce que le code fait plutôt que ce qu’il devrait faire. Notre fiche EXP-06 du iones lab l’illustre : sur 138 corrections générées par des agents sur des tickets réels, 34 % ont été acceptées sans modification et 22 % après retouche. Et 18 corrections étaient « techniquement fonctionnelles mais fausses » : elles passaient les tests existants tout en étant fausses. Aucun test ne pouvait les repérer : il faut un relecteur qui connaît le besoin.

Dette technique et maintenabilité

Le vibe coding accumule de la dette à grande vitesse : duplication, conventions incohérentes, code mort. Le jour où il faut faire évoluer le produit, personne ne connaît sa structure.

Selon notre fiche EXP-01 du iones lab, avec des agents encadrés (catalogue de skills partagé, revue systématique), nous avons mesuré −32 % de temps sur les tâches standard (CRUD, tests, migrations, sur 140 tickets), mais aucun gain sur la compréhension du besoin, l’architecture ou les cas limites, et +9 % de temps sur les tâches complexes au début. L’IA accélère ce qui est déjà cadré ; sans cadre ni relecture, elle accélère surtout la dette.

Responsabilité : qui répond d’un code que personne n’a lu ?

En juillet 2025, le fondateur de SaaStr a raconté comment l’agent de Replit, utilisé en mode vibe coding, a supprimé sa base de production pendant un gel de code explicitement demandé, puis affirmé à tort que la restauration était impossible.

Face à un client, un utilisateur ou une autorité, « c’est l’IA qui l’a écrit » n’est pas une réponse. Le RGPD exige une sécurité adaptée aux données traitées ; pour les fabricants de produits comportant des éléments numériques, les obligations de signalement du Cyber Resilience Act s’appliquent depuis le 11 septembre 2026. Il faut un humain capable d’expliquer, de corriger et d’assumer chaque ligne en production.

Du prototype vibe-codé au produit : la méthode en 5 étapes

Étape 1 : décider (jeter, reprendre ou réécrire)

Étape 2 : auditer

Un audit de code avant toute mise en production couvre au minimum :

• Dépendances : existence réelle, date de création, maintenance, licence, vulnérabilités.
• Secrets dans le code et l’historique Git, puis rotation de ce qui a fuité.
• Analyse statique (SAST) et revue manuelle des zones sensibles : authentification, autorisations, paiement, requêtes en base.
• Données personnelles : lesquelles, où, sur quelle base légale.
• Architecture : environnements séparés, journalisation, sauvegardes.

# Secrets dans tout l'historique Git (TruffleHog v3)
trufflehog git file://. --only-verified

# Vulnérabilités connues des dépendances
npm audit --omit=dev          # Node.js
composer audit                # PHP
pip-audit                     # Python

# Slopsquatting : vérifier que chaque paquet existe et n'est pas apparu hier
for pkg in $(jq -r '.dependencies | keys[]' package.json); do
  echo "$pkg : $(npm view "$pkg" time.created 2>/dev/null || echo 'INTROUVABLE')"
done

Un paquet introuvable ou créé très récemment exige une vérification manuelle.

Étape 3 : poser un filet de tests

Figez d’abord le comportement actuel avec des tests de caractérisation sur les parcours critiques, puis écrivez des tests à partir du besoin (règles métier, cas limites, erreurs attendues), pas à partir du code. Des tests de bout en bout (Playwright, par exemple) sur les parcours qui font le chiffre d’affaires protègent la suite. C’est le cœur de notre offre d’assurance qualité et tests.

Étape 4 : instaurer la revue humaine

Plus aucun code, généré ou non, n’entre sans une pull request relue par un autre développeur, avec un propriétaire nommé par module (fichier CODEOWNERS). Critère d’acceptation : la règle de Willison. Si le relecteur ne peut pas expliquer le code, il ne passe pas, surtout quand il « fait passer les tests ».

Étape 5 : refactorer sous contrôle de la CI

Le refactoring se fait par petites étapes, chacune protégée par une CI qui bloque la fusion si un contrôle échoue : installation depuis le lockfile (npm ci), lint, tests, npm audit --audit-level=high, scan de secrets, quality gate SonarQube et protection de branche exigeant une revue approuvée. Rien n’empêche de continuer à utiliser des assistants : dans ce cadre, ce n’est plus du vibe coding, c’est du développement assisté par IA.

Questions fréquentes

Le vibe coding, un outil de prototypage, jamais un mode de livraison

Le vibe coding a une définition précise : décrire, accepter sans lire, juger au résultat. Pour explorer une idée, il est redoutablement efficace. En production, il transfère à vos utilisateurs des risques mesurés : failles, secrets exposés, dépendances piégées, code faux mais « vert » et dette technique.

Votre prototype vibe-codé doit devenir un produit ? Nous pouvons l’auditer, poser le filet de tests et reprendre le développement avec une équipe senior, en direct ou en marque blanche. Commencez par un audit de code ou contactez-nous : réponse sous 48 à 72 h, échange sans engagement et sous NDA.