Une question avant une fonctionnalité
Un prototype utile commence avec une question précise. Peut-on récupérer cette information depuis l’outil existant ? Le document contient-il assez de données pour préparer le dossier ? L’équipe comprend-elle le parcours sans explication ?
Construire juste ce qu’il faut pour répondre à cette question évite de consacrer l’essentiel du temps à des fonctionnalités qui ne changent pas la décision.
Montrer un parcours de bout en bout
Prenons un petit outil de suivi de demandes. Le prototype peut recevoir une demande, en afficher les informations essentielles et permettre de changer son état. Il n’a pas encore besoin de tous les rôles, de tous les rapports ou de tous les cas particuliers.
En revanche, les limites doivent être explicites. Une donnée de démonstration ne doit pas se faire passer pour une connexion réelle. Un email préparé n’est pas un email envoyé. Un résultat généré par IA n’est pas une information vérifiée.
Observer ce que les personnes font vraiment
Demander « est-ce que cela vous plaît ? » apporte moins d’informations que de proposer une tâche réelle. Regardez où la personne hésite, ce qu’elle cherche et ce qu’elle contourne.
Les retours les plus utiles sont souvent très concrets : ce champ n’est jamais connu à cette étape ; cette pièce arrive plus tard ; cette décision appartient à une autre équipe. Ces détails font la différence entre une démo et un outil de travail.
Construire ensuite, avec moins d’inconnues
Un prototype concluant ne remplace pas le travail de fiabilisation. La gestion des accès, les sauvegardes, les erreurs, la documentation et la mise en service restent à traiter avant un usage réel.
Il permet de le faire sur une base éprouvée : un problème mieux compris, un parcours testé et des critères de réussite partagés. C’est cette connaissance qui rend la suite plus précise.