MVP SaaS : quoi inclure avant le premier test ?

Le minimum d’un MVP SaaS ne se compte ni en écrans ni en fonctions. Il prend la forme d’un test borné : une population précise obtient un résultat vendu par un parcours défini, puis un événement observable indique s’il faut continuer, modifier ou arrêter. Le « contrat de test » relie ce résultat aux responsables, aux limites et aux preuves attendues. Même réduit, le périmètre couvre l’exploitation dont le test dépend.

Écrivez d’abord sept éléments : le format et la période exacte du test, le résultat vendu, l’événement qui fera preuve, le nombre maximal de clients, le mode de vente et la capacité humaine totale disponible sur cette période. Passez ensuite les sept familles en revue. Une fonctionnalité absente est acceptable si le contrat attribue encore chaque responsabilité nécessaire au test.

Avec un premier client en production, chaque famille reçoit un traitement actuel. Le couple « Non » puis « Reporter » laisse la responsabilité sans traitement ; un choix manuel ou intégré reste possible.

Le format fixe ce que vous pourrez conclure. Un prototype sans production peut tester une compréhension ou un parcours sans accueillir de données réelles. Un pilote accompagné sert quelques utilisateurs avec une équipe présente et des limites annoncées. Un premier client en production dépend du service. Son invitation déclenche la revue des conditions d’exploitation, de sécurité, de continuité et de support prévues pour ce cas.

Partez du moment où l’utilisateur cherche à obtenir le résultat, puis suivez les états normaux et les échecs. Nommez la personne qui l’invite. Décrivez ce qui arrive quand son accès est refusé, sa donnée invalide, son paiement échoué ou son résultat incomplet. Pour chaque échec, attribuez la détection, la réponse, la restauration et la décision suivante. Cette journée transforme une liste d’écrans en responsabilités testables.

Une ouverture de session ou un clic ne vaut preuve que s’il correspond au résultat vendu. Avant le test, écrivez qui consultera l’événement retenu, à quel moment et quelle décision il pourra réellement changer.

Les sept familles répartissent sept responsabilités ; elles ne prescrivent aucun module logiciel. Pour chacune, indiquez si elle est nécessaire au test, le choix retenu, le responsable, la preuve attendue et la reprise en cas d’échec. Terminez par le « déclencheur de réexamen » : l’événement observable qui vous obligera à revoir ce choix.

Une décision « non nécessaire » doit rester motivée par le format. Dans un prototype ou un pilote borné, ce motif peut justifier un report. Avec un premier client en production, le domaine reste actif et demande un traitement actuel. Ce traitement peut être manuel ou confié à une intégration.

Si le test traite des données personnelles, consignez la finalité, la minimisation, les rôles, la base légale, la conservation et les mesures adaptées au risque. Pour la continuité, rejouez un scénario réaliste de restauration : la présence d’une sauvegarde ne suffit pas. Pour les journaux techniques, nommez l’événement à observer et les secrets à exclure.

Une opération manuelle permet d’apprendre avant d’automatiser si vous nommez l’opération, son responsable, sa limite, sa reprise en cas d’échec et le moment où ce choix devra être revu. Additionnez ensuite la charge de toutes les familles manuelles pour le nombre maximal de clients du test. Nommez d’abord la période couverte : les occurrences par client et la capacité totale doivent porter sur l’ensemble de cette même période. Aucune conversion implicite de semaine, de jour ou de disponibilité n’est appliquée.

sur une même période nommée : charge d’une opération = minutes par occurrence × occurrences par client sur toute la période × clients
charge manuelle totale sur cette période = somme des opérations manuelles
capacité restante sur cette période = capacité totale disponible sur cette même période − charge manuelle totale

Pour la période fictive « Du 7 septembre au 18 octobre 2026 inclus — période fictive du pilote Accordia », Accordia consomme 237 minutes sur une capacité totale de 300 minutes, soit 63 minutes restantes. Chaque fréquence par client et cette capacité couvrent toute la même période. Le calcul établit uniquement que la charge décrite tient dans la capacité saisie, sous les hypothèses écrites. Il n’établit ni la sécurité ni la légalité du test.

Dans la variante à cinq clients, la même organisation demande 395 minutes et dépasse la capacité de 95 minutes. La variante à six clients double exactement la population fictive de départ : la charge atteint 474 minutes et dépasse la capacité de 174 minutes. Ce doublement exact vient des seuls facteurs inchangés de l’exemple.

