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 en sortent bien, et elles ne se pilotent pas 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

Dans les trois cas, tu n'as pas besoin de savoir coder pour démarrer.

Les avantages de Lovable

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.

Les inconvénients de Lovable

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.

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 de base est là, le SEO sérieux non. Lovable gère les fondations techniques tout seul, et il a même une revue intégrée que je détaille plus bas. Mais sa propre documentation le reconnaît : "strong SEO and AEO still require intentional review and iteration". Sur un site de contenu, tu passeras du temps dessus.

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 prix de Lovable en 2026

Quatre paliers publics, Free, Pro, Business et Enterprise, plus un cinquième qui n'apparaît nulle part et dont je parle plus bas. Le vrai sujet n'est pas le tarif affiché, c'est ce que consomment tes crédits.

Le plan gratuit de Lovable

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.

Si tu veux essayer, t'inscrire par ce lien te donne 10 crédits en plus des dotations habituelles. C'est mon lien de parrainage : tu récupères les crédits, et j'en touche de mon côté seulement si tu passes un jour à un plan payant. Ça ne te coûte rien de plus, et tu sais maintenant d'où je parle.

Les plans payants : Pro et Business

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.

Le plan Lovable Lite offert avec Revolut

Une porte d'entrée que Lovable n'affiche nulle part, et qui vaut le détour si tu es déjà client Revolut.

Les comptes Premium, Metal et Ultra donnent droit à 12 mois d'abonnement Lovable Lite plus 100 crédits offerts en une fois. Ça se réclame dans l'application Revolut : icône de profil, Your plan, puis See all dans les avantages, puis Lovable. Au bout des 12 mois, le compte bascule automatiquement en gratuit.

Trois conditions à connaître : l'offre n'existe que dans certains pays, elle se perd si tu résilies ton plan Revolut, et elle ne se réclame qu'une fois par plan. Si tu as déjà un abonnement Lovable en cours, il faut attendre qu'il se termine pour l'activer.

Le point que je ne peux pas trancher, et je préfère le dire : Lovable ne documente pas ce que contient exactement le plan Lite. Il n'apparaît ni sur la page de tarifs, ni dans la documentation, c'est un palier réservé aux partenaires. Vérifie ce que tu obtiens au moment de l'activer plutôt que de te fier à ce qui traîne sur le web.

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.

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 Supabase : lequel choisir ?

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.

Comment passer de Lovable Cloud à Supabase ?

C'est la question que j'entends le plus souvent une fois le projet lancé, et la réponse tient en deux temps.

Il n'existe aucun bouton pour le faire. La documentation Lovable est catégorique : "There is no one-click migration from the built-in backend (Cloud) to Supabase or the other way." Ni dans un sens, ni dans l'autre.

Et non, remixer le projet ne sert à rien ici, contrairement à ce qu'on imagine. Un remix copie le code et la structure des tables, mais pas les données, pas les secrets, pas les connecteurs, pas les domaines. Et il te laisse sur le même type de backend. Tu obtiens un doublon vide, pas une migration.

La vraie procédure est manuelle, et la voici dans l'ordre.

1. Exporte ta base. Dans ton projet, va dans l'onglet Cloud, puis Overview, puis Advanced settings. Dans Export project data, clique sur Export data, puis sur Export dans la carte Database, et confirme avec Start export. Lovable t'envoie un mail quand c'est prêt et dépose le fichier dans le stockage du projet, à récupérer dans l'onglet Cloud puis Storage. L'export contient la structure et les données
2. Télécharge tes fichiers séparément. L'export de base n'inclut ni les fichiers du stockage, ni le code de tes edge functions, ni tes secrets. Il faut les récupérer à la main
3. Crée ton projet Supabase, recrée le schéma, importe les données
4. Rebranche Lovable dessus. On lie d'abord l'organisation Supabase dans Connectors, puis on connecte le projet via More puis Cloud
5. Refais ce qui n'a pas suivi : le code des edge functions, les secrets, les connecteurs
6. Supprime l'instance Cloud si tu ne veux plus la payer, dans Advanced settings puis Remove Lovable Cloud. Attention, c'est définitif : "Removing Lovable Cloud permanently deletes your Cloud instance and cannot be undone."

