Vibe coding : quand l'intuition remplace la sur-ingénierie

Vous connaissez ce moment où vous passez 3 heures à débattre de l'architecture parfaite, à choisir entre 5 design patterns, à créer 12 abstractions "au cas où", pour finalement écrire 50 lignes de code qui marchent ?

Bienvenue dans le monde merveilleux de la sur-ingénierie.

Et si je vous disais qu'il existe une approche radicalement différente ? Une approche où :

• ✨ Vous codez ce qui semble juste sur le moment
• 🚀 Vous livrez vite et itérez ensuite
• 🎯 Vous optimisez quand le besoin se présente, pas avant
• 💡 Vous faites confiance à votre intuition de développeur

Cette approche, c'est le vibe coding.

Né sur Twitter/X en 2024, popularisé par des développeurs solo et des startups qui shipent vite, le vibe coding est une réaction contre des décennies de dogmes et de sur-complexification.

Dans cet article, je vous explique :

• Ce qu'est vraiment le vibe coding
• Pourquoi ça marche (et quand ça ne marche pas)
• Comment l'appliquer sans tomber dans le n'importe quoi
• Les exemples concrets qui m'ont convaincu
• Vibe coding vs Clean Code : le match

Disclaimer : Cet article va bousculer certaines croyances. Si vous pensez que SOLID est une religion, que chaque fonction doit avoir un test unitaire, et que refactorer avant même d'avoir des utilisateurs est normal, attachez votre ceinture.

C'est quoi le vibe coding exactement ?

La définition

Vibe coding = Coder en suivant votre intuition et le flow plutôt que des règles rigides.

Traduction : "Coder à l'instinct" ou "coder au feeling".

Principes fondamentaux :

1. Ship first, perfect later : Livrez quelque chose qui marche, vous améliorerez après 2. YAGNI radical : You Ain't Gonna Need It - vraiment, vraiment pas 3. Simplicité brutale : La solution la plus simple qui marche 4. Confiance en l'expérience : Votre instinct de dev vaut mieux que 10 frameworks 5. Itération rapide : Mieux vaut 10 versions imparfaites qu'une version "parfaite" jamais livrée

Ce que le vibe coding N'EST PAS

❌ Ce n'est PAS du code sale

• Le vibe coding privilégie la simplicité, pas le bordel
• Le code peut être élégant tout en étant pragmatique

❌ Ce n'est PAS du cowboy coding

• Il y a une réflexion, juste pas 3 semaines de design upfront
• C'est pragmatique, pas irresponsible

❌ Ce n'est PAS "no tests"

• Les tests sont bienvenus, mais pas 100% de coverage avant la v1
• Testez ce qui compte vraiment

❌ Ce n'est PAS incompatible avec la qualité

• Qualité ≠ complexité
• Un code simple et direct est souvent plus maintenable qu'une architecture "propre" de 15 couches

L'exemple qui résume tout

Approche traditionnelle :

Besoin : Afficher une liste d'utilisateurs
Planning :
Jour 1-2 : Conception architecture (Repository, Service, DTO, Mapper...)Jour 3 : Setup DI containerJour 4 : Écrire les interfacesJour 5 : Implémenter le Repository patternJour 6 : Ajouter la couche ServiceJour 7 : Créer les DTOs et mappingsJour 8 : Tests unitaires de chaque coucheJour 9 : Controller et intégrationJour 10 : Finalement afficher la liste

Approche vibe coding :

// users.ts
export async function getUsers() { const users = await db.query('SELECT * FROM users'); return users; }
// users-page.tsx export default function UsersPage() { const [users, setUsers] = useState([]);
useEffect(() => { getUsers().then(setUsers); }, []);
return (

{users.map(u => {u.name})}
 ); }

Résultat : 30 minutes, 2 fichiers, 20 lignes de code

"Mais c'est pas propre !" → Ça marche. Vous avez des utilisateurs ? Non ? Alors pourquoi perdre 9.5 jours ?

Quand vous aurez 10,000 utilisateurs, ALORS vous refactorez si le besoin se présente.

Pourquoi le vibe coding émerge maintenant ?

Raison 1 : La sur-ingénierie a atteint des sommets ridicules

