Guide · Vibe coding
Vibe coding en production : sept leçons tirées de projets construits avec Lovable
Par Marie Van Haecke ·
Construire avec l'IA va vite. Ce qui distingue un projet qui tient en production d'une belle démo, ce sont des habitudes simples : cadrer avant de demander, une demande pour un changement, poser les rôles avant les écrans, penser dès le départ aux robots qui liront les pages, brancher l'existant plutôt que tout reconstruire, garder une validation humaine là où elle compte, et tester avec de vraies données.
Ces leçons viennent des projets présentés dans les réalisations du studio : mon site personnel et son blog, le site de Grabloop, Le Board, Pulse Outdoor, Wavestay, Filon Français et le site de l'association Mission Naïm. Tous sont en ligne : vous pouvez vérifier ce que j'en dis.
1. Cadrer avant de demander
Le temps gagné ne vient pas du prompt, il vient de ce qui est décidé avant : pour qui, pour faire quoi, avec quelles informations, et ce qui n'est pas dans le projet. C'est la première étape de la méthode du studio, avant tout écran. Une demande précise donne un résultat juste du premier coup ; une demande floue lance une série de corrections qui consomment des crédits et fragilisent le projet.
La trame du brief est dans Cadrer son projet avant de prompter.
2. Une demande, un changement
Demander dans le même message de changer le menu, d'ajouter un champ et de corriger un bug, c'est s'exposer à ce qu'une modification en casse une autre sans qu'on sache laquelle. Une demande à la fois, vérifiée dans l'aperçu, permet de revenir en arrière proprement si le résultat ne convient pas. Voir Faire évoluer un projet Lovable sans tout casser.
3. Poser les rôles avant les écrans
Pulse Outdoor a trois rôles : coach, adhérent et administrateur. Ils ne voient pas les mêmes informations et n'ont pas le droit de faire les mêmes choses. Ces règles se décident avant de construire les écrans : ajoutées après coup, elles obligent à reprendre à la fois les écrans et les règles d'accès de la base de données, là où se joue la protection des données.
4. Penser aux robots dès le départ
Mon site personnel compte plus de 90 articles. Je l'ai migré en génération statique pour que chaque page arrive avec son titre et son texte, sans JavaScript, et soit lue en entier par les robots de Google, de ChatGPT, de Claude et de Perplexity. Un site invisible pour les robots peut être très beau : il ne fait venir personne. Voir Lovable et SEO.
5. Brancher l'existant plutôt que tout reconstruire
Le site de Mission Naïm reçoit les dons par HelloAsso et affiche un agenda alimenté par un Google Sheet. Plutôt que de construire un module de paiement et un écran d'administration, le site s'appuie sur des outils éprouvés et sur un tableur simple à mettre à jour. Moins de code, c'est moins de choses à sécuriser et à maintenir. Voir Brancher son outil Lovable à Notion, à son CRM et à ses emails.
6. Garder une validation humaine là où elle compte
Sur Filon Français, n'importe qui peut proposer une adresse, mais rien n'est publié sans validation. Automatiser, ce n'est pas tout laisser passer : identifiez les moments où une erreur se verrait publiquement ou coûterait cher, et gardez-y une étape de contrôle.
7. Tester avec de vraies données
Une maquette remplie de trois fiches d'exemple fonctionne toujours. Les vraies données apportent ce qu'elle cache : des champs vides, des noms très longs, des doublons, des périodes sans activité. Plus elles arrivent tôt dans le projet, moins elles coûtent cher à prendre en compte.
En résumé
| Leçon | Ce qu'elle évite |
|---|---|
| Cadrer avant de demander | Les allers-retours et les crédits consommés pour rien |
| Une demande, un changement | Les corrections qui en cassent d'autres |
| Poser les rôles avant les écrans | Des données visibles par les mauvaises personnes |
| Penser aux robots dès le départ | Un site que Google et les IA lisent mal |
| Brancher l'existant | Du code en plus à sécuriser et à maintenir |
| Garder une validation humaine | Des erreurs publiées sans contrôle |
| Tester avec de vraies données | Un outil qui ne tient pas au premier vrai usage |
Questions fréquentes
Peut-on reprendre un projet commencé seul en vibe coding ?
Oui. On commence par un audit : ce qui peut être gardé, ce qui doit être repris, et un chiffrage avant de toucher au code. C'est souvent plus rapide que de repartir de zéro.
Faut-il connecter son projet Lovable à GitHub ?
C'est recommandé : vous gardez une copie du code chez vous, un historique des modifications, et la possibilité de confier le projet à un développeur.
Combien de temps pour passer d'un prototype à un outil en production ?
Cela dépend de l'état du prototype et du nombre de rôles et de connexions. Pour un outil centré sur un process principal, le délai indicatif du studio est de 4 semaines, cadrage compris.
Votre projet Lovable est bloqué à 80 % ? L'audit technique dit ce qui peut être gardé, ce qui doit être repris, et combien ça coûte, avant de toucher au code.
Marie Van Haecke · 20 ans à concevoir des produits tech et à coacher des équipes produit. Fondatrice de Grabloop, Lovable Certified Expert 2026 (App builder et Website builder).