Comment définir le périmètre d’un MVP vraiment utile ?

Au début d’un projet, presque chaque fonctionnalité semble indispensable. Il faut un espace utilisateur, un tableau de bord, des notifications, des exports, une application mobile, plusieurs rôles et peut-être une fonction IA. À force d’additionner les besoins, la première version finit par ressembler au produit complet.

Un MVP, pour minimum viable product, poursuit un objectif plus précis : mettre une proposition de valeur à l’épreuve d’un usage réel avec un périmètre limité. Il ne s’agit ni de construire une petite version de chaque fonctionnalité, ni de livrer un produit fragile pour aller vite.

Le bon périmètre permet de répondre à une question importante sans développer tout ce qui pourrait être utile un jour.

Partir d’une hypothèse que l’usage peut confirmer ou contredire

« Créer une plateforme de gestion » est une intention. « Permettre aux responsables de site de suivre une intervention sans appeler notre équipe » décrit un résultat observable.

Prenons ce second cas comme exemple fictif. L’hypothèse peut être formulée ainsi :

Si les responsables de site disposent d’un suivi à jour de leurs interventions, ils consulteront le portail pour connaître l’avancement et solliciteront moins souvent l’équipe par téléphone.

Cette formulation identifie un utilisateur, une situation et un changement attendu. Elle permet aussi d’envisager plusieurs causes d’échec : le suivi n’est pas assez frais, les statuts sont incompréhensibles, l’accès est compliqué ou les utilisateurs préfèrent leur interlocuteur habituel.

Choisissez l’incertitude principale. Cherchez-vous à vérifier l’intérêt des utilisateurs, la faisabilité technique, l’efficacité opérationnelle ou la disposition à payer ? Un même test ne répond pas nécessairement à ces quatre questions.

Si l’obstacle concerne uniquement la faisabilité d’une intégration, un POC technique peut suffire. Si vous voulez vérifier la compréhension d’un parcours, une maquette testable peut être appropriée. Le développement d’un MVP devient utile lorsqu’il faut observer le service en fonctionnement.

Choisir un utilisateur prioritaire et un parcours complet

Représentez le chemin nécessaire pour obtenir le résultat promis. Pour le portail d’interventions, une première version pourrait permettre au responsable de site de :

1. accéder à son espace ;
2. retrouver ses interventions ;
3. comprendre leur statut et la prochaine étape ;
4. consulter un compte rendu ;
5. poser une question lorsqu’une information manque.

Ce parcours est plus utile qu’un produit doté de dix rubriques dont aucune ne va jusqu’au bout. Il fait apparaître un besoin souvent oublié : quelqu’un doit alimenter les statuts pour que l’information présentée soit fiable.

Il faut donc cadrer également le travail de l’équipe interne. Comment met-elle à jour une intervention ? Que se passe-t-il si le technicien n’a pas transmis son compte rendu ? Qui répond à la question du client ? La valeur du portail dépend de cette organisation, pas seulement de son interface.

Couper les fonctions qui ne participent pas au test

Pour chaque fonctionnalité envisagée, posez la question : sans elle, peut-on encore tester l’hypothèse dans des conditions acceptables ?

Dans notre exemple, un accès adapté aux droits du client et des statuts compréhensibles sont indispensables. Un tableau de bord analytique avancé, une personnalisation complète de l’interface ou une application mobile native peuvent attendre si une version web utilisable sur téléphone couvre le parcours.

Un export peut également être secondaire si le pilote porte sur la consultation de l’avancement. Il devient indispensable si le résultat promis consiste précisément à produire un justificatif pour un autre service.

La priorité dépend donc du test, pas du nom de la fonctionnalité. Écrivez les éléments volontairement exclus, avec la raison de leur exclusion. Cette liste vous aidera à résister aux ajouts qui ne changent pas ce que vous cherchez à apprendre.

Pour une fonction IA, appliquez le même raisonnement : si un statut structuré ou un texte préparé suffit, un agent autonome n’est pas nécessaire au premier test. Le guide agent IA ou automatisation classique permet d’évaluer ce besoin séparément.

Accepter du travail manuel, à condition de le rendre visible

