Développement produit / 03
Un MVP a besoin d’un premier client, pas d’une liste de souhaits raccourcie.
Le tableau contient quarante fonctionnalités. En garder vingt ressemble à un progrès. Mais pourquoi quelqu’un ouvrirait-il le produit demain ? Partez de la tâche du premier client et du résultat qui lui donnera envie de revenir.
Décrivez une transaction
Pour un service de réservation fictif : le client trouve un créneau, réserve, paie et reçoit une confirmation ; le prestataire voit une réservation fiable. Cette phrase explique mieux le produit que « tableau de bord, IA, paiements, notifications ».
Quel signal permettra de juger l’idée ? Une première réservation terminée, une seconde visite payée, un prestataire qui souhaite continuer ? Choisissez un indicateur proche du problème traité. Les inscriptions seules peuvent en dire très peu.
Hypothèse
Qui paiera et pour quel travail accompli ?
Parcours
Un chemin de la demande au résultat obtenu.
Pilote
De vrais utilisateurs ; erreurs et aide manuelle visibles.
Décision
Continuer, ajuster ou arrêter selon les observations.
Exemple de périmètre pour un service de réservation. Pour un autre produit, modifier l’hypothèse avant la liste des fonctions.
Distinguer prototype, pilote et premier produit
Un prototype sert à vérifier la compréhension d’une idée ou d’une interface. Il peut utiliser des données simulées et ne pas disposer de paiement fonctionnel. Un pilote teste une prestation limitée avec de vrais participants et une assistance définie. Un MVP doit terminer la tâche centrale dans les conditions promises. Ces livrables sont différents. Les appeler tous « MVP » rend les devis difficiles à comparer et empêche de savoir clairement ce qui doit être accepté.
Écrivez la décision que la première version doit éclairer. Un prestataire paiera-t-il pour réduire la gestion des rendez-vous ? Un client reviendra-t-il pour une seconde séance ? Définissez participants, mode d’arrivée et observations contraires à l’hypothèse. Un nombre élevé d’inscriptions n’est pas forcément pertinent si les personnes n’avaient pas besoin du service. Un petit groupe accomplissant une tâche réelle peut révéler des difficultés importantes. Conservez les limites de cette observation lorsque vous décidez de poursuivre l’investissement.
Dessiner le parcours complet avant la liste des écrans
Suivez une personne depuis la découverte de l’offre jusqu’au résultat promis. Incluez ce qui se passe entre deux interfaces : message tardif, disponibilité validée par un prestataire, paiement encore en attente. Notez ce que le client sait et ce que l’entreprise doit connaître pour avancer. Une liste « connexion, tableau de bord, paiement » masque facilement ces états intermédiaires, alors qu’ils influencent directement la confiance et les demandes d’assistance.
Dans un service de réservation, le côté prestataire compte autant que la confirmation client. Le prestataire doit voir la bonne séance, les coordonnées utiles et l’état du paiement. Limiter la première version à un prestataire et une prestation est un choix de périmètre valable. Supprimer la reprise après une réservation interrompue touche au fonctionnement de la promesse elle-même. Examinez le parcours avec les deux parties avant de décider quelles fonctions attendront. Cette discussion est souvent plus utile qu’un débat abstrait sur le nombre de pages à développer.
Prévoir explicitement les interventions manuelles
Une personne peut gérer les changements inhabituels, relire un document incertain ou préparer un premier rapport pendant la validation de la demande. Rendez ce travail visible dans le périmètre : qui le réalise, comment reçoit-elle la tâche et quel statut voit le client ? Une intervention prévue peut éviter de construire trop tôt un outil administratif complexe. Une intervention cachée fausse les hypothèses de coût et de capacité.
Mesurez fréquence et durée. Si le fondateur doit réparer chaque réservation normale, le pilote révèle une faiblesse du parcours central. Si une demande particulière est rare et rapide à traiter, son automatisation peut rester secondaire. Conservez toutefois une structure permettant de remplacer ce travail plus tard : statut, responsable et historique sont préférables à des messages privés dispersés. Le test doit montrer où investir, et non paraître concluant grâce à des heures supplémentaires que personne ne comptabilise dans les résultats.
Faites défiler horizontalement pour voir toutes les colonnes.
| Fonction | Choix pour le pilote | Critère de validation |
|---|---|---|
| Choix du créneau et réservation | Construire le parcours complet | Deux personnes ne peuvent pas réserver le même créneau |
| Report inhabituel | Traitement manuel par l’administration | La demande a un responsable et un statut visible |
| Paiement, si nécessaire pour tester la demande | Confirmer le paiement côté serveur | Une notification répétée ne crée pas un second achat |
| Fidélité et parrainage | Attendre la validation de la demande principale | Des données relient la fonction au réachat |
Choisir le web ou le mobile à partir de l’usage
Une application web responsive peut suffire lorsque la tâche est occasionnelle et accessible par un lien. Une application mobile dédiée se justifie davantage si l’usage répété, les fonctions du téléphone ou le fonctionnement hors ligne modifient réellement l’expérience. Listez ces besoins avant de choisir un framework. « Nous voulons une application » peut simplement signifier que le service doit être facile à utiliser sur smartphone, sans impliquer plusieurs publications sur les boutiques.
Comparez aussi création des comptes, validation des versions, appareils compatibles, mises à jour et assistance. Si une base de code partagée est proposée, demandez quelles parties restent propres à chaque plateforme et comment elles sont testées. À l’inverse, ne forcez pas une solution navigateur sur une fonction matérielle qu’elle ne peut pas fournir correctement. Faites une expérimentation technique limitée sur le point incertain. Une capacité démontrée sur l’appareil cible est plus utile qu’une longue comparaison de technologies sans lien avec le parcours.
Vérifier les dépendances avant de fixer la date
Une petite interface peut dépendre d’un calendrier, d’un paiement, d’un CRM et d’une base existante. Vérifiez accès, opérations nécessaires, données d’exemple et environnement de test avant de considérer ces intégrations comme acquises. Un connecteur disponible peut ne pas permettre l’écriture exacte dont le produit a besoin. Le devis doit exposer ces hypothèses, surtout lorsque les autorisations et documents dépendent d’une autre organisation.
Déterminez quel système fait référence pour chaque état et comment résoudre des mises à jour contradictoires. Si un rendez-vous est annulé directement dans le calendrier, que montre le portail ? Si la notification de paiement arrive avant la mise à jour de réservation, que fait l’application ? Toutes les pannes imaginables ne nécessitent pas immédiatement une interface de gestion sophistiquée. Le parcours central doit néanmoins avoir un état sûr et une reprise visible. Ces décisions rendent aussi le calendrier de livraison plus réaliste, car les transitions difficiles ne restent pas cachées jusqu’à la recette.
Tester les droits avec deux comptes ordinaires
Créez deux utilisateurs normaux dans l’environnement de test. Essayez d’accéder aux dossiers du premier depuis le second et vérifiez interface et réponse du serveur. Masquer un bouton n’établit pas une permission sur les données. Définissez les rôles selon les responsabilités réelles, par exemple client, prestataire et administration. Le modèle initial peut être simple, mais les actions importantes doivent être contrôlées à l’endroit où l’information est lue ou modifiée.
Incluez récupération d’accès, invitations et retrait de permissions. Une personne peut quitter une entreprise ou recevoir une invitation destinée à une autre adresse. Le produit doit traiter ces situations sans rendre accessibles les dossiers d’autrui. Demandez qui peut consulter les données pour l’assistance et comment cet accès est encadré. Ce sont des besoins ordinaires du produit, pas des options réservées à une future version entreprise. Un premier périmètre réduit peut tout à fait conserver des frontières claires entre ses utilisateurs et leurs informations.
Confirmer le paiement indépendamment du navigateur
Un client peut fermer l’onglet, perdre sa connexion ou actualiser la page pendant le traitement. L’application a besoin d’un état de paiement vérifiable auprès du prestataire, au-delà du seul écran de succès. Distinguez opération en attente, réussie et échouée de manière compréhensible. Évitez de proposer un nouveau paiement à l’aveugle tant que le résultat du précédent reste incertain. Le client doit savoir si une action est nécessaire ou si une vérification est en cours.
Utilisez les notifications serveur documentées et vérifiez leur authenticité. Leur traitement doit supporter les répétitions et un ordre différent de celui attendu. Contrôlez ensuite commande et réservation, pas seulement la réponse technique du point d’entrée. Prévoyez aussi la procédure pour une demande de remboursement ou un paiement à examiner, même si une personne s’en charge pendant le pilote. Un rattrapage manuel clair vaut mieux qu’un écran de paiement soigné dont l’équipe ne sait pas expliquer les conséquences sur le dossier client.
Évaluer l’IA lorsqu’elle porte la promesse principale
Si le produit interprète des documents ou répond à partir d’une base de connaissances, la qualité de cette fonction appartient à la recette initiale. Constituez des entrées représentatives et définissez résultats acceptables, refus et passages en revue humaine. Séparez manque d’information dans les sources, mauvaise interprétation et action incorrecte après la réponse. Un exemple séduisant ne suffit pas à démontrer que le produit accomplira sa tâche dans les situations promises.
Examinez le coût de l’incertitude : qui vérifie un résultat douteux, que peut corriger le client et que se passe-t-il lorsque le service de modèle est indisponible ? Une tâche mise en attente, une réponse limitée ou une aide humaine peuvent être adaptées. Choisissez ce comportement volontairement. Si l’assistant est seulement un raccourci facultatif autour d’un parcours de réservation complet, il peut attendre. La décision doit suivre l’hypothèse produit, sans imposer une fonction d’IA à chaque écran indépendamment du problème rencontré.
Comparer les offres sur la même histoire de recette
Donnez à chaque partenaire le même parcours court, les mêmes données d’exemple et les mêmes résultats observables. Demandez de distinguer découverte, design, réalisation, intégrations, tests et transmission. Les dépendances et exclusions doivent être visibles. Deux totaux se comparent mal si l’un inclut exploitation et reprise des erreurs, tandis que l’autre couvre une démonstration. Clarifiez ce décalage avant de négocier une réduction sur un périmètre encore ambigu.
Définissez aussi qui répond aux questions métier, qui accepte les livraisons et comment une modification est enregistrée. Demandez des étapes intermédiaires démontrant l’avancement de la tâche client. Une incertitude technique peut justifier une investigation limitée avant un chiffrage ferme. Reliez la réserve budgétaire à des inconnues identifiées et à des conditions d’utilisation précises. La discussion devient concrète sans prétendre que le projet ne contient aucune incertitude, ni transformer chaque question future en travail supplémentaire illimité.
Mesurer la décision à prendre après le lancement
Suivez les étapes révélant l’accomplissement de la tâche : demande valide, rendez-vous confirmé, paiement réussi ou nouvelle utilisation selon l’hypothèse. Séparez tentatives et résultats, et évitez de compter deux fois le même événement. Observez les abandons dans leur contexte avant de conclure qu’une fonction manque. Un prix mal expliqué, une confirmation tardive ou un défaut technique peut mieux décrire le problème qu’une liste d’idées supplémentaires.
Gardez le bilan lié aux participants et à l’hypothèse initiale. Un petit échantillon peut révéler des difficultés d’usage sans prouver une demande générale du marché. Notez ce qui reste incertain et l’observation qui ferait changer votre décision. Développez une grande fonction supplémentaire lorsqu’un lien existe avec le comportement client ou le coût d’exploitation. Si la tâche centrale n’est pas appréciée, un programme de parrainage ou davantage de graphiques ne clarifiera probablement pas pourquoi. La première version doit rendre la prochaine décision d’investissement plus éclairée.
Réduisez l’étendue, préservez la fiabilité
Un type de client, une prestation, un parcours. Une personne peut traiter les demandes particulières manuellement si la procédure est claire. Parrainage, cinq tarifs et rapports automatiques peuvent attendre.
Validation, permissions, état du paiement et reprise après erreur restent essentiels. Essayez d’ouvrir la réservation d’un autre client depuis un second compte. Actualisez pendant le paiement. Envoyez deux fois le formulaire. Une démo qui exige des clics parfaits n’est pas un test client solide.
Le mobile doit répondre à un besoin
Une application web responsive peut suffire lorsque la tâche commence par un lien. Une application iOS et Android mérite sa place si les capacités du téléphone ou un usage répété changent l’expérience. Écrivez ces besoins avant de choisir.
Même raisonnement pour l’IA. Pour simplement réserver une prestation, l’assistant peut venir plus tard. Si comprendre un document constitue le cœur du produit, l’évaluation de ses réponses appartient à la première version.
Incluez la remise du produit
Décidez qui possède le domaine, le dépôt de code, l’hébergement et le compte de paiement. Prévoyez export, sauvegarde et procédure de signalement. Le lundi suivant le lancement, quelqu’un doit savoir exploiter le produit.
Décrivez la première version par un scénario de réception court, avec des résultats observables. Gardez les idées suivantes à part. Les clients montreront ensuite ce qui mérite d’être développé.
Avant de commencer
- Nommer le premier client et la tâche complète à accomplir.
- Tester les permissions, le paiement interrompu et le double envoi.
- Convenir des accès au code, aux comptes et à la documentation.
Note de la rédaction. Les exemples illustrent une décision ou un test ; ce ne sont pas des résultats clients.