Comment développer un MVP

Comment développer un MVP à partir d'un problème précis

Si vous cherchez comment développer un MVP, partez du problème plutôt que de la liste de fonctionnalités. Un produit minimum viable est une version réelle et délimitée qui produit des preuves interprétables pour une décision identifiée. Cette décision peut consister à continuer d'investir dans un parcours, à resserrer l'audience ou à arrêter. Si vous ne pouvez pas formuler le problème en une phrase, en précisant qui le rencontre et ce qu'il lui coûte aujourd'hui, tout développement relèvera de la devinette.

IVRYN est un studio parisien qui gère plusieurs produits, chacun cadré pour sa propre audience. Ce contexte oriente les conseils qui suivent. Ils privilégient un périmètre étroit, une utilité mesurable et une automatisation dont on peut rendre compte. Cet article applique ces préférences au travail sur un MVP. Il ne rend pas compte d'une étude et ne décrit pas les résultats d'un produit en particulier.

Décidez à quelle question votre MVP répond

Distinguez trois types de travail avant de définir quoi que ce soit. Une preuve de concept teste une hypothèse technique précise, par exemple le bon fonctionnement d'une intégration, le respect d'une contrainte de calcul ou le traitement d'un cas d'échec particulier. Elle n'établit ni la demande, ni l'utilisabilité, ni la capacité opérationnelle. Un prototype vérifie si les gens comprennent une interaction. Un MVP est réellement mis en ligne, afin qu'un groupe limité d'utilisateurs réels puisse s'en servir et que vous puissiez recueillir des preuves. Le guide d'IVRYN sur les prototypes, les MVP et les preuves de concept détaille ces différences, et c'est en les confondant que les équipes finissent par répondre à la mauvaise question.

Restez modeste sur ce que ces preuves signifient. Le guide rappelle qu'un MVP déployé ne prouve pas, à lui seul, un usage régulier, l'adoption, le chiffre d'affaires ou l'adéquation produit-marché. Notez donc la décision que la version doit éclairer, l'hypothèse qui la sous-tend et le résultat qui ferait pencher la décision dans un sens ou dans l'autre. Par exemple : « Si les agences invitées envoient deux rapports hebdomadaires consécutifs via l'outil, nous automatiserons la troisième source de données ; sinon, nous les interrogerons avant de développer davantage. » Une telle formulation vous indique quoi construire, qui inviter et quoi mesurer.

Définissez la plus petite version qui reste sûre à livrer

Cartographiez le parcours unique qu'un utilisateur suit, depuis son arrivée avec le problème jusqu'à son départ avec le problème réglé. Chaque écran, intégration ou réglage qui ne se trouve pas sur ce parcours est un candidat à la suppression. Des étapes manuelles en coulisses sont acceptables au début, à condition d'être honnête sur ce qu'elles coûtent et sur leurs limites.

Réduire le périmètre a toutefois un plancher. Comme un MVP est mis en ligne et pas seulement présenté en démonstration, son périmètre peut inclure l'authentification, les autorisations, la confidentialité, l'accessibilité, la gestion des erreurs, la supervision et la reprise après incident, partout où le contexte l'exige. « Minimum » s'applique aux fonctionnalités, pas aux protections qui ont des conséquences. Si de vraies personnes se connectent, partagent des données ou dépendent du résultat, les protections associées font partie du minimum.

Prévoyez des versions assez petites pour être évaluées. Une version qui regroupe cinq changements empêche de savoir lequel a compté. Un seul changement significatif par version, chacun avec un effet attendu, permet de garder des preuves lisibles.

• Rédigez le problème, la décision et l'hypothèse sur une seule page.
• Listez les étapes du parcours utilisateur principal et supprimez tout le reste.
• Indiquez quelles étapes sont automatisées et lesquelles sont traitées manuellement.
• Listez les protections exigées par votre contexte et gardez-les dans le périmètre.
• Définissez ce que « terminé » signifie pour chaque version avant de la développer.

