Lovable — Générateur d'applications full-stack IA

Que fait Lovable — Générateur d'applications full-stack IA ?

Aperçu

Lovable (lovable.dev) génère et modifie des applications web à partir de messages de discussion dans le navigateur. Les projets utilisent Tailwind CSS et shadcn/ui ; les applications créées depuis mai 2026 utilisent TanStack Start (rendu serveur), les plus anciennes sont React + Vite. Pour le backend, vous choisissez Lovable Cloud (base de données, authentification, stockage, temps réel et fonctions intégrés, basé sur la pile open-source de Supabase) ou votre propre projet Supabase. Le code peut être synchronisé de deux manières avec GitHub, et les applications sont publiées sur une URL lovable ou un domaine personnalisé. Il n'y a rien à installer et pas de CLI ; un agent aide en écrivant de bons prompts, en examinant la sortie et en travaillant sur le dépôt synchronisé.

Instructions

1. Planifier avant le premier prompt

Répondez à quatre questions : qu'est-ce que c'est, qui l'utilise, pourquoi, et quelle est l'action clé. Décrivez l'application section par section avec du vrai contenu, pas des espaces réservés. Conseil de Lovable : un prompt complet donne du bruit, un prompt par section donne du signal. Nommez une direction de design ("minimal", "premium", "ludique") pour guider la typographie et l'espacement.

2. Choisir le backend

• Nouveaux projets : Lovable Cloud (par défaut) ou Supabase, choisi lors de la première activation du backend.
• Les projets existants connectés à Supabase continuent de fonctionner. Il n'y a pas de migration de Supabase vers Cloud, ni de déplacement en un clic de Cloud vers votre propre projet Supabase, alors décidez tôt.

3. Travailler en modes

Lovable a un mode Agent (construit et modifie les choses) et un mode Chat (discuter, planifier, pas de modifications). Le mode Plan coûte 1 crédit par message ; les modifications normales coûtent environ 0,5 à 1,7 crédits selon la complexité. Ajoutez "Demandez-moi toutes les questions nécessaires avant de construire" pour obtenir des questions de clarification. Mettez les règles durables (stack, nommage, ton) dans les connaissances du projet ou de l'espace de travail pour qu'elles persistent entre les discussions.

4. Examiner la sécurité

Les tables générées doivent avoir une sécurité au niveau des lignes (Row Level Security). Lisez chaque politique, exécutez l'analyse de sécurité intégrée et testez avec deux utilisateurs différents avant de publier.

5. Synchroniser et posséder le code

Connectez GitHub à partir des paramètres du projet. La synchronisation est bidirectionnelle pour une branche à la fois (la branche par défaut sauf changement) ; les nouvelles branches partent de la branche active. Vous ne pouvez exporter les projets Lovable que vers GitHub, pas importer un dépôt existant, et les fichiers de plus de 10 Mo ne peuvent pas être modifiés par Lovable. La déconnexion conserve les deux copies, mais la reconnexion crée un nouveau dépôt.

6. Forfaits

Gratuit, Pro, Entreprise et Business ; la tarification se fait par crédits, pas par sièges. Le forfait Gratuit comprend 5 crédits de construction quotidiens (jusqu'à 30 par mois) plus de petits crédits Cloud. Consultez lovable.dev/pricing pour les prix actuels.

Exemples

Exemple 1 : Application de liste d'attente avec parrainage

Demande : "Utilise Lovable pour construire une liste d'attente SaaS : formulaire d'inscription avec compteur, liens de parrainage, un classement et une page administrateur."

Prompt à coller :

Construis un site de liste d'attente pour "Parcelly", un outil d'étiquettes d'expédition pour les vendeurs Etsy.
Sections : héros ("Imprimez les étiquettes en 10 secondes") avec un formulaire email et un compteur
en direct des inscriptions ; un classement des 10 meilleurs parrains ; page /admin derrière
une connexion email qui liste les inscriptions et exporte en CSV.
Chaque inscription obtient un lien de parrainage unique (?ref=code) qui crédite le parrain.
Style : minimal, mode sombre. Utilise Lovable Cloud pour les données et l'authentification.
Demande-moi toutes les questions nécessaires avant de construire.

Résultat : Lovable pose des questions sur les emails d'invitation, puis crée les pages, une table signups et des politiques, et une URL de prévisualisation. Un ensemble raisonnable de table et politiques à vérifier par rapport à celui généré :

create table public.signups (
  id uuid primary key default gen_random_uuid(),
  email text not null unique,
  referral_code text not null unique default encode(gen_random_bytes(6), 'hex'),
  referred_by uuid references public.signups(id),
  created_at timestamptz not null default now()
);
alter table public.signups enable row level security;
create policy "anyone can join" on public.signups for insert to anon with check (true);
-- lire toutes les lignes doit être limité aux admins, par exemple via une table user_roles

Exemple 2 : Itérer et synchroniser avec GitHub

Demande : "Ajoute un graphique des inscriptions au fil du temps, puis mets le code dans mon dépôt pour que je puisse continuer à travailler dans Cursor."

Message de discussion : "Ajoute un graphique linéaire des inscriptions par jour à /admin en utilisant les données existantes ; affiche un état vide quand il n'y a pas d'inscriptions." Ensuite : Paramètres du projet, GitHub, Connecter, choisir le compte et créer le dépôt. Après :

git clone [email protected]:parcelly-dev/parcelly-waitlist.git
cd parcelly-waitlist && npm install && npm run dev

Les pushs vers la branche synchronisée apparaissent dans Lovable ; conservez les modifications locales sur cette branche (ou changez la branche dans les paramètres du projet).

Directives

• Mettez chaque fonctionnalité de base dans le premier prompt, puis modifiez une chose par suivi pour que l'historique des versions reste utile ; créez des signets des versions fonctionnelles.
• Ne collez pas de clés API dans la discussion ; utilisez les dialogues secrets/intégrations. Les clés côté serveur appartiennent aux fonctions backend, jamais dans le code client.
• Ne faites jamais aveuglément confiance à la RLS générée : une politique insert ... with check (true) est acceptable pour un formulaire public, une politique select ne l'est pas.
• Les crédits sont consommés par la construction, l'hébergement et les fonctionnalités IA, et ne sont pas remboursables ; préférez le mode Chat/Plan pour les questions.
• Pas adapté aux applications mobiles natives, aux backends lourds sur mesure ou aux monorepos complexes existants : utilisez un agent de codage dans le dépôt à la place.