# Créer un SaaS avec l’IA : du MVP au premier client

URL: https://agentvera.dev/fr/blog/build-saas-mvp-with-ai/ · Publié: 2026-10-11

Guide pratique pour créer un SaaS avec l’IA : cadrer le MVP, rédiger une spec que l’agent suit, Next.js, Supabase, Stripe, isolation des tenants, tests, déploiement.

**En bref:**

- Réduisez le MVP à un seul parcours central et notez décisions, règles et exclusions dans CLAUDE.md ou AGENTS.md, que les agents lisent au début de chaque session.
- Mettez un organization_id sur chaque table et imposez l’isolation des tenants par la sécurité au niveau des lignes (RLS) dans la base, puis testez avec deux utilisateurs d’organisations distinctes.
- Le statut d’abonnement ne doit changer que via des webhooks Stripe à signature vérifiée, jamais depuis la page de succès, et un développeur expérimenté doit relire avant l’argent et les données réels.

Vous pouvez créer un SaaS avec l’IA dès aujourd’hui : un [agent de code](/fr/glossary/coding-agent/) comme Claude Code ou Codex peut écrire l’inscription, les abonnements, un tableau de bord et une API en quelques jours. Mais un MVP qui fonctionne demande plus qu’un « construis-moi un SaaS » : un périmètre réduit à un seul parcours central, une spec écrite que l’agent relit à chaque session, et des tests sur les chemins où se jouent l’argent et l’isolation des données. Cet article détaille la méthode que je suis, du cadrage au déploiement.

L’objectif est un guide que peut suivre quelqu’un qui code peu, voire pas du tout. Sortir un prototype en [vibe coding](/fr/glossary/vibe-coding/) est facile ; faire vivre un produit une fois que quelqu’un saisit sa carte bancaire est la partie difficile. Je vais donc indiquer où vous pouvez aller vite et où il faut ralentir.

## 1. Réduire le périmètre à un seul parcours central

Les MVP meurent rarement à cause du code. Ils meurent à cause du périmètre. L’agent écrira tout ce que vous demandez ; le problème, c’est que chaque fonctionnalité ajoutée doit être testée, maintenue et déboguée.

Avant de commencer, écrivez une phrase : « L’utilisateur fait ___ et obtient ___ en retour. » Par exemple : « Une agence téléverse les publications sociales d’un client, et le client les valide depuis un lien unique. » Tout ce qui sort de cette phrase part en version deux.

Une première version n’a généralement besoin que de :

- Inscription, connexion, réinitialisation du mot de passe
- Une organisation (tenant) avec des membres invités
- Un parcours central (la phrase ci-dessus)
- Une offre payante, abonnement mensuel
- Une page de réglages simple et un lien vers le portail de facturation

Centre de notifications, matrice de rôles, plusieurs langues, application mobile, panneau d’administration : plus tard. Si les clients paient pour le parcours central, ils vous diront de quoi d’autre ils ont besoin.

## 2. Rédiger une spec que l’agent suit

Les agents ne gardent pas de mémoire d’une conversation à l’autre. Claude Code lit `CLAUDE.md` à la racine du projet à chaque session ; Codex et de nombreux autres agents lisent `AGENTS.md`. Notez-y vos décisions et chaque nouvelle session repart des mêmes règles. Si vous utilisez les deux agents, gardez le contenu dans un seul fichier et faites pointer l’autre vers lui.

Une spec utile est courte et concrète :

```markdown
# Project: ApproveLink (MVP)

## Product
Agencies upload posts; the client approves or comments from one link.

## Stack
- Next.js (App Router, TypeScript), Tailwind
- Supabase: Postgres, Auth, Storage
- Stripe: one plan, monthly subscription, Checkout + Customer Portal
- Tests: Vitest (unit), Playwright (end to end)

## Rules
- Every table has organization_id; RLS is on for every table.
- Subscription status changes only from the Stripe webhook.
- Database changes only through migration files.
- Secrets live in .env.local; never in code or logs.
- Ask before adding a new package.
- After every task: pnpm lint && pnpm test

## Out of scope (for now)
Roles, i18n, mobile, admin panel.
```

La section « hors périmètre » compte. Les agents cherchent à bien faire et ajoutent des choses que vous n’avez pas demandées ; une limite écrite réduit nettement ce travers.

## 3. Choisir la stack : miser sur l’ennuyeux

Quand on travaille avec l’IA, la meilleure stack est celle dont l’agent a vu le plus d’exemples. Pour ce type de MVP, je prendrais :