Concevez des interfaces accessibles dès la première version

L'accessibilité n'est pas une finition à ajouter plus tard. Si les personnes qui naviguent au clavier, utilisent un lecteur d'écran ou ont une basse vision ne peuvent pas terminer le parcours principal, votre MVP sous-estimera le besoin réel et vous donnera un signal faussé. Corriger la structure après coup coûte aussi plus cher que de bien faire pendant que l'interface est encore petite.

Concentrez-vous sur les fondamentaux le long du parcours principal : titres et libellés sémantiques, états de focus visibles, contraste suffisant, erreurs de formulaire expliquées par du texte, et parcours qui ne reposent ni sur la couleur ni sur des mouvements de pointeur précis. Vérifiez ces points manuellement à chaque version, car les outils de vérification automatique aident mais ne détectent pas tout.

Contrôles de fiabilité : mesurer les résultats et vérifier la mise en ligne

Mesurez si le problème a été réglé, pas seulement si les gens ont cliqué. Les indicateurs utiles d'un MVP se rattachent à la décision : tâches accomplies, temps passé par rapport à l'ancienne méthode, ou usage répété lorsque le besoin se représente. Le nombre d'inscriptions indique rarement si le produit est utile.

La fiabilité dépend autant de la discipline de mise en ligne que des indicateurs. La page publique de méthodologie d'IVRYN décrit la façon dont le studio traite les preuves produit, et le même esprit s'applique ici : décidez à l'avance de ce que vous allez compter, consignez ce qui a changé et n'affirmez rien de plus que ce que les données permettent. Une version qui fonctionne en local n'est pas une mise en ligne réussie. Tant que l'adresse publique n'a pas été vérifiée, vous savez seulement que le produit fonctionne sur votre propre machine : ne déclarez donc un déploiement terminé qu'après cette vérification.

• Les critères de réussite et d'échec ont-ils été fixés avant le lancement ?
• Chaque indicateur est-il lié au parcours principal plutôt qu'à l'activité générale ?
• Le parcours principal affiche-t-il des états d'erreur clairs et propose-t-il un moyen de reprise ?
• La collecte de données se limite-t-elle à ce que la fonctionnalité exige réellement ?
• Les dépendances à des services tiers sont-elles notées, avec leurs contraintes de disponibilité et de coût ?
• L'adresse publique a-t-elle été vérifiée après le déploiement, et pas seulement la version locale ?
• Existe-t-il un journal de ce qui a changé à chaque version et de la version actuellement en ligne ?
• Les étapes manuelles sont-elles signalées aux utilisateurs lorsque c'est important ?
• Le parcours principal a-t-il été vérifié pour l'accessibilité sur cette version ?

Exemple commenté (hypothétique) : un outil de reporting pour petites agences

Exemple uniquement, pas un projet réel. Une équipe de deux personnes pense que les petites agences marketing passent des heures chaque semaine à assembler à la main les rapports de leurs clients. La décision à prendre est d'automatiser ou non une troisième source de données, ou de repenser l'audience. Le MVP prend en charge un modèle de rapport et deux intégrations, la troisième source étant traitée manuellement. Comme les agences vont connecter les comptes de leurs clients, la connexion, un accès limité aux rapports de chaque agence et une erreur claire avec option de nouvel essai en cas d'échec d'une intégration restent tous dans le périmètre.

La première version est proposée à quelques agences invitées, après des vérifications au clavier et au lecteur d'écran et un contrôle de l'adresse en ligne. Le signal convenu est de savoir si la plupart d'entre elles envoient deux rapports hebdomadaires consécutifs via l'outil. Cela éclaire la décision d'automatisation ; cela ne prouve pas l'adoption. La deuxième version ne change qu'une seule chose, l'automatisation de la source manuelle, afin que son effet puisse être lu isolément. Si les agences s'arrêtent après un rapport, l'équipe discute avec elles avant d'ajouter des fonctionnalités, car c'est peut-être le problème ou l'audience qui est en cause plutôt que le développement.