Apprendre Lovable : le guide complet pour non-développeurs

Lovable, c’est quoi exactement ?

Lovable est une plateforme qui construit des applications web à partir d’une description écrite. Vous tapez ce que vous voulez dans un chat. Lovable écrit le code de l’interface, de la base de données et de la connexion. Puis il héberge l’application pour vous.

Selon la FAQ de Lovable (consultée le 26/10/2026), la société a été fondée en 2023 à Stockholm par Anton Osika et Fabian Hedin. Elle s’appelait d’abord GPT Engineer.

Trois points à retenir avant de commencer :

• Vous écrivez en français. Le guide de démarrage précise qu’on décrit son application en langage courant, dans n’importe quelle langue.
• Le code est du vrai code. Vous pouvez le lire, le récupérer et le faire évoluer ailleurs. Il vous appartient, selon la FAQ.
• Vous ne choisissez pas la technologie. Depuis le 13 mai 2026, les nouveaux projets utilisent TanStack Start, et les plus anciens React et Vite (FAQ Lovable, consultée le 26/10/2026). La base de données est toujours PostgreSQL.

Cette façon de construire par la conversation porte un nom : le vibe coding. On décrit l’intention, l’IA écrit le code, on juge le résultat à l’écran plutôt que ligne par ligne. Lovable est un des outils les plus accessibles pour pratiquer cette méthode quand on n’est pas développeur.

Si vous voulez une présentation plus courte de l’outil, nous avons écrit un article dédié : Lovable, c’est quoi ?.

Que fait bien Lovable, et que fait-il mal ?

Nous préférons commencer par les limites. C’est ce qui vous évitera de perdre des semaines sur un projet qui n’est pas fait pour cet outil.

Quelques précisions, toutes tirées de la documentation officielle consultée le 26/10/2026 :

• Mobile : Lovable construit des applications web, pas des applications natives. Il ne génère pas de projet React Native.
• Framework : impossible de choisir Next.js ou une autre technologie. Si vous en avez besoin, il faut synchroniser le code avec GitHub et le reprendre ailleurs.
• Sécurité : les scans intégrés repèrent des problèmes courants. La page Security overview précise qu’ils ne remplacent pas une revue de sécurité complète. Pour des données sensibles, la documentation recommande une revue professionnelle.

Ce que nous constatons en pratique : Lovable est très bon pour passer d’une idée floue à quelque chose de cliquable. Il devient plus exigeant quand l’application grossit. C’est là que la méthode compte plus que l’outil.

Combien coûte Lovable pour apprendre ?

Lovable fonctionne avec des crédits. Un crédit est l’unité qui mesure votre usage : construire, discuter avec l’IA, héberger l’application, faire tourner sa base de données. Tous les chiffres de cette section viennent des pages Subscription plans et Credits and usage de la documentation Lovable, consultées le 26/10/2026.

Les plans Free, Pro et Business reçoivent aussi chaque mois 20 crédits pour l’hébergement et la base de données, et 4 crédits pour les fonctions d’IA de l’application publiée.

Ce qu’un crédit achète varie. La documentation donne des exemples indicatifs : « rendre le bouton gris » a coûté 0,50 crédit, « ajouter l’authentification » 1,20 crédit, « construire une page d’accueil avec images » 2 crédits. Un message en mode Plan coûte 1 crédit, plus les recherches que Lovable lance pour planifier.

Deux règles utiles :

• Les crédits mensuels d’un plan payant expirent deux mois après leur émission.
• Les crédits achetés en recharge restent valables douze mois.

Pour apprendre, nous conseillons de commencer sur le plan gratuit. Il permet de tester la méthode sur un petit projet. Il oblige aussi à écrire des demandes précises, ce qui est une bonne école. Le détail des plans, des recharges et des pièges est dans notre article Lovable : prix et crédits.

Attention : Lovable change ses prix et ses quotas régulièrement. La documentation signale elle-même que certaines allocations sont temporaires. Vérifiez la page tarifs avant de payer.

Comment passer d’une idée à une application en ligne ?

Voici le parcours complet, dans l’ordre où nous le pratiquons. Chaque étape a sa section plus bas.

1. Cadrer l’idée : qui utilise l’outil, pour faire quoi, avec quelle action principale.
2. Décrire le premier écran dans un prompt, avec des données d’exemple.
3. Itérer par petites demandes, en testant à chaque fois.
4. Ajouter la base de données quand les informations doivent être conservées.
5. Ajouter la connexion quand plusieurs personnes utilisent l’outil.
6. Publier sur une adresse en ligne.
7. Brancher un nom de domaine et GitHub si le projet dure.

