Principe de fonctionnement
Le vibe coding repose sur une idée simple : vous décrivez une intention, et un ensemble d’agents IA s’organise pour produire des modifications concrètes dans un projet (fichiers, dépendances, configuration, tests). L’outil ne “devine” pas magiquement un site complet : il enchaîne une série de petites décisions, chacune alimentée par du contexte (votre prompt, le code existant, des fichiers de référence, parfois le web), puis matérialisée par des actions sur le projet.
Qu’est-ce qu’un agent IA dans ce contexte ?
Le mot “agent” est souvent utilisé à toutes les sauces, donc autant cadrer.
Un agent IA, dans un outil de vibe coding, c’est généralement :
- un LLM (claude est à la mode pour le code, mais GPT, gemini et d’autres font très bien le travail aussi)
- doté d’outils (lire un fichier, écrire un fichier, chercher une information, exécuter des commandes, lancer des tests…)
- configuré pour un rôle précis (pré-prompt, règles de style, contraintes techniques, priorités, niveau d’autonomie)
Où vivent ces agents IA ?
Ces agents sont intégrés dans un IDE ou un éditeur de code :
- soit côté cloud (Lovable, Bolt, etc.), avec un environnement pré-configuré
- soit sur votre machine (Cursor), en s’appuyant sur votre dépôt local, votre terminal, vos accès, votre git
Dans les deux cas, l’éditeur fournit les fonctions classiques : navigation de fichiers, recherche, refactor, gestion des dépendances, contrôle de version (git), exécution, aperçu du rendu. L’agent s’appuie sur ces capacités pour passer du “je comprends” au “je modifie”.
Que se passe-t-il entre un prompt et la génération d’un site ?
Prenons un prompt du type : “créez un site pour un consultant seo”.
Derrière, il se passe généralement plusieurs étapes, parfois invisibles (de moins en moins), qui ressemblent à un mini cycle de gestion de projet.
1) Analyse et cadrage du besoin
Le llm commence par interpréter l’intention, repérer les ambiguïtés, et construire une représentation “actionnable” du résultat attendu.
Exemples de sous-questions internes :
- quelle cible ? (b2b, pme, grands comptes, local)
- quelles pages minimales ? (accueil, services, cas clients, à propos, contact)
- quel ton éditorial ? (expert, accessible, orienté conversion)
- quelles contraintes ? (performance, SEO, accessibilité, multi-langue)
À ce stade, selon l’outil et votre prompt, il peut soit :
- vous poser des questions
- faire des hypothèses “raisonnables” et avancer
- chercher des signaux dans le projet (si un dépôt existe déjà)
2) Décomposition en plan d’actions
Ensuite, le LLM transforme l’objectif en tâches séquentielles. Par exemple :
- proposer une arborescence de pages
- rédiger les contenus (titres, sections, cta)
- choisir une stack (react/next, vue, statique, etc.)
- initialiser le projet (dépendances, scripts)
- créer les composants et les pages
- ajouter le style (souvent tailwind)
- gérer les images et assets
- mettre en place les basiques seo (metadata, open graph, sitemap, robots)
- vérifier la performance et corriger
- lancer les tests et corriger les erreurs
- préparer le déploiement
Point important : ce “plan” peut être explicite (affiché dans un mode planification) ou implicite (l’agent enchaîne directement). Certains outils alternent aussi entre planification et exécution.
3) Sélection des agents spécialisés
Une fois le plan esquissé, l’outil route chaque tâche vers un agent adapté. Typiquement :
- agent “planner” : structure, roadmap, priorisation
- agent “coder” : implémentation, composants, wiring
- agent “designer” : mise en page, cohérence visuelle, responsive
- agent “content” : textes, micro-copy, structure persuasive
- agent “SEO” : meta, headings, maillage, données structurées
- agent “QA” : lancer des tests, vérifier la build, corriger les erreurs
Selon le produit, ce ne sont pas toujours des “personnalités” séparées : ça peut être un seul llm qui change de rôle via des instructions internes. Mais l’effet est le même : spécialiser l’attention.
4) Collecte de contexte (le nerf de la guerre)
Avant d’écrire quoi que ce soit, l’agent doit savoir “où il met les pieds”. Il va donc récupérer du contexte :
- structure des dossiers
- conventions existantes (typescript ou JS, eslint, prettier)
- composants déjà présents
- dépendances installées
- contraintes de build (Vite, Next, Astro, etc.)
- contenu de fichiers clés (readme, package.json, config)
C’est là que l’on comprend pourquoi la documentation et les fichiers markdown aident énormément : ils servent de “boussole” au llm. Sans contexte, il invente plus, et se contredit davantage.
5) Exécution : écrire, modifier, relire, corriger
L’exécution se fait par boucles courtes :
- l’agent modifie des fichiers (création ou patch)
- il relit ce qu’il a écrit (souvent automatiquement)
- il lance une commande (build, lint, tests) si l’outil le permet
- il observe les erreurs
- il corrige
- il recommence jusqu’à obtenir un état stable
Ce mécanisme explique deux choses :
- pourquoi les outils sont très bons pour “itérer” (corriger rapidement)
- pourquoi ils peuvent aussi tourner en rond s’ils manquent de signaux (logs incomplets, dépendances cassées, consignes contradictoires)
6) Orchestration : qui décide du prochain pas ?
Le LLM joue souvent le rôle de “chef d’orchestre”. À chaque retour d’outil (fichier modifié, erreur de build, résultat de test), il décide :
- est-ce que je continue la tâche ?
- est-ce que je dois revenir en arrière ?
- est-ce que je dois créer une nouvelle tâche ?
- est-ce que je dois demander une précision à l’utilisateur ?
C’est aussi là qu’il peut “s’appeler lui-même” : l’agent produit un sous-prompt pour clarifier un point, puis réintègre la réponse dans le flux. En pratique, ça ressemble à de l’auto-contrôle qualité.
Pourquoi ces outils “orientent” vers certaines technos ?
Les outils font des choix qui guident lesIA vers des stacks particulières. Ce biais vient de plusieurs facteurs :
- templates de démarrage : si l’outil initialise souvent react + tailwind, il y revient par défaut
- bibliothèques “connues” : le LLM a vu beaucoup d’exemples react/tailwind dans ses données et dans les projets publics
- contraintes produit : certains environnements cloud sont optimisés pour un set restreint de frameworks
- stratégie de fiabilité : limiter les options réduit les cas d’erreurs et améliore le taux de réussite
À titre d’exemple, lovable s’appuie très souvent sur react et tailwind car cela permet :
- de produire un rendu correct rapidement
- de rester cohérent visuellement sans écrire beaucoup de css “à la main”
- de réutiliser des patterns standard (layout, cards, sections, responsive)
Ce qu’il faut retenir
Entre votre prompt et un site “complet”, il y a surtout :
- une phase de compréhension et de décomposition
- une collecte de contexte (projet, conventions, contraintes)
- une exécution en boucles (écriture → test → correction)
- une orchestration qui décide du prochain pas
That’s it.
Il existe d’autres couches (mémoire de conversation, indexation du dépôt, règles de sécurité, limitations d’outils, sandbox d’exécution), mais le principe de base n’est pas beaucoup plus complexe : des agents outillés, pilotés par un LLM, qui transforment une intention en modifications successives d’un projet.
Discussions en lien