Choisir la plus petite version utile d'un produit

La planification d'un MVP commence par un seul résultat, pas une liste de fonctionnalités

La planification d'un MVP échoue le plus souvent dès la première étape : les équipes rédigent une liste de fonctionnalités qu'elles pensent nécessaires au produit, puis cherchent des moyens de la réduire. Cela produit une version réduite de tout, plutôt qu'une version fonctionnelle de la seule chose qui compte. Une question de départ plus fiable est : quel résultat unique, s'il est atteint, rend cette version digne d'être utilisée ? Tout le reste sert ce résultat, ou ne fait pas partie de la version.

Cadrer la version autour d'un résultat plutôt qu'un ensemble de fonctionnalités change aussi la façon dont on évalue les coupes plus tard. Quand une fonctionnalité est remise en question, le test n'est pas « est-ce utile en général » mais « le fait de la retirer empêche-t-il un utilisateur d'atteindre le résultat ». Cette distinction évite que les négociations de périmètre ne deviennent des débats subjectifs sur le goût.

Le guide de GOV.UK sur la phase bêta souligne un point voisin : une bêta sert à tester si un service fonctionne réellement pour les gens, et non à construire chaque fonctionnalité anticipée. La même discipline s'applique à une première version commerciale. L'objectif de la planification d'un MVP n'est pas l'exhaustivité, c'est une réponse claire sur la solidité du résultat central face à de vrais utilisateurs.

Séparer le résultat central de son échafaudage de support

Une fois le résultat central identifié, le reste du périmètre se répartit en un petit nombre de catégories : ce qui produit le résultat, ce qui rend le résultat fiable (gestion des erreurs, accessibilité de base, retours clairs), et ce qui rend le résultat confortable ou pratique sans être essentiel dès le premier jour. Confondre la deuxième et la troisième catégorie est la cause la plus fréquente de dérive de périmètre, car les fonctionnalités de confort semblent souvent nécessaires à l'équipe, même quand un premier utilisateur pourrait s'en passer.

Une discipline utile consiste à demander, pour chaque fonctionnalité candidate, ce qui se passe si elle manque quand une vraie personne essaie d'accomplir la tâche. Si la réponse honnête est « elle obtient une erreur sans explication » ou « elle ne peut pas du tout accomplir la tâche », la fonctionnalité relève probablement de la catégorie fiabilité et doit rester. Si la réponse honnête est « cela lui prend un peu plus de temps » ou « c'est moins soigné », cela peut généralement attendre.

Cette séparation protège aussi les interfaces accessibles d'être traitées comme un ajout tardif. L'accessibilité de base, comme une navigation au clavier utilisable, un contraste lisible et des messages d'erreur clairs, fait partie de savoir si le résultat fonctionne réellement pour les personnes qui en ont besoin, et non une touche finale appliquée une fois le « vrai » périmètre terminé.

Utiliser de petites versions testables pour remplacer les suppositions

Une petite version testable n'est pas simplement une version avec moins de fonctionnalités ; c'est une version conçue pour que l'équipe puisse en tirer un enseignement précis. Avant de construire, il est utile d'écrire ce qui constituerait une preuve que le résultat est atteint ou non. Sans cette étape, une petite version risque quand même d'être livrée discrètement et jugée uniquement sur des opinions.

Le guide de priorisation de GOV.UK présente cela comme le fait de décider ce qu'il faut construire ensuite à partir de preuves de besoin utilisateur plutôt que d'hypothèses internes sur l'importance. Appliqué à la planification d'un MVP, cela signifie que chaque version doit être suffisamment ciblée pour que l'équipe puisse observer, dans un délai raisonnable, si le résultat visé se produit réellement pour les utilisateurs, plutôt que de le supposer parce que la fonctionnalité existe.

Les petites versions réduisent aussi le coût de l'erreur. Si une version est cadrée autour d'un seul résultat et que les preuves montrent qu'il ne se concrétise pas, l'équipe a peu perdu et sait précisément quoi changer. Une version construite autour de dix fonctionnalités faiblement liées rend beaucoup plus difficile d'identifier quelle partie a échoué.

Un exemple concret : cadrer une première version pour un outil de planification

Ce qui suit est hypothétique, purement illustratif, et ne décrit aucun produit ou client IVRYN. Imaginez une petite équipe construisant un outil permettant à des indépendants d'envoyer à leurs clients un lien de réservation pour qu'ils choisissent un créneau sans échanges d'e-mails. L'instinct de l'équipe, avant toute coupe, est une liste incluant plusieurs intégrations d'agenda, la collecte de paiement, des rappels automatiques, la planification pour plusieurs membres d'équipe, et un portail client à l'image de la marque.