Pour illustrer, nous prenons un exemple fictif tout au long de ce guide : un outil de devis interne pour une petite entreprise de rénovation. Le gérant veut que ses deux chefs de chantier saisissent un devis depuis leur téléphone, à partir d’un catalogue de prestations. Le devis doit être enregistré et retrouvable. C’est un exemple, pas un cas client.

La version pas à pas, avec captures et prompts, est dans Créer une application avec Lovable.

Comment cadrer son idée avant le premier prompt ?

La documentation de Lovable conseille de passer environ quinze minutes à répondre à quatre questions avant d’écrire quoi que ce soit (guide How to build a real product, consulté le 26/10/2026) :

1. Qu’est-ce que ce produit ?
2. Pour qui est-il ?
3. Pourquoi ces personnes vont-elles l’utiliser ?
4. Quelle est la seule action clé qu’un utilisateur doit accomplir ?

Pour notre outil de devis, cela donne :

• Produit : un outil pour créer un devis à partir d’un catalogue.
• Pour qui : les chefs de chantier, sur le terrain.
• Pourquoi : aujourd’hui, ils notent sur papier et le gérant ressaisit le soir.
• Action clé : créer un devis en choisissant des lignes du catalogue.

La même documentation recommande de garder une première version minuscule : un utilisateur, une action, un résultat. Les relances, l’envoi par email et la signature viendront après. Une première demande qui veut tout coûte plus cher et donne un résultat moins net.

Un conseil que nous appliquons toujours : racontez une histoire plutôt qu’une liste de fonctions. « Karim est chef de chantier, il est chez un client, il veut sortir un devis en cinq minutes. » Lovable comprend mieux le contexte, le ton et les priorités.

Comment écrire un bon prompt Lovable ?

Le chat d’un projet Lovable a trois modes. Les connaître change beaucoup la qualité du résultat (documentation Lovable, pages Chat mode, Plan mode et Build mode, consultées le 26/10/2026).

Un bon prompt de modification contient trois éléments, selon le guide Prompting best practices de Lovable :

1. Ce qu’il faut construire.
2. Où cela va.
3. Ce qui ne doit pas bouger.

Exemple pour notre outil de devis :

Ajoute un filtre par statut (brouillon, envoyé, accepté) dans la liste des devis. Modifie uniquement la page Devis. Garde le style actuel du tableau et ne touche pas au reste de l’application.

La dernière phrase est la plus importante. Sans limite, une petite demande peut modifier des parties qui marchaient.

Autre technique recommandée par la documentation : demander à Lovable de vous poser des questions avant de coder. Ajoutez à la fin de votre demande : « Pose-moi les questions dont tu as besoin pour bien comprendre ce que je veux. » En mode Plan, cela fonctionne particulièrement bien.

Enfin, donnez une mémoire au projet. Lovable propose un champ Knowledge (connaissances du projet), toujours inclus dans le contexte. Mettez-y une page de brief : à quoi sert l’outil, pour qui, les parcours principaux, le ton visuel, et ce que Lovable a tendance à rater. Vous pouvez même lui demander de rédiger cette page à partir de ce qui existe déjà.

Notre bibliothèque de prompts testés est dans Prompts Lovable.

Comment itérer sans tout casser ?

L’itération est le cœur de l’apprentissage. C’est aussi là que se perdent la plupart des crédits.

L’historique des versions est votre filet. Chaque modification crée une version automatiquement (page Version history, consultée le 26/10/2026). Vous pouvez revoir une version, revenir en arrière, et marquer d’un favori une version qui fonctionne. Nous marquons une version après chaque fonctionnalité qui marche. Quand une modification part dans le mauvais sens, nous revenons au dernier favori.

Une limite à connaître : revenir en arrière restaure le code, pas les données de votre base. La documentation le précise dans son guide de construction.

Quand quelque chose casse, la documentation de Lovable propose cet ordre (page Debug and improve your app, consultée le 26/10/2026) :

1. Cliquer sur « Try to fix » une ou deux fois. Selon la documentation de Lovable, votre compte dispose de 10 corrections gratuites, chacune redevient disponible 24 heures après usage.
2. Décrire le bug précisément : ce qui est cassé, où, ce que vous attendiez, ce qui s’est passé. Ajoutez une capture d’écran ou le message d’erreur.
3. Passer en mode Plan pour trouver la cause, au lieu d’enchaîner les corrections à l’aveugle.
4. Revenir à une version qui marchait si les corrections ont emmêlé le code.