Une partie du service peut être opérée manuellement pendant le pilote. L’équipe peut importer les premières interventions, vérifier les comptes rendus ou préparer un récapitulatif avant sa mise à disposition.

Ce choix permet de tester l’intérêt du parcours sans construire immédiatement toute la chaîne d’intégration. Il a cependant une limite : une intervention manuelle invisible peut donner une fausse impression de rentabilité ou de qualité.

Notez le temps passé, les corrections et les compétences nécessaires. Un service apprécié mais demandant deux heures de préparation par dossier n’a pas encore démontré sa viabilité économique. Ce résultat reste utile : il indique quelle partie du processus doit être simplifiée ou automatisée.

Ne simulez pas un résultat disponible si personne ne peut réellement le fournir. Le pilote doit rendre le service promis, même si l’organisation en arrière-plan reste provisoire.

Définir ce que « terminé » signifie

« Le client peut consulter ses interventions » laisse trop de place à l’interprétation. Des critères d’acceptation précis rendent le travail vérifiable :

• un client ne voit que les interventions des sites auxquels il a accès ;
• chaque intervention indique son état et la date de sa dernière mise à jour ;
• l’absence de compte rendu est expliquée plutôt que présentée comme une erreur ;
• les données persistent après le redémarrage du service ;
• un échec de mise à jour est détectable par l’équipe ;
• le parcours principal reste utilisable sur le téléphone des participants.

Limiter les fonctionnalités ne dispense pas des protections nécessaires aux données et aux utilisateurs. Les droits d’accès, la récupération des données et le traitement des erreurs font partie de la fiabilité minimale du service.

En revanche, inutile de construire une architecture prévue pour des millions de comptes sans besoin démontré. Choisissez une solution que l’équipe peut déployer, surveiller et faire évoluer au niveau de charge attendu.

Préparer le pilote avant de finir le développement

Identifiez les participants, les situations dans lesquelles ils utiliseront le produit et la personne qui les accompagnera. Une application livrée sans utilisateurs disponibles ne produit aucun apprentissage.

Le protocole doit préciser :

1. La situation de référence : comment le travail est effectué aujourd’hui.
2. La durée d’observation : assez longue pour voir plusieurs occurrences du parcours.
3. Les indicateurs : ce qui permettra de juger le résultat.
4. Les retours qualitatifs : les raisons des abandons, des hésitations et des contournements.
5. La règle de décision : poursuivre, modifier le parcours ou abandonner l’hypothèse.

Pour le portail, comptez les consultations utiles, les demandes téléphoniques de suivi et les interventions qui nécessitent une correction. Rapportez les résultats au volume de dossiers : une baisse d’appels pendant une semaine de faible activité ne prouve pas l’efficacité du produit.

Un petit pilote aide à trouver les problèmes d’usage. Il ne permet pas à lui seul de conclure que tous les clients adopteront le service. Notez les limites de l’échantillon avant de généraliser.

Faire du premier bilan une décision, pas une nouvelle liste de fonctions

Après le pilote, regroupez les observations selon leur effet sur l’hypothèse. Si les utilisateurs consultent le portail mais appellent quand même parce que les statuts sont trop vagues, ajouter un graphique ne réglera probablement pas le problème.

Si le portail est peu utilisé, cherchez d’abord pourquoi : absence de besoin fréquent, mauvaise information au bon moment, accès difficile ou valeur insuffisante. Chaque cause appelle une réponse différente.

Vous pouvez alors décider de corriger le parcours, d’élargir progressivement le périmètre ou de ne pas investir davantage. Arrêter un projet après un test clair peut être une bonne décision ; poursuivre sans comprendre les résultats l’est rarement.

Avant de développer, vérifiez enfin qu’un SaaS existant ou une solution hybride ne permet pas de tester la même proposition plus simplement. Le MVP est un moyen d’apprendre et de rendre un service, pas une obligation de tout construire.

Vous avez une idée accompagnée d’une liste de fonctionnalités qui s’allonge ? Discutons du premier parcours à livrer, de l’hypothèse qu’il doit vérifier et des fonctions qui peuvent attendre.