Le problème existe-t-il vraiment ?
Le besoin exprimé correspond-il à une difficulté suffisamment fréquente ou importante pour justifier une solution ?
Une idée ne se valide pas dans une présentation. Elle se valide lorsqu’une personne peut essayer un parcours concret et dire ce qui fonctionne, ce qui bloque et ce qui ne lui sert pas.
Le but d’un prototype rapide n’est pas de produire en quelques heures une application terminée. Il consiste à fabriquer la plus petite expérience crédible capable de répondre à une question précise. On remplace ainsi plusieurs semaines de spéculation par un premier retour observable.
Le besoin exprimé correspond-il à une difficulté suffisamment fréquente ou importante pour justifier une solution ?
L’utilisateur sait-il quoi faire sans explication, et arrive-t-il au résultat attendu avec un effort raisonnable ?
Le résultat fait-il réellement gagner du temps, réduit-il les erreurs ou rend-il possible une action auparavant difficile ?
Données, intégrations, performance ou sécurité : le prototype révèle tôt les hypothèses techniques les plus fragiles.
Le prototype peut utiliser des données limitées, simuler certaines intégrations ou ne couvrir qu’un seul scénario. Ces limites doivent être explicites. En revanche, le parcours testé doit être suffisamment réaliste pour produire un retour fiable. La vitesse vient de la réduction volontaire du périmètre, pas de l’abandon de la qualité.
À la fin de la session, la décision devient concrète : poursuivre, modifier l’approche, tester une autre variante ou arrêter sans avoir engagé le budget d’un produit complet.
Un premier échange de 30 minutes permet d’identifier la question décisive et le plus petit prototype capable d’y répondre.
Prendre rendez-vous