Un prompt du type « rien ne marche, répare » ne sert à rien. La documentation donne un meilleur exemple, que nous traduisons : « L’écran devient blanc quand j’ouvre la page Projets, et je ne peux plus rien modifier. Peux-tu vérifier ce qui s’est passé ? »

Tester comme un utilisateur. Le guide de Lovable propose une vérification en cinq points que nous reprenons telle quelle : l’affichage de chaque page (y compris vide), chaque bouton et chaque formulaire (y compris avec de mauvaises saisies), la conservation des données après rafraîchissement, l’accès avec un deuxième utilisateur, et l’affichage en taille téléphone.

Comment stocker des données avec Supabase ou le backend intégré ?

Tant que vous travaillez avec des données d’exemple, rien n’est enregistré. Rafraîchissez la page, le devis disparaît. Il faut une base de données.

Lovable propose deux options (pages Built-in backend et Connect to Supabase, consultées le 26/10/2026) :

Le backend intégré repose sur la base open source de Supabase. Il est activé par défaut. Quand vous demandez une fonction qui en a besoin, Lovable l’active seul ou vous demande votre accord. Il comprend une base de données, des comptes utilisateurs, un stockage de fichiers et des fonctions côté serveur.

Point important : on ne passe pas automatiquement de l’un à l’autre. La documentation recommande de décider tôt. Pour apprendre, le backend intégré suffit. Nous ne conseillons un Supabase personnel que si vous voulez posséder votre infrastructure ou en avez déjà une.

Pour notre outil de devis, la demande ressemblerait à ceci :

Enregistre les devis dans la base de données : client, adresse du chantier, lignes de prestations, quantités, prix unitaires, total, statut et date. Relie le formulaire pour qu’il enregistre de vrais devis et les affiche dans la liste. Prévois les états vide, chargement et erreur.

La documentation propose un test simple : ouvrez l’application dans deux onglets, créez un devis dans l’un, rafraîchissez l’autre. S’il apparaît, la base fonctionne.

Le détail des tables, des permissions et du choix entre les deux options est dans Lovable et Supabase.

Comment ajouter une connexion utilisateur ?

Dès que plusieurs personnes utilisent l’outil, il faut des comptes. Demandez simplement à Lovable d’ajouter une connexion. Selon la page Users and authentication (consultée le 26/10/2026), il génère les pages d’inscription et de connexion et protège les données des utilisateurs. Sans précision de votre part, il met en place l’email avec mot de passe, la connexion Google et « Sign in with Lovable ». Précisez si vous ne voulez que l’email.

La protection repose sur la sécurité au niveau des lignes (RLS, pour row level security). Définition courte : ce sont des règles dans la base qui décident qui peut lire ou modifier chaque ligne. Exemple : un chef de chantier ne voit que ses propres devis, le gérant voit tout.

La documentation de Lovable insiste sur trois vérifications avant publication (Security best practices, consultée le 26/10/2026) : la RLS est active sur toutes les tables sensibles, un utilisateur ne peut pas accéder aux données privées d’un autre, et chaque nouvelle table a bien ses règles. Lovable crée des règles de base, mais il faut les relire.

Le test que nous faisons systématiquement : créer deux comptes, se connecter avec le premier, créer un devis, puis vérifier que le second ne le voit pas. Cinq minutes qui évitent une fuite de données.

Comment publier son application et la mettre sur un nom de domaine ?

Publier prend deux clics, selon la page Publish de la documentation (consultée le 26/10/2026). Vous cliquez sur Publish en haut à droite, Lovable propose une adresse en lovable.app, lance un scan de sécurité rapide, puis met l’application en ligne. L’hébergement et le HTTPS sont inclus. La FAQ précise que publier sur une adresse lovable.app est gratuit sur tous les plans.

Ce qu’il faut savoir :

• Seule la version publiée est visible. Vous pouvez continuer à modifier dans l’aperçu. Vos utilisateurs ne verront les changements qu’après Publish changes.
• Vous choisissez qui voit l’application. Sur les plans Free et Pro, vous pouvez la réserver à des personnes invitées, jusqu’à 10 par projet (page Subscription plans, consultée le 26/10/2026).
• Le nom de domaine personnalisé est réservé aux plans payants. Vous pouvez en acheter un depuis Lovable ou connecter un domaine que vous possédez déjà.

Pour un outil interne comme notre outil de devis, l’adresse lovable.app et un accès sur invitation suffisent souvent. Le domaine personnalisé devient utile quand l’application est vue par des clients.

La procédure complète, DNS compris, est dans Publier une application Lovable.

Faut-il connecter GitHub quand on débute ?