Le moteur examine le report critique avant la capacité. Reporter la continuité nécessaire laisse 177 minutes calculées et maintient le STOP. Si la durée ou le responsable d’une opération manuelle est inconnu, les 165 minutes des seules opérations exploitables restent visibles avec l’état « partiel/inexploitable », sans permettre de conclure : le STOP « opération manuelle non bornée » reste prioritaire sur le dépassement de capacité.

Un achat autonome sans procédure d’échec de paiement bloque aussi la revue. Dans ce mode, « Vente et droits associés » doit être nécessaire : la déclarer « Non » puis la reporter reste un STOP, même avec les états et la procédure complets. En production, déclarer toute autre famille « Non » puis la reporter provoque également un STOP : le libellé ne supprime pas la responsabilité.

Le formulaire s’ouvre vide ; vous pouvez charger l’exemple fictif à la demande. Le calcul se fait uniquement dans votre navigateur : aucune requête réseau, aucun stockage local et aucun téléchargement. Le résultat réunit la période, les états et la procédure d’achat autonome, chaque limite et équation manuelle, les inconnues, le statut et un texte Markdown sélectionnable ou copiable. Ce texte conserve ainsi les décisions qui ont conduit au verdict.

Les limites numériques écartent les entrées hors du périmètre technique : un million au maximum pour les clients, les minutes et les occurrences, avec trois décimales au plus. Les minutes par occurrence et les occurrences par client doivent être strictement positives ; une capacité totale nulle reste une décision possible. Ces bornes ne sont pas des références commerciales. Corrigez toute valeur signalée avant d’interpréter le statut.

# Contrat du premier client SaaS — brouillon local

- Statut : STOP_REQUIRED_DECISIONS_UNKNOWN
- Lecture : STOP — décisions indispensables à vérifier
- Format du test : À vérifier
- Période couverte par le test : À vérifier
- Résultat vendu : À vérifier
- Événement de preuve : À vérifier
- Mode de vente : À vérifier
- États d’achat autonome et de droits : Non applicable — achat autonome non retenu
- Procédure d’échec de paiement autonome : Non applicable — achat autonome non retenu
- Clients du test : À vérifier
- Capacité manuelle totale déclarée sur cette période : À vérifier

## Capacités

| Famille | Nécessaire | Traitement | Responsable | Preuve | Reprise sur échec | Déclencheur |
| --- | --- | --- | --- | --- | --- | --- |
| Parcours de valeur | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Comptes et accès | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Données et continuité | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Vente et droits associés | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Aide et incidents | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Administration et exploitation | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |
| Mesure et sortie | INCONNU | À vérifier | À vérifier | À vérifier | À vérifier | À vérifier |

## Charge manuelle planifiée

Période commune : À vérifier
Les occurrences par client et la capacité totale couvrent l’ensemble de cette même période, sans conversion implicite.

Aucune équation exploitable. À vérifier.

Les incidents imprévisibles ne valent jamais zéro : ils restent hors de la somme planifiée et exigent la reprise sur échec écrite dans chaque famille.

## Décisions à vérifier

- Format du test à vérifier
- Période couverte par le test à vérifier
- Résultat métier vendu à vérifier
- Événement qui prouve le résultat à vérifier
- Mode de vente à vérifier
- Nombre de clients du test à vérifier
- Capacité manuelle disponible à vérifier
- Parcours de valeur : nécessité pour le test à vérifier
- Parcours de valeur : traitement à vérifier
- Parcours de valeur : preuve attendue à vérifier
- Comptes et accès : nécessité pour le test à vérifier
- Comptes et accès : traitement à vérifier
- Comptes et accès : preuve attendue à vérifier
- Données et continuité : nécessité pour le test à vérifier
- Données et continuité : traitement à vérifier
- Données et continuité : preuve attendue à vérifier
- Vente et droits associés : nécessité pour le test à vérifier
- Vente et droits associés : traitement à vérifier
- Vente et droits associés : preuve attendue à vérifier
- Aide et incidents : nécessité pour le test à vérifier
- Aide et incidents : traitement à vérifier
- Aide et incidents : preuve attendue à vérifier
- Administration et exploitation : nécessité pour le test à vérifier
- Administration et exploitation : traitement à vérifier
- Administration et exploitation : preuve attendue à vérifier
- Mesure et sortie : nécessité pour le test à vérifier
- Mesure et sortie : traitement à vérifier
- Mesure et sortie : preuve attendue à vérifier