Exemple vécu : Projet startup, 0 utilisateur

Architecture "propre" proposée :
Microservices (5 services pour 3 features)Event sourcingCQRSKafka pour la messagerieKubernetesCI/CD avec 15 étapes3 environnements (dev, staging, prod)

Approche vibe :

• Monolithe Next.js
• PostgreSQL
• Vercel (déploiement en 1 clic)
• Budget : $20/mois
• Temps : 3 semaines
• Résultat : PMF trouvé, puis scale

Raison 2 : Les outils modernes permettent la simplicité

Avant (2010) :

• Il fallait VRAIMENT architecturer
• Changer de DB = réécrire tout
• Pas de types = bugs partout
• Tests unitaires = seule sécurité

Maintenant (2025) :

• TypeScript : sécurité sans boilerplate
• Frameworks batteries-included (Next.js, Laravel, Rails)
• ORMs qui gèrent 90% des cas
• Hot reload : feedback instantané
• Refactoring IDE puissant

Résultat : On peut se permettre d'être plus direct.

Raison 3 : Le marché récompense la vitesse

Statistiques startups :

• 70% échouent par manque de product-market fit
• 5% échouent pour des raisons techniques
• Temps moyen avant PMF : 12-18 mois

Traduction : Vos 6 mois à architecturer parfaitement sont du temps perdu.

Vibe coding : Testez 10 idées en 6 mois au lieu d'architecturer parfaitement 1 idée.

Raison 4 : L'IA change la donne

Avec GitHub Copilot / ChatGPT :

• Générer du boilerplate = 10 secondes
• Refactorer = demander à l'IA
• Convertir code → architecture propre = automatisable

Conséquence :

• Moins peur de "mal coder" (refacto facile)
• Plus focus sur la logique métier
• Accélération naturelle du développement

Les principes du vibe coding en pratique

Principe 1 : YAGNI, vraiment

Mauvais :

// "Au cas où on veuille supporter plusieurs DB"
interface DatabaseAdapter { connect(): Promise; query(sql: string): Promise; disconnect(): Promise; }
class PostgresAdapter implements DatabaseAdapter { / ... / } class MongoAdapter implements DatabaseAdapter { / ... / } class MySQLAdapter implements DatabaseAdapter { / ... / }

Vibe coding :

// On utilise Postgres. Point.
import { query } from './db';
export async function getUsers() { return query('SELECT * FROM users'); }

Règle : N'ajoutez une abstraction que quand vous avez 2 implémentations concrètes.

Principe 2 : Copier-coller n'est pas un péché