Ce n’est pas obligatoire. La documentation le dit clairement : beaucoup d’utilisateurs construisent et publient sans jamais toucher à Git.

La synchronisation Git (GitHub, GitLab ou Bitbucket) est disponible sur tous les plans (page Subscription plans, consultée le 26/10/2026). Elle fonctionne dans les deux sens : ce que Lovable modifie est envoyé dans votre dépôt, et ce qu’un développeur pousse dans le dépôt revient dans Lovable.

Nous la conseillons dans trois situations :

• Garder une copie du code hors de Lovable, sur un compte que vous contrôlez.
• Travailler avec un développeur, qui pourra intervenir avec ses propres outils.
• Quitter Lovable un jour, pour héberger l’application ailleurs.

Une précision qui surprend souvent : Lovable crée un nouveau dépôt pour votre projet. Selon la FAQ, on ne peut pas connecter un dépôt existant à un projet. Pour reprendre du code existant, il faut passer par l’import d’un fichier ZIP.

Quelles sont les erreurs les plus fréquentes quand on débute ?

Ces erreurs reviennent dans les recommandations de la documentation Lovable, et nous les voyons aussi dans nos propres projets.

1. Tout demander dans le premier prompt. Résultat : un écran confus et des crédits brûlés. Commencez par une seule action.
2. Brancher la base de données trop tôt. La documentation conseille de construire d’abord l’interface avec des données d’exemple, puis de connecter la base quand le produit est juste.
3. Ne pas dire ce qui ne doit pas bouger. Chaque demande doit préciser son périmètre.
4. Enchaîner les « répare » à l’aveugle. Après deux échecs, passez en mode Plan pour trouver la cause.
5. Oublier les favoris de version. Sans point de retour connu, un bug ancien devient très difficile à localiser.
6. Publier sans tester avec deux comptes. C’est le test le plus simple pour vérifier la sécurité des données.
7. Mettre une clé d’API dans le code de l’interface. Les clés vont dans les secrets du backend, jamais dans le code visible par le navigateur.
8. Ignorer le style au départ. La documentation recommande de donner la direction visuelle dès les premiers prompts. Corriger le style de toute une application après coup coûte plus cher.

Quand vaut-il mieux utiliser autre chose que Lovable ?

Lovable n’est pas le bon choix dans tous les cas. Voici les situations où nous regardons ailleurs.

Les autres outils se rangent en deux familles. D’un côté, des outils proches de Lovable, qui construisent une application depuis un prompt dans le navigateur, comme Bolt. De l’autre, des assistants qui travaillent directement dans le code, comme Cursor ou Claude Code. Les seconds demandent plus de bases techniques, mais laissent plus de liberté.

Bonne nouvelle si vous changez d’avis : la FAQ de Lovable (consultée le 26/10/2026) indique qu’on peut importer un projet venu d’autres outils sous forme de ZIP. Et dans l’autre sens, la synchronisation Git permet de reprendre son code ailleurs.

La comparaison détaillée est dans Lovable vs Bolt, Cursor et Claude Code.

Par où commencer : quel parcours d’apprentissage suivre ?

Voici le parcours que nous recommandons à quelqu’un qui n’a jamais codé. Il tient en quatre semaines, à raison de quelques sessions courtes par semaine. C’est notre conseil, pas une norme.

Semaine 1 : comprendre et faire un premier écran.

1. Créez un compte gratuit.
2. Suivez le guide de démarrage officiel jusqu’à la publication.
3. Choisissez un vrai problème de votre activité, petit et répétitif.
4. Répondez aux quatre questions de cadrage.

Semaine 2 : apprendre à piloter.

1. Construisez l’interface de votre outil avec des données d’exemple.
2. Utilisez le mode Plan pour chaque changement important.
3. Écrivez la page Knowledge du projet.
4. Marquez une version favorite après chaque étape qui marche.

Semaine 3 : rendre l’outil réel.

1. Ajoutez la base de données et vérifiez avec deux onglets.
2. Ajoutez la connexion et faites le test des deux comptes.
3. Lancez un scan de sécurité et lisez les résultats.

Semaine 4 : mettre en ligne et entretenir.

1. Publiez, d’abord sur invitation.
2. Faites utiliser l’outil par une vraie personne et notez ce qui bloque.
3. Corrigez à partir de ce que vous observez, pas de ce qui semble amusant à ajouter.
4. Connectez GitHub si le projet doit durer.

À la fin de ce parcours, vous saurez construire et maintenir un outil interne simple. Le reste vient avec les projets suivants. Chaque article lié dans ce guide détaille une étape : commencez par celle qui vous bloque aujourd’hui.