En appliquant le test du résultat : le résultat central est « un client peut choisir un créneau disponible et les deux parties voient la confirmation ». La collecte de paiement, la planification d'équipe et l'image de marque n'affectent pas si ce résultat se produit ; elles affectent le confort et la monétisation ultérieure. Une seule intégration d'agenda, plutôt que plusieurs, suffit à tester si le mécanisme de disponibilité et de confirmation fonctionne. Les rappels automatiques ne relèvent de la catégorie fiabilité que si leur absence provoquerait des rendez-vous manqués que le flux central lui-même ne prévient pas déjà, dans ce cas, un e-mail de confirmation au moment de la réservation couvre probablement suffisamment ce risque pour une première version.

La version résultante : une intégration d'agenda, un lien de réservation, et un e-mail de confirmation. Pas de paiement, pas de comptes d'équipe, pas d'image de marque personnalisée. L'équipe peut maintenant observer, en quelques semaines, si les indépendants et leurs clients concluent des réservations sans confusion. Ces preuves, et non une liste de fonctionnalités plus longue, décident de ce qui sera construit ensuite.

• Nommer le résultat unique que la version doit atteindre avant de lister la moindre fonctionnalité
• Trier le reste du périmètre en : produit le résultat, protège la fiabilité du résultat, ou ajoute du confort ultérieur
• Écrire à l'avance quelles preuves montreraient que le résultat fonctionne ou non
• Traiter l'accessibilité de base comme faisant partie du résultat, pas comme un ajout ultérieur
• Préférer une seule intégration ou un seul chemin à plusieurs, si cela suffit à tester le mécanisme

Mesurer ce que la version devait démontrer

Une version cadrée autour d'un seul résultat n'est utile que si l'équipe vérifie réellement si ce résultat s'est produit. Cela implique de définir, à l'avance, un signal mesurable directement lié au résultat plutôt qu'à une activité générale. Pour l'exemple de planification ci-dessus, un signal pertinent est la proportion de liens de réservation qui aboutissent à un créneau confirmé, et non le nombre de fois où le lien a été ouvert ou où l'outil a été mentionné favorablement.

Les résultats produit mesurables doivent aussi être assortis d'une décision, pas seulement d'un chiffre. Avant la sortie de la version, il vaut la peine de convenir de quel résultat inciterait l'équipe à étendre le périmètre, quel résultat inciterait à changer d'approche, et quel résultat est suffisamment ambigu pour justifier plus de temps avant de décider. Sans cet accord, les équipes ont tendance à interpréter les résultats ambigus comme une confirmation de ce qu'elles voulaient déjà construire ensuite.

C'est aussi là que le guide de priorisation de GOV.UK est utile au-delà de la version initiale : décider ce qu'il faut construire ensuite est traité comme un exercice continu de pesée des preuves de besoin face à l'effort, et non comme un exercice de cadrage ponctuel qui se termine une fois la première version livrée.

Comment IVRYN traite le périmètre dans son propre portefeuille

IVRYN est un studio de produits indépendant basé à Paris qui maintient un petit portefeuille de produits distincts, dont Imryn, Datvero, Cascads, Reef, Flare, Sealed, Crucible CLUB et Victor Laybats, chacun avec son propre domaine, son propre public et sa propre page produit. La position éditoriale du studio est de documenter comment les produits ciblés sont étudiés, conçus, livrés et améliorés sans gonfler les affirmations, et cet article reflète cette position plutôt qu'un rapport sur un résultat spécifique obtenu par ces produits.

Aucune étude interne ni résultat client n'est revendiqué ici ; le raisonnement de cet article s'appuie sur des guides publics généraux de livraison et sur la préférence affichée du studio pour un périmètre clair et une utilité mesurable, pas sur des données internes. Les lecteurs qui évaluent leur propre planification de MVP doivent considérer l'exemple concret ci-dessus comme un raisonnement illustratif, et non comme la preuve d'une méthode testée.

Comme chaque produit IVRYN occupe son propre périmètre et son propre public, l'intérêt pratique du studio pour ce sujet est simple : une version qui essaie de servir trop de résultats à la fois est plus difficile à évaluer honnêtement, qu'il s'agisse d'un outil de planification, d'un produit de contenu, ou de tout autre chose.