Comment créer un SaaS en 2026 : le guide complet

Par où commencer quand on veut créer un SaaS

Créer un SaaS, ce n'est pas seulement coder un produit. C'est assembler une dizaine de briques qui doivent tenir ensemble : authentification, données isolées par client, paiements, emails, sécurité, tests, déploiement. Ce guide suit l'ordre dans lequel ces décisions se posent, avec la stack que j'utilise pour HeartCo, et renvoie vers l'article détaillé de chaque étape.

Il vise les SaaS B2B : des organisations avec des membres, des rôles et des données qu'il ne faut jamais mélanger. Pour un petit outil B2C, plusieurs de ces étapes sont trop lourdes.

Étape 1 : valider le besoin avant d'écrire du code

Avant de choisir une stack, une question : qui paiera, et pour quel problème précis ? Quelques entretiens avec de futurs utilisateurs valent mieux qu'un mois de développement. À chaque entretien, notez trois choses : la tâche qui leur fait perdre du temps, l'outil qu'ils utilisent aujourd'hui, et ce qu'ils paient déjà. Si personne ne paie pour une solution imparfaite, le besoin est probablement moins fort que prévu.

Restez sur trois fonctionnalités au départ. Chaque fonctionnalité ajoutée demande la même rigueur : isolation des données, permissions, tests. Trois fonctionnalités bien faites valent mieux que vingt bâclées.

Étape 2 : choisir la stack

Voici la stack de HeartCo, telle qu'elle figure dans le code :

const stack = {
  framework: "Next.js 15 (App Router) + React 19",
  api: "tRPC v11",
  orm: "Prisma 7",
  database: "PostgreSQL (Supabase)",
  auth: "NextAuth v5 (Auth.js)",
  ui: "Tailwind CSS v4 + shadcn/ui",
  paiements: "Stripe",
  ia: "Mistral AI",
  deploy: "Vercel",
  monorepo: "pnpm workspaces + Turborepo",
};

Pourquoi Next.js App Router ?

Les Server Components changent la donne. Vous pouvez faire vos requêtes Prisma directement dans vos composants : plus besoin d'API route pour le rendu côté serveur.

// Un composant serveur qui lit directement la base
export default async function DashboardPage() {
  const session = await auth();
  const stats = await db.invoice.aggregate({
    _sum: { totalHT: true },
    where: { organizationId: session.user.organizationId },
  });
 
  return <StatsCard total={stats._sum.totalHT} />;
}

Pourquoi tRPC ?

Vous définissez votre API une fois, et TypeScript vous donne l'autocomplétion côté client automatiquement. Pour un SaaS dont l'API n'est consommée que par son propre frontend, c'est le choix le plus productif. Le détail est dans tRPC v11 : une API full type-safe sans code generation, et l'assemblage complet dans Next.js 15 + tRPC + Prisma : le trio gagnant.

// Côté serveur : définir le router
export const invoiceRouter = createTRPCRouter({
  getAll: staffProcedure.query(async ({ ctx }) => {
    return ctx.orgDb.invoice.findMany({
      orderBy: { createdAt: "desc" },
    });
  }),
});
 
// Côté client : appel typé automatiquement
const { data } = api.invoice.getAll.useQuery();
// data est typé : Invoice[]

Et l'interface ?

Tailwind CSS v4 avec des composants shadcn/ui permet d'avoir un design system cohérent très tôt. Voir Tailwind CSS v4 : construire un design system SaaS en 1 journée.

Si vous ne voulez pas assembler tout cela vous-même, un boilerplate évite des semaines de plomberie. L'estimation dépend de votre expérience, mais le calcul est simple à faire : Quel boilerplate SaaS Next.js choisir en 2026 compare les options.

Étape 3 : isoler les données de chaque client dès le premier jour

C'est le sujet critique d'un SaaS B2B : une organisation ne doit jamais voir les données d'une autre. Deux principes, l'un pour les lectures, l'autre pour les écritures.

Lectures : un filtre automatique. Une extension Prisma ($extends) ajoute organizationId à chaque findMany, findFirst, findFirstOrThrow, count, aggregate et groupBy sur les modèles concernés. Un développeur ne peut plus oublier ce filtre sur une lecture.

Écritures : une règle explicite. create, update et delete ne passent pas par ce filtre. Ils portent organizationId dans leur where, et dans leurs data à la création.

// Lecture : organizationId est ajouté par ctx.orgDb
const clients = await ctx.orgDb.client.findMany();
 
// Écriture : organizationId explicite dans le where (protection IDOR)
await ctx.db.client.update({
  where: { id: input.id, organizationId: ctx.session.user.organizationId },
  data: input.data,
});