Trois limites à connaître avant de te lancer, parce qu'elles ne sont écrites nulle part en français :

• Les mots de passe ne sont pas exportés de façon utilisable. Tous tes utilisateurs devront réinitialiser le leur. Sur une application avec des comptes clients, ce n'est pas un détail, c'est une opération de communication
• L'export est plafonné à 5 Go, et tu n'as droit qu'à un export toutes les 24 heures
• La suppression de Cloud est irréversible. Fais l'export, vérifie que tu peux le relire, et seulement ensuite supprime

Autrement dit : c'est faisable, mais c'est un chantier d'une journée avec un risque réel sur tes comptes utilisateurs. D'où ma règle de la section précédente. Ce choix se fait au premier jour, pas au premier pic de trafic.

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.

Que peut-on créer avec Lovable ?

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

Le site vitrine. Tu prompts section par section, jamais la page entière, et tu réclames tes balises title et description page par page. Surtout, tu ne branches aucun backend : ni Cloud, ni Supabase, donc aucune consommation qui court pendant que le site vit. 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.

C'est aussi le terrain des Jobs, les tâches planifiées. Tu les crées en le demandant simplement dans le chat, du genre « programme un job tous les matins à 7 h qui m'envoie par mail le résumé des relances du jour ». Elles tournent sur le backend intégré, donc chaque exécution consomme du Cloud comme n'importe quel travail serveur : un job qui tourne toutes les cinq minutes coûtera nettement plus qu'un job quotidien. Le suivi se regarde dans Project usage.

Comment créer un site ou une application avec Lovable

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

Une seule question tranche : est-ce que des inconnus vont utiliser cette application ? Si oui, Supabase externe. Sinon, Cloud.

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

4. Branche tes connecteurs

Le catalogue compte 104 connecteurs au moment où j'écris, rangés par catégorie : 48 en productivité, 15 en marketing, 12 en vente, 11 chez Google, 10 en e-commerce, 9 en messagerie, 9 chez Microsoft, 3 chez AWS.

On y trouve les évidences, Gmail, Slack, Notion, Google Sheets, Stripe, Shopify, mais aussi des choses plus intéressantes pour un site de contenu : Google Search Console, Google Analytics, PostHog, Firecrawl, Resend. Et si le tien manque, un bouton Request existe, sinon Connect any API et les serveurs MCP personnalisés couvrent le reste.

Deux entrées de ce catalogue ne sont pas des intégrations tierces mais des briques de Lovable, et il vaut mieux le savoir : Cloud est le backend intégré dont je parlais plus haut, et AI est la passerelle qui fait tourner les modèles OpenAI et Google dans ton application publiée. Les activer consomme des crédits, pas les brancher.

On les branche une fois dans l'espace de travail, via Connectors, puis on demande en français dans le chat : connecte Slack à ce projet et poste un message dans le canal ventes quand quelqu'un remplit le formulaire. La même connexion sert pendant la construction et dans l'application publiée.

5. Mets ton nom de domaine

Réservé aux plans payants, et c'est l'étape où tout le monde bloque. Trois portes d'entrée mènent au même écran : Project puis Settings puis Domains, le bouton Add domain dans la fenêtre de publication, ou Workspace settings puis Workspace domains.

C'est ma propre page que tu vois ci-dessus, et elle illustre le piège numéro un. lorisgautier.fr est en Live, mais www.lorisgautier.fr affiche Not connected. Lovable traite le domaine nu et le sous-domaine www comme deux entrées distinctes : brancher l'un ne branche pas l'autre. Si tu ne connectes que le nu, les visiteurs qui tapent le www par réflexe tombent sur une erreur. Connecte les deux, ça se fait en un clic depuis cet écran.

Si tu achètes le domaine depuis Lovable, clique sur Buy new domain, cherche ton nom, choisis la durée d'enregistrement entre 1 et 10 ans, laisse le renouvellement automatique activé, remplis tes coordonnées ICANN et paie par Stripe. Lovable pose les enregistrements DNS et le certificat tout seul. Le statut passe de Pending à Live en quelques heures.

Si tu branches un domaine que tu possèdes déjà, clique sur Connect domain, entre ton domaine, puis choisis la configuration automatique via Entri ou la configuration manuelle. En manuel, tu crées deux enregistrements chez ton registrar :

