Guide
Le vibe coding est-il dangereux ? Ce qui coince et comment vérifier votre code
Le vibe coding n’est pas mauvais en soi : le risque, c’est de livrer du code que personne n’a lu. Les erreurs que les assistants IA répètent et comment les repérer.
· 7 min de lecture · Par l’équipe vetkit
La réponse courte
Non, le vibe coding n’est pas mauvais en soi. C’est un moyen rapide d’obtenir un logiciel qui fonctionne et, pour un prototype, un outil interne ou un apprentissage, c’est souvent le bon choix. Il devient un problème à un moment bien précis : quand du code que personne n’a lu commence à servir de vrais utilisateurs, à manipuler de vraies données ou de l’argent réel. Le risque n’est pas qu’une IA ait écrit le code. Le risque, c’est que personne ne l’ait vérifié.
La question utile n’est donc pas « le vibe coding est-il mauvais ? » mais « que dois-je vérifier avant la mise en production ? ». La suite de ce guide y répond.
Ce que signifie le vibe coding
Le vibe coding consiste à construire un logiciel en décrivant ce que l’on veut à un assistant IA et en acceptant le code qu’il écrit, la plupart du temps sans le lire. Le terme a été inventé par Andrej Karpathy début 2025 pour désigner une façon de travailler où l’on se laisse porter par les « vibes » et où l’on oublie jusqu’à l’existence du code. On juge le résultat en lançant l’application, pas en relisant les modifications.
C’est différent du développement assisté par l’IA, où un développeur utilise les mêmes outils mais continue de lire, de tester et d’assumer la responsabilité de chaque modification. La plupart des projets réels se situent entre les deux, et ils glissent vers le vibe coding dès que les délais se resserrent.
Ce qui coince
Les assistants IA savent produire du code qui tourne. Ils sont moins fiables sur tout ce qui ne se voit pas quand on clique une fois dans l’application. Les mêmes erreurs reviennent sans cesse :
| Problème | À quoi cela ressemble | Pourquoi on ne le remarque pas |
|---|---|---|
| Secrets au mauvais endroit | Une clé d’API commitée dans le dépôt ou embarquée dans le bundle du navigateur | L’application fonctionne exactement pareil dans les deux cas |
| Contrôles d’accès manquants | N’importe quel utilisateur connecté peut lire les enregistrements d’un autre ; des tables sans règles au niveau des lignes (row-level security) | Vous ne testez jamais qu’avec votre propre compte |
| Paquets qui n’existent pas | L’assistant invente un nom de paquet plausible, que quelqu’un d’autre a peut-être enregistré | La commande d’installation réussit |
| Code inachevé | Fonctions bouchons, branches TODO et erreurs avalées laissées dans le chemin principal | Le scénario nominal passe toujours |
| Entrées non fiables utilisées telles quelles | Données de requête injectées dans du SQL, des commandes shell, des chemins de fichiers ou du HTML | Une saisie normale se comporte normalement |
| Rien de prévu en cas de panne | Appels HTTP sans timeout, requêtes dans des boucles, aucune remontée d’erreurs | Tout est rapide avec dix lignes et un seul utilisateur |
Rien de tout cela n’est nouveau. Les développeurs ont commis chacune de ces erreurs bien avant l’arrivée des assistants IA. Ce qui change avec le vibe coding, c’est le volume et l’absence de relecture : davantage de code arrive plus vite, et la personne qui aurait repéré le problème ne le lit jamais. Trois de ces sujets sont traités en détail ailleurs sur ce site : les clés d’API dans le navigateur, les paquets inventés et les secrets divulgués.
Quand cela compte, et quand ce n’est pas grave
Le vibe coding est un choix raisonnable quand une erreur coûte peu :
- Un prototype ou une démo qui sera jeté ou réécrit.
- Un script personnel ou un outil interne sans données sensibles.
- L’apprentissage d’un nouveau framework ou l’exploration d’une idée.
Il faut une vérification avant la mise en ligne quand une erreur coûte cher :
- L’application gère des comptes utilisateurs, des paiements ou des données personnelles.
- Elle détient des identifiants pour d’autres services, comme un fournisseur de LLM ou une base de données.
- D’autres personnes compteront sur sa disponibilité, ou quelqu’un d’autre devra la maintenir.
La frontière ne tient pas à la façon dont le code a été écrit, mais à ce qui se passe si le code est faux. Beaucoup de projets franchissent cette ligne sans que personne ne l’ait décidé : la démo reçoit ses premiers vrais utilisateurs et personne ne revient la lire.
Garder la vitesse sans garder le risque
Inutile de renoncer à la vitesse. Il faut simplement réintroduire la vérification que le vibe coding saute.
- Lisez les modifications qui touchent à l’argent, à la connexion et aux données. Vous pouvez vous dispenser de lire le code de mise en page. Pas l’authentification, les autorisations, les paiements ni tout ce qui écrit en base. La checklist de revue du code généré par IA liste les points à examiner.
- Testez avec deux comptes. Connectez-vous avec un utilisateur et essayez de lire ou de modifier les enregistrements d’un autre. Ce seul test révèle la catégorie de bugs la plus dommageable dans les applications développées en vibe coding.
- Vérifiez chaque nouvelle dépendance. Assurez-vous que le paquet existe, que c’est bien celui que vous vouliez et qu’il n’a pas été publié la semaine dernière.
- Scannez le dépôt avant de livrer. Un audit automatisé trouve les problèmes mécaniques plus vite qu’un humain : secrets commités, dépendances vulnérables ou inexistantes, timeouts manquants et traitement non sécurisé des entrées. Le catalogue de contrôles de vetkit présente les règles qu’il exécute, et le Security Quick Scan gratuit couvre les secrets, les vulnérabilités connues des dépendances et les bases de la posture de sécurité.
- Demandez à l’assistant de corriger ce que le scan trouve. Connectez le scanner à votre agent de code pour que les résultats reviennent dans la même conversation. Le guide MCP explique comment faire.
Quand vous êtes prêt à publier, la checklist de sécurité avant de livrer une application développée en vibe coding détaille la décision de mise en production étape par étape.
Sources et limites
La liste des problèmes fréquents reprend les catégories couvertes par les règles maison de vetkit sur les risques du code IA, la sécurité, la résilience et l’accès aux données, vérifiées le 10 novembre 2026. Elle décrit des schémas récurrents ; elle ne mesure pas leur fréquence. Le terme « vibe coding » vient du post d’Andrej Karpathy de février 2025.
Un scan automatisé fournit des éléments à examiner, pas la preuve qu’une application est sûre. Il lit le code source ; il ne teste ni les permissions de votre déploiement, ni la configuration de votre hébergement, ni vos règles métier. Le test à deux comptes et la revue manuelle ci-dessus restent votre travail.