Quelle est la différence entre un MVP et un v1 en production ?

Un MVP répond à « est-ce que quelqu’un veut ça ? » et peut dépendre de vous pour fonctionner. Un v1 en production répond à « est-ce que ça tient quand un client s’en sert tous les jours ? » : auth, données solides, paiements réels, emails, erreurs gérées, admin, monitoring. La frontière est le premier client payant.

De quoi un SaaS prêt pour la production a-t-il besoin ?

Authentification, autorisation, un modèle de données solide, gestion des erreurs, facturation, emails transactionnels, analytics, interface d’administration, outillage de support, journaux, monitoring, sécurité, sauvegardes, rate limits, cas limites gérés, exports, confidentialité et chemins de récupération. La liste complète est sur cette page.

Combien de temps faut-il pour construire un v1 de SaaS ?

Quatre à six semaines de sprint après une semaine de cadrage, avec une démo chaque vendredi. La semaine une pose les données et l’auth ; les semaines deux et trois livrent le flux principal et les paiements ; les suivantes construisent ce qui fait tenir le produit.

Peut-on partir du prototype existant ?

Parfois pour l’interface, rarement pour les données. Un prototype a en général un modèle de données conçu pour la démo ; je le repose en semaine une plutôt que de le payer en semaine dix. Le cadrage le dit franchement.

Que se passe-t-il après le v1 ?

Le produit vous appartient, avec trente jours de support. La suite se décide avec les premiers clients : chaque évolution est un nouveau forfait cadré, ou votre équipe reprend — le code est construit pour ça.

V1 SaaS · Production

Développement d’un v1 de SaaS.

Un prototype n’a besoin que de démontrer une idée. Un v1 doit survivre à son premier vrai client. C’est ce que je construis : la première version d’un SaaS qui tient seule — authentification, autorisation, modèle de données solide, gestion des erreurs, facturation, emails transactionnels, analytics, interface d’administration, journaux, monitoring, sécurité et sauvegardes — sans les fonctionnalités qui peuvent attendre le deuxième client.

Cadrer un v1 Lire : Prototype ou v1 ↓Formulaire de contact

Mis à jour le 17 oct. 2026

En bref

Thèse: Un prototype démontre. Un v1 survit à son premier client.
Délai: 4 à 6 semaines de sprint, démo chaque vendredi
Fourchette: CHF 20’000 – 45’000 au forfait selon le périmètre
Ordre de construction: Données → auth → flux principal → paiements → emails → admin → observabilité → déploiement
Ce qui attend: Multi-tenant avancé, API publique, intégrations secondaires, personnalisation, mobile natif
En production: Atamatax · Horvera · Wabiro — construits avec cette liste

La question n’est pas « combien de fonctionnalités » mais « que se passe-t-il quand ça se passe mal ». Un premier client va entrer une donnée inattendue, payer avec une carte qui échoue, oublier son mot de passe, demander un export, et écrire au support à 22h. Un v1 est la version qui absorbe tout cela sans que vous ayez à ouvrir la base de données.

Cette page est la liste de ce qu’un v1 orienté production contient — dans l’ordre où je le construis — et de ce qu’il ne contient volontairement pas. Elle sert de référence pour cadrer un projet, y compris avec quelqu’un d’autre que moi.

01 — Le contenu d’un v1

Ce qu’un v1 orienté production doit contenir

Dix-huit éléments. Aucun n’est une fonctionnalité que le client demande ; tous sont ce qui vous évite de le perdre.

