Le prototype répond à une question, affiche un résultat et impressionne l’équipe. Pourtant, une partie du parcours a été préparée à la main. Ce n’est pas un problème si c’est expliqué. Présenter un prototype numérique demande de distinguer ce qui fonctionne déjà, ce qui est simulé et ce qui reste à construire.
Chaque démonstration doit annoncer son périmètre
Une maquette cliquable peut montrer l’enchaînement des écrans sans traiter de données réelles. Un prototype fonctionnel peut exécuter une partie du travail avec un périmètre limité. Une démonstration assistée peut faire intervenir une personne derrière le système. Ces approches répondent à des questions différentes.
Dites ce que l’essai permet d’évaluer : compréhension de l’interface, intérêt de l’usage, faisabilité d’une fonction ou performance dans une situation précise. Une équipe peut prendre une bonne décision avec une simulation, à condition de ne pas la confondre avec un service déjà prêt.
Notre article sur la création de sites à l’aide d’une IA pose la question de ce que les outils produisent réellement. Pour un prototype aussi, une présentation fluide doit être rapprochée des fonctions effectivement réalisées.
Une recherche peut utiliser une liste fixe, un bouton peut afficher un résultat préparé, une estimation peut ne porter que sur un jeu d’essai. Notez ces éléments et expliquez leur rôle. Le public n’a pas besoin de lire tout le code, mais il doit comprendre les limites qui influencent sa décision.
Les conditions favorables doivent aussi être visibles. Si le fichier de démonstration possède un format particulier, dites-le. Si le temps de réponse n’a pas été testé avec plusieurs utilisateurs, ne présentez pas l’essai individuel comme une preuve de capacité générale.
Une limite annoncée augmente la valeur de l’observation.
Elle permet de concentrer les questions sur ce qui doit encore être appris. À l’inverse, une limite cachée fait perdre du temps : l’équipe peut demander une généralisation fondée sur une fonction qui n’existe pas encore.
Montrer une exception, pas seulement le parcours parfait
Ajoutez une donnée manquante ou une demande hors périmètre. Observez le message obtenu et la manière de reprendre. Si le prototype ne gère pas encore ce cas, indiquez-le explicitement et montrez la décision envisagée pour la version suivante.
La démonstration peut aussi comparer deux scénarios : un cas prévu et un cas non prévu. Cette différence aide les métiers à comprendre où leur expertise sera nécessaire. Un outil ne devient pas autonome simplement parce qu’il a réussi une fois devant une salle.
Les données utilisées doivent être adaptées à l’essai. Un jeu fictif peut suffire à montrer le parcours et évite d’exposer des informations clients. Si des données réelles sont nécessaires, leur usage doit suivre les règles de l’organisation et le périmètre autorisé.
Préparez quelques questions : l’utilisateur comprend-il la prochaine action ? Le résultat contient-il les informations utiles ? Quel cas manque pour juger le besoin ? Notez les réponses avec leur contexte, plutôt qu’un simple score de satisfaction.
Un commentaire « cela paraît simple » devient plus utile si la personne a réellement réalisé une tâche. Laissez le public manipuler le prototype lorsque cela convient, sans guider chaque clic. Vous découvrirez des hésitations que la démonstration du concepteur masque naturellement.
Terminer avec les preuves et les inconnues
Le compte rendu devrait distinguer les observations réalisées, les hypothèses encore ouvertes et les décisions prises. Ajoutez la prochaine expérience nécessaire : essai avec un autre fichier, intégration à un outil réel ou test de charge limité.
Un test de prototype réussit lorsqu’il réduit une incertitude importante. Son rôle n’est pas de faire passer une maquette pour un produit terminé. Une présentation précise permet à l’entreprise d’investir dans la bonne étape suivante, avec une compréhension partagée de ce qui reste à vérifier.
