Guide · Outil métier
Cadrer son projet avant de prompter : le brief d'une page
Par Marie Van Haecke ·
Un projet Lovable réussi commence hors de Lovable, par un brief d'une page : le problème à résoudre, qui utilise l'outil, les informations qu'il manipule, les écrans, les règles d'accès et ce qui est hors périmètre. Ce brief devient ensuite la « connaissance du projet » que l'IA relit à chaque demande.
Pourquoi cadrer avant de prompter
L'IA de Lovable construit exactement ce que vous lui demandez, même quand ce n'est pas ce dont vous avez besoin. Chaque demande floue produit une version à corriger, et chaque correction consomme des crédits. La documentation de Lovable recommande elle-même de planifier avant de prompter, de construire composant par composant et d'utiliser de vrais contenus.
Source : documentation Lovable, « Prompting best practices », consultée le 30 septembre 2026.
La trame du brief, en huit rubriques
Le problème
En deux phrases : ce qui coince aujourd'hui, et ce que ça coûte. « Nos demandes d'intervention arrivent par téléphone, SMS et email ; on en perd une par semaine. »
Les utilisateurs
Chaque type de personne qui utilisera l'outil, et ce qu'elle doit pouvoir faire. Technicien, responsable, client, administrateur.
Le process principal
Les étapes dans l'ordre, du déclencheur au résultat. Un seul process pour la première version.
Les données
Les objets manipulés (client, chantier, intervention) et, pour chacun, les champs indispensables. Pas plus.
Les écrans
La liste des écrans, avec pour chacun ce qu'on y voit et ce qu'on y fait. Un croquis à la main suffit.
Les règles
Qui voit quoi, qui peut modifier quoi, ce qui déclenche un email ou une relance.
Le hors périmètre
Ce que la première version ne fera pas. C'est la rubrique qui protège le plus le budget.
Le critère de réussite
Comment vous saurez que ça marche : « plus aucune demande perdue », « le devis part le jour même ».
Un exemple de brief rempli
| Rubrique | Contenu |
|---|---|
| Problème | Les demandes arrivent par trois canaux et certaines se perdent. |
| Utilisateurs | Assistante (saisit), techniciens (consultent et clôturent), dirigeant (suit). |
| Process | Demande reçue → planifiée → réalisée avec photo → facturée. |
| Données | Client (nom, adresse, contact), intervention (date, technicien, statut, photo, commentaire). |
| Écrans | Liste des interventions, fiche intervention, planning de la semaine, vue mobile technicien. |
| Règles | Un technicien ne voit que ses interventions. Email au client à la clôture. |
| Hors périmètre | Facturation, stock, application pour les clients. |
| Réussite | Zéro demande perdue sur un mois. |
Comment l'utiliser dans Lovable
- Collez le brief dans la connaissance du projet (Project knowledge). Lovable la relit à chaque demande ; elle accepte jusqu'à 10 000 caractères.
- Construisez écran par écran, dans l'ordre du process, plutôt que de tout demander en un seul message.
- Utilisez le mode Plan pour discuter d'une fonction avant que l'IA ne modifie le code.
- Mettez de vrais contenus : vrais statuts, vrais libellés, quelques vraies lignes de données.
Source : documentation Lovable, « Knowledge », consultée le 30 septembre 2026.
Les erreurs de cadrage les plus fréquentes
- Décrire la solution au lieu du problème : « il me faut un tableau de bord » ne dit pas quelle décision il doit aider à prendre.
- Oublier un rôle, souvent celui qui valide ou celui qui reçoit les notifications.
- Laisser le hors périmètre vide : tout devient alors prioritaire.
Questions fréquentes
Faut-il un cahier des charges complet pour un projet Lovable ?
Non. Un brief d'une page suffit pour une première version. Il sera complété au fil de la construction, écran par écran.
Qu'est-ce que la connaissance du projet dans Lovable ?
Un champ de texte où l'on décrit le projet, ses utilisateurs, ses règles et ses choix techniques. Lovable le prend en compte à chaque demande. Il accepte jusqu'à 10 000 caractères.
Combien de temps faut-il pour écrire le brief ?
Quelques heures si le process est clair pour vous. S'il ne l'est pas, c'est justement le signe qu'il faut commencer par analyser le process avec les personnes qui le vivent.
Vous préférez être accompagné ? Chaque outil métier commence par ce cadrage, fait avec vous et vos équipes, avant la première ligne de code.
Marie Van Haecke · 20 ans à concevoir des produits tech et à coacher des équipes produit. Fondatrice de Grabloop, Lovable Certified Expert 2026 (App builder et Website builder).