Ressources
Écris ton périmètre avant qu'on te donne un prix
Un template à remplir pour ton MVP.
Un prix donné avant que le périmètre soit écrit est un pari. Ce template sert à ne plus recevoir de paris.
Remplis-le une fois, puis envoie le même document à chaque studio ou développeur avec qui tu échanges. Tu recevras des devis vraiment comparables — et tu en apprendras beaucoup en voyant qui pose de bonnes questions dessus, et qui le chiffre sans rien demander.
Compte deux à trois heures. La section qui fait économiser le plus d'argent, c'est la 4.
Télécharger le template (.docx)
- 01
Le problème, en une phrase
Qui a le problème, quel est-il, et comment il s'en sort aujourd'hui.
Conseil — Si tu n'arrives pas à l'écrire en une phrase, le périmètre dérivera. Laisse la solution en dehors de cette phrase.
- 02
Qui l'utilise
Chaque type d'utilisateur, en une ligne : qui il est, et ce qu'il vient faire.
Conseil — Pense aux personnes qui font tourner le produit (toi, un administrateur, le support). Ce sont les utilisateurs que tout le monde oublie.
- 03
Les trois parcours clés
Les trois parcours qui font que ton produit vaut la peine d'être utilisé, décrits pas à pas, tels que l'utilisateur les vit.
Conseil — Écris « l'utilisateur ouvre…, voit…, appuie…, reçoit… », pas « le système doit… ». Si tu en as plus de trois, tu as plus d'un MVP.
- 04
V1 : dedans, dehors, plus tard
Trois listes.
- Dans la V1 — ce qui doit exister pour que les trois parcours fonctionnent.
- Dehors — ce que tu décides de ne pas construire.
- Plus tard — les bonnes idées, mises de côté jusqu'après le lancement.
Conseil — C'est ici que se font les économies. Chaque ligne que tu passes de « dedans » à « plus tard », c'est de l'argent gardé pour ce que tes utilisateurs demanderont vraiment. Un bon studio discutera cette section ; méfie-toi de celui qui ne le fait pas.
- 05
L'indicateur de réussite
Le seul chiffre qui te dira que la V1 a marché.
Conseil — « 30 réservations par semaine au deuxième mois » vaut mieux que « les utilisateurs adorent ». Un chiffre, avec une date.
- 06
Les écrans
La liste des écrans, avec pour chacun un croquis, une capture ou un lien si tu en as.
Conseil — Des croquis sur papier suffisent. Un prototype fait avec un outil d'IA aussi : un prototype cliquable est le meilleur périmètre qui soit.
- 07
Les données
Ce que le produit conserve, et si une partie est sensible (santé, paiements, enfants, documents personnels).
Conseil — Des données sensibles changent l'hébergement, la sécurité et la conformité. Dis-le maintenant, pas en semaine six.
- 08
Les intégrations
Tout ce avec quoi le produit doit communiquer : paiement, connexion, email, agendas, API tierces, outils existants.
Conseil — Chaque intégration représente un vrai travail. Nomme le service si tu le connais.
- 09
Les plateformes
Web, iOS, Android. Quels appareils, quelles langues.
Conseil — « Le web d'abord, le mobile ensuite » est une décision de V1 légitime — et moins chère.
- 10
Les contraintes
Échéance (et pourquoi), fourchette de budget, lieu d'hébergement imposé, réglementations applicables.
Conseil — Une échéance avec sa raison (« démo aux investisseurs le 12 mars ») est plus utile qu'une date seule. Donner une fourchette de budget n'est pas une faiblesse : c'est ce qui permet de te dire ce qui tient dedans.
- 11
L'administration et le back-office
Qui gère quoi en coulisses : les utilisateurs, les contenus, les paiements, les demandes de support.
Conseil — La partie que personne ne cadre, et celle qui surprend tout le monde sur la facture.
- 12
Ce qui existe déjà
Maquettes, prototype, app faite avec l'IA, tableur qui fait tourner l'activité, données existantes.
Conseil — Rien n'est perdu : ce qui existe fait comprendre ce que tu veux plus vite que n'importe quel document.
- 13
Les questions ouvertes
Ce que tu ne sais pas encore, et les hypothèses que tu fais.
Conseil — Lister ce que tu ne sais pas est une force. Les réponses du studio à cette section en disent long sur lui.
Un court exemple (fictif)
1. Problème — Les kinésithérapeutes libéraux perdent 3 à 5 heures par semaine à gérer leurs rendez-vous par téléphone et SMS, et les patients oublient leurs séances.
2. Utilisateurs — Le kiné (gère sa semaine). Le patient (réserve et reçoit des rappels). Administration : le kiné, encore lui.
3. Parcours clés — (a) Un patient ouvre le lien de réservation, choisit un créneau, confirme, reçoit un email. (b) Un patient reçoit un rappel 24 heures avant et peut annuler en un geste. (c) Le kiné voit sa semaine, bloque des indisponibilités, déplace un rendez-vous.
4. Dans la V1 — lien de réservation, rappels, agenda de la semaine. Dehors — paiement, téléconsultation. Plus tard — cabinets à plusieurs praticiens, tiers payant.
5. Indicateur — 20 kinés qui prennent 80 % de leurs rendez-vous par le lien au troisième mois.
7. Données — Noms des patients, coordonnées, horaires de rendez-vous. Aucune note médicale en V1 — volontairement.
10. Contraintes — Données hébergées dans l'UE. Lancement avant la rentrée de septembre.
Une fois rempli
- Envoie le même document à tous tes interlocuteurs.
- Pose à chacun la même question : « Que retireriez-vous de la V1, et pourquoi ? »
- Compare les devis avec notre scorecard de devis. Évaluer un devis
C'est la première étape de notre Sprint de cadrage, mise par écrit. Si tu préfères le faire avec nous, le Sprint en fait aussi un prototype cliquable et un prix ferme. Product Discovery Sprint
Conçu par NexusInsight. Un prix devrait sortir d'un périmètre, pas l'inverse.