Le certificat SSL est généré automatiquement et gratuitement, le HTTPS est actif dès la vérification. Compte quelques heures, jusqu'à 72 dans le pire des cas.

Trois pièges qui font perdre une soirée, et que j'ai tous croisés :

• Supprime tes anciens enregistrements AAAA et CNAME sur le même hôte. Ils entrent en conflit avec le A que tu viens de créer
• Si tu es chez Cloudflare, passe l'enregistrement en DNS only, le nuage gris. Avec le proxy orange activé, la vérification échoue sans message clair
• Si ton app a des comptes utilisateurs, mets à jour tes URL de redirection dans l'onglet Cloud puis Users puis Auth settings. Sinon la connexion Google renvoie tes utilisateurs sur l'ancienne adresse

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 :

• Lance un scan de sécurité, détaillé deux sections plus bas. Il part automatiquement à la publication, mais lis-le
• Vérifie ton contenu réel. Aucun texte d'exemple, aucune fausse photo, aucun témoignage inventé qui traîne

Les Skills et le Knowledge de Lovable

C'est la partie la plus sous-estimée de l'outil, et celle qui change le plus la qualité de ce qui sort. Lovable a deux mémoires, et elles ne servent pas à la même chose.

Le Knowledge de Lovable : ce qui est toujours dans le contexte

Le Knowledge est un bloc d'instructions permanentes que Lovable prend en compte à chaque message, sans que tu le rappelles. Il existe à deux étages : au niveau de l'espace de travail, partagé par tous tes projets, et au niveau d'un projet précis. Ça se remplit dans Settings puis Knowledge, et chaque niveau accepte 10 000 caractères.

Ce que je mets dans le Knowledge de l'espace de travail : mes conventions de nommage, le fait que je veux du TypeScript strict, mes règles de style, l'interdiction absolue du faux contenu. Ce que je mets dans celui du projet : à quoi sert l'application, qui l'utilise, le vocabulaire métier, le schéma de la base.

Écris-le une fois, tu arrêtes de le répéter à chaque prompt. Et tu arrêtes de payer des crédits pour corriger ce que tu aurais pu éviter.

Les Skills de Lovable : ce qui se charge quand c'est utile

Une Skill est un dossier d'instructions réutilisable, chargé seulement quand la tâche correspond. La doc pose la distinction proprement : "Knowledge is always included in context [...] Skills are loaded on demand".

Cinq façons de créer une Skill : la construire en discutant avec Lovable, l'écrire à la main, l'importer depuis un dépôt GitHub public, envoyer un ZIP, ou sauvegarder une conversation qui a bien marché. Elles vivent dans l'espace de travail, donc tous tes projets en profitent, et seuls les propriétaires et les admins peuvent les modifier. Lovable les déclenche tout seul quand la demande colle, ou tu les appelles avec un slash suivi de leur nom.

Et voilà le détail qui devrait t'intéresser si tu utilises déjà Claude, parce que je ne l'ai vu écrit nulle part en français : c'est exactement le même format. La documentation Lovable est explicite : "Skills in Lovable use the same SKILL.md shape as Anthropic's Claude and any other tool that follows the Agent Skills convention."

Concrètement, tu exportes une Skill Claude en ZIP, tu l'importes dans Lovable, elle marche. Et dans l'autre sens aussi. Tu écris ta méthode une fois, elle sert dans les deux outils.

Dernier point qui compte : utiliser une Skill ne coûte aucun crédit supplémentaire. "There is no additional skill-specific cost. Credits are tied to chat messages, not to skills themselves." Les crédits sont liés aux messages, pas aux Skills.

La sécurité sur Lovable

Je m'attendais à trouver ça réservé au plan Business, ce n'est pas le cas. Les deux scanners sont sur tous les plans, y compris le gratuit. Seules les analyses programmées et les intégrations tierces comme Wiz ou Aikido dépendent du plan.

• Le scan Basic est rapide : il relit tes règles de sécurité au niveau des lignes pour y repérer les erreurs classiques, passe ton schéma de base en revue, et audite tes dépendances npm à la recherche de vulnérabilités connues
• Le scan Deep est une revue agentique du code : contrôle des accès, protection des points d'entrée du backend, vulnérabilités au niveau du code

