Prototype technique ou pas ?

Nous aurions tendance à dire non.

Pourquoi ?

1. Le but du prototype technique est de rapidement mettre quelque chose dans les mains des beta-testeurs. On prend donc normalement énormément de raccourcis que ce soit sur la gestion de données, sa validation des données, la sécurité… afin de ne pas mettre sur pied un début d'usine à gaz qui ressemblerait au vrai produit. En faisant ça :
   1. On risque de ne pas représenter les vrais usages du produit, et donc il est peu probable que les gens aillent tester régulièrement un outil qui est partiellement stable ;
   2. Il faudra dans tous les cas faire table rase de ce prototype car il a été construit sur des fondations précipitées ;
2. Nous considérons qu'il est plus efficace d'avoir bien fignolé ses maquettes et de disposer d'un "wireframe animé" afin de valider la cohérence du produit avec vos beta-testeurs. Cela ne demande aucune compétence technique, vous n'avez donc pas passé de temps à essayer de mettre en place des outils comme un faux frontend branché à une "base de données" tel que Grist ou Airtable…

Si les wireframes conviennent aux beta-testeurs vous pouvez passer à la réalisation d'un MVP (produit minimum viable). Vous vous lancez donc dans la réalisation du vrai produit, tout en limitant le développement initial qu'à certaines fonctionnalités.

Contexte qui suit

Nous considérons ici et dans la suite du guide que vous partez sur un produit numérique à construire. Les maquettes et MVP n'ont quasiment aucun sens si vous réutilisez un outil déjà fait sans le modifier (il devient automatiquement votre "produit").