Dossier exemple InvoiceRadar

Étape 10 sur 10

Création du MVP

Des prompts optimisés pour Cursor, Claude Code, Codex, Lovable, Bolt et v0. Votre SaaS se code tout seul.

Stack recommandée

Frontend: Next.js 16 avec l'App Router et Tailwind CSS
Backend: Server Actions Next.js, sans service séparé
Base de données: PostgreSQL managé sur Supabase
Authentification: Supabase Auth, email et Google
Paiement: Stripe Checkout et portail client
Hébergement: Vercel

Un seul dépôt, un seul déploiement, aucun serveur à administrer : c'est ce qui permet de tenir les quatre-vingt-dix heures de la roadmap. L'agrégation bancaire est le seul vrai morceau technique du projet — tout le reste doit être du service managé pour lui laisser la place.

Modèle de données

users

Le compte de l'artisan, ses préférences de relance et son abonnement.

id uuid primary key
email text not null unique
plan text not null default 'trial'
created_at timestamptz not null

bank_connections

Le lien vers un compte bancaire agrégé, et l'état de son consentement.

id uuid primary key
user_id uuid references users
provider_account_id text not null
status text not null
last_synced_at timestamptz

clients

Les clients facturés, avec leur délai de paiement observé.

id uuid primary key
user_id uuid references users
name text not null
email text
average_payment_days integer

invoices

Les factures émises et leur état d'encaissement.

id uuid primary key
client_id uuid references clients
amount_cents integer not null
issued_on date not null
due_on date not null
settled_at timestamptz

transactions

Les mouvements bancaires importés, avant et après rapprochement.

id uuid primary key
bank_connection_id uuid references bank_connections
amount_cents integer not null
booked_on date not null
label text
matched_invoice_id uuid references invoices

reminders

Les relances préparées, validées et envoyées.

id uuid primary key
invoice_id uuid references invoices
level integer not null
status text not null
sent_at timestamptz

Écrans du MVP

1
Connexion du compte bancaire
Le premier écran : sans lui, rien à montrer.
2
Saisie des factures en attente
Quatre champs par facture, au démarrage puis au fil de l'eau.
3
Tableau des encours
La liste triée par ancienneté, avec le total dû.
4
Fiche client
L'historique de paiement et le délai habituel.
5
Préparation de relance
Le texte proposé, relu et validé avant envoi.
6
Historique des relances
Ce qui est parti, quand, et ce que ça a donné.
7
Abonnement
Essai, passage au payant, portail de facturation.

Ordre de construction

Générer dans cet ordre évite de se retrouver bloqué à mi-parcours.

01Authentification et modèle de données, avant toute interface
02Saisie manuelle des factures : elle rend l'application testable sans la banque
03Connexion bancaire et import des transactions
04Rapprochement automatique, avec son écran de confirmation des cas ambigus
05Tableau des encours, une fois que les données sont fiables
06Modèles et envoi des relances
07Abonnement Stripe en dernier : rien à facturer avant que le reste tourne

Prompts prêts à coller

Un prompt par outil, adapté à sa façon de fonctionner.

Lovable

Prompt Lovable

Construis une application web de suivi des factures impayées pour artisans, en français. Sept écrans : connexion d'un compte bancaire (écran d'accueil après inscription), saisie des factures en attente, tableau des encours, fiche client, préparation d'une relance, historique des relances, abonnement. Le tableau des encours est l'écran central : une liste de factures triée par nombre de jours de retard décroissant, avec le nom du client, le montant, la date d'échéance, le nombre de jours de retard, et un bouton « Préparer la relance ». Un bandeau en haut affiche le total dû et le nombre de clients concernés. La préparation de relance ouvre un panneau latéral avec le texte pré-rempli, modifiable, trois niveaux de fermeté sélectionnables, et deux boutons : « Envoyer » et « Reporter d'une semaine ». Rien ne part sans ce clic. Ton visuel : sobre, dense, lisible sur téléphone, aucune illustration. Utilise des données d'exemple réalistes (noms d'artisans, montants entre 300 et 4 000 €).

À surveiller : Lovable a tendance à ajouter des tableaux de bord et des graphiques non demandés. Rappeler à chaque itération que l'écran central est la liste, pas un dashboard.

Bolt

Prompt Bolt

Application web française de suivi des encours pour artisans indépendants, en React avec Tailwind. Parcours : l'utilisateur s'inscrit, connecte un compte bancaire (simule cette étape par un écran de sélection de banque puis un état « connecté »), saisit ses factures en attente, et arrive sur le tableau des encours. Le tableau des encours liste les factures non réglées, triées par jours de retard décroissants : client, montant, échéance, retard en jours, action « Préparer la relance ». Total dû affiché en haut. La préparation de relance est un panneau latéral : texte pré-rempli selon trois niveaux de fermeté, modifiable, bouton d'envoi explicite. Stocke l'état en mémoire pour l'instant, avec des données d'exemple crédibles. Interface en français, sobre, utilisable sur téléphone.

