Qu’est-ce qu’un bon prompt Lovable ?
Un prompt est le message que vous écrivez à Lovable pour qu’il construise ou modifie votre application. Lovable ne voit que ce que vous lui donnez. Tout ce que vous ne précisez pas, il le devine.
Un bon prompt réduit la part de devinette. Il contient quatre choses :
- Le but : ce que fait l’application ou l’écran.
- L’utilisateur : qui s’en sert et pour faire quoi.
- Le contenu réel : vos vrais textes, vos vrais champs, vos vraies données.
- Les limites : ce qui ne doit pas changer.
La documentation de Lovable va dans le même sens. Elle recommande de répondre à quatre questions avant d’écrire : ce qu’est le produit, pour qui, pourquoi on l’utilise, et l’action principale que l’utilisateur doit faire. Elle insiste sur le fait que ce cadrage reste court : une direction, pas un cahier des charges.
Si vous débutez, lisez d’abord le guide complet pour apprendre Lovable. Ici, on se concentre sur l’écriture des prompts.
Que mettre dans le premier prompt ?
Le premier prompt pose la structure de l’application. C’est celui qui coûte le plus cher à rattraper s’il part dans la mauvaise direction.
Voici un prompt vague :
Fais-moi une app pour gérer mes clients.
Lovable va produire quelque chose. Mais il choisira seul les champs, les écrans et le style. Vous passerez ensuite plusieurs prompts à corriger ses choix.
Voici la même demande, en prompt utile :
Je suis consultant indépendant. Je veux une application interne pour suivre mes clients et mes devis.
Utilisateur : moi seul, sur ordinateur.
Écrans :
1. Liste des clients (nom, entreprise, email, statut : prospect, client, ancien client).
2. Fiche client avec l'historique des devis.
3. Formulaire de création de devis (client, montant HT, date d'envoi, statut : envoyé, accepté, refusé).
Style : sobre et professionnel, fond clair, une seule couleur d'accent bleue.
Ne crée pas encore de connexion ni de base de données : je veux d'abord valider les écrans.
Pose-moi les questions nécessaires avant de commencer.
La dernière ligne compte. La documentation de Lovable conseille d’ajouter à la fin du prompt une demande de questions de clarification. Lovable relève alors des points que vous n’aviez pas précisés.
Pour la suite de la construction, écran par écran, voyez comment créer une application avec Lovable.
Comment demander une modification sans tout casser ?
C’est là que la plupart des projets dérapent. Un prompt flou sur une application existante peut modifier des zones que vous ne vouliez pas toucher.
La documentation de Lovable donne trois règles que nous appliquons systématiquement.
Une modification à la fois. Demandez un changement, vérifiez-le, puis passez au suivant.
Nommez l’élément précis. Parlez de “la carte”, “le badge”, “le bouton Enregistrer”, “la colonne Statut”, plutôt que de “la page”.
Dites ce qui ne doit pas bouger. Une phrase comme “ne modifie que la page Devis” contient la modification.
Prompt vague :
Améliore la page des devis.
Prompt utile :
Sur la page Devis uniquement :
- ajoute un filtre par statut (envoyé, accepté, refusé) au-dessus du tableau ;
- affiche le montant total HT des devis filtrés sous le tableau.
Ne modifie pas la page Clients ni le formulaire de création de devis.
Évitez aussi les verbes vagues comme “améliore” ou “rends plus joli”. La documentation recommande des verbes précis : remplacer, mettre à jour, ajuster.
Pour une retouche visuelle, vous n’êtes pas obligé d’écrire. La barre d’outils de l’aperçu permet de sélectionner un élément à l’écran et de décrire le changement. Le texte simple se modifie directement sur la page.
Quand utiliser les modes Chat, Plan et Build ?
Le chat d’un projet Lovable a trois modes, selon la documentation consultée le 26/10/2026. Le choix du mode change ce que fait votre prompt.
| Mode | Ce qu’il fait | Modifie le code ? | Quand l’utiliser |
|---|---|---|---|
| Chat | Discute du projet, explique le code, compare des options | Non | Comprendre avant de décider |
| Plan | Analyse le projet et rédige un plan à relire et approuver | Non | Changement lourd ou risqué |
| Build | Applique les changements et vérifie le résultat | Oui | Exécuter une demande claire |
Côté coût, la documentation indique qu’un message en mode Plan coûte un crédit, plus le coût de la recherche éventuelle. Un message en mode Chat coûte en général une fraction de crédit, couverte d’abord par l’allocation de chat quotidienne. Le détail des crédits est dans l’article sur les prix et crédits Lovable.
Notre usage : nous passons par Plan dès qu’une demande touche plusieurs écrans ou la base de données. Nous relisons le plan, corrigeons ce qui ne va pas, puis approuvons. Exemple :
Je veux ajouter des comptes utilisateurs : chaque consultant ne voit que ses propres clients et devis.
Propose un plan avant de toucher au code. Liste les tables modifiées et les écrans impactés.
Comment décrire un bug pour que Lovable le corrige ?
Quand une erreur de build apparaît, Lovable affiche un bouton Try to fix. Selon la documentation consultée le 26/10/2026, votre compte dispose de 10 corrections gratuites, partagées entre ce bouton et les corrections proposées par la vue Sécurité. Chaque correction gratuite redevient disponible 24 heures après usage. Au-delà, la correction consomme des crédits.
Si le bouton ne suffit pas, ne renvoyez pas le même prompt. Décrivez ce que vous voyez et ce que vous attendiez.
Prompt vague :
Ça ne marche pas, corrige.
Prompt utile :
Sur la page Devis, quand je clique sur "Enregistrer" avec un montant de 1 500, rien ne se passe.
Je m'attends à voir le devis apparaître dans le tableau.
Aucun message d'erreur ne s'affiche.
Cherche la cause avant de modifier quoi que ce soit, et explique-la-moi.
Si l’erreur revient, la documentation conseille de revenir à la version précédant le problème dans l’historique, puis de reformuler un prompt plus précis. Le chat permet aussi d’annuler la dernière modification ou de revenir à une version antérieure.
Où enregistrer les consignes que Lovable doit retenir ?
Répéter vos règles dans chaque prompt est une perte de temps. Lovable propose pour cela la Knowledge du projet : un champ de texte dans les paramètres, que Lovable lit avant de générer ses modifications.
Selon la documentation consultée le 26/10/2026, la Knowledge d’un projet accepte jusqu’à 10 000 caractères. Il existe aussi une Knowledge d’espace de travail, pour les règles communes à tous vos projets.
Ce que nous y mettons :
- le but de l’application et ses utilisateurs ;
- le vocabulaire métier (devis, avoir, acompte) ;
- les règles de style retenues ;
- les contraintes : “ne jamais supprimer de données sans confirmation”, “tous les montants sont en euros HT”.
Quels exemples de prompts Lovable copier ?
Quelques modèles à adapter. Remplacez les éléments entre crochets.
Ajouter une section à une page :
Sur la page d'accueil, sous le titre principal, ajoute une section avec un titre centré et trois cartes alignées horizontalement.
Chaque carte : une icône, un titre court, une phrase.
Contenu des cartes : [vos trois arguments].
Ne modifie pas le reste de la page.
Fixer un style pour la suite du projet :
Style du projet : minimal, professionnel, beaucoup d'espace blanc, coins légèrement arrondis, une couleur d'accent [couleur].
Applique ce style à la page actuelle uniquement, je validerai avant de l'étendre.
Prévoir les états d’un écran :
Sur la liste des clients, gère trois cas :
- aucun client : affiche un message et un bouton "Ajouter un client" ;
- chargement : affiche un indicateur ;
- erreur de chargement : affiche un message clair et un bouton "Réessayer".
Ce dernier point est souvent oublié. La documentation de Lovable recommande de penser dès le départ aux états vides, de chargement et d’erreur.
Quelles erreurs éviter dans vos prompts ?
- Tout demander d’un coup. Une page complète en un prompt donne un résultat difficile à corriger. Construisez bloc par bloc.
- Utiliser du faux texte. Le “lorem ipsum” ne donne aucune information à Lovable. Vos vrais titres révèlent aussi plus tôt les problèmes de mise en page.
- Ne pas marquer les versions qui marchent. Ajoutez un signet dans l’historique avant une modification risquée.
- Accepter sans regarder. Testez chaque changement dans l’aperçu avant de passer au suivant.
Ce dernier point rejoint une question plus large : jusqu’où peut-on laisser l’IA écrire le code sans le relire ? Nous y répondons dans l’article sur le vibe coding.
Pour la vue d'ensemble, lisez le guide complet : Apprendre Lovable : le guide complet pour non-développeurs.
À lire ensuite
Questions fréquentes
Faut-il écrire ses prompts Lovable en anglais ?
Non. Le guide de démarrage de Lovable, consulté le 26/10/2026, indique que vous pouvez décrire votre projet dans n'importe quelle langue. Nous gardons simplement les noms techniques tels qu'ils apparaissent dans l'outil (Plan, Build, Knowledge).
Combien coûte un prompt dans Lovable ?
Cela dépend du mode. Selon la documentation consultée le 26/10/2026, un message en mode Plan coûte un crédit plus la recherche éventuelle, et un message en mode Chat coûte en général une fraction de crédit, couverte d'abord par l'allocation de chat quotidienne.
Que faire quand Lovable tourne en rond sur un bug ?
Arrêtez de renvoyer le même prompt. Revenez à la dernière version qui marchait via l'historique, puis décrivez précisément ce que vous voyez et ce que vous attendiez.
Où mettre les consignes que Lovable doit toujours suivre ?
Dans la Knowledge du projet, dans les paramètres. Lovable la lit avant chaque modification. Elle accepte jusqu'à 10 000 caractères selon la documentation consultée le 26/10/2026.
Sources
- Lovable Docs, Quick start, consulté le 26/10/2026
- Lovable Docs, Prompting best practices, consulté le 26/10/2026
- Lovable Docs, Plan mode, consulté le 26/10/2026
- Lovable Docs, Chat mode, consulté le 26/10/2026
- Lovable Docs, Project chat (corriger les erreurs, annuler), consulté le 26/10/2026
- Lovable Docs, Workspace and project knowledge, consulté le 26/10/2026
- Lovable Docs, Debug and improve your app, consulté le 26/10/2026