Par Thomas Cohen, fondateur de Maestro
Prototype, MVP, application : quand passer à de vrais utilisateurs ?
Un prototype explore une idée ; un MVP teste un usage limité. Pour passer à de vrais utilisateurs, vérifiez le parcours et consignez les preuves qui autorisent un pilote.
Votre page affiche des créneaux. Une personne en choisit un, clique sur « Réserver » et voit une confirmation. Vous avez quelque chose à montrer. Pour savoir si vous pouvez recevoir les rendez-vous de lundi, il reste une autre question : qu’est-ce qui s’est réellement passé après le clic ?
Ce guide concerne les prototypes d’applications, pas les objets physiques. Nous suivrons Élise, qui organise des séances photo dans un exemple fictif. Sa page de réservation explore d’abord un parcours, puis un usage limité, avant une utilisation régulière. Les résultats décrits sont pédagogiques, pas des essais réalisés chez un client.
Quatre mots qui ne désignent pas le même engagement
Les équipes n’emploient pas toutes ces mots de la même façon. Voici nos repères pour préciser vos attentes avec la personne qui construit. Ils ne constituent pas des définitions universelles.
- Prototype : une représentation ou une version qui permet d’examiner une idée et un parcours, avec des opérations éventuellement simulées.
- MVP : une première version limitée pour apprendre si un usage apporte la valeur attendue. MVP signifie minimum viable product, soit produit minimum viable.
- Application utilisable : une version qui réalise le parcours prévu dans des conditions définies et vérifiées.
- Produit en exploitation : une application dont l’usage régulier s’accompagne d’un suivi, d’une aide aux utilisateurs et de responsables identifiés.
La méthode Lean Startup présente le MVP comme un moyen d’apprendre à partir d’un premier produit. « Minimum » décrit donc le périmètre de l’essai, pas une permission d’ignorer ce qui rend cet essai fiable.
Ces termes peuvent se recouvrir. Un MVP peut être utilisable par quelques personnes ; un prototype peut contenir du vrai code. Précisez l’engagement : que peut faire l’utilisateur, avec quelles données, et qui intervient si le résultat est incorrect ?
Une réservation, trois stades à observer
Au premier stade de notre exemple, Élise montre des horaires inventés. Cliquer sur « Réserver » ouvre une page de confirmation, mais aucune réservation n’est enregistrée. Le prototype permet de discuter du vocabulaire, de l’ordre des étapes et des informations demandées. Il ne permet pas de remplir son agenda réel.
Au deuxième stade, elle prépare un MVP consacré à un seul type de séance, proposé à quelques personnes. Le choix d’un horaire produit une réservation enregistrée, consultable par Élise. Les paiements restent gérés comme avant et cette limite est annoncée. Elle cherche à savoir si les personnes terminent la réservation sans devoir lui téléphoner.
Au troisième stade envisagé, la réservation devient un service utilisé régulièrement. Il faut alors savoir qui ouvre les horaires, surveille les problèmes, traite une annulation et récupère les informations après une panne. Le passage à ce stade ne résulte pas du simple ajout d’un bouton « Publier ».
Distinguer ce qui est simulé de ce qui est enregistré
Avant une présentation, faites l’inventaire des opérations : ce qui change, où cela est conservé et comment le retrouver. Une animation de chargement ou un message vert peut s’afficher sans que le travail annoncé ait eu lieu.
Pour la page d’Élise, séparez les horaires visibles, la création de la réservation, l’envoi du message et la mise à jour du planning. Une opération peut fonctionner alors que la suivante reste simulée. Le dire évite de tirer une conclusion générale à partir d’un seul écran convaincant.
Le Service Manual de GOV.UK rappelle qu’un prototype en code peut ressembler à un service réel sans répondre aux mêmes exigences. Son apparence ne suffit donc pas à justifier son utilisation en production.
- Horaire affiché : provient-il d’une liste inventée ou des disponibilités enregistrées ?
- Réservation confirmée : existe-t-elle après fermeture et réouverture du navigateur ?
- Message envoyé : a-t-il réellement été reçu à l’adresse de test ?
- Planning modifié : Élise retrouve-t-elle la même réservation depuis son accès ?
Utilisez d’abord des noms et des adresses de test. Distinguez ce qui a été observé, reste à vérifier ou est simulé. « Non testé » est utile ; « normalement, oui » transforme une inconnue en fausse assurance.
Décrire une action complète, du besoin au résultat
Pour décider si le MVP est utilisable, choisissez une action que la personne doit pouvoir terminer. Dans notre exemple : trouver un créneau libre, réserver une séance et retrouver la confirmation. Du côté d’Élise, il faut pouvoir consulter cette réservation pour préparer le rendez-vous.
Définissez le résultat attendu avant l’essai. Par exemple : une seule réservation existe pour le créneau choisi, la personne retrouve la bonne date et Élise voit le même rendez-vous. « Le bouton fonctionne » ne dit rien sur ces trois résultats. Une vérification écrite permet de parler de la même chose.
Réalisez aussi l’essai dans les conditions prévues : téléphone si les clients réservent sur téléphone, accès d’Élise si elle gère le planning et compte de test distinct pour le participant. Une démonstration menée uniquement avec le compte qui peut tout modifier ne représente pas ces différents usages.
Ne changez pas discrètement le critère après avoir vu le résultat. Si l’envoi de la confirmation manque, vous pouvez décider de le préparer manuellement pendant un pilote. Écrivez alors ce fonctionnement, son responsable et sa limite. Ce sera un choix de périmètre explicite, pas une réussite inventée de l’automatisation.
Essayer les erreurs qui changent la conclusion
Un parcours réussi ne couvre pas les situations qui rendent une réservation ambiguë. Dans la version fictive d’Élise, les contrôles déterminants concernent un horaire déjà pris, un clic répété et deux personnes qui essaient de réserver ensemble. Chacun demande une réponse attendue différente et une observation précise.
Pour les demandes simultanées, préparez deux comptes et le même horaire libre. Faites déclencher les demandes au même moment, avec l’aide de la personne qui réalise l’application si nécessaire. Vérifiez ensuite les enregistrements, pas uniquement les messages affichés. Une seule réservation doit être acceptée pour ce créneau dans notre règle fictive.
Pour le clic répété, vérifiez qu’une impatience ne produit pas deux rendez-vous. Pour une information incorrecte, observez si la personne comprend comment corriger sa saisie. Pour l’annulation, regardez à la fois la confirmation reçue et l’état du planning. Chaque contrôle répond à une conséquence réelle du parcours.
Cette liste ne remplace pas une vérification technique complète. Le guide des risques d’une application créée avec l’IA approfondit notamment les accès, les données et les changements. Ici, le but est d’identifier les preuves qui manquent avant votre prochain essai avec des utilisateurs.
Préparer la reprise avant de confier des rendez-vous à l’outil
La reprise couvre deux questions différentes : retrouver un fonctionnement utilisable et retrouver les informations. Revenir à une ancienne version du code ne restaure pas nécessairement les réservations. Une copie de données ne remet pas forcément le service en état de fonctionner. Demandez une explication concrète pour les deux.
Dans l’exemple, Élise veut savoir où retrouver les rendez-vous déjà confirmés si la page devient indisponible. Une personne désignée prépare la reprise et la teste avec des données fictives. Le compte rendu indique ce qui revient, ce qui manque et combien d’interventions restent manuelles, sans promettre un délai jamais mesuré.
Préparez aussi le traitement des réservations reçues après la copie utilisée pour restaurer. Sinon, vous pourriez retrouver un planning qui paraît normal tout en perdant les dernières demandes. Le dossier de passage au pilote doit nommer la personne chargée de repérer et de reprendre ces écarts.
Constituer un dossier de preuves simple
Ce dossier peut tenir dans un document partagé. Il rassemble les contrôles qui justifient un essai ou son élargissement. Une capture ne suffit pas toujours : pour une réservation, relevez aussi l’enregistrement, le message reçu et la version examinée.
Pour chaque contrôle, copiez cette grille et remplissez les crochets. Ce n’est pas un certificat de qualité : elle rend les faits et les responsabilités relisibles, même pour quelqu’un qui n’a pas assisté à l’essai.
- Version et date : [version examinée, date et environnement de l’essai].
- Situation de départ : [utilisateur, données de test, état du planning].
- Action réalisée : [geste exact ou suite d’actions].
- Résultat attendu : [ce qui doit se produire et rester inchangé].
- Résultat observé : [faits constatés, y compris les écarts].
- Preuve conservée : [capture, message, relevé ou compte rendu retrouvable].
- Responsable : [personne qui vérifie et personne qui corrige si nécessaire].
- Décision : [corriger, poursuivre l’essai prévu ou suspendre].
- Suite et limite : [prochaine action, personne et condition de réexamen].
Conservez des preuves sans informations sensibles, plutôt que les coordonnées des participants. Une ligne sans résultat observé reste un contrôle à effectuer, même si le résultat attendu est très clair.
Deux exemples remplis pour décider sans deviner
Exemple fictif : réservation ordinaire
Version : essai A, le 26 septembre, environnement de test. Situation : un compte participant fictif, un horaire libre et le planning d’Élise ouvert séparément. Action : réserver puis fermer et rouvrir la page de confirmation. Résultat attendu : une réservation unique, toujours retrouvable, avec le même horaire dans le planning.
Résultat observé dans cet exemple inventé : la réservation demeure visible après réouverture et les deux vues affichent le même horaire. Preuves : références de la réservation test, captures des deux vues et compte rendu. Responsable de vérification : Élise. Décision : poursuivre les contrôles prévus ; ce seul résultat n’autorise pas encore l’ouverture du pilote.
Exemple fictif : deux personnes choisissent le même horaire
Version : même essai A. Situation : deux comptes fictifs et un seul horaire libre. Action : confirmer les deux demandes ensemble. Résultat attendu : une seule réservation acceptée ; l’autre personne reçoit une explication et peut choisir un autre horaire. Résultat observé inventé : les deux demandes affichent « confirmé » et deux réservations existent.
Décision : suspendre l’ouverture du pilote et corriger ce point. Responsable : la personne chargée de réaliser l’application ; Élise vérifie ensuite le résultat avec elle. Preuves conservées : les deux références et le compte rendu de simultanéité. Condition de reprise : rejouer ce cas après correction, puis la réservation ordinaire pour vérifier qu’elle fonctionne encore.
Évitez le bilan « un test réussi sur deux ». Le second résultat empêche l’usage prévu, même si le premier est correct. Décidez selon les conséquences de l’écart, pas selon une moyenne donnant le même poids à chaque contrôle.
Ouvrir un pilote avec des limites compréhensibles
Une fois les blocages corrigés et revérifiés, précisez les participants, le périmètre et la date du bilan. Le Service Manual de GOV.UK décrit une beta privée limitée avant une ouverture plus large. Nous adaptons cette progression à un petit projet.
Dans le pilote fictif, Élise invite quelques personnes pour un seul type de séance. Elle leur explique comment signaler un problème et par quel autre moyen la joindre. Elle sait quelle liste de rendez-vous fait référence. Si elle conserve un suivi parallèle, elle désigne qui rapproche les deux listes et quand.
Écrivez les motifs qui arrêteront l’essai : une réservation perdue, un doublon non résolu ou une impossibilité d’identifier les personnes concernées, selon les risques de votre parcours. Prévoyez qui décide de la suspension et comment les participants seront informés. « On verra si cela arrive » ne prépare pas la décision.
Un pilote n’a pas besoin de devenir un grand chantier d’organisation. Il a besoin de règles que ses participants comprennent et d’une personne joignable. Pour répartir ces responsabilités entre collègues, notre guide sur l’application interne d’une petite équipe détaille le travail à plusieurs.
Décider de corriger, poursuivre ou suspendre
À la date convenue, reprenez le dossier de preuves et les problèmes signalés pendant le pilote. Corriger signifie traiter un écart avant la prochaine étape. Poursuivre signifie autoriser un périmètre nommé. Suspendre signifie interrompre l’essai concerné et revenir au fonctionnement prévu pour cette situation. Aucune de ces décisions ne vaut pour tous les usages futurs.
Si les réservations sont cohérentes mais que les participants appellent encore pour comprendre la durée des séances, l’essai a révélé un problème de compréhension. Si les personnes terminent leur réservation mais qu’Élise ressaisit tout ailleurs pour travailler, le parcours reste incomplet pour elle. Ces observations disent quoi modifier ensuite.
Pour une utilisation régulière, désignez qui suit les incidents, maintient l’application et revoit les contrôles après modification. Conservez les limites connues. « Utilisable pour ce parcours » est une conclusion située, pas la promesse qu’aucune erreur ne surviendra.
Préparer votre prochaine version
Commencez par une phrase : « Cette version doit permettre à [personne] de terminer [action] ; nous déciderons de la suite à partir de [preuves]. » Listez ensuite ce qui est simulé, choisissez le premier contrôle manquant et nommez son responsable. Vous aurez une prochaine étape vérifiable plutôt qu’une estimation vague de ce qui reste.
Si vous préparez un devis, notre guide du budget d’un MVP aide à chiffrer le périmètre retenu. Demandez séparément la préparation, les essais et le suivi nécessaire. La qualité du passage au pilote dépend de ce travail, même lorsque la première démonstration a été rapide à construire.
Maestro aide à organiser la construction avec des agents IA ; il ne transforme pas automatiquement une démonstration en application prête à servir. Sa beta sur invitation est proposée sur Mac, gratuitement pour l’application, avec l’usage IA à part. La présentation de Maestro permet de découvrir ce parcours. Les preuves et la décision d’usage restent à établir pour votre projet.