Vibe coding - qu'est-ce que c'est et quand c'est dangereux pour le business
Le vibe coding est une approche où l'on n'écrit pas le code ligne par ligne, mais via un dialogue avec l'IA : vous décrivez le comportement souhaité, acceptez la proposition du modèle, vérifiez le résultat « au feeling » et affinez la demande. Le terme a été popularisé par Andrej Karpathy : vous ne gardez plus tout le code en tête, vous pilotez l'intention. Pour le business, cela accélère prototypes et outils internes - et crée en même temps une dette cachée si l'artefact arrive en production sans revue, tests ni propriétaire d'architecture.
- Essence - coder via des prompts dans Cursor, Copilot, Claude Code et assistants similaires
- Avantage - vitesse pour MVP, landings, scripts, panneaux « pour hier »
- Inconvénient - l'IA écrit un code qui « marche », mais peu sécurisé et difficile à maintenir
- Dangereux - argent, données personnelles, paiements, accès CRM et serveurs
- Sûr - brouillons, utilitaires jetables, pilotes sous code review strict
- Règle - vibe pour la vitesse d'une idée ; ingénierie pour le code qui porte le business
Qu'est-ce que le vibe coding en mots simples
Développement classique : la personne conçoit, écrit, débugue, teste. Le vibe coding déplace le focus :
- Vous formulez la tâche en langage naturel.
- L'assistant IA génère fichiers, diffs, tests, configs.
- Vous lancez, observez le comportement et corrigez par prompt (« rends le formulaire plus joli », « ajoute l'auth »).
- Le cycle se répète jusqu'à ce que le « vibe » corresponde à l'attente.
Ce n'est ni un langage ni un framework à part. C'est un mode de travail avec les assistants IA pour programmer : moins de saisie manuelle, plus de direction et de vérification.
| Mode | Qui « mène » | Résultat typique |
|---|---|---|
| Code classique | Développeur | Architecture prévisible, plus de contrôle |
| Assisted coding | Humain + suggestions IA | Routine plus rapide sans perdre l'ownership |
| Vibe coding | Dialogue avec le modèle | Artefact rapide, ownership flou |
| Mode agent | Un agent IA modifie le repo lui-même | Encore plus de vitesse et risque « boîte noire » |
En pratique la frontière entre « assisted » et « vibe » est fine : si vous lisez le diff et comprenez chaque changement - vous êtes un développeur amplifié. Si vous approuvez des paquets de code parce que « l'UI a l'air de marcher » - c'est déjà du vibe coding avec toutes les conséquences.
Pourquoi le business aime ça
Le vibe coding répond à la douleur du dirigeant et du product manager :
- Vitesse jusqu'à la première démo - des jours au lieu de semaines.
- Moins de dépendance à la file de développement pour les « petites » demandes internes.
- Expériences moins chères : hypothèse de landing, calculateur, bot, scraper.
- Plus de personnes peuvent monter un brouillon sans background senior profond.
Pour une startup en phase d'idée ou l'automatisation interne d'une équipe, c'est un vrai levier. Pour un flux de paiement, un espace personnel avec des données personnelles ou un module qui porte le CA 24/7 - un autre niveau de responsabilité.
Quand le vibe coding est utile
Utilisez-le comme accélérateur si plusieurs conditions sont réunies :
- L'artefact est temporaire ou facile à remplacer - prototype, landing A/B, script d'export ponctuel.
- Il y a une personne qui sait lire le code et assume le merge.
- Il y a des tests (au moins smoke) et un environnement distinct de la production.
- Pas d'accès aux secrets de production, à la BD live ni aux clés de paiement.
- Périmètre local : un écran, un cron, un microservice-brouillon.
Bons cas :
- brouillon d'admin pour import manuel ;
- bot Telegram pour une file interne de demandes ;
- boilerplate et migrations sous review ;
- refactor rename-and-split dans un sandbox ;
- docs et tests d'une logique déjà claire.
Quand c'est dangereux pour le business
Le danger n'est pas que l'IA soit « stupide ». Le danger est qu'elle soit persuasive : le code compile, l'UI est cliquable - et la faille, la fuite de clé ou le bug silencieux sur l'argent apparaissent plus tard.
1. Sécurité et accès
Le modèle peut facilement :
- hardcoder des clés API « pour la commodité » ;
- désactiver CSRF / ouvrir CORS
*; - construire du SQL par concaténation de chaînes ;
- logger mots de passe ou tokens ;
- laisser un endpoint de debug « temporaire » ouvert.
Sans security review, c'est un risque direct d'amendes, de fuites et d'indisponibilité.
2. Dette technique cachée
Le code vibe souvent :
- duplique la logique à trois endroits ;
- tire des dépendances inutiles ;
- ignore les patterns du projet ;
- « soigne » les symptômes par des rustines au lieu de la cause.
En 2-3 mois le produit coûte plus cher à maintenir que s'il avait été écrit volontairement dès le départ. L'économie initiale devient un paiement d'intérêts.
3. Pas de propriétaire du comportement
Quand un diff de 800 lignes est accepté « au vibe », personne ne peut répondre avec certitude :
- que se passe-t-il avec des commandes concurrentes ;
- comment annuler un paiement partiellement appliqué ;
- pourquoi le rapport comptable et le CRM divergent.
Pour le business, c'est un risque de réputation et financier, pas du « code moche ».
4. Conformité et données
Si le périmètre inclut des données personnelles, des infos médicales/financières ou des exigences réglementaires - « générer et mettre en prod » est inacceptable. Il faut des politiques d'accès, un audit des changements et une chaîne claire de responsabilité.
5. Échelle et intégrations
L'IA écrit bien des widgets isolés. Elle est plus faible pour joindre proprement billing, stock, CRM, webhooks, idempotence et files. C'est exactement à ces jonctions que le business perd de l'argent.
| Signal « déjà dangereux » | Pourquoi |
|---|---|
| Code direct en prod sans review | Pas de filtre bugs et vulnérabilités |
| Pas de tests argent/stock/rôles | Les bugs frappent le CA et les clients |
| Secrets dans le repo ou le chat IA | Fuite et compromission de l'infra |
| Personne ne comprend le module généré | Bus factor = 0 ; tout incident = arrêt |
| « Ça marche chez moi » = terminé | Pas de critères d'acceptation business |
Règles pratiques pour le dirigeant et le CTO
- Séparez les zones : sandbox pour le vibe, périmètre protégé pour le CA et les données.
- Human review obligatoire pour tout ce qui touche auth, paiements, données personnelles, migrations BD.
- Definition of Done n'est pas « UI ok », mais tests + logs + rollback + monitoring.
- Ne nourrissez pas les modèles publics de secrets ni de dumps clients.
- Fixez l'ownership : chaque merge a un développeur responsable, pas « un chat avec l'IA ».
- Budgétez la réécriture du pilote dès le départ : prototype ≠ production.
- Choisissez l'outil consciemment - Cursor, Claude Code ou Copilot pour votre équipe, pas « ce qui est trendy sur TikTok ».
Formule de bon sens :
Vibe coding = accélérer une hypothèse. Ingénierie = protéger le business.
Confondre ces rôles coûte cher.
Combien ça « coûte » en pratique
Le prix direct d'un abonnement à une IDE IA est faible face au salaire d'un développeur. Le prix caché est autre :
| Poste | Ce qui se passe avec un vibe non contrôlé |
|---|---|
| Incident de sécurité | Investigation, downtime, avis clients |
| Réécriture du module | 2-5× le coût du « pilote rapide » |
| Perte de savoir dans l'équipe | L'onboarding s'allonge plusieurs fois |
| Erreurs de calculs/commandes | Pertes financières et de réputation directes |
Un prototype bon marché est un investissement normal. Une production bon marché sans contrôles est une loterie.
Conclusion
Le vibe coding est un mode puissant de travail avec l'IA : vous décrivez l'intention, le modèle livre du code, vous itérez vite. Pour le business, il convient aux brouillons, utilitaires internes et tests d'hypothèse. Il devient dangereux quand le critère de « prêt » reste « ça a l'air de marcher », alors que l'argent, les données et la continuité de service sont en jeu. Gardez le vibe dans le sandbox - et la production sous review, tests et propriétaire clair du code.
Questions fréquemment posées
Le vibe coding, c'est la même chose que le low-code / no-code ?
Non. Le low-code offre des blocs visuels et des limites de plateforme. Le vibe coding génère du code habituel (Python, JS, SQL, etc.) via un dialogue avec l'IA. La flexibilité est plus grande - mais qualité, sécurité et support sont entièrement à vous ; la plateforme n'« assure » pas l'architecture.
Peut-on construire tout un produit en vibe coding ?
Un prototype et même un MVP précoce - oui, si un tech lead solide est à côté. Un produit scalable sans ingénierie - en général non : intégrations, charge, audit et prévisibilité croissent. Le vibe accélère le démarrage ; la maturité exige une discipline de code.
Est-il légal d'utiliser du code IA dans un projet commercial ?
Cela dépend de la licence de l'outil, de la politique de l'entreprise et des contrats clients. Vérifiez à part : où vont prompts et code, si le modèle peut être entraîné sur vos données, qui possède le résultat. Le contrôle juridique et sécurité va avant le périmètre de production - pas après la plainte client.
Comment voir qu'un prestataire « vibe » de façon dangereuse ?
Drapeaux rouges : PR énormes sans explication, pas de tests, secrets dans le repo, « ne touchez pas ce fichier - l'IA l'a écrit », refus de walkthrough d'architecture, pas de staging. Un bon prestataire utilise l'IA comme accélérateur et défend calmement chaque décision.
Par où commencer en sécurité dans l'équipe ?
Par des tâches internes non critiques et un pilote de 2-4 semaines : assistant IDE choisi, review obligatoire, interdiction des secrets dans le chat, métriques (temps de tâche, incidents, part de code réécrit). Élargissez le périmètre seulement quand le processus de contrôle est stable.