- **Next.js + TypeScript :** Frontend et API dans un seul projet. TypeScript détecte une partie des erreurs de l’agent dès la compilation.
- **PostgreSQL (Supabase ou un autre Postgres managé) :** Données relationnelles, sécurité au niveau des lignes (RLS) et migrations. Supabase fournit aussi l’authentification et le stockage de fichiers au même endroit.
- **Authentification toute prête :** Supabase Auth, Auth.js ou Clerk. Ne demandez pas à l’agent d’écrire de zéro le stockage des mots de passe et la gestion des sessions.
- **Abonnements Stripe :** Checkout pour la page de paiement, Customer Portal pour les changements d’offre et la résiliation. Vous ne construisez jamais de formulaire de carte.
- **Vercel ou une plateforme similaire :** Déploie à chaque push et donne à chaque branche une URL de prévisualisation.

À installer : Node.js (LTS), pnpm, Git, un compte GitHub, la CLI Supabase, la CLI Stripe et un agent de code (`claude` ou `codex`).

```bash
pnpm create next-app@latest approvelink --typescript --tailwind --app
cd approvelink
git init && git add -A && git commit -m "chore: empty project"
```

Placez la spec à la racine de ce dossier et commitez-la aussi.

## 4. Le premier prompt : le plan d’abord, le code ensuite

Mon premier message ne demande pas de code ; il demande un plan. Lire et corriger un plan coûte bien moins cher que d’annuler 40 fichiers mal écrits.

```text
Read CLAUDE.md. Don't write code yet.
Produce an implementation plan for this MVP:
1. Database tables (fields, relations, RLS policies)
2. Pages and API routes
3. The Stripe flow (which webhook events, where subscription status lives)
4. 6–8 small steps in order, each with what gets tested at the end
List anything unclear as questions at the end.
```

Lisez le plan, répondez aux questions, mettez à jour la spec si besoin. Faites ensuite exécuter les étapes une par une :

```text
Implement step 1 of the plan: write the migration for the organizations,
memberships and projects tables and add the RLS policies. When done,
apply the migration to the local database, write a test proving two
different users can't see each other's data, and run it. Then stop.
```

Le « Then stop » est voulu. Après chaque étape, je regarde le diff et je commite : quand l’agent dérive, il y a un point propre où revenir.

## 5. Isolation des données multi-tenant : la partie la plus dangereuse

Le pire bug d’un SaaS, c’est « le client A a vu les données du client B ». Le code de l’agent paraît généralement correct parce que vous le testez avec un seul utilisateur pendant le développement. Le problème apparaît à l’arrivée du deuxième client.

Mes règles :

- **`organization_id` sur chaque table.** Sans exception, tables enfants comprises.
- **Laissez la base imposer le filtre.** Sur Supabase/Postgres, activez la RLS sur chaque table et écrivez la politique autour des organisations auxquelles l’utilisateur appartient. Un `where organization_id = ...` dans le code applicatif ne suffit pas à lui seul ; l’agent peut l’oublier dans la prochaine requête qu’il écrit.
- **La clé service role reste côté serveur.** Elle contourne la RLS. Elle ne doit jamais atteindre le code livré au navigateur ; dans Next.js, ne la mettez jamais dans une variable `NEXT_PUBLIC_`.
- **Testez avec deux utilisateurs.** Créez deux organisations et, connecté avec l’une, essayez de récupérer l’enregistrement de l’autre par son ID. Ce test doit être automatisé et exécuté à chaque modification.

Demandez directement à l’agent : « Liste tous les endroits de ce projet qui contournent la RLS. » La réponse devrait être le code serveur utilisant la clé service role et les webhooks ; s’il y en a davantage, demandez pourquoi.

## 6. Migrations : ne modifiez jamais la base à la main

Quand l’agent veut ajouter une colonne, il doit le faire avec un fichier de migration, pas en cliquant dans un tableau de bord. Avec la CLI Supabase :

```bash
supabase start                      # local Postgres (needs Docker)
supabase migration new add_projects # empty migration file
supabase db reset                   # apply all migrations from scratch
supabase db push                    # apply to the remote database
```

Exécutez `db reset` régulièrement : si les migrations ne s’appliquent pas proprement depuis zéro, la production aura aussi des problèmes. Une fois en ligne, lisez chaque migration que l’agent écrit. Si vous voyez `DROP COLUMN`, `DROP TABLE`, un `UPDATE` sans `WHERE` ou un index bloquant sur une grosse table, arrêtez-vous et demandez pourquoi. Une migration qui supprime des données est irréversible.

## 7. Tester les chemins de l’argent

Vous n’avez pas besoin de tests partout ; le temps d’un MVP est court. Mais ces chemins ne doivent pas arriver en production sans test :

1. **Inscription → création d’organisation → parcours central.** De bout en bout avec Playwright.
2. **Webhooks Stripe.** Le statut d’abonnement se met-il correctement à jour sur `checkout.session.completed`, `customer.subscription.updated`, `customer.subscription.deleted` et `invoice.payment_failed` ?
3. **Accès sans paiement.** Quand un abonnement est résilié ou qu’un paiement échoue, la fonctionnalité payante est-elle réellement fermée ?
4. **Isolation des données.** Le test à deux utilisateurs vu plus haut.

