Logo de la startup Et le vibecoding dans tout ça ?


Et le vibecoding dans tout ça ?

Depuis 2025, l’expression vibe coding s’est imposée dans toutes les discussions geek de la frenchtech. Il s’agit d’une pratique devenue courante : décrire ce que l’on veut en langage naturel, laisser une IA générer le code, puis itérer jusqu’à ce que “ça marche”. Collins Dictionary en a même fait son Word of the Year 2025 et rappelle que le terme a été popularisé par Andrej Karpathy, qui résumait l’idée par la possibilité d’avancer au point « d’oublier que le code existe ».

Avant, pour faire un programme, il fallait faire une récolte du besoin, étudier la faisabilité, pondre une analyse fonctionnelle, doublée d’une analyse technique.
Rédiger le cahier de tests, puis à la toute fin, on codait, en omettant bien volontiers la rédaction de la documentation.
Maintenant avec le vibe coding, il suffit de décrire le programme attendu dans un prompt et bim bam boum, l’IA génère le code pour vous.
IE : Avant, il fallait savoir coder, mais plus maintenant :-) (enfin en théorie)

Derrière l’effet de mode, le vibe coding révèle une transformation plus profonde : le code devient une sortie (un résultat) plutôt qu’une entrée (un acte d’écriture), et le rôle du développeur se déplace vers la spécification, l’orchestration, la revue et la validation.

Pour une startup, le vibe coding est surtout un accélérateur de time-to-market : il permet de transformer rapidement une idée en MVP testable, d’enchaîner des itérations produit (écrans, endpoints, intégrations) et de réduire le temps passé sur le “boilerplate”, ce qui est précieux quand l’équipe est petite et que la trésorerie est contrainte. Concrètement, cela aide à multiplier les expérimentations (A/B tests, nouvelles features, prototypes internes), à automatiser des tâches d’ingénierie répétitives (tests de base, refactors mécaniques, scripts), et à concentrer les développeurs sur les différenciateurs (architecture, UX, performance, sécurité, fiabilité). Bien utilisé, c’est aussi un levier d’alignement : une spec claire + des prompts structurés rendent plus explicites les choix et les critères d’acceptation. En contrepartie, une startup doit absolument poser des garde-fous (tests automatisés, revues systématiques, droits limités en production, politique de dépendances) pour éviter que la vitesse initiale ne se transforme en dette technique ou en risque de sécurité.

Les principes du vibe coding

Le vibe coding n’est pas une méthodologie “officielle” comme Scrum ou TDD. C’est plutôt une manière de travailler rendue possible par les LLM (grands modèles de langage) intégrés aux IDE et aux plateformes de développement.

Principe 1 — L’intention prime sur la syntaxe

Au lieu d’écrire : “j’implémente une API REST, puis je branche l’ORM, puis j’écris les contrôleurs”, on formule :

“Crée une API d’inscription/connexion avec JWT, endpoints /login /signup, et une table users. Ajoute la validation et des tests.”

L’IA produit alors un squelette fonctionnel (souvent complet), que l’on ajuste.

Principe 2 — Itération ultra-rapide (boucle courte)

On travaille par boucles :

  1. prompt → 2) génération → 3) exécution/tests → 4) corrections → 5) nouveau prompt.

Le “flow” est central : on cherche à réduire les frictions (setup, boilerplate, recherche de doc, etc.).

Principe 3 — Le développeur devient un “directeur” plus qu’un “scribe”

De plus en plus, l’objectif n’est pas de “taper du code”, mais de :

La pratique “mature” ressemble à ce que Microsoft appelle du structured vibe coding : démarrer par une spécification, découper en issues, laisser des agents produire des PR, puis faire de la revue comme avec une équipe humaine.

Comment ça fonctionne, concrètement ?

Derrière l’illusion d’un dialogue “naturel”, il y a généralement 4 mécanismes.

a) Le modèle + le contexte (codebase-aware)

L’outil ne se contente pas d’un prompt : il essaie de comprendre le dépôt, via indexation, recherche sémantique, lecture de fichiers, historiques, etc.

b) Le travail “en diffs” (modifications contrôlées)

Les meilleurs outils proposent des changements sous forme de diff / PR, ce qui permet :

c) Le mode agent : lire → planifier → modifier → exécuter → réparer

Le vibe coding évolue souvent vers l’agentic coding : l’IA ne propose plus seulement du code, elle agit (exécute des commandes, lance des tests, corrige des erreurs).

Par exemple, GitHub explique que son agent mode orchestre plusieurs éléments (prompt, workspace, outils) et itère jusqu’à un état final.
OpenAI décrit Codex dans la même logique : à partir d’une spec, il navigue dans le repo, édite des fichiers, exécute des commandes et des tests, en terminal ou IDE.

d) L’orchestration multi-agents

On voit apparaître des interfaces où plusieurs agents travaillent en parallèle (un agent “frontend”, un “backend”, un “tests”, etc.). Cursor met en avant une interface multi-agents et un modèle “Composer” dédié à ce workflow.

 

C Comment le vibe coding modifie le travail des développeurs

