MVP

MVP : Version réduite au strict nécessaire pour vérifier une hypothèse auprès de vrais utilisateurs, livrée tôt afin d’apprendre avant d’investir davantage.

Classé dans la famille « Produit et UX », ce terme revient dans les échanges entre un client et son agence. Voici ce qu’il faut en comprendre avant d’en discuter le prix.

Pourquoi MVP compte sur un projet mobile

MVP appartient au vocabulaire de la conception, celui des décisions prises avant la première ligne de code. Ce sont les moins chères à changer, et celles qui engagent le plus la suite.

Dans la pratique, deux interlocuteurs qui n’ont pas la même définition en tête avancent d’accord pendant des semaines, puis découvrent le désaccord à la livraison.

De la définition à la ligne de cahier des charges

Un cahier des charges lisible relie « MVP » à un utilisateur nommé et à une action précise : qui fait quoi, depuis quel écran, avec quel résultat visible.

À écrire noir sur blanc, dans le chapitre qui correspond :

• Le parcours principal, décrit du premier lancement à la première action utile.
• Les critères d’acceptation, rédigés de manière à pouvoir être refusés.
• Le nombre d’allers-retours de maquettes inclus dans le prix.
• Le niveau d’accessibilité visé, et les écrans sur lesquels il est vérifié.

Reste à désigner qui écrit cette ligne et qui la valide. Sans nom en face, la rubrique se remplit la veille de la signature, avec les mots du prestataire.

Pour le cadre général, le guide des prix donne les fourchettes constatées en France et le modèle de cahier des charges la structure qui les rend opposables.

Vérifier plutôt que croire

Sur « MVP », la recette se fait écran par écran, y compris dans les cas que personne n’aime tester : liste vide, erreur, coupure de réseau.

• Reprendre les critères d’acceptation et les cocher un par un, sans indulgence.
• Utiliser l’application sur un petit écran, d’une seule main.
• Comparer les maquettes validées au résultat livré, écran par écran.

Chacun de ces contrôles prend quelques minutes. Les découvrir après la mise en ligne prend des jours.

Les pièges à éviter

Aucune de ces erreurs ne se voit le jour où elle est commise. Toutes se paient plus tard, au moment le moins commode.

• Décrire une fonctionnalité par une intention plutôt que par des écrans et des règles.
• Oublier les cas qui vont mal : liste vide, erreur réseau, droits insuffisants.
• Confondre l’avis de trois collègues et un test auprès de vrais utilisateurs.
• Laisser le back-office hors du cahier des charges, alors qu’il pèse lourd dans le chiffrage.
• Reprendre la formulation d’un autre projet sans vérifier qu’elle décrit bien celui-ci.

Termes liés

Les entrées du glossaire déjà publiées sur des sujets voisins :

• Onboarding
• Churn
• Wireframe
• User story
• Design system

Questions fréquentes

MVP : de quoi parle-t-on exactement ?

Version réduite au strict nécessaire pour vérifier une hypothèse auprès de vrais utilisateurs, livrée tôt afin d’apprendre avant d’investir davantage. Cette définition suffit pour une discussion de cadrage. Pour un contrat, il faut y ajouter ce que le terme recouvre exactement sur votre application.

Comment le vérifier à la recette ?

Avec un critère écrit avant le développement, formulé de façon à pouvoir être refusé. « L’écran doit être agréable » ne se recette pas. « La liste vide affiche tel message et tel bouton » se recette.

Est-ce que ça se retrouve dans le devis ?

Un devis lisible sépare conception, design, développement, tests, publication et suivi. La grille de lecture des devis détaille poste par poste ce qui doit y apparaître.

Toutes les définitions publiées sont rassemblées dans l’index du glossaire, classées de A à Z et par famille.