Essayez les webhooks Stripe en local ainsi :

```bash
stripe login
stripe listen --forward-to localhost:3000/api/webhooks/stripe
stripe trigger checkout.session.completed
```

Un prompt pour l’agent :

```text
Review the Stripe webhook route. Is the signature verified? What happens
if the same event arrives twice (idempotency)? Which table holds
subscription status? Write tests for these four events:
checkout.session.completed, customer.subscription.updated,
customer.subscription.deleted, invoice.payment_failed.
Run them and show me the result.
```

Une erreur courante : l’agent active l’abonnement sur la page de « succès » vers laquelle Stripe redirige. N’importe qui peut ouvrir cette URL à la main. Le statut ne doit changer que depuis un webhook à signature vérifiée.

## 8. Déploiement et supervision

Sur une plateforme comme Vercel, le flux est simple : poussez le dépôt sur GitHub, connectez le projet, saisissez les variables d’environnement dans le tableau de bord. Chaque pull request reçoit sa propre URL de prévisualisation ; testez-y les changements avant la production.

Ma checklist avant la mise en ligne :

- Variables d’environnement définies en production ; clés Stripe live et test non mélangées
- Un endpoint de webhook live configuré dans Stripe, son secret de signature dans une variable d’environnement
- Migrations appliquées à la base de production
- URL de redirection de Supabase Auth définies pour le domaine de production
- Sauvegardes de la base activées

Pour la supervision, ajoutez un service de suivi d’erreurs comme Sentry afin de voir les erreurs avant qu’un utilisateur n’écrive « ça ne marche pas ». Il suffit de dire à l’agent : « Add Sentry to the Next.js project, capture server and client errors, and don’t attach user emails or secret values to events. » Ajoutez aussi une simple vérification de disponibilité.

## Ce que l’IA se trompe à faire

- **Inventer des API qui n’existent pas.** Surtout avec les nouvelles versions de bibliothèques. Quand la compilation ou les tests cassent, donnez l’erreur telle quelle à l’agent et demandez-lui de consulter la documentation officielle.
- **Modifier le test pour qu’il passe.** Si un fichier de test apparaît dans le diff, demandez pourquoi.
- **Ajouter des paquets inutiles.** La règle « demander avant d’ajouter un paquet » de la spec est rentable ici.
- **Avaler les erreurs.** Des blocs `catch {}` vides rendent les échecs de paiement invisibles.
- **Faire l’autorisation côté client.** Masquer un bouton n’est pas de la sécurité ; la vérification relève du serveur et de la base.
- **Élargir le périmètre.** Annulez les fonctionnalités qui arrivent avec « j’ai aussi ajouté… » ou déplacez-les sur une branche séparée.
- **Perdre le contexte dans les longues sessions.** Plus la conversation s’allonge, plus l’agent oublie les décisions du début. Ouvrez une session neuve par étape ; les décisions durables vivent déjà dans la spec. Fermer une session avant que la [fenêtre de contexte](/fr/glossary/context-window/) ne se remplisse protège à la fois la qualité et le coût en [tokens](/fr/glossary/token/).

## Sécurité : court mais sérieux

- **Les secrets vont dans `.env.local`.** Vérifiez qu’il figure dans `.gitignore`. Si une clé a un jour été commitée, révoquez-la et émettez-en une nouvelle ; la supprimer de l’historique ne suffit pas.
- **Ne collez jamais de clés d’API dans le chat.** L’agent n’a pas besoin de voir la clé, seulement le nom de la variable.
- **Lisez les commandes que l’agent exécute.** Surtout `rm`, `git push --force`, les commandes de base de données et `curl … | sh`. N’approuvez automatiquement que les actions sûres comme lire des fichiers et lancer des tests.
- **Ne pointez pas l’agent vers la base de production.** Laissez-le travailler sur une base locale ou de test.
- **Validez les entrées côté serveur.** Faites vérifier chaque entrée d’API avec une bibliothèque de schémas comme Zod.
- **Auditez les dépendances.** Donnez de temps en temps la sortie de `pnpm audit` à l’agent.

## Quand faire appel à un développeur humain

Si l’un de ces cas vous concerne, quelques heures de relecture par un développeur expérimenté valent la peine :

- Avant d’encaisser le premier vrai paiement (webhooks, statut d’abonnement, remboursements)
- Quand les données clients incluent des données personnelles (RGPD et obligations similaires)
- Quand un client grand compte envoie un questionnaire de sécurité
- Quand vous et l’agent n’avez pas réussi à corriger le même bug en trois sessions de suite
- Quand les problèmes de performance commencent (requêtes lentes, index manquants)