Authentification: Inscription, connexion, réinitialisation, vérification d’email, sessions côté serveur, protection contre la force brute. Le premier écran qu’un client voit, et le premier qui casse dans un prototype.
Autorisation: Qui peut voir et faire quoi — modélisé en base (compte, rôle, ressource), vérifié à chaque lecture et écriture côté serveur. Une interface qui cache un bouton n’est pas une autorisation.
Modèle de données: Le schéma Postgres avec ses contraintes, ses index et ses migrations versionnées. Posé en premier, parce qu’il est le seul élément que le reste du produit ne peut pas contourner.
Gestion des erreurs: Chaque échec a un message pour l’utilisateur, une entrée dans le journal et, s’il est grave, une alerte pour vous. Un v1 qui échoue en silence perd des clients sans que personne ne le sache.
Facturation: Stripe avec webhooks signés, état d’abonnement en base, factures, échecs de paiement, changements de plan, annulation. Testée avec les cartes de test de tous les cas — pas seulement le succès.
Emails transactionnels: Bienvenue, vérification, reçu, échec de paiement, réinitialisation — depuis un domaine vérifié, avec un journal des envois. Le canal par lequel votre produit parle quand l’utilisateur n’est pas dessus.
Analytics: Les événements qui disent si le produit est utilisé : inscription, activation, action clé, paiement, désabonnement. Sans cela, le deuxième mois se pilote à l’aveugle.
Interface d’administration: Chercher un compte, voir ce qu’il a fait, corriger, rembourser, désactiver. Le premier ticket de support arrive avant la première fonctionnalité demandée.
Outillage de support: Un moyen de voir ce que l’utilisateur voit — ses données, ses dernières actions, ses emails reçus — sans requête SQL. Souvent une page de l’admin ; toujours nécessaire.
Journaux: Journaux structurés côté serveur, journal d’audit pour les actions sensibles (paiement, suppression, changement de rôle). Ce que vous relirez le jour où un client dit « ce n’est pas moi ».
Monitoring: Disponibilité, erreurs, latence, échecs de webhook — avec une alerte qui vous réveille si nécessaire. Un v1 sans monitoring apprend ses pannes par ses clients.
Sécurité: Validation côté serveur de chaque entrée, secrets hors du code, en-têtes de sécurité, données scopées par compte, limitation de débit sur les endpoints sensibles, dépendances à jour.
Sauvegardes: Sauvegardes automatiques de la base, testées au moins une fois par une restauration réelle. Une sauvegarde jamais restaurée est une hypothèse.
Rate limits: Sur l’authentification, les formulaires publics, les endpoints coûteux et les fonctionnalités facturées à l’usage. Ce qui sépare un pic de trafic d’une facture surprise.
Cas limites: Le compte sans données, le nom de 200 caractères, le fuseau horaire, la double soumission, le webhook reçu deux fois. Ils arrivent tous la première semaine.
Exports de données: L’utilisateur peut récupérer ses données (CSV, JSON) — une exigence de confiance, souvent légale, et le premier outil de votre propre support.
Confidentialité: Quelles données sont collectées, où elles sont hébergées, combien de temps, qui y accède — décidé et documenté pour la nLPD et le RGPD, avec la suppression de compte qui fonctionne.
Chemins de récupération: Ce qui se passe quand un paiement échoue, quand un email ne part pas, quand un utilisateur supprime la mauvaise chose. Un v1 ne prévient pas tout ; il permet de réparer.

02 — Ce qui attend

Ce qu’un v1 ne contient volontairement pas

Les fonctionnalités qui semblent indispensables avant le lancement et qui, presque toujours, attendent le deuxième client.

La personnalisation avancée — thèmes, champs personnalisés, workflows configurables. Vous ne savez pas encore ce qui doit être configurable.
L’API publique et les webhooks sortants — tant qu’aucun client n’a demandé à s’intégrer.
Les intégrations secondaires — la première intégration est dans le v1 si elle est au cœur du produit ; les suivantes attendent une demande.
Le multi-tenant avancé (organisations imbriquées, SSO d’entreprise) — sauf si vos premiers clients sont des entreprises.
L’application mobile native — une application web responsive couvre le premier client.
L’optimisation prématurée — cache distribué, microservices, files de messages. Un Postgres bien indexé porte loin.
Les fonctionnalités « au cas où » — chaque écran en plus est un écran à maintenir avant d’avoir un utilisateur.

La règle : si un élément vous évite de perdre le premier client, il est dans le v1. S’il vous aide à en gagner un dixième, il attend. La distinction entre prototype, MVP et v1 est détaillée dans Prototype ou v1.

03 — Ordre

Dans quel ordre je construis un v1

Semaine une : le modèle de données et l’authentification. Le schéma Postgres est posé, migré, et le premier compte peut se créer, se connecter et ne rien voir d’autre que ce qui lui appartient. Rien d’autre n’est visible, et c’est voulu — tout ce qui suit s’appuie dessus.

Semaines deux et trois : le flux principal — la chose pour laquelle le client paie — de bout en bout, avec ses erreurs gérées, puis les paiements avec Stripe et leurs webhooks, puis les emails. La démo du vendredi de la semaine trois est le moment où un vrai utilisateur pourrait, en principe, payer.

Semaines quatre à six : l’interface d’administration, les analytics, les journaux, le monitoring, les sauvegardes, les cas limites, les exports, la page de confidentialité, la documentation du hand-off. C’est la partie qu’un prototype saute, et celle qui fait qu’un v1 tient. Le détail technique est dans Architecture Next.js pour un SaaS en production.

04 — Coût

Ce que coûte un v1 de SaaS

Entre CHF 20’000 et 45’000 au forfait, en 4 à 6 semaines. Le bas de la fourchette est un produit à un rôle, un flux principal, des paiements simples ; le haut ajoute plusieurs rôles, une logique métier dense, des intégrations, un tableau de bord. La mécanique est dans Combien coûte le développement d’un v1 de SaaS en Suisse ; le calculateur situe votre produit dans la fourchette.