Dogme traditionnel : DRY (Don't Repeat Yourself) à tout prix

Réalité vibe coding : Duplication > Mauvaise abstraction

Exemple :

// Deux fonctions similaires
function formatUserDate(date: Date) { return date.toLocaleDateString('fr-FR'); }
function formatOrderDate(date: Date) { return date.toLocaleDateString('fr-FR'); }
// Développeur "propre" : function formatDate(date: Date) { return date.toLocaleDateString('fr-FR'); }
// 1 mois plus tard : // "Les dates de commande doivent inclure l'heure" function formatDate(date: Date, includeTime = false, context?: 'user' | 'order') { if (context === 'order' && includeTime) { return date.toLocaleString('fr-FR'); } return date.toLocaleDateString('fr-FR'); }

Vibe coding : Gardez les 2 fonctions séparées. Si elles divergent, tant mieux, c'est qu'elles ont des responsabilités différentes.

Citation célèbre : "Duplication is far cheaper than the wrong abstraction" - Sandi Metz

Principe 3 : La dette technique, c'est OK

Mindset traditionnel : Zéro dette technique, code parfait dès le début

Vibe coding : Dette technique = levier de croissance

Analogie : Une startup qui ne prend jamais de dette financière ne peut pas grandir.

Exemple :

// V1 : Quick & dirty mais ça marche
function sendEmail(to: string, subject: string, body: string) { // TODO: Gérer les erreurs, retry, templates, etc. fetch('https://api.sendgrid.com/v3/mail/send', { method: 'POST', headers: { 'Authorization': Bearer ${process.env.SENDGRID_KEY} }, body: JSON.stringify({ / ... / }) }); }

3 mois plus tard, 10K utilisateurs :

// V2 : Maintenant ça vaut le coup d'investir

Leçon : La v1 quick vous a permis de valider le produit. La dette était intentionnelle et remboursée au bon moment.

Principe 4 : Tests, mais pas tous

Approche TDD rigide :

• 100% de coverage
• Tests unitaires de chaque fonction
• Tests avant le code
• Mocks partout

Vibe coding :

• Testez ce qui a de la valeur business
• Testez ce qui casse souvent
• Tests d'intégration > tests unitaires
• Pas de tests pour du code trivial

Exemple :

// Ne mérite PAS de test
function getUserFullName(user: User) { return ${user.firstName} ${user.lastName}; }

Règle d'or : Si le test est plus long que le code, c'est probablement inutile.

Principe 5 : Refactoring "just in time"

Anti-pattern : Refactorer préventivement "au cas où"

Vibe coding : Refactorer quand ça fait vraiment mal

Exemple :

// Code qui marche mais "pas propre"
function handleCheckout(cartId: string) { const cart = getCart(cartId); const total = cart.items.reduce((sum, i) => sum + i.price * i.qty, 0); const tax = total * 0.2; const shipping = total > 50 ? 0 : 5; const final = total + tax + shipping;
createOrder({ cartId, total: final }); sendConfirmationEmail(cart.userId); clearCart(cartId); }

Quand refactorer :

• ✅ Quand vous copiez-collez ce code pour la 3ème fois
• ✅ Quand il devient difficile d'ajouter une feature
• ✅ Quand les bugs s'accumulent
• ❌ Parce que "c'est pas propre"

Vibe coding vs Clean Code : le grand débat

Ce que Clean Code a apporté de bien

À crédit de Uncle Bob :

• Nommage descriptif (good!)
• Fonctions courtes et focalisées (good!)
• Commentaires explicatifs (good!)
• Éviter la complexité (good!)

Ces principes restent vrais en vibe coding.

Où Clean Code part en vrille

Dogme 1 : "Une fonction ne doit faire qu'une chose"

Résultat : 50 fonctions de 2 lignes pour faire une chose simple

// Clean Code poussé à l'extrême
function validateEmail(email: string): boolean { return isEmailFormatValid(email) && isEmailDomainValid(email); }
function isEmailFormatValid(email: string): boolean { return hasAtSymbol(email) && hasValidLocalPart(email); }
function hasAtSymbol(email: string): boolean { return email.includes('@'); }
function hasValidLocalPart(email: string): boolean { const localPart = extractLocalPart(email); return isLocalPartNotEmpty(localPart); }

Vibe coding :

function isValidEmail(email: string): boolean {
return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email); }

Dogme 2 : "Jamais de nombres magiques"

// Clean Code
const HOURS_IN_DAY = 24; const MINUTES_IN_HOUR = 60; const SECONDS_IN_MINUTE = 60; const MILLISECONDS_IN_SECOND = 1000;
const MILLISECONDS_IN_DAY = HOURS_IN_DAY  MINUTES_IN_HOUR  SECONDS_IN_MINUTE * MILLISECONDS_IN_SECOND;
// Vibe coding const MS_PER_DAY = 24  60  60 * 1000;

Dogme 3 : "Classes, objets, SOLID partout"

Résultat : 15 classes pour gérer une simple liste de todos.

Vibe coding : Des fonctions pures suffisent 90% du temps.

La vraie différence philosophique

Mon avis : Clean Code est excellent pour un produit mature avec 50 développeurs. Vibe coding est parfait pour une startup avec 2 devs.

Cas concrets où le vibe coding a sauvé ma peau

Cas 1 : La fonctionnalité "au cas où"

Contexte : Plateforme SaaS, 0 client

Demande PM : "On veut permettre 3 niveaux de permissions utilisateur"

Approche traditionnelle (ce que j'aurais fait avant) :

• 3 jours à designer le système de permissions
• Rôles, permissions, ACL, middleware
• 500 lignes de code
• 20 tests

Approche vibe :

// users table: role: 'admin' | 'user'
function canAccess(user: User, resource: string) { return user.role === 'admin'; }

12 mois plus tard : Toujours que 2 niveaux utilisés. Les 3 jours économisés ont servi à faire de vraies features.

Cas 2 : Le refactoring qui n'est jamais venu

Contexte : API de traitement d'images

V1 (vibe coding) :

async function processImage(file: File) {
const buffer = await file.arrayBuffer(); const resized = await sharp(buffer).resize(800, 600).toBuffer(); const uploaded = await uploadToS3(resized); return uploaded.url; }

Résultat : 2 ans plus tard, toujours cette fonction. Jamais eu besoin de la changer. 100K images traitées.

Leçon : La complexité "au cas où" n'est jamais venue.

Cas 3 : La dette technique assumée

Contexte : Feature demandée en urgence (démo investisseur dans 48h)

Code produit :

// Hardcodé, pas de config, pas de tests
async function generateReport() { const users = await db.query('SELECT * FROM users WHERE created_at > NOW() - INTERVAL 7 DAY'); const orders = await db.query('SELECT * FROM orders WHERE created_at > NOW() - INTERVAL 7 DAY');
return { newUsers: users.length, revenue: orders.reduce((s, o) => s + o.total, 0), avgOrder: orders.reduce((s, o) => s + o.total, 0) / orders.length }; }

Résultat :

• Démo réussie
• Levée de fonds obtenue
• 6 mois plus tard : refactoré en système de reporting complet
• ROI : Infini

Sans vibe coding : On aurait passé 1 semaine à faire un système de reporting configurable. Pas eu la démo. Pas de fonds. Game over.

Quand le vibe coding NE MARCHE PAS

Soyons honnêtes : le vibe coding a ses limites.

Limite 1 : Systèmes critiques

Ne faites PAS de vibe coding pour :

• Systèmes de paiement
• Sécurité / authentification
• Infrastructure cloud
• Systèmes médicaux
• Aviation, automobile

Raison : Le coût d'une erreur est trop élevé.

Alternative : Utilisez des libraries éprouvées, testez rigoureusement.

Limite 2 : Grandes équipes

Vibe coding scale mal au-delà de 10 développeurs.

Pourquoi :

• Besoin de conventions communes
• Coordination difficile sans structure
• Onboarding complexe sans guidelines

Solution : Vibe coding pour les features, conventions légères pour la cohésion.

Limite 3 : Legacy codebase

Introduire du vibe coding dans un projet de 500K lignes = recette pour le chaos.

Exception : Nouveau module isolé peut être en vibe coding.

Limite 4 : Compliance / régulation

Si vous devez passer des audits (RGPD, SOC2, ISO...), certaines pratiques sont obligatoires :

• Tests de sécurité
• Documentation
• Traçabilité

Vibe coding compatible : Oui, mais pas sur les parties auditées.

Comment adopter le vibe coding sans tomber dans le n'importe quoi

Règle 1 : Définir vos "non-négociables"

Exemple :

Non-négociables :
✅ Tests sur les paiements ✅ Validation des inputs utilisateur ✅ Logs des erreurs critiques ✅ TypeScript strict mode ✅ Code review

Règle 2 : Itérer en cycles courts

Anti-pattern : 6 mois de vibe coding → spaghetti code

Good pattern :

Sprint 1 : Feature A (vibe coding)

Ratio recommandé : 70% nouvelles features, 30% amélioration technique

Règle 3 : Mesurer la douleur

Indicateurs que votre code vibe devient problématique :

• 🔴 Bugs récurrents au même endroit
• 🔴 Peur de toucher à certaines parties
• 🔴 Onboarding > 2 semaines
• 🔴 Hotfixes fréquents
• 🔴 Vélocité qui diminue

Indicateurs que tout va bien :

• 🟢 Features livrées rapidement
• 🟢 Peu de bugs en production
• 🟢 Développeurs heureux
• 🟢 Code compris facilement

Règle 4 : Code reviews adaptées

Mauvaise review : > "Il faut extraire ça dans une classe abstraite avec une interface générique"

Bonne review : > "Ce code marche mais sera difficile à modifier. On attend qu'il soit utilisé 3 fois avant de généraliser ?"

Questions à poser :

• Est-ce que ça marche ?
• Est-ce lisible ?
• Y a-t-il des risques de sécurité ?
• Peut-on le modifier facilement si besoin ?

Règle 5 : Documentation minimaliste mais efficace

Inutile :

/**
* Récupère un utilisateur par son ID * @param id - L'identifiant de l'utilisateur * @returns L'utilisateur correspondant */ function getUserById(id: string): User { / ... / }

Utile :

/**
* IMPORTANT : Cette fonction cache le résultat pendant 1h * Si vous modifiez un utilisateur, appelez invalidateUserCache() */ function getUserById(id: string): User { / ... / }

Vibe coding et IA : le combo gagnant

L'IA amplifie le vibe coding

Avec ChatGPT / Copilot :

Vous : "Fonction pour envoyer un email avec pièce jointe"
IA : [génère le code complet en 5 secondes]
Vous : "Ajoute la gestion d'erreurs"
IA : [ajoute try/catch, logging, retry]
Vous : "Refactor en classe EmailService"

Résultat : Vous pouvez vibe coder encore plus vite, et refactorer facilement quand nécessaire.

Nouveau workflow : Vibe → IA → Iterate

Ancien workflow :

Réfléchir architecture (3h)
↓ Coder (2h) ↓ Tester (1h) ↓ Deploy (30min)

Nouveau workflow avec IA :

Vibe : "J'ai besoin de ça" (30s)
↓ IA génère (10s) ↓ Ajustements manuels (10min) ↓ Test rapide (5min) ↓ Deploy (1min)

Leçon : L'IA rend le vibe coding encore plus viable.

Conclusion : trouver votre équilibre

Le vibe coding n'est pas une révolution. C'est un retour aux fondamentaux :

• Résoudre des problèmes
• Livrer de la valeur
• Itérer rapidement

Ce que j'ai appris après 18 mois de vibe coding

1. La simplicité est sous-estimée

90% des projets n'ont pas besoin de microservices, event sourcing, ou 15 design patterns. Un bon monolithe avec du code lisible suffit.

2. L'intuition se construit avec l'expérience

Le vibe coding ne marche que si vous avez de l'expérience. Un junior ne doit PAS vibe coder seul. Un senior peut se le permettre.

3. La sur-ingénierie est une perte de temps

J'ai perdu des centaines d'heures à architecturer pour des besoins qui ne sont jamais venus. Le vibe coding m'a sauvé de ce piège.

4. Le dogme est l'ennemi

Que ce soit "Clean Code à tout prix" ou "Vibe coding pour tout", les extrêmes sont dangereux. Trouvez votre équilibre.

Mon framework personnel

Aujourd'hui, je code comme ça :

Phase 1 : Vibe (MVP, 0-100 users)

• Code direct, minimal
• Tests sur le critique uniquement
• Shipping rapide
• Itération quotidienne

Phase 2 : Structure (100-1000 users)

• Refactoring des parties qui font mal
• Tests d'intégration ajoutés
• Patterns émergent naturellement
• Documentation des gotchas

Phase 3 : Engineering (1000+ users)

• Architecture formalisée
• Tests complets
• Monitoring et observabilité
• Process et guidelines

Règle : Ne passez JAMAIS à la phase suivante prématurément.

Le vibe coding est-il pour vous ?

Oui si :

• ✅ Vous êtes en startup / projet solo
• ✅ Vous privilégiez la vitesse
• ✅ Vous avez de l'expérience
• ✅ Vous acceptez la dette technique intentionnelle
• ✅ Vous itérez souvent

Non si :

• ❌ Vous êtes dans une grande entreprise
• ❌ Votre système est critique (santé, finance, sécurité)
• ❌ Vous avez 50+ développeurs
• ❌ Vous devez respecter des normes strictes
• ❌ Vous ne refactorez jamais

La vraie question

Pas : "Vibe coding ou Clean Code ?"

Mais : "Quel est le juste niveau de complexité pour mon contexte ?"

Parfois c'est SOLID et TDD. Parfois c'est 20 lignes de code qui marchent.

Soyez pragmatique, pas dogmatique.

Et vous, vous pratiquez le vibe coding sans le savoir ? Partagez votre expérience en commentaires ! 👇