À côté de ça, trois protections tournent sans que tu demandes rien : la détection des clés d'API laissées en clair, la vérification des mots de passe compromis via Have I Been Pwned sur l'authentification par email, et un scan automatique au moment de la publication.

Le détail à connaître : la correction automatique d'un problème critique puise dans un quota de 10 corrections gratuites par jour. Au-delà, une revue conversationnelle consomme des crédits normaux. Autrement dit, sécuriser ton app ne te coûte rien tant que tu restes raisonnable.

Mon conseil : lance un scan Deep avant chaque mise en ligne d'une application qui a des utilisateurs. Ça prend quelques minutes et ça rattrape exactement le genre d'oubli qui transforme une base de données en fuite publique.

Le SEO avec Lovable

Sur un site de contenu, c'est l'outil que j'utilise le plus après le chat. Il vit dans le menu More, sous SEO & AI search.

Ci-dessus, c'est la revue de ce site, telle qu'elle est. Je la montre sans la nettoyer d'abord, parce qu'une capture avec un score parfait ne t'apprendrait rien : elle me signale que ma Search Console n'est pas complètement configurée, que mes règles de crawl méritent un coup d'œil, et que mes aperçus sociaux ne sont pas assez distincts d'une page à l'autre. Trois vrais points, sur un site qui se positionne déjà.

Deux boutons comptent sur cet écran. Scan again relance l'analyse, et le badge Out of date te prévient quand ta dernière revue date d'avant tes derniers changements. Try to fix all tente de corriger les problèmes tout seul, ce qui consomme des crédits comme n'importe quel travail de build : lis les points avant de cliquer, tu n'as pas forcément envie de tous les régler.

À gauche, Research SEO with Lovable est une brique de recherche de mots-clés propulsée par Semrush, directement dans l'outil. Tu peux lui demander tes principaux termes de recherche, ce sur quoi tes concurrents se positionnent, ou la part de tes recherches qui vient de France. Pour un site vitrine, ça évite un abonnement de plus.

La revue elle-même contrôle sept familles de choses :

Deux choses à savoir sur le rendu, parce qu'elles décident de ton référencement. Les nouvelles applications tournent sur TanStack Start avec du vrai rendu serveur, c'est le cas de ce site. Les anciennes utilisent un pré-rendu à la demande, déclenché pour les crawlers vérifiés seulement : Google, Bing, ChatGPT, Perplexity, Claude et Gemini. Si ton projet est ancien et que tu vises le SEO, vérifie de quel côté tu te trouves.

L'AEO, pour Answer Engine Optimization, désigne l'optimisation pour ces moteurs de réponse par IA plutôt que pour les moteurs de recherche classiques. Les fondations sont les mêmes, la cible change : être cité dans une réponse générée, pas seulement listé dans dix liens bleus.

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 conseils pour bien utiliser Lovable

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 sur Lovable

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, et mieux qu'avant. Lovable gère les fondations techniques tout seul, les nouvelles applications tournent en rendu serveur, et une revue intégrée accessible dans More puis SEO & AI search contrôle métadonnées, indexation, sitemap, données structurées et Core Web Vitals. Sa propre documentation prévient quand même qu'un bon référencement demande de la relecture et des itérations. Ce site en est la preuve : il est sur Lovable et il se positionne.

Peut-on utiliser ses Skills Claude dans Lovable ?

Oui, littéralement les mêmes fichiers. Lovable utilise le format SKILL.md de la convention Agent Skills, celle d'Anthropic. Tu exportes une Skill Claude en ZIP, tu l'importes dans ton espace de travail Lovable, et elle fonctionne. Dans l'autre sens aussi. Et les utiliser ne consomme aucun crédit supplémentaire.

Lovable fait-il des audits de sécurité ?

Oui, et sur tous les plans, plan gratuit compris. Le scan Basic relit tes règles de sécurité au niveau des lignes, ton schéma de base et tes dépendances npm. Le scan Deep pousse jusqu'au contrôle des accès et aux vulnérabilités du code. Un scan part automatiquement à la publication, et tu disposes de 10 corrections automatiques gratuites par jour sur les problèmes critiques.

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 que deux choses, prends celles-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 remplis ton Knowledge avant ton dixième prompt, parce que chaque règle que tu y écris est une correction que tu ne paieras pas.

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