Studio MVP · Document de cadrage
Préparez le cadrage fonctionnel de votre produit
Un guide pas-à-pas pour formaliser, en autonomie, tout ce dont notre studio a besoin pour concevoir puis développer votre MVP — sans attendre un atelier de cadrage complet.
Ce document vous permet de produire vous-même une première passe de cadrage. Vous le remplissez à votre rythme, vous nous l'envoyez, et nous le complétons ensemble en une ou deux passes de feedback. Idéalement, vous allez même un cran plus loin : vous montez un prototype cliquable de votre produit à partir de ce cadrage, pour le mettre à l'épreuve. Une fois l'ensemble solide, nous pouvons nous engager sur un coût et un délai fermes pour le développement.
- Vous remplissez les six artefacts décrits dans ce guide — c'est votre product spec.
- Idéalement, vous montez un prototype cliquable à partir de cette spec, avec un outil de vibe coding (Lovable, Cowork…). Optionnel mais vivement conseillé.
- Vous nous envoyez le tout : la spec (un dossier de fichiers, ou ce document rempli) et le prototype si vous l'avez fait.
- Nous faisons un feedback ciblé : ce qui est clair, ce qui manque, ce qu'il faut trancher. Une à deux itérations suffisent généralement.
- On s'engage sur un coût et un délai fermes pour le développement, sur une base déjà éprouvée.
1Notre méthode de conception MVP
Nous concevons des MVP — des premières versions utiles, ciblées et mises en production, pas des maquettes jetables. Pour y arriver vite et bien, notre méthode suit toujours le même ordre, du plus structurant au plus concret :
Le socle : vision, personae, glossaire, domaines métier, fonctionnalités, cas d'usage. C'est ce qui fait foi pour tout le reste — et exactement ce que ce kit vous aide à produire.
Les enchaînements d'écrans : qui fait quoi, dans quel ordre, avant de parler d'esthétique. C'est exactement ce que matérialise le prototype que vous montez à partir de votre spec.
Votre identité visuelle (couleurs, composants, style). Nous partons de ce que vous proposez : on ne le recrée pas.
Une fois le produit validé sur les trois plans précédents, on construit et on met en production.
Les outils de vibe coding transforment aujourd'hui une product spec en application cliquable en quelques heures, sans écrire de code. Donnez-leur votre cadrage et itérez :
- Lovable — génère une app web à partir d'une description en langage naturel.
- Cowork — part directement de vos fichiers de spec pour produire un prototype fonctionnel.
Construire le prototype vous-même est le meilleur test de votre cadrage : si un parcours coince à l'écran, c'est souvent qu'une règle manque dans la spec. Vous nous l'envoyez avec, et on accélère d'autant.
Notre engagement, dans cette méthode : nous prenons votre cadrage et votre direction visuelle telle que vous la proposez, et nous vous conseillons sur quelle structure et quel périmètre sont réalistes à emmener en production. Un bon cadrage en amont, c'est ce qui rend la suite rapide et prévisible.
2À quoi ressemble un bon cadrage
Un cadrage fonctionnel se décompose toujours de la même façon : du plus général (la vision) au plus précis (le geste utilisateur). Voici la structure cible — six types d'artefacts, organisés en arborescence :
- product-specs/
- 00-vision.md la raison d'être, le périmètre, la réussite
- 01-personae.md qui sont les utilisateurs
- 02-glossaire.md le vocabulaire qui fait foi
- EP-01-…/ domaine métier une grande aire métier
- README.md description du domaine métier
- F-01-…/ fonctionnalité une capacité
- README.md description de la fonctionnalité
- UC-01-….md cas d'usage un geste utilisateur
- UC-02-….md
- F-02-…/
- …
La logique d'emboîtement :
- Un produit = 1 vision + des personae + 1 glossaire.
- La vision énumère 3 à 6 domaines métier (les grandes aires métier stables).
- Chaque domaine métier contient 2 à 4 fonctionnalités (des capacités concrètes).
- Chaque fonctionnalité contient 1 à N cas d'usage (un geste précis d'un acteur, avec ses règles).
3Le workbook
Pour chaque artefact : à quoi il sert, comment le remplir, le modèle vierge, et un exemple rempli « Toutou ». Chaque modèle se copie bloc par bloc, ou se récupère dans l'archive téléchargeable ci-dessous.
Les modèles sont en Markdown — du texte brut
avec quelques symboles, qui s'ouvre dans n'importe quel éditeur. L'essentiel tient en
trois signes : # en début de ligne = un titre,
**texte** = du gras, - = une puce.
Vous remplacez le texte entre < > et vous gardez la structure :
pas besoin de tout maîtriser.
Pas à l'aise avec les fichiers ? Ouvrez un éditeur en ligne
gratuit et sans installation comme stackedit.io ou
dillinger.io : collez un modèle, remplissez-le
avec l'aperçu en direct à côté, puis téléchargez le .md.
↓ Télécharger tous les modèles (.zip)
3.1 — Vision
À quoi ça sert. La vision pose la raison d'être du produit : le contexte, le problème, ce que le produit doit être, et — surtout — le périmètre du MVP. C'est la boussole : toutes les décisions ultérieures s'y rattachent.
Comment la remplir.
- Décrivez le contexte et le problème sans parler de la solution. Restez factuel, chiffrez si possible.
- Énumérez vos domaines métier (3 à 6). Si vous en avez plus de 6, regroupez.
- Tranchez le périmètre du MVP : chaque domaine métier est soit dedans, soit repoussé. C'est la décision la plus importante.
- Donnez des indicateurs de réussite observables, pas des intentions.
# Vision <NomDuProduit> ## Contexte <Situation actuelle, sans la solution : acteurs, outils, volumes. Factuel.> ## Le problème 1. **<Problème 1>.** <Explication concrète, avec un fait ou un chiffre.> 2. **<Problème 2>.** <…> ## Ce que <NomDuProduit> doit être <Une phrase de synthèse, puis la liste des domaines métier :> 1. **EP-01 — <Titre>** — <ce qu'il recouvre.> 2. **EP-02 — <Titre>** — <…> ## Périmètre du MVP **Inclus dans le MVP** - **EP-XX — <Titre>** : <pourquoi indispensable dès le MVP.> **Hors MVP, traité ultérieurement** - **EP-XX — <Titre>** : <pourquoi ça peut attendre.> ## Ce que veut dire la réussite - **<Indicateur observable>** : <cible visée.> ## Principes directeurs - **<Principe>.** <ce qu'il implique concrètement.>
# Vision Toutou ## Contexte Faire garder son animal pendant une absence (vacances, déplacement, hospitalisation) relève du casse-tête. Les propriétaires sollicitent la famille ou des voisins quand ils peuvent, sinon des pensions souvent chères, éloignées et impersonnelles. Les échanges se font par bouche-à-oreille, SMS et groupes Facebook, sans visibilité sur les disponibilités ni les tarifs. ## Le problème 1. **Trouver un gardien de confiance prend du temps et reste risqué.** Aucun moyen simple de vérifier le sérieux d'un gardien rencontré en ligne. 2. **Aucune visibilité sur les disponibilités et les tarifs.** Il faut contacter chaque gardien un par un pour savoir s'il est libre et combien il prend. 3. **La réservation et le paiement restent informels.** Accords oraux, paiement en espèces : ni preuve, ni cadre en cas de problème. ## Ce que Toutou doit être Toutou est la plateforme qui met en relation propriétaires et gardiens près de chez eux, avec réservation et paiement intégrés. Elle s'articule autour de trois aires métier : 1. **EP-01 — Constituer son profil et déclarer ses animaux** — devenir membre, décrire ses animaux, ou publier une offre de garde en tant que gardien. 2. **EP-02 — Trouver et réserver une garde** — rechercher un gardien disponible, demander une réservation, la payer. 3. **EP-03 — Réaliser et suivre la garde** — échanger pendant la garde, la clôturer, laisser un avis. ## Périmètre du MVP **Inclus dans le MVP** - **EP-01 — Profil et animaux** et **EP-02 — Trouver et réserver** : indissociables (« pas de réservation sans profils ni recherche »). Livrés en première vague. **Hors MVP, traité ultérieurement** - **EP-03 — Réaliser et suivre la garde** : vague suivante. - Sont aussi reportés : la messagerie temps réel, le parrainage, et la gestion multi-animaux d'une même garde (un animal par réservation dans le MVP). ## Ce que veut dire la réussite - **Taux de recherches abouties** : au moins 1 recherche sur 3 débouche sur une demande de réservation. - **Délai première réservation** : un nouveau propriétaire réserve en moins de 10 min. - **Confiance** : 90 % des gardes notées 4/5 ou plus. ## Principes directeurs - **La confiance d'abord.** Tout gardien a un profil vérifiable (avis, vérifications). - **Pas de transaction hors plateforme.** Réservation et paiement passent toujours par Toutou — c'est ce qui protège les deux parties. - **Mobile d'abord.** L'usage type se fait depuis un téléphone, en mobilité.
3.2 — Personae
À quoi ça sert. Un persona incarne un type d'utilisateur réel. Ils garantissent qu'on conçoit pour des gens précis, avec des besoins et des frustrations concrètes — pas pour un « utilisateur » abstrait.
Comment les remplir.
- Un persona par rôle distinct. Donnez-lui un prénom et un rôle.
- Distinguez les internes (qui se connectent et agissent) des externes (qui reçoivent un e-mail, un SMS, un lien sans utiliser l'app).
- Les frustrations actuelles sont le plus utile : ce sont elles que le produit doit soulager.
- Si vous avez interviewé de vraies personnes, citez-les (verbatim).
# Personae ## Personae internes (utilisateurs du produit) ### <Prénom> — <Rôle> (<ACRONYME>) **Qui.** <bio courte : poste, contexte.> **Ce qu'il/elle fait dans <NomDuProduit>.** - <action principale.> **Ce qu'il/elle attend de l'outil.** - <bénéfice recherché.> **Frustrations actuelles (pains).** - <douleur concrète d'aujourd'hui.> ## Personae externes (consommateurs des livrables) ### <Type de contact externe> **Qui.** <qui c'est, quel livrable il reçoit.> **Ce qu'il/elle attend.** - <…>
# Personae ## Personae internes (utilisateurs du produit) ### Camille — Propriétaire d'animal (PROP) **Qui.** 34 ans, vit en ville avec un chien. Part en week-end et en vacances plusieurs fois par an et ne sait jamais à qui confier son animal. **Ce qu'elle fait dans Toutou.** - Crée le profil de son chien (race, âge, besoins particuliers). - Recherche un gardien disponible sur ses dates et réserve. **Ce qu'elle attend de l'outil.** - Trouver vite quelqu'un de confiance, près de chez elle. - Payer en sécurité et garder une trace de la réservation. **Frustrations actuelles (pains).** - « Je passe des heures à demander autour de moi, et au final je culpabilise. » - Aucune idée du tarif « normal » d'une garde. ### Hugo — Gardien (GARD) **Qui.** 27 ans, étudiant, aime les animaux et cherche un revenu d'appoint flexible. **Ce qu'il fait dans Toutou.** - Publie son offre de garde (zone, tarif, types d'animaux acceptés). - Indique ses disponibilités et accepte ou refuse les demandes. **Ce qu'il attend de l'outil.** - Recevoir des demandes sérieuses et être payé sans avance de frais. - Construire une réputation grâce aux avis. **Frustrations actuelles (pains).** - Sur les groupes Facebook, beaucoup de messages, peu de demandes concrètes. ## Personae externes (consommateurs des livrables) ### Contact d'urgence du propriétaire **Qui.** Personne désignée par Camille, prévenue par e-mail si un incident est signalé pendant la garde. N'utilise pas l'application. **Ce qu'il/elle attend.** - Être joignable et informé clairement en cas de problème.
3.3 — Glossaire
À quoi ça sert. Le glossaire fixe une seule définition par terme métier. C'est ce qui évite que deux personnes parlent de la même chose avec des mots différents — ou de choses différentes avec le même mot.
Comment le remplir.
- Listez les objets du domaine (les « choses » manipulées), leurs états, les acteurs, et vos référentiels (listes de valeurs).
- Test simple : si deux membres de votre équipe ne nommeraient pas une notion de la même façon, ajoutez une entrée.
- Une définition = ce que c'est + ce qui le caractérise. Notez les exclusions entre crochets.
# Glossaire ## Objets du domaine - **<Terme>** — <définition : ce que c'est, ses attributs clés. [exclusions].> ## Cycle de vie et états - **<État de X>** — <valeur 1>, <valeur 2>, <valeur 3>. <transitions.> ## Acteurs et droits - **<ACRONYME>** — <rôle complet et périmètre d'action.> ## Référentiels métier - **<Nom du référentiel>** — <de quoi il s'agit, exemples de valeurs.>
# Glossaire ## Objets du domaine - **Animal** — Compagnon déclaré par un propriétaire : espèce, race, âge, besoins particuliers (traitement, alimentation). Un animal appartient à un seul propriétaire. - **Profil gardien** — Page publique d'un gardien : zone couverte, tarif journalier, types d'animaux acceptés, avis reçus. [Un gardien peut aussi être propriétaire.] - **Réservation** — Engagement entre un propriétaire et un gardien pour la garde d'un animal sur une période donnée, à un tarif convenu, payé via la plateforme. - **Avis** — Note (1 à 5) et commentaire laissés après une garde terminée. ## Cycle de vie et états - **Statut de la réservation** — *Demandée* (en attente de réponse du gardien), *Confirmée* (acceptée et payée), *En cours* (garde démarrée), *Terminée*, *Annulée*. ## Acteurs et droits - **PROP** — Propriétaire. Déclare ses animaux, recherche, réserve, note. - **GARD** — Gardien. Publie une offre, accepte/refuse, réalise la garde. ## Référentiels métier - **Type d'animal** — chien, chat, NAC (nouveaux animaux de compagnie). - **Motif d'annulation** — imprévu propriétaire, indisponibilité gardien, animal malade.
3.4 — Domaines métier
À quoi ça sert. Un domaine métier est une grande aire métier stable. C'est le premier niveau de découpage du produit. Les domaines métier sont déjà annoncés dans la vision ; ici, on détaille chacun.
Comment le remplir.
- Décrivez le périmètre du domaine métier et pourquoi il existe.
- Donnez ses outcomes mesurables — des effets, pas des écrans.
- Listez ses fonctionnalités et précisez ce qui est hors périmètre (et où ça se trouve sinon). C'est là qu'on évite les malentendus.
# EP-XX — <Titre du domaine métier> **Description.** <périmètre couvert, où il commence et s'arrête.> **Pourquoi ce domaine métier.** <quel problème de la vision il adresse.> ## Outcomes mesurables - **<Outcome>** <(comment on le mesure).> ## Fonctionnalités | Fonctionnalité | Cas d'usage | |---|---| | F-01 — <Titre> | UC-01, UC-02 | | F-02 — <Titre> | UC-03 | ## Périmètre **Inclus dans ce domaine métier.** <ce qu'il couvre.> **Hors périmètre.** <ce qui n'y est pas, et où ça se trouve (autre domaine métier / V-next).> ## Acteurs | Acteur | Rôle dans le domaine métier | |---|---| | **<ACRONYME>** (<Prénom>) | <ce qu'il y fait.> |
# EP-02 — Trouver et réserver une garde **Description.** Couvre tout le parcours d'un propriétaire entre « j'ai besoin d'un gardien » et « ma garde est confirmée et payée » : recherche par dates et zone, consultation des profils, demande de réservation, paiement. S'arrête à la confirmation ; le déroulé de la garde est traité en EP-03. **Pourquoi ce domaine métier.** C'est le cœur de la valeur de Toutou : sans recherche fiable et sans réservation sécurisée, la mise en relation reste aussi informelle qu'avant. ## Outcomes mesurables - **Au moins 1 recherche sur 3 aboutit à une demande de réservation.** - **Délai moyen recherche → réservation confirmée inférieur à 24 h.** - **Zéro transaction hors plateforme** signalée (paiement toujours intégré). ## Fonctionnalités | Fonctionnalité | Cas d'usage | |---|---| | F-01 — Rechercher un gardien | UC-05 | | F-02 — Réserver une garde | UC-06, UC-07 | ## Périmètre **Inclus dans ce domaine métier.** La recherche filtrée (dates, zone, type d'animal), la consultation d'un profil gardien, la demande de réservation, son acceptation/refus par le gardien, et le paiement. **Hors périmètre.** Le déroulé et la clôture de la garde (cf. EP-03). La messagerie temps réel est V-next : dans le MVP, l'échange se limite aux informations de la demande. ## Acteurs | Acteur | Rôle dans le domaine métier | |---|---| | **PROP** (Camille) | Recherche, demande la réservation, paie. | | **GARD** (Hugo) | Reçoit la demande, l'accepte ou la refuse. |
3.5 — Fonctionnalités
À quoi ça sert. Une fonctionnalité est une capacité concrète à l'intérieur d'un domaine métier. Elle regroupe les cas d'usage qui servent un même objectif utilisateur.
Comment la remplir. Court : une description, le pourquoi, la liste de ses cas d'usage, et ses dépendances éventuelles. Le détail vit dans les cas d'usage.
# F-XX — <Titre de la fonctionnalité> **Domaine métier parent** : EP-XX — <Titre du domaine métier> **Description.** <la capacité offerte, en 1-2 paragraphes.> **Pourquoi cette fonctionnalité.** <à quel besoin elle répond.> ## Cas d'usage - UC-XX — <Titre> — <résumé d'une ligne : qui fait quoi.> - UC-XX — <Titre> — <…> ## Dépendances - <ce dont la fonctionnalité a besoin (autre fonctionnalité, donnée, référentiel).>
# F-02 — Réserver une garde **Domaine métier parent** : EP-02 — Trouver et réserver une garde **Description.** Permet à un propriétaire, une fois un gardien repéré, de lui adresser une demande de réservation pour des dates et un animal donnés, et au gardien d'y répondre. La confirmation déclenche le paiement. **Pourquoi cette fonctionnalité.** C'est le moment où la mise en relation devient un engagement concret et sécurisé — la promesse centrale de Toutou. ## Cas d'usage - UC-06 — Demander une réservation à un gardien — le propriétaire envoie une demande datée pour l'un de ses animaux. - UC-07 — Répondre à une demande de réservation — le gardien accepte (ce qui déclenche le paiement) ou refuse. ## Dépendances - Un profil gardien publié et au moins un animal déclaré (cf. EP-01). - Le prestataire de paiement intégré.
3.6 — Cas d'usage
À quoi ça sert. Le cas d'usage est le cœur du cadrage : un geste précis d'un acteur, avec son scénario, ses cas d'erreur et — surtout — ses règles de gestion. C'est ce niveau qui rend le produit développable sans ambiguïté.
Comment le remplir.
- Titre = une action courte vue de l'acteur (verbe à l'infinitif + complément).
- Le flux nominal décrit le scénario qui marche, étape par étape.
- Les règles de gestion sont le plus important : ce qui doit toujours être vrai (unicité, validations, droits, calculs). Pas les détails d'interface.
- Précisez ce qui est hors périmètre pour ce geste précis.
UC-01, UC-02… de façon
continue sur tout le produit (pas remise à zéro par fonctionnalité).
Emplacement : EP-XX/F-XX/UC-XX-<titre-en-tirets>.md.
# UC-XX — <Titre du cas d'usage> **Domaine métier** : EP-XX — <Titre du domaine métier> **Fonctionnalité** : F-XX — <Titre de la fonctionnalité> ## Acteur principal <rôle(s), avec le persona réel si connu.> ## Déclencheur <l'événement qui amorce le cas d'usage. 1-2 phrases, pas une liste.> ## Pré-conditions - <ce qui doit être vrai avant de démarrer.> ## Flux nominal 1. <étape, du point de vue de l'acteur.> 2. <…> N. <résultat observable.> ## Flux alternatifs - <variante / erreur → conséquence côté acteur.> ## Règles de gestion - <invariant du domaine : unicité, validation, droits, calcul.> ## Post-conditions - <état du système après succès, effets de bord (notifications…).> ## Extensions hors périmètre - <ce que ce cas d'usage n'adresse pas aujourd'hui (cf. UC-YY si délégué).>
# UC-06 — Demander une réservation à un gardien **Domaine métier** : EP-02 — Trouver et réserver une garde **Fonctionnalité** : F-02 — Réserver une garde ## Acteur principal Camille — Propriétaire d'animal (PROP). ## Déclencheur Camille a trouvé un gardien qui lui convient dans les résultats de recherche et souhaite réserver pour les dates de son prochain déplacement. ## Pré-conditions - Camille est connectée et a déclaré au moins un animal. - Le gardien a une offre publiée et s'est déclaré disponible sur les dates visées. ## Flux nominal 1. Camille ouvre le profil du gardien et clique sur « Demander une réservation ». 2. Elle choisit l'animal concerné, les dates de début et de fin. 3. Toutou affiche le montant total (tarif journalier × nombre de jours). 4. Camille confirme l'envoi de la demande. 5. La demande part au gardien ; Camille voit sa réservation au statut *Demandée*. ## Flux alternatifs - Dates indisponibles chez le gardien → un message propose des dates libres voisines. - Aucun animal déclaré → Camille est invitée à en créer un avant de continuer. - Camille abandonne avant l'envoi → aucune demande n'est créée. ## Règles de gestion - Une demande porte sur **un seul animal** et **une seule période continue** (MVP). - Les dates doivent être **futures** et la fin **postérieure ou égale** au début. - Le montant est figé à l'envoi de la demande : un changement de tarif du gardien ne s'applique pas à une demande déjà émise. - Une demande *Demandée* expire automatiquement après **48 h** sans réponse. - Le paiement n'est **pas** débité à ce stade — seulement à l'acceptation (cf. UC-07). ## Post-conditions - Une réservation au statut *Demandée* existe, visible des deux parties. - Le gardien reçoit une notification de nouvelle demande. ## Extensions hors périmètre - Acceptation/refus et paiement par le gardien : cf. UC-07. - Réserver pour plusieurs animaux en une fois : V-next. - Négocier le tarif ou les dates par message : V-next (messagerie).
4Discipline de périmètre — les « clous »
Un cadrage exploitable n'est pas un cadrage complet : c'est un cadrage tranché. Quelques règles qui nous permettent d'avancer vite :
- Bonne granularité d'un cas d'usage. Un cas d'usage = un geste qu'on peut raconter d'une traite (« demander une réservation »). S'il vous faut « et puis, si…, sinon… » trois fois, c'est probablement plusieurs cas d'usage.
- Les règles de gestion priment sur les écrans. Décrivez ce qui doit être vrai (« une demande expire après 48 h »), pas l'apparence du bouton. L'UI viendra après, sur cette base.
- Tout hors-scope se nomme. Ce que le MVP ne fait pas doit être écrit. Ce qui n'est écrit nulle part finit par être supposé — par vous d'un côté, par nous de l'autre, rarement de la même façon.
- En cas de doute, gardez la trace du doute. Une question ouverte notée est une bonne contribution : c'est précisément ce qu'on traitera au feedback.
5Avant de nous l'envoyer
Une auto-évaluation rapide. Si vous cochez l'essentiel, votre cadrage est prêt pour une première passe de feedback — il n'a pas besoin d'être parfait.
- La vision décrit le contexte et le problème sans parler de la solution.
- Le périmètre du MVP est tranché : chaque domaine métier est clairement « inclus » ou « repoussé ».
- Les indicateurs de réussite sont observables (pas des intentions).
- Tous les rôles qui utiliseront le produit ont un persona (internes et externes).
- Le glossaire définit chaque terme métier une seule fois, sans ambiguïté.
- Chaque domaine métier a des outcomes mesurables et un « hors périmètre » explicite.
- Chaque fonctionnalité est rattachée à un domaine métier et liste ses cas d'usage.
- Chaque cas d'usage a des règles de gestion explicites.
- Les cas d'usage sont numérotés en continu et rangés sous leur fonctionnalité.
- Vos incertitudes et questions ouvertes sont notées quelque part.
- (Optionnel, conseillé) Un prototype cliquable matérialise vos parcours principaux — et vous a aidé à repérer les trous de la spec.
.md du .zip téléchargé plus haut, remplis et organisés
selon l'arborescence cible), soit ce document complété, dans le format qui vous
arrange (Markdown, Word,
Google Docs, Notion…). Si vous avez monté un prototype, joignez le
lien (ou le projet). Le fond compte plus que la forme.