Comment bien utiliser Lovable : le guide 2026

Petite question avant de commencer : tu sais sur quoi tourne la page que tu es en train de lire ?

Sur Lovable. Ce site était sur Framer jusqu'au 24 juillet 2026. Je l'ai migré, et depuis, il a encaissé 136 commits et porte 47 articles, avec du rendu serveur, une base Supabase et une synchro GitHub. Ce n'est pas une démo faite un dimanche après-midi pour écrire un article, c'est l'outil sur lequel je gagne ma vie.

C'est aussi pour ça que ce que tu vas lire ne ressemble pas aux autres articles sur Lovable. Je ne vais pas te réciter la page de tarifs. Je vais te dire où j'ai cramé des crédits pour rien, quel choix se fait au début et jamais après, et comment je fais tourner ce site sans consommer un seul crédit Lovable.

À quoi sert Lovable, concrètement

Lovable transforme une description en application web qui fonctionne. Tu écris ce que tu veux en français, l'IA génère le code, l'héberge, et te donne une URL en ligne.

Ce que tu récupères n'est pas une maquette : c'est du React avec du TypeScript et du Tailwind, du vrai code que tu peux ouvrir, lire et modifier. C'est la différence avec un Webflow ou un Framer, où tu restes prisonnier de l'éditeur.

Trois familles de projets sortent bien de Lovable, et j'y reviens en détail plus bas parce qu'elles ne se pilotent pas du tout pareil :

• Un site vitrine ou une landing page : le cas le plus simple, celui où Lovable est imbattable en rapport temps passé sur résultat
• Un SaaS ou un micro-SaaS : il te faut des comptes utilisateurs, une base de données, des paiements. Lovable sait faire, mais les décisions techniques comptent
• Un outil interne : le CRM maison, le suivi de production, le tableau de bord d'équipe. C'est là que le rapport valeur sur effort est le plus violent

Le point commun : tu n'as pas besoin de savoir coder pour démarrer. Tu as besoin de savoir ce que tu veux, ce qui est une compétence différente et beaucoup plus rare.

Ce que Lovable fait vraiment bien

Après un mois de production quotidienne, voilà ce qui tient réellement ses promesses.

La vitesse du premier jet. Une landing page correcte en dix minutes, une application avec authentification et base de données en une soirée. Ce n'est pas du marketing, c'est mon expérience. Le gain n'est pas sur le code, il est sur tout ce qu'on ne fait pas : configurer un projet, choisir des librairies, câbler un déploiement.

Le code t'appartient et il est propre. React, TypeScript, Tailwind, shadcn/ui. Des choix standards, pas une techno propriétaire. Tu peux partir avec.

La synchro GitHub est bidirectionnelle et sur tous les plans. La documentation est explicite : "Changes made in Lovable sync to GitHub" et "Changes pushed to the active GitHub branch sync back into Lovable". C'est le pilier de tout ce que je raconte dans la section sur Claude, et c'est disponible même sur le plan gratuit.

Le déploiement est intégré. Pas de Vercel à configurer, pas de DNS à comprendre. Tu cliques sur Publish, c'est en ligne.

L'interface existe en français. Onze langues au sélecteur, dont le français. Et surtout, tu peux prompter en français sans dégrader le résultat, ce qui n'est pas vrai partout.

Ce que Lovable fait mal

Autant le dire franchement, parce que c'est ce qui te fera gagner du temps.

Il génère du générique si tu le laisses faire. Un prompt vague donne une page qui ressemble à toutes les pages générées par IA : le même dégradé, la même grille de trois cartes, la même section témoignages. Le remède est dans la section prompting plus bas.

Il casse ce qu'il a réparé. Sur un projet qui grossit, une demande mal bornée fait bouger trois fichiers que tu n'avais pas demandé de toucher. Chaque prompt doit dire ce qui ne doit pas changer.

Le compteur tourne pendant que tu explores. Chaque message consomme, y compris ceux où tu cherches. C'est le poste de dépense que personne n'anticipe.