Gardez la spec, le dossier des migrations et la sortie des tests à portée de main pour accélérer la relecture. Un projet écrit avec un agent mais commité par petites étapes et couvert par des tests est un projet qu’un développeur comprend vite.

## Comment je procède avec AgentVera

Tout ce qui précède fonctionne dans un seul terminal. J’utilise AgentVera pour piloter plusieurs agents à la fois ; voici ce qui aide :

- **Frontend et backend dans des worktrees séparés.** Dans le [workspace](/fr/features/workspace/), j’ouvre un agent Claude Code pour l’API et les webhooks et un agent Codex pour l’interface, chacun dans son propre [git worktree](/fr/glossary/git-worktree/). Ils ne touchent pas aux mêmes fichiers et ne se gênent donc pas. La méthode est détaillée dans [les git worktrees pour agents parallèles](/fr/blog/git-worktree-parallel-agents/).
- **Le diff avant la fusion.** Le [panneau Git](/fr/features/git-and-github/) montre les changements de chaque worktree, et la [revue de code](/fr/features/code-review/) vérifie chaque tour terminé. Ce qu’il faut chercher est expliqué dans [la revue de code par IA](/fr/blog/ai-code-review/).
- **Voir la base de données.** Avec le [gestionnaire de base de données](/fr/features/database-manager/), j’ouvre les tables du Postgres local et je vérifie ce que l’agent a réellement écrit ; [DB Guard](/fr/features/db-guard/) signale les migrations risquées à la fin d’un tour.
- **Prévisualisations.** Les [environnements de prévisualisation](/fr/features/preview-environments/) donnent au serveur de développement de chaque worktree sa propre adresse, ce qui me permet d’essayer deux branches côte à côte.
- **Surveiller les tokens.** Chaque panneau affiche la taille du contexte en direct ; quand elle explose, je ferme la session et j’en ouvre une neuve.

Cela accélère les choses mais ne remplace pas les règles ci-dessus : la spec, les tests et votre propre relecture comptent toujours.

## Pour conclure

Créer un SaaS avec l’IA, c’est moins générer du code qu’écrire les décisions et protéger les chemins critiques. Réduisez le périmètre à un parcours, mettez les décisions dans `CLAUDE.md` ou `AGENTS.md`, choisissez une stack ennuyeuse et courante, imposez l’isolation des tenants dans la base, testez les chemins de l’argent et mettez la supervision en place avant de déployer. Faites relire par un humain avant que l’argent et les données réels n’entrent en jeu. Si vous voulez lancer des agents en parallèle, [téléchargez AgentVera gratuitement](/fr/download/) et ouvrez vos deux premiers worktrees.

## Questions fréquentes

**Puis-je créer seul un SaaS avec l’IA ?** Vous pouvez livrer seul un MVP avec un parcours central grâce aux agents de code. Le plus dur n’est pas de générer du code, mais de garder un périmètre réduit, de donner une spec écrite à l’agent et de tester et relire vous-même les chemins critiques comme les paiements et le contrôle d’accès.

**Quelle stack technique choisir pour créer un SaaS avec l’IA ?** Choisissez une stack courante que les agents ont vue de nombreuses fois : Next.js, PostgreSQL (par exemple Supabase), une solution d’authentification toute prête et Stripe pour les abonnements. Sur une stack grand public, l’agent invente moins et vous trouvez de l’aide plus vite en cas de blocage.

**Quelle est l’erreur multi-tenant la plus fréquente dans un SaaS créé par IA ?** Une requête qui oublie le filtre de tenant, de sorte qu’un client voit les données d’un autre. Mettez un identifiant de tenant sur chaque table, imposez le filtre dans la base avec la sécurité au niveau des lignes (RLS) et testez avec deux utilisateurs distincts.

**Quand un développeur humain doit-il relire mon SaaS créé par IA ?** Avant que de l’argent réel et des données clients réelles n’entrent en jeu. Quelques heures de relecture par un développeur expérimenté sur les webhooks de paiement, les autorisations, l’isolation des données et les migrations coûtent bien moins cher qu’une fuite de données ensuite.

**Comment faire configurer correctement les abonnements Stripe par l’IA ?** Dites à l’agent que le statut d’abonnement ne peut changer que depuis des webhooks Stripe à signature vérifiée, jamais depuis la redirection du navigateur après le paiement. Déclenchez ensuite chaque événement de webhook en local avec la CLI Stripe et testez-le.

---

**À propos d’AgentVera.** AgentVera est une app de bureau pour macOS, Windows et Linux, développée par Solviera Teknoloji. Elle exécute 18 agents de code IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) côte à côte, par projet, dans de vrais terminaux avec les installations et connexions CLI de l’utilisateur. L’offre gratuite inclut des agents illimités. Télécharger: https://agentvera.dev/fr/download/ · Tarifs: https://agentvera.dev/fr/pricing/