Le plus petit prototype qui prouve quelque chose
Trouver la question dangereuse
Demandez : qu'est-ce que nous regretterons, dans six mois, de ne pas avoir vérifié la première semaine ? La réponse tombe presque toujours dans l'une de ces trois catégories : est-ce seulement possible techniquement, les données existent-elles et sont-elles accessibles, et quelqu'un s'en servira-t-il ?
Si la question dangereuse porte sur les données ou l'adoption, ne construisez rien cette semaine. Vérifiez les données, ou faites réaliser le travail manuellement en coulisses et observez s'il y a une demande.
Trois niveaux, par ordre de coût
Entièrement manuel. Une personne rend le service sans que l'utilisateur le sache. En deux jours vous savez s'il y a une demande, et vous récoltez des dizaines d'exemples réels.
Tableur et colonne de contrôle. Cinquante cas réels, le même traitement pour tous, et une colonne où un humain indique si le résultat convient. Sans interface, sans base de données.
Prototype connecté. Seulement si les deux premiers niveaux sont concluants : interface minimale, une source de données réelle, un petit groupe d'utilisateurs.
Le seuil fixé à l'avance
La décision la plus importante se prend avant de voir les résultats : quelle est la barre au-dessus de laquelle on continue. Fixée après coup, on trouvera toujours une explication à pourquoi 62 pour cent est en fait prometteur.
Définissez aussi une limite basse d'arrêt. Un projet stoppé en semaine trois est une réussite de méthode, pas un échec.
Pour aller plus loin
Dans un prototype, on peut se passer du design, de l'authentification, de la vitesse et de la gestion des erreurs. On ne peut pas se passer de données réelles ni de mesure. Un prototype qui tourne sur trois exemples inventés au bureau n'apprend rien : ils ont été choisis, sans le vouloir, pour que ça marche.