Le SEO n'est pas automatique. Sur un site de contenu, il faut réclamer explicitement le rendu serveur, les balises, le sitemap, les données structurées. Lovable ne les met pas tout seul.

Le débogage plafonne. Sur un bug tordu, tu peux enchaîner cinq prompts sans avancer, et tu auras payé les cinq. À partir de là, mieux vaut sortir du chat, ce que j'explique dans la partie GitHub.

Le plan gratuit de Lovable : ce qu'on peut vraiment en faire

Le plan gratuit est à 0 dollar et ne demande pas de carte bancaire. Il donne, en dotations mensuelles :

• 5 crédits de build par jour, plafonnés à 30 par mois
• 20 crédits Cloud par mois pour faire tourner le backend intégré
• 4 crédits IA par mois pour les fonctions d'intelligence artificielle de ton application publiée
• 5 domaines en lovable.app, des projets privés et un nombre illimité de collaborateurs

Traduction pratique. 30 crédits de build par mois, c'est une landing page bien faite, ou une petite application testée sérieusement. Ce n'est pas un SaaS.

Ce que le plan gratuit ne donne pas et qui compte : le nom de domaine personnalisé. Il est réservé aux plans payants. Tu peux donc tout construire gratuitement, mais pas brancher ton monentreprise.fr dessus.

Mon conseil : reste en gratuit tant que tu explores. Le jour où tu sais quoi construire, tu passes en payant, et pas avant.

Les plans payants et le vrai prix des crédits

Le Pro démarre à 25 dollars par mois pour 100 crédits, le Business à 50 dollars pour 100 crédits. L'annuel offre deux mois. Les crédits non consommés se reportent sur un mois.

Ce que le Pro ajoute par rapport au gratuit : les domaines personnalisés, le retrait du badge Lovable, les rôles et permissions, les limites de crédits par membre, les recharges à la demande. Le Business ajoute l'espace de travail d'équipe, le SSO, le centre de sécurité et la publication interne.

Les trois choses qui consomment tes crédits

C'est le point que presque personne n'explique, et c'est celui qui décide de ta facture. Lovable utilise un solde unique pour trois usages différents :

• Le build : chaque message où tu demandes à Lovable de planifier, générer ou modifier ton application
• Le Cloud : l'hébergement et le backend intégré de ton application déployée, une fois qu'elle vit
• La passerelle IA : les appels aux modèles que ton application publiée fait tourner pour ses propres utilisateurs

Autrement dit, le trafic de ton application mange le budget avec lequel tu la construis. Retiens cette phrase, c'est le cœur de la section suivante.

Combien coûte un prompt

Lovable publie des exemples officiels de consommation en mode Build :

La documentation précise que ces chiffres sont "illustrative examples" et que la consommation réelle varie selon la complexité. Deux choses à savoir en plus, qui ne sont pas dans les articles habituels :

• Le mode Plan coûte 1 crédit fixe par message et ne modifie jamais ton code. C'est le mode où tu réfléchis, tu compares des approches, tu fais préparer un plan
• Une requête que tu interromps est facturée au travail déjà fait. Arrêter ne rembourse pas

Les paliers de crédits

Si 100 crédits ne suffisent pas, les paliers montent, et le prix au crédit reste stable avant de baisser légèrement en volume.

Les recharges ponctuelles, elles, coûtent plus cher : 15 dollars les 50 crédits en Pro, soit 0,30 dollar l'unité contre 0,25 dans l'abonnement, et 30 dollars les 50 en Business. Elles restent valables douze mois. Si tu recharges tous les mois, change de palier, tu paies une surtaxe pour rien.

Lovable Cloud ou ton propre Supabase : le choix à ne pas rater

Voilà la décision la plus importante de ton projet, et elle se prend au début.

Lovable Cloud est le backend intégré : base de données, authentification, stockage, temps réel, fonctions. Il repose sur la brique open source de Supabase, mais géré par Lovable et facturé en crédits.

L'alternative est de connecter ton propre projet Supabase, que tu paies directement à Supabase.

Ce qui change vraiment