À surveiller : Bolt part vite sur une stack complète. Fixer explicitement React plus Tailwind et l'état en mémoire, sinon il installe une base de données et perd du temps.

Prompt v0

Génère un composant React `EncoursTable` en TypeScript avec Tailwind et shadcn/ui. Props : `invoices: { id: string; clientName: string; amountCents: number; dueOn: string; daysLate: number }[]`, `onPrepareReminder: (id: string) => void`. Affichage : un en-tête avec le total dû (somme formatée en euros) et le nombre de clients concernés ; puis un tableau trié par `daysLate` décroissant, colonnes client, montant, échéance, retard, action. Le retard est un badge coloré : gris sous 8 jours, ambre de 8 à 30, rouge au-delà. L'action est un bouton « Préparer la relance » appelant `onPrepareReminder`. Variantes à couvrir : liste vide (message « Aucun encours en retard »), chargement (skeleton de cinq lignes). Sur mobile, le tableau passe en cartes empilées. Libellés en français, montants formatés avec `Intl.NumberFormat`.

À surveiller : v0 rend un seul composant à la fois : ne pas lui demander le parcours complet. Vérifier le rendu mobile, souvent traité en dernier.

Cursor

Prompt Cursor

Projet Next.js 16 (App Router, TypeScript, Tailwind) avec Supabase. Implémente le rapprochement bancaire, étape par étape, en t'arrêtant après chaque fichier pour que je relise. Arborescence attendue : - `src/lib/matching/match.ts` — la logique pure - `src/lib/matching/match.test.ts` — les tests - `src/server/actions/transactions.ts` — la Server Action d'import - `src/types/database.ts` — types générés, ne pas éditer à la main Règle de rapprochement : une transaction est associée à une facture si le montant correspond au centime près et si la date de valeur tombe entre la date d'émission et l'échéance plus soixante jours. Si plusieurs factures correspondent, prendre la plus ancienne et marquer le résultat `needs_confirmation`. Si aucune, laisser la transaction non rapprochée. Contraintes : fonction pure sans accès base dans `match.ts`, tous les montants en centimes entiers, aucun `any`, tests couvrant le cas ambigu et le cas sans correspondance. Commence par `match.ts` et ses tests, rien d'autre.

À surveiller : Cursor élargit le périmètre s'il n'est pas borné. Le « commence par, rien d'autre » est ce qui tient la session.

Claude Code

Prompt Claude Code

Dépôt Next.js 16 avec App Router, TypeScript strict, Tailwind et Supabase. Objectif : la fonctionnalité de relance, de la préparation à l'envoi. Avant d'écrire quoi que ce soit, lis `src/lib/matching/match.ts` et `src/types/database.ts` pour reprendre les conventions existantes. À livrer : 1. `src/lib/reminders/templates.ts` — trois modèles de relance en français (courtois, ferme, mise en demeure), fonctions pures prenant client, facture et jours de retard. 2. `src/server/actions/reminders.ts` — Server Actions `prepareReminder` et `sendReminder`. `sendReminder` vérifie que la facture est toujours impayée avant d'envoyer, et refuse un second envoi de même niveau à moins de sept jours d'écart. 3. `src/components/reminders/reminder-panel.tsx` — le panneau de validation. 4. Les tests des modèles et de la règle des sept jours. Contraintes : aucune requête base dans les composants, toute erreur remontée par un type de retour explicite plutôt que par une exception, textes en français dans le code comme dans l'interface. Procède fichier par fichier, en lançant les tests après chaque étape.

À surveiller : Lui faire lire les fichiers existants d'abord évite qu'il réinvente des conventions déjà posées ailleurs dans le dépôt.

Codex

Prompt Codex

Tâche : implémenter `computeAveragePaymentDays(invoices)` dans `src/lib/clients/payment-delay.ts` d'un projet TypeScript. Entrée : un tableau de factures `{ issuedOn: string; dueOn: string; settledAt: string | null }` (dates ISO) pour un même client. Sortie : `number | null` — la moyenne, arrondie à l'entier, du nombre de jours entre `dueOn` et `settledAt` pour les factures réglées. Critères d'acceptation : - Les factures non réglées (`settledAt` à `null`) sont ignorées. - Moins de trois factures réglées renvoie `null` : la moyenne ne serait pas significative. - Un paiement en avance produit une valeur négative, qui doit être conservée. - Les fuseaux horaires sont ignorés : comparer les dates au jour près, en UTC. - Aucune dépendance externe, aucune bibliothèque de dates. - Tests unitaires couvrant chacun de ces cas dans `payment-delay.test.ts`.

À surveiller : Codex travaille bien sur une fonction bornée avec des critères d'acceptation explicites, mal sur une consigne ouverte. Découper le reste du produit de la même façon.