Quand une ressource n'appartient pas à l'organisation de l'utilisateur, répondez NOT_FOUND et non FORBIDDEN : un attaquant ne doit pas apprendre qu'un identifiant existe.

Pour aller au fond du sujet : Multi-tenant avec Prisma et tRPC : isoler les données par organisation.

Étape 4 : authentification et permissions

L'authentification, ce n'est pas qu'un formulaire de connexion. C'est l'identité, l'appartenance à une organisation et les droits de chaque membre. Deux règles simples : la session et la permission se vérifient côté serveur, dans chaque procédure, jamais seulement dans l'interface ; et les permissions se décrivent sous la forme ressource:action, dans une matrice unique plutôt que dispersées dans le code.

Le cas complet, avec les rôles et l'isolation par organisation, est traité dans Authentification multi-tenant avec NextAuth v5. La documentation sur les permissions décrit la matrice de HeartCo.

Étape 5 : paiements et facturation

Utilisez Stripe Checkout plutôt qu'un formulaire de carte maison, traitez les webhooks de façon idempotente, et vérifiez leur signature. Quand vous comparez vous-même une signature HMAC, utilisez une comparaison en temps constant (crypto.timingSafeEqual), jamais ===.

Pour un SaaS français, la TVA et les factures ont leurs propres règles : voir Intégrer Stripe dans un SaaS français : TVA, factures, webhooks.

Étape 6 : les emails transactionnels

Confirmations, factures, relances : ces emails font partie du produit. Choisissez un fournisseur avec un bon suivi de délivrabilité, et configurez SPF, DKIM et DMARC sur votre domaine avant le lancement, pas après le premier email en spam. Le comparatif est dans Resend vs SendGrid vs Postmark.

Étape 7 : sécurité, limites d'usage et conformité

Toute route qui coûte de l'argent, comme un envoi d'email ou un appel à un modèle d'IA, doit être limitée par utilisateur. Voir Rate limiting Next.js avec Upstash Redis.

Côté données personnelles, la checklist RGPD pour un SaaS B2B français recense ce qu'il faut prévoir avant d'accepter un premier client. L'approche de HeartCo est résumée sur la page sécurité.

Étape 8 : tests et intégration continue

Écrivez au minimum un test qui prouve qu'un utilisateur de l'organisation B reçoit NOT_FOUND sur une ressource de l'organisation A, pour chaque router critique. C'est le test qui vous protège de la pire erreur d'un SaaS B2B. La méthode est dans Tester un SaaS multi-tenant : 7 patterns Vitest indispensables.

Faites tourner lint, vérification de types, tests et build à chaque pull request : CI/CD GitHub Actions pour SaaS Next.js.

Étape 9 : déployer

Avant le jour du lancement, vérifiez trois choses : les variables d'environnement sont validées au démarrage, les migrations de base de données sont versionnées, et des alertes d'erreur et de disponibilité sont en place. La checklist complète est dans Déployer un SaaS Next.js en production sur Vercel.

Étape 10 (optionnelle) : ajouter de l'IA

Une fonctionnalité d'IA n'est utile que si elle résout une tâche précise. Limitez son usage par plan et par utilisateur avant de l'ouvrir. Cinq cas concrets, avec le code, sont détaillés dans Mistral AI dans un SaaS B2B : 5 use-cases en TypeScript.

Un calendrier en quatre semaines

À titre indicatif, pour un développeur qui part d'un boilerplate :

1. Semaine 1 : cloner le projet, configurer l'authentification et la base, déployer sur Vercel.
2. Semaine 2 : construire les trois fonctionnalités clés de votre SaaS.
3. Semaine 3 : paiements, emails transactionnels, onboarding.
4. Semaine 4 : bêta-testeurs, retours, itérations.

Ce rythme suppose que les fondations (authentification, multi-tenant, paiements) existent déjà. Construites de zéro, elles prennent plusieurs semaines à elles seules.

Erreurs à éviter

• Parler d'argent trop tard : abordez le prix dès les premiers entretiens. L'ajustement fin viendra après, mais il faut savoir très tôt si quelqu'un paiera.
• Multiplier les fonctionnalités : trois bien faites valent mieux que vingt bâclées.
• Repousser le multi-tenant : l'ajouter après coup sur un produit existant est l'une des migrations les plus pénibles. Posez-le dès le jour 1.
• Reconstruire les fondations : l'authentification, les paiements et les permissions ne différencient pas votre produit. Votre temps est mieux employé ailleurs.

Pour aller plus loin

• ShipFast vs HeartCo : quel boilerplate SaaS choisir en 2026 ?
• Lancer un SaaS sans coder en 2026, la stack hybride no-code + code
• Documentation HeartCo : démarrage
• Comparatifs HeartCo