Le tableau dit l'essentiel, mais il faut le formuler franchement : Lovable ne publie aucun tarif à l'unité pour le Cloud. La documentation liste ce qui consomme (taille de l'instance, stockage, réseau, calcul, temps réel) sans donner un prix au gigaoctet ni à la requête. Supabase publie tout.

Tant que ton application a trois utilisateurs, ça n'a aucune importance. Le jour où elle prend du trafic, la consommation Cloud vient piocher dans le même solde que ton build. Tu te retrouves à ne plus pouvoir modifier ton application parce que ses visiteurs ont mangé tes crédits. C'est un mode de panne que l'abonnement Supabase séparé n'a tout simplement pas.

Pourquoi il n'y a pas de retour en arrière

Le point qui rend ce choix définitif, et que j'ai vu écrit nulle part en français. La documentation Lovable est catégorique : "There is no one-click migration from the built-in backend (Cloud) to Supabase or the other way."

Aucune migration automatique, ni dans un sens, ni dans l'autre. Changer d'avis veut dire exporter tes données à la main, rebrancher, et reconstruire ton schéma.

Ma règle, simple :

• Prototype, démo, outil interne à cinq personnes : Lovable Cloud, sans hésiter. La simplicité vaut largement l'opacité tarifaire
• Tout ce qui a vocation à recevoir du trafic ou des clients : ton propre Supabase, dès le premier jour

Une nuance honnête pour finir : certaines fonctions de Lovable exigent le Cloud, notamment les paiements intégrés, les emails personnalisés et l'authentification gérée type Google ou SAML. Si ton projet en dépend, le choix est fait pour toi.

Site vitrine, SaaS ou outil interne : trois usages, trois façons de piloter

Même outil, trois pilotages qui n'ont rien à voir.

Le site vitrine. Ton ennemi est le rendu générique et le SEO absent. Tu prompts section par section, jamais la page entière. Tu réclames explicitement le rendu serveur, les balises title et description par page, le sitemap et les données structurées. Tu n'as pas besoin de backend : pas de Cloud, pas de Supabase, donc pas de consommation qui court. C'est exactement ce que fait ce site.

Le SaaS ou le micro-SaaS. Ton ennemi est la dette technique invisible. Tu as des utilisateurs, donc de l'authentification, donc des données à protéger. La documentation le martèle et j'insiste : "Before going live, make sure every table has Row Level Security policies". Sans ces règles, ta base est ouverte. Ici, Supabase externe, sans discussion.

L'outil interne. Ton ennemi est de vouloir trop bien faire. Cinq utilisateurs qui connaissent l'outil, ça n'a pas besoin d'être beau ni parfait. Lovable Cloud, publication interne réservée aux membres de l'espace de travail, et tu passes à autre chose. C'est le meilleur rapport valeur sur temps de toute la plateforme.

Créer son premier projet, étape par étape

La partie que tu es venu chercher. Voilà l'ordre dans lequel je procède, et pourquoi.

1. Écris ton brief avant ton premier prompt

Le réflexe qui fait la différence entre un projet propre et trois heures perdues. Avant d'ouvrir Lovable, réponds à quatre questions, celles que Lovable recommande lui-même :

• Qu'est-ce que ce produit ?
• Pour qui ?
• Pourquoi vont-ils s'en servir ?
• Quelle est la seule action que l'utilisateur doit faire ?

Cinq lignes suffisent. C'est ce document qui empêche l'IA de partir dans son générique habituel.

2. Passe en mode Plan avant de laisser Lovable coder

Le mode Plan coûte 1 crédit par message et ne touche pas ton code. Le mode Build coûte selon la complexité et modifie tout.

Donc : tu réfléchis en mode Plan, tu construis en mode Build. Et le premier message du mode Plan, celui que je tape systématiquement :

Pose-moi toutes les questions dont tu as besoin pour comprendre exactement ce que je veux, avant d'écrire la moindre ligne de code.

Trois crédits de réflexion t'économisent dix crédits de corrections.

3. Choisis ton backend maintenant

Relis la section plus haut. Ce choix ne se refait pas. Si tu hésites, pose-toi une seule question : est-ce que des inconnus vont utiliser cette application ? Si oui, Supabase.

Et si tu n'as pas besoin de comptes utilisateurs ni de base de données, ne branche aucun backend. Beaucoup de projets démarrent avec un Cloud allumé pour rien, qui consomme pour rien.

4. Branche tes connecteurs

Les connecteurs relient ton application à tes outils, Slack, HubSpot, Google Sheets et le reste du catalogue, avec la même connexion utilisable pendant la construction et dans l'application publiée.

On les branche une fois dans l'espace de travail, puis on demande simplement dans le chat, en français : connecte Slack à ce projet et poste un message dans tel canal quand quelqu'un crée un compte.

Ne les branche qu'au moment où tu en as besoin. Un connecteur configuré trop tôt est un connecteur qu'il faudra reconfigurer.

5. Mets ton nom de domaine

Réservé aux plans payants. Deux chemins : tu achètes le domaine directement depuis Lovable, dans Projet puis Réglages puis Domaines, ou tu branches un domaine que tu possèdes déjà ailleurs.

Acheter depuis Lovable évite la configuration DNS, ce qui est un vrai confort si tu n'as jamais touché à un enregistrement CNAME. Passer par ton registrar habituel garde tous tes domaines au même endroit. Les deux marchent, et les prix affichés par Lovable sont en dollars, les domaines premium coûtant plus cher.

6. Publie, puis sécurise

Tu cliques sur Publish, c'est en ligne. Mais avant d'envoyer le lien à qui que ce soit, deux vérifications :

• Les règles de sécurité au niveau des lignes, si tu as une base de données. Chaque table doit dire qui a le droit de lire et d'écrire quoi. C'est le point sur lequel des applications entières fuitent
• Le contenu réel. Aucun texte d'exemple, aucune fausse photo, aucun témoignage inventé qui traîne

Connecter Lovable à Claude avec GitHub

On arrive à ce que je considère comme la meilleure façon d'utiliser Lovable, et celle dont personne ne parle.

Le workflow qui ne consomme aucun crédit

La synchro GitHub de Lovable est bidirectionnelle. Ce que tu modifies dans Lovable part sur GitHub, et ce que tu pousses sur la branche active revient dans Lovable. Elle est disponible sur tous les plans, plan gratuit compris.

Ce que ça ouvre : tu branches ton dépôt en local, et tu travailles avec Claude Code directement dans le code. Tu pousses, Lovable synchronise, tu publies.

Le jour où j'écris cet article, j'ai poussé sept commits sur ce site de cette façon. Consommation Lovable : zéro crédit. Le code a été écrit hors de Lovable, Lovable n'a fait que synchroniser et héberger.

Quand utiliser quoi, en pratique :

• Lovable pour partir de zéro, poser une page, une maquette, une structure. C'est là qu'il est imbattable
• Claude Code pour tout ce qui est précis, répétitif ou tordu : refactoriser, corriger un bug qui résiste, appliquer un changement dans quinze fichiers, écrire un article dans le dépôt

Le bug qui te coûterait cinq prompts Lovable sans être résolu se règle en local sans dépenser un crédit. C'est aussi ce qui fait que tu peux rester sur un petit palier de crédits avec un vrai projet en production.

Un point de vigilance : Lovable ne synchronise qu'une branche à la fois. Travaille sur la branche connectée, ou tu chercheras longtemps pourquoi tes changements n'apparaissent pas.

Et avec ChatGPT, Codex ou un autre agent

Rien de tout ça n'est propre à Claude. Le mécanisme, c'est GitHub, pas l'IA. N'importe quel agent capable de travailler dans un dépôt local entre dans le même circuit : Codex d'OpenAI, Cursor, ou l'assistant que tu préfères.

J'utilise Claude Code parce que je le trouve meilleur sur le code existant et parce que ses Skills me permettent de lui apprendre mes conventions une fois pour toutes. Mais le schéma reste : Lovable héberge et publie, ton agent écrit, GitHub fait le pont.

Mes tips

Ce que j'aurais aimé qu'on me dise le premier jour.

• Un prompt, un changement. Trois demandes dans un message donnent trois résultats moyens et une régression
• Dis toujours ce qui ne doit pas bouger. « Ne touche pas au header ni aux styles globaux » évite la moitié des dégâts
• Épingle une version qui marche dès que tu en tiens une. L'historique existe, sers-t'en avant de tenter un gros changement
• Regarde le coût réel de chaque réponse. Le menu à trois points sous une réponse affiche ce qu'elle a coûté. Trois jours à regarder ça et tu sais où part ton argent
• Donne du vocabulaire visuel. Des mots comme minimal, éditorial, premium ou cinématographique pilotent vraiment la typographie et les couleurs. « Fais joli » ne pilote rien
• Ne demande jamais une page entière d'un coup. Section par section. Une demande globale donne du bruit, une demande ciblée donne du signal
• Mets tes vrais textes tout de suite. Le faux contenu oriente le design vers du générique et il faudra tout reprendre
• Configure le seuil d'alerte des longues requêtes. Il est à 20 crédits par défaut : sur un gros chantier, Lovable te demande si tu continues avant de creuser plus loin

FAQ

Lovable est-il gratuit ?

Oui, il existe un plan gratuit à 0 dollar, sans carte bancaire, avec 5 crédits de build par jour plafonnés à 30 par mois, 20 crédits Cloud et 4 crédits IA mensuels. Tu peux construire et publier sur une adresse en lovable.app. En revanche, brancher ton propre nom de domaine demande un plan payant.

Combien coûte Lovable par mois ?

Le plan Pro démarre à 25 dollars par mois pour 100 crédits, le Business à 50 dollars. Les paliers montent jusqu'à 10 000 crédits pour 2 250 dollars en Pro. L'engagement annuel offre deux mois. Le vrai coût dépend surtout de ta façon de prompter et du trafic de ton application, puisque l'hébergement puise dans le même solde.

Est-ce que Lovable fonctionne en français ?

Oui. L'interface est disponible en français parmi onze langues, et tu peux décrire ton projet en français dans le chat sans perte de qualité. La documentation technique, elle, reste en anglais.

Peut-on récupérer le code généré par Lovable ?

Oui, et c'est un de ses vrais atouts. Le code est du React, du TypeScript et du Tailwind standard, et la synchro GitHub te le donne en clair sur ton propre dépôt, sur tous les plans. Tu n'es pas enfermé.

Lovable ou Claude Code, lequel choisir ?

Ce n'est pas un choix, c'est une répartition. Lovable pour créer et publier vite, Claude Code pour travailler dans le code existant sans consommer de crédits. GitHub relie les deux, et c'est comme ça que je fais tourner ce site.

Faut-il prendre Lovable Cloud ou son propre Supabase ?

Lovable Cloud pour un prototype, une démo ou un outil interne. Ton propre Supabase dès que des inconnus vont utiliser ton application, parce que sa tarification est publiée à l'unité et qu'elle ne vient pas manger tes crédits de développement. Et surtout : décide au début, il n'existe aucune migration automatique entre les deux.

Peut-on faire du SEO avec Lovable ?

Oui, mais rien n'est automatique. Il faut demander explicitement le rendu serveur, les balises title et description par page, le sitemap et les données structurées. Ce site en est la preuve : il est sur Lovable et il se positionne.

Conclusion

Lovable n'est pas magique, et c'est une bonne nouvelle. C'est un outil qui écrase le coût du démarrage et qui te rend du vrai code, à condition de prendre trois décisions correctement : réfléchir avant de prompter, choisir ton backend dès le premier jour, et sortir du chat quand le chat n'est plus le bon endroit.

Si tu ne retiens qu'une chose, prends celle-ci : branche GitHub tout de suite, même si tu ne comptes pas t'en servir. C'est gratuit, c'est sur tous les plans, et c'est ce qui fait la différence entre un outil que tu subis et un outil dont tu es propriétaire.

Et si tu te demandes toujours à quoi ressemble un vrai site construit comme ça, tu es dessus depuis le début.