1) Moins de temps sur le “boilerplate”, plus sur le design et la validation

Dans les meilleures équipes, l’IA avale :

Certaines études (sur tâches contrôlées) rapportent des gains de vitesse significatifs (par ex. ~55,8% plus rapide sur une tâche de dev dans une étude Microsoft).
Mais en pratique, le gain dépend fortement de la qualité de la revue, des tests et du contexte projet.

2) Un basculement vers la “specification literacy”

On attend davantage des devs qu’ils sachent :

Le “structured vibe coding” formalise précisément ça : spec → issues → PR → review.

3) La revue devient le cœur du métier (et pas seulement du code review)

On ne relit plus seulement le code, on relit :

4) Une nouvelle fracture : prototype vs production

Pour des prototypes “low stakes”, le vibe coding est redoutable.
Pour de la production, la question devient : quels garde-fous ?
Le risque classique : un prototype “assez bon” finit poussé en prod, sans le travail d’industrialisation.

Simon Willison (observateur très écouté dans l’écosystème web) résume le danger : vibe coder une codebase de production est une mauvaise idée parce que l’essentiel du métier est d’faire évoluer un système existant dont la qualité et la lisibilité comptent.

Ce que le vibe coding apporte

 1) Prototypage fulgurant et réduction du “time-to-first-demo”

Exemples concrets :

C’est ce que vendent explicitement des plateformes “prompt-to-app” (ex. Replit Agent génère un plan de fonctionnalités puis construit l’app à partir du prompt).

 2) Accélération des tâches répétitives et refactors

 3) Onboarding et compréhension d’une base de code

Les assistants capables de “chat avec ton code” (ex. Cody chez Sourcegraph) se positionnent clairement sur l’aide à comprendre, écrire et corriger plus vite en s’appuyant sur le contexte de dev.

 4) Démocratisation : plus de gens peuvent produire du logiciel

C’est un point central : le vibe coding sort du seul périmètre “ingénierie”. Des outils sont conçus pour transformer une idée en app avec très peu de code manuel (ex. Bolt.new, v0, etc.).

 

Limites, risques et problèmes concrets rencontrés 

1) Illusion de fiabilité : “ça marche” ≠ “c’est correct”

Symptôme fréquent : l’app fonctionne sur le happy path, mais casse sur :

Conséquence : plus de temps de debug et d’industrialisation… parfois plus que le gain initial.

 

2) Sécurité : vulnérabilités “classiques”, mais introduites à grande vitesse

Plusieurs acteurs sécurité documentent des patterns récurrents dans des apps vibe-codées :

Exemple concret (red team) : Databricks décrit un cas où un jeu généré “au vibe” utilisait pickle pour sérialiser des objets réseau — une pratique connue pour exposer à l’exécution de code à distance si elle est mal utilisée. Le projet “marchait”, mais portait un risque critique.

 

 3) Incidents réels : quand l’agent “fait n’importe quoi” en environnement sensible

Un cas très commenté : lors d’une expérience, un agent de Replit a supprimé une base de données de production et a ensuite tenté de masquer l’erreur en générant des données fictives.

Le point important ici n’est pas “Replit est mauvais”, mais :
si un agent a des droits d’écriture sur de la prod, le risque systémique devient énorme (même avec de “bonnes intentions”)

 4) Supply chain : dépendances inventées et attaques opportunistes

Trend Micro décrit le risque de packages hallucinés : le modèle propose un nom de dépendance plausible mais inexistant ; un attaquant peut ensuite enregistrer ce nom dans un registre public et y placer du malware (“slopsquatting”).

Problème typique rencontré par des vibe coders :
“L’IA me dit d’installer X pour corriger l’erreur… je l’installe… et je viens peut-être d’introduire un composant non vérifié.”

 5) Attaques par prompt injection / outils compromis : l’IDE devient une surface d’attaque

Les environnements “agentiques” connectés aux fichiers, au terminal, au navigateur ou à Git peuvent être trompés par des instructions cachées (dans un fichier, une doc, un commentaire, une sortie de commande…).

Un ensemble de failles baptisé “IDEsaster” a été rapporté comme touchant de nombreux outils/IDE testés, avec des scénarios allant jusqu’à l’exfiltration de données et l’exécution de code à distance.

 6) Risques juridiques et conformité (licences, provenance du code)

Même si tout n’est pas tranché juridiquement, le sujet est suffisamment sérieux pour que :

Problème concret côté équipes :
“Qui a généré ce bout de code ? Avec quel modèle/prompt ? Peut-on prouver la provenance ?”

Conclusion : les principaux outils de vibe coding disponibles aujourd’hui

Plutôt que “un” outil, il y a 4 grandes familles.

1) IDE “AI-native” (pensés autour de l’agent)

2) Assistants intégrés aux IDE classiques (pair programming + agent mode)

3) Agents de dev “autonomes” (SWE agents)

4) “Prompt-to-app” (vibe coding grand public : idée → app)

Bon code :)

PS : nous étions obligés de vous parler de BuilderAi : la licorne anglaise qui promettait une IA pour coder vos projets… alors qu’il s’agissait d’une bande de dev en Inde

Exit mobile version