Transformer l’idée en une hypothèse testable
Décrivez un utilisateur, un problème récurrent et un résultat attendu. Par exemple : un responsable reçoit des demandes par email et veut les attribuer sans perdre leur historique. L’hypothèse est que ce parcours mérite d’être adopté, pas que dix fonctionnalités auront l’air convaincantes en démonstration.
Décidez avant le test ce que vous observerez : la personne termine-t-elle sa tâche, où hésite-t-elle, revient-elle et demande-t-elle à poursuivre ? Une intention exprimée et un usage régulier sont des signaux différents.
Tester l’incertitude la plus importante
Si le risque porte sur l’intérêt du parcours, une maquette ou un test accompagné peut suffire au départ. S’il porte sur une intégration essentielle, vérifiez la connexion tôt. N’engagez pas tout le budget dans l’interface avant de savoir si la partie décisive est réalisable.
La méthode alpha de GOV.UK conseille de tester les hypothèses les plus risquées. Nous retenons ce principe de validation ; un prototype exploratoire et un produit exploitable restent deux livrables différents.
Choisir ce qui entre dans le MVP
Le MVP doit former un parcours cohérent, pas une collection d’écrans incomplets. Listez ce que l’utilisateur doit accomplir et ce que l’équipe peut traiter manuellement pendant un pilote. Indiquez clairement les limites aux testeurs.
- Une tâche principale et les données nécessaires pour la terminer.
- Des accès adaptés, une validation des entrées et des erreurs compréhensibles.
- Un moyen de recevoir les retours et de retrouver les incidents.
- Une liste explicite des fonctions reportées : pas d’engagement implicite.
Éviter une architecture prématurément complexe
Une première version a besoin de limites claires dans le code, de sauvegardes et d’une exploitation compréhensible. Elle n’a pas automatiquement besoin de services indépendants pour chaque fonction. Le choix technique doit répondre à des contraintes observées.
Martin Fowler décrit le coût d’une séparation en microservices lorsque les frontières du produit restent incertaines. Cette observation invite à justifier la complexité ; elle n’interdit pas une architecture distribuée quand le besoin l’exige.
Réserver une place à l’usage après livraison
Au budget de construction s’ajoutent les outils, l’hébergement et le travail d’exploitation. Prévoyez qui traite les retours, quelles données sont conservées et comment les prochaines décisions seront prises. Ne transformez pas chaque demande d’un testeur en développement automatique.
Le sprint MVP / SaaS Okys vise un premier parcours testable en 14 jours, à 5 000 € pour un périmètre approuvé. Vous payez la moitié au lancement et le solde à la livraison ; le code vous appartient. Cela ne promet ni toutes les fonctions d’un SaaS, ni des ventes, ni une montée en charge déjà validée. Une suite se cadre après examen des besoins.
Avant de décider
- Nommer un premier utilisateur et sa tâche prioritaire.
- Identifier l’hypothèse qui pourrait invalider le projet.
- Séparer le parcours indispensable des fonctions reportées.
- Prévoir exploitation, retours et critères pour décider de la suite.
Questions fréquentes
Faut-il intégrer le paiement dès le premier MVP ?
Seulement si encaisser fait partie de ce que vous devez tester. Un pilote accompagné peut parfois vérifier l’usage autrement. Les besoins de facturation et d’accès restent à cadrer.
Un sprint suffit-il pour lancer tout le SaaS ?
Pas nécessairement. Le sprint vise un premier parcours au périmètre défini. Les autres rôles, intégrations, exigences d’exploitation et fonctions se planifient selon le projet.