LES POINTS ESSENTIELS
À retenir
- Définir la question à vérifier avant de choisir les écrans.
- Livrer un parcours central complet et exploitable.
- Préparer des critères de poursuite, de correction ou d’arrêt.
Formuler une hypothèse d’usage
Écrivez ce que vous voulez apprendre : des techniciens peuvent-ils terminer leur rapport sur place, ou des clients retrouvent-ils seuls leurs documents ? Définissez le public et la situation. Cette hypothèse doit être plus précise que « les utilisateurs aiment l’application ».
Choisissez ensuite un parcours qui expose la question. Un prototype cliquable peut suffire pour vérifier la compréhension des écrans, mais pas pour valider une synchronisation réelle ou un usage répété. Le niveau de réalisation doit correspondre à l’incertitude que vous souhaitez réduire.
Conserver un parcours complet
Un parcours réduit doit encore fonctionner du début à la fin. Pour une demande de réservation, il faut comprendre la disponibilité, envoyer la demande et recevoir un état fiable. Un bouton animé sans traitement derrière ne valide pas ce service.
Séparez les fonctions indispensables des conforts reportables. L’authentification, la récupération d’un compte ou la reprise d’une erreur peuvent sembler secondaires sur une maquette, tout en étant nécessaires à l’essai réel. Réduisez le périmètre autour d’un usage cohérent plutôt que de supprimer les étapes moins visibles.
Préparer les données et l’administration
Une application dépend souvent d’un planning, de contenus ou de comptes gérés par une équipe. Même si ces opérations sont manuelles dans la première version, leur responsable doit être identifié. L’expérience peut échouer à cause d’une information non tenue à jour, sans que l’interface mobile soit en cause.
Prévoyez un moyen de corriger une donnée et d’aider un utilisateur bloqué. Le premier lancement doit rester exploitable par l’équipe qui l’accompagne. Une administration proportionnée peut être simple, mais elle ne doit pas être remplacée par des interventions improvisées dans les données de production.
Définir une observation utile
Choisissez quelques éléments : tâche terminée, blocage rencontré, besoin d’aide et raison d’abandon. Complétez les chiffres par des échanges avec les utilisateurs. Un nombre d’installations ne prouve pas qu’un problème a été résolu.
Annoncez à l’avance les critères de décision. Selon les résultats, vous pourrez améliorer le parcours, changer le public ciblé ou arrêter une fonction. Cette possibilité d’arbitrer fait partie de l’intérêt du MVP. Si la suite est déjà décidée indépendamment de l’essai, le projet sert surtout de première livraison, ce qui est une autre démarche.
Prévoir ce qui restera après le test
Documentez les choix techniques, les accès et les limites connues. Une version expérimentale peut devenir un outil quotidien avant que l’équipe l’ait anticipé. Identifiez ce qu’il faudra renforcer si l’usage se confirme : maintenance, assistance, droits ou capacité serveur.
Le périmètre réduit doit rester honnête envers ses utilisateurs. Expliquez ce qui est disponible et ce qui ne l’est pas encore. Chez Site en Or, ce cadrage permet de construire une première version qui sert réellement à apprendre, puis d’investir dans les évolutions justifiées par le terrain.