Estimer le périmètre avec le calculateur

Cinq minutes. Une bande de complexité, pas un devis.

05 — Recruter ?

Recruter pour construire le v1 ?

Un v1 a une fin : la version qui tient face au premier client. Recruter pour le construire, c’est engager une personne pour une capacité permanente avant de savoir si le produit trouvera des clients — et la laisser seule face à toutes les décisions d’architecture. Quand le produit tient, recruter devient la bonne décision : la feuille de route ne s’arrête plus.

Le guide recruter ou externaliser compare les deux chemins avec le coût employeur réel en Suisse.

Est-ce le bon service ?

Ce service a du sens si

Un vrai client — payant, ou avec ses données — va se servir du produit dans les trois mois.
Vous avez un prototype ou un MVP qui « marche » tant que vous êtes derrière, et ça ne tient plus.
Vous levez des fonds ou signez un pilote et il vous faut la version qu’on peut montrer sans s’excuser.

Ce n’est pas le bon service si

Vous testez encore si quelqu’un veut le produit — un prototype ou une page d’attente coûte une fraction.
Le produit doit être une plateforme complète dès le premier jour — c’est un v1 par découpage, pas un v1.
Vous voulez tout garder du prototype existant sans revue de l’architecture — je repose souvent le modèle de données, et je le dis.

Preuves — produits construits et exploités

Mes propres produits, avec leur état réel. Aucun projet client n’est publié à ce jour.

Méthode

Quatre étapes, scope fixe, prix convenu à l’avance.

01
Diagnostic
20 minutes, gratuit. Modèle économique, workflows, risques, périmètre produit. Si je ne suis pas la bonne personne, je le dis.
02
Architecture et proposition
Sous 48h : modèle de données, frontières du système, intégrations, UX — et un seul prix forfaitaire avec des jalons datés. Pas de « à partir de ».
03
Construction
4 à 6 semaines d’itérations contrôlées. Démo chaque vendredi sur une preview Vercel. Vous voyez le système grandir en direct — pas de boîte noire.
04
Mise en production
Paiements, analytics, déploiement, workflows opérationnels. Vous repartez avec le repo, les comptes, le pipeline — et 30 jours de réponses sous 24h.
05
Amélioration
Itération mesurée sur l’usage réel : un nouveau forfait par périmètre, ou rien si votre équipe reprend. Pas de dépendance cachée.

Le déroulé complet, les garanties et les prix →

Questions fréquentes

Quelle est la différence entre un MVP et un v1 en production ?
Un MVP répond à « est-ce que quelqu’un veut ça ? » et peut dépendre de vous pour fonctionner. Un v1 en production répond à « est-ce que ça tient quand un client s’en sert tous les jours ? » : auth, données solides, paiements réels, emails, erreurs gérées, admin, monitoring. La frontière est le premier client payant.
De quoi un SaaS prêt pour la production a-t-il besoin ?
Authentification, autorisation, un modèle de données solide, gestion des erreurs, facturation, emails transactionnels, analytics, interface d’administration, outillage de support, journaux, monitoring, sécurité, sauvegardes, rate limits, cas limites gérés, exports, confidentialité et chemins de récupération. La liste complète est sur cette page.
Combien de temps faut-il pour construire un v1 de SaaS ?
Quatre à six semaines de sprint après une semaine de cadrage, avec une démo chaque vendredi. La semaine une pose les données et l’auth ; les semaines deux et trois livrent le flux principal et les paiements ; les suivantes construisent ce qui fait tenir le produit.
Peut-on partir du prototype existant ?
Parfois pour l’interface, rarement pour les données. Un prototype a en général un modèle de données conçu pour la démo ; je le repose en semaine une plutôt que de le payer en semaine dix. Le cadrage le dit franchement.
Que se passe-t-il après le v1 ?
Le produit vous appartient, avec trente jours de support. La suite se décide avec les premiers clients : chaque évolution est un nouveau forfait cadré, ou votre équipe reprend — le code est construit pour ça.

Développement d’un v1 de SaaS.

Ce qu’un v1 orienté production doit contenir

Ce qu’un v1 ne contient volontairement pas

Dans quel ordre je construis un v1

Ce que coûte un v1 de SaaS

Recruter pour construire le v1 ?

Ce service a du sens si

Ce n’est pas le bon service si

Preuves — produits construits et exploités

Quatre étapes, scope fixe, prix convenu à l’avance.

Diagnostic

Architecture et proposition

Construction

Mise en production

Amélioration