Cadrer un MVP : construire le plus petit produit qui prouve l'idée, puis le faire grandir

Avant le MVP : comprendre, puis prototyper

Le Service Manual du gouvernement britannique, écrit pour les équipes qui conçoivent des services publics numériques, décrit des phases qui valent tout autant pour le produit d'une PME. En découverte (discovery), on apprend qui sont les utilisateurs, ce qu'ils cherchent à accomplir et les contraintes du contexte ; le manuel est clair : on ne commence pas à construire en découverte, et s'arrêter à ce stade n'est pas un échec si l'étude montre que cela n'en vaut pas la peine.

En alpha, on essaie différentes solutions aux problèmes repérés, en se concentrant sur les points qu'on pense les plus difficiles. Le manuel conseille de construire des choses juste assez complexes pour tester des idées, pas du code de production, et de s'attendre à jeter le code et beaucoup d'idées à la fin. Ce n'est qu'en bêta qu'on prend la meilleure idée pour la construire pour de vrai, d'abord avec un groupe restreint d'utilisateurs, puis de façon ouverte.

La fiche de cadrage

1. L'utilisateur : un seul type d'utilisateur à servir d'abord, décrit en une phrase.
2. La tâche : la chose qu'il doit pouvoir faire de bout en bout pour que le produit soit utile.
3. Les étapes : le chemin le plus court pour accomplir cette tâche, écran par écran ou message par message.
4. L'hypothèse la plus risquée : ce qui doit être vrai pour que cela marche (les gens paieront, les données existent, l'API d'un partenaire le permet), et comment le prototype l'a testée.
5. Le signal de réussite : ce que vous mesurerez les premières semaines pour décider de la suite.
6. La liste « pas maintenant » : tout ce qui est volontairement laissé de côté, écrit pour cesser d'y revenir.
7. Les contraintes : protection des données, paiements, obligations légales qui ne peuvent pas attendre la version deux.

Ce qui a généralement sa place dans la version un

• La connexion, si les utilisateurs ont leurs propres données.
• La tâche centrale, bien faite, y compris les cas qui tournent mal (erreurs, annulations).
• Le paiement, si faire payer fait partie de ce que vous testez.
• Une administration simple : un moyen pour votre équipe de voir et corriger les données sans développeur.
• La mesure du signal de réussite.
• Des environnements de dev, de recette et de prod séparés, des sauvegardes et une surveillance, parce qu'une première version contient déjà de vraies données.

Ce qui généralement ne l'a pas

Laisser quelque chose hors de la version un est une décision, pas un échec. La liste « pas maintenant » est le début de votre feuille de route, classée selon ce que demandent les vrais utilisateurs.

• Tous les types d'utilisateurs à la fois.
• Des applications natives iOS et Android, quand une application web adaptée au mobile et installable sur le téléphone suffit pour une première version.
• Des rôles et droits complexes au-delà des besoins des premiers utilisateurs.
• Des intégrations avec des outils que les premiers utilisateurs n'emploient pas.
• Des tableaux de bord au-delà du signal de réussite.
• Le peaufinage d'écrans que personne n'a encore utilisés.

Les signaux d'alerte dans un cadrage de MVP

• Le document liste des fonctionnalités mais ne nomme jamais l'utilisateur ni la tâche.
• Personne ne sait dire quel résultat ferait arrêter ou changer de direction.
• L'hypothèse la plus risquée n'a pas été testée avant de construire.
• La version un doit être parfaite parce qu'elle sera montrée à tout le monde le premier jour.
• Rien n'est prévu pour les données, les sauvegardes ou le support des utilisateurs après le lancement.

Comment nous menons les projets de MVP chez Takat

Nous travaillons par les mêmes étapes : comprendre le processus, prototyper la partie risquée, construire la plus petite vraie version, puis la mettre en ligne avec des environnements de dev, de recette et de prod, une adresse d'aperçu par branche, des compilations sur GitHub Actions, des contrôles de santé et des instantanés quotidiens. Nos développeurs travaillent avec des agents de code IA, sous relecture, et chaque modification est fusionnée par une personne. Parmi les plateformes que nous avons construites et faisons tourner en production : un logiciel de gestion en ligne pour des organismes de formation en France, et une plateforme de réservation et de relation client pour un groupe de restaurants, qui a repris la base clients d'un précédent outil. Nous construisons des applications web adaptées au mobile et installables sur le téléphone ; nous n'avons pas encore livré d'application native iOS ou Android. Voir MVP et prototypes et la formule Lancement de MVP.