## Décision humaine

Au moins une décision structurante, une preuve, la période du test ou une entrée numérique manque ou est invalide. Aucune inconnue n’est convertie en zéro.

Complétez d’abord les décisions listées, puis relisez les capacités une par une.

Ce brouillon n’est ni une autorisation juridique, ni une homologation de sécurité, ni une mise en production.

Le choix dépend de l’incertitude à fermer. Une maquette ou un entretien structuré peut suffire pour comprendre le problème. Pour éprouver la livraison du résultat, un service accompagné révèle le processus avant son automatisation. Une capacité générique déjà couverte par un produit existant peut être intégrée si ses états et ses erreurs préservent la preuve recherchée.

Pour une intégration, écrivez qui détecte l’indisponibilité, quelle solution de repli protège le client, qui reprend l’erreur et comment quitter le fournisseur sans perdre la preuve ou les données nécessaires.

Les contenus concurrents consultés en août 2026 suivent souvent deux recettes. La première réduit le MVP à « une promesse, un parcours, une mesure », parfois assortis de quotas ou de délais universels. La seconde impose d’emblée une plateforme mutualisée entre clients, un paiement automatisé, une connexion d’entreprise ou une durée fixe. Les deux confondent le cœur d’apprentissage et le minimum opérationnel. Définissez chaque capacité depuis le test réel et écartez tout nombre de clients, de semaines ou gain de vitesse externe présenté comme règle.

Avant toute invitation réelle, une personne désignée relit la promesse et les preuves, puis confirme qu’un responsable est attribué à chaque choix. La même revue couvre les accès, les données, les tests de reprise, la sécurité, l’accessibilité, les incidents, la capacité et les termes convenus avec le client.

Le résultat du moteur n’a aucune autorité juridique ou technique propre. « Candidat » veut seulement dire que le contrat est assez renseigné pour entrer dans cette revue.

Test automatisé, image valide et page rendue prouvent chacun leur propre contrôle. Le déploiement, la publication, l’indexation et l’acceptation par un client demandent des preuves distinctes après la revue éditoriale et technique.

Combien de fonctionnalités faut-il dans un MVP SaaS ?

Il n’existe aucun nombre universel. Gardez ce qui produit la preuve choisie et rend le format retenu exploitable ; une capacité peut rester manuelle ou intégrée.

Peut-on lancer sans paiement automatisé ?

Oui, si le mode convenu est un contrat et une facture gérés manuellement, avec responsable et droits associés. Si l’achat est autonome, marquez « Vente et droits associés » comme nécessaire, puis fermez les états de paiement, d’échec et de retrait des droits.

Le support peut-il être un simple courriel ?

Oui, pour un test borné, si l’adresse, le responsable, les délais réalistes, l’escalade et la communication d’incident sont écrits. Une boîte non surveillée n’est pas un dispositif d’aide.

Faut-il automatiser les sauvegardes dès le pilote ?

L’automatisation des sauvegardes n’est pas obligatoire dans tous les pilotes. Une continuité déclarée nécessaire doit exister et rester testable selon les données et le risque ; une copie jamais restaurée ne démontre pas la reprise.

Un statut candidat signifie-t-il que le produit est conforme ?

Non. « Candidat » signifie seulement que le contrat peut être relu. La conformité, la sécurité, l’accessibilité, les engagements contractuels et la décision de production restent à vérifier dans le contexte réel.

Que faire si une durée manuelle est inconnue ?

Gardez-la « à vérifier », mesurez un petit échantillon ou nommez une borne prudente défendable, puis rejouez le calcul. Ne la remplacez ni par zéro ni par une moyenne de marché sans preuve.

Quand passer du manuel à l’automatisation ?

Quand le déclencheur écrit avant le test est atteint : charge, fréquence, erreur, délai, risque ou volume maximal. Comparez alors automatisation, réduction du test, intégration et arrêt.

Ce contrat définit-il une architecture SaaS ?

Non. Il organise les décisions du test. Architecture, isolation des clients, hébergement, contrôle d’accès et intégrations doivent être choisis selon les contraintes réelles et faire l’objet de leur propre revue.

Peut-on utiliser le Markdown généré comme cahier des charges ?

Oui, comme point de départ seulement. Il faut encore faire relire les responsabilités, les preuves, les obligations, les tests d’acceptation et les conditions de production, puis versionner les décisions acceptées.