Créer un SaaS : de l’idée au MVP en 7 étapes

Créer un SaaS commence rarement par le code. Les projets qui s’enlisent ont souvent démarré par une liste de fonctions ou par le choix d’une technologie, avant d’avoir décidé pour qui, et pour quelle tâche précise, le produit existe. Résultat : une première version qui grossit, recule, et sort sans savoir ce qu’elle doit prouver.

La méthode qui suit tient en 7 étapes, de l’idée aux premiers utilisateurs. Je l’illustre avec Docalio, le portail client B2B que j’ai conçu pour demander des pièces et faire valider des documents. Le produit est en phase de lancement : je parle ici des décisions prises, pas de résultats chiffrés.

Un MVP, c’est quoi exactement ?

Le terme a été popularisé par Eric Ries, qui définit le minimum viable product comme « la version d’un nouveau produit qui permet à une équipe de recueillir le maximum d’apprentissage validé sur ses clients avec le moins d’effort » (traduction). Autrement dit, un MVP sert à apprendre, pas à impressionner.

Trois confusions à éviter :

• Ce n’est pas une maquette. Une maquette se montre, un MVP s’utilise : de vrais utilisateurs y accomplissent une vraie tâche.
• Ce n’est pas une version au rabais. « Minimum » porte sur le périmètre, pas sur la qualité. Un seul parcours, mais qui fonctionne à chaque fois.
• Ce n’est pas la V1 de vos rêves. Tout ce qui ne sert pas le parcours principal attend la suite.

Pour un SaaS B2B, j’ajoute une règle : le minimum ne s’applique jamais à la sécurité. Dès que des clients confient leurs données, la séparation entre comptes doit être parfaite dès le premier jour.

Étape 1 : partir d’un problème précis et d’un utilisateur réel

Écrivez le problème en une phrase, sur ce modèle : « [qui] perd [quoi] quand [situation] ». Si la phrase demande trois virgules et deux « et », le périmètre est déjà trop large.

Pour Docalio, le constat de départ est simple : cabinets comptables, juridiques, studios passent du temps à réclamer des pièces à leurs clients. Les documents arrivent par e-mail, en pièce jointe, dans le désordre, et l’on ne sait plus ce qui manque. J’ai choisi de recentrer le produit sur cette collecte de pièces plutôt que sur le partage de fichiers en général : un besoin précis et fréquent parle mieux qu’un espace de stockage de plus, et le partage devient un argument secondaire.

Posez aussi la question que l’on oublie souvent en B2B : celui qui paie est-il celui qui utilise ? Sur Docalio, il y a deux utilisateurs. Le professionnel crée les demandes et suit les dossiers ; son client dépose ou valide des documents. Le premier achète, mais c’est la facilité du second à répondre qui décide si le produit tient sa promesse.

• Le problème tient en une phrase, sans « et »
• Vous connaissez plusieurs personnes réelles qui ont ce problème, et vous leur avez parlé
• Vous savez ce qu’elles utilisent aujourd’hui : e-mail, tableur, logiciel du marché
• Vous savez qui paiera, et qui utilisera

Étape 2 : écrire ce que la première version ne fera pas

C’est l’étape la plus difficile, et la plus rentable. Chaque fonction ajoutée coûte deux fois : une fois pour la construire, puis en continu pour la tester, la maintenir et la sécuriser. La règle que j’applique : une fonction entre dans la V1 seulement si, sans elle, le parcours principal ne peut pas aller au bout.

Exemple type, pour un SaaS B2B :

Gardez précieusement la colonne de droite : c’est votre feuille de route. Elle rassure les premiers clients (« c’est prévu ») sans retarder le lancement. Si vous travaillez avec un prestataire, elle a sa place dans le cahier des charges.

Étape 3 : dessiner le parcours principal, écran par écran

Le parcours principal va du premier contact jusqu’au moment où l’utilisateur obtient ce qu’il est venu chercher. Écrivez-le comme une liste d’écrans numérotés, avec pour chacun une seule action attendue. Puis comptez : chaque écran, chaque champ, chaque e-mail de confirmation est une occasion d’abandon.

Sur Docalio, la décision structurante a porté sur le client final : il ouvre son portail par un lien sécurisé, sans inscription. Il consulte, dépose ou approuve un document sans mot de passe à créer ni compte à oublier. Ce choix simplifie l’usage, mais déplace la difficulté vers la sécurité : un lien qui donne accès à des documents doit être impossible à deviner et limité dans le temps. C’est l’objet de l’étape 5.

Avant de coder, testez ce parcours sur des maquettes cliquables avec quelques futurs utilisateurs. Vous ne cherchez pas leur avis sur les couleurs : vous regardez où ils hésitent.

Étape 4 : choisir une pile technique éprouvée, pas originale

Un MVP n’est pas le moment d’expérimenter. Choisissez des outils documentés, répandus, et qui vous évitent d’administrer des serveurs. Voici ce que je pratique sur mes deux produits :

• Next.js pour l’interface et la logique côté serveur, sur Docalio comme sur Reviu, avec TypeScript et Tailwind CSS sur Docalio ;
• Supabase, sur les deux produits : un service qui réunit base de données PostgreSQL, authentification et stockage de fichiers ;
• Stripe pour le paiement, sur la boutique Reviu ;
• Vercel pour l’hébergement et les déploiements.

Trois critères comptent plus que la mode. La réversibilité : PostgreSQL est un standard, vos données s’exportent si vous changez d’outil. L’emplacement des données : celles de Docalio sont hébergées en Europe, un argument concret pour des clients qui confient des documents sensibles. Des coûts qui suivent l’usage, pour ne pas payer une infrastructure dimensionnée pour mille clients quand vous en avez trois.

Étape 5 : sécuriser l’accès aux données dès le premier client

Un SaaS B2B est dit multi-locataire : plusieurs organisations partagent la même application et la même base, et chacune ne doit voir que ses propres données. C’est là que se joue le premier risque de l’OWASP Top 10:2025, le contrôle d’accès défaillant : un utilisateur change un identifiant dans une adresse et tombe sur le dossier d’un autre client.

Sur Docalio, trois principes ont été posés dès la conception :

• Données isolées par organisation : un cabinet ne peut jamais lire les dossiers d’un autre.
• Stockage privé : aucun document n’a d’adresse publique.
• Liens temporaires : l’accès à un fichier passe par un lien signé qui expire.

Quel que soit l’outil, ces règles se vérifient côté serveur, jamais seulement dans l’interface. Si vous partez sur Supabase, par exemple, sa documentation demande d’activer la sécurité au niveau des lignes (RLS) sur chaque table d’un schéma exposé : une fois activée, aucune donnée n’est accessible par l’API avec la clé publique tant qu’une règle ne l’autorise pas. La clé secrète, qui contourne ces règles, ne doit jamais se retrouver dans le navigateur. Pour les fichiers, un compartiment privé n’a pas d’adresse publique, et l’on génère des liens signés à durée limitée.

Le RGPD entre en jeu au même moment. Son article 25 impose la protection des données dès la conception et par défaut, et la CNIL publie un guide RGPD du développeur très concret. Si votre SaaS traite les données des clients de vos clients, vous êtes en général leur sous-traitant au sens du RGPD, avec un contrat à prévoir. Le détail des contrôles à mettre en place est dans la checklist de sécurité d’une application web.

Étape 6 : déléguer le paiement à un spécialiste

Le paiement est le dernier endroit où innover. Avec Stripe, la page de paiement Checkout gère les paiements ponctuels comme les abonnements, et le portail client permet à vos abonnés de changer de moyen de paiement, de résilier ou de télécharger leurs factures, sans que vous développiez ces écrans.

Le point technique à soigner, ce sont les webhooks : c’est par eux que Stripe prévient votre application qu’un paiement a abouti. La documentation fixe trois règles :

• vérifier la signature de chaque événement, sinon n’importe qui peut simuler un paiement ;
• gérer les doublons : un même événement peut arriver plusieurs fois, d’où l’intérêt de garder la trace des identifiants déjà traités ;
• ne pas dépendre de l’ordre d’arrivée des événements, que Stripe ne garantit pas.

Sur Reviu, j’ai fait de Stripe la source de vérité des ventes : la provenance de la visite est recopiée dans les métadonnées Stripe de la commande, ce qui relie chaque vente à son canal. Testez tout dans un environnement de test (sandbox), avec les cartes de test de Stripe comme 4242 4242 4242 4242 : ces transactions ne déplacent aucun argent.

Faut-il faire payer dès le MVP ? En B2B, je le pense souvent : un paiement, même modeste, est le signal le plus fiable qu’un problème mérite d’être résolu. Un essai gratuit reste une bonne porte d’entrée (Docalio propose un parcours d’essai depuis son site), à condition de définir à l’avance ce qui comptera comme un succès.

Étape 7 : lancer petit et mesurer l’usage, pas les visites

La bonne question n’est pas « combien de personnes sont venues ? » mais « combien sont allées au bout du parcours principal, et sont revenues ? ». Choisissez deux ou trois indicateurs d’usage et suivez-les chaque semaine.

Sur Docalio, j’ai fait un choix assumé : aucun outil d’analytics tiers ni traceur publicitaire à ce stade. Pour des documents sensibles, la confiance passe avant la mesure marketing. Les indicateurs utiles viennent de l’application elle-même : pièces demandées, reçues, validées. Sur Reviu, au contraire, la boutique doit savoir quels canaux amènent des ventes : GA4 n’y est chargé qu’après consentement, avec un événement d’achat dédoublonné. J’explique cette mise en place dans le guide GA4 et consentement.

Ensuite, parlez à vos premiers utilisateurs, souvent. Notez chaque demande dans la colonne « attend la suite » de l’étape 2, et ne la faites entrer dans le produit que si elle revient chez plusieurs clients et sert le parcours principal.

En résumé : décider avant de développer

Un MVP réussi est d’abord une suite de décisions écrites : un problème en une phrase, une liste de ce qui attend, un parcours principal testé sur maquette, une pile technique sans surprise, des données cloisonnées dès le premier client, un paiement confié à un spécialiste et deux ou trois indicateurs d’usage. Le code vient ensuite, et il avance plus vite parce qu’il sait où il va.

Vous avez une idée de SaaS ou un espace client à créer ? Je vous aide à cadrer la première version puis à la mettre en ligne : voir la création de SaaS et d’application web.