Blog
Méthode7 avril 2026

72h pour un prototype jouable

Le format, les contraintes, un exemple honnete, et pourquoi la contrainte de temps cree la direction plutot que de la subir.

La contrainte de départ

En 72 heures, il n'y a pas de temps pour se tromper de scope. Il faut cadrer, coder et livrer un build jouable. Pas un document. Pas un mockup.

Le format est utile justement parce qu'il force une réduction brutale du périmètre. Il n'y a pas la place pour cinq mécaniques moyennes, donc il faut trancher laquelle mérite d'exister. C'est là que la direction apparait: pas dans un brainstorm, dans une contrainte qui refuse le confort du 'on verra'.

La contrainte de 72h ne limite pas la direction, elle la crée: quand il n'y a de place que pour une seule idée, il faut décider laquelle.

Quand ce format gagne son temps

Il est utile quand une mécanique reste au stade de l'intuition et qu'on hésite à y engager des semaines. Trois jours suffisent à savoir si l'idée tient une fois entre les mains, ou si elle était plus séduisante sur le papier.

Le but n'est pas de finir un jeu en trois jours. Le but est de sortir du stade des intentions et d'avoir quelque chose à juger, pas à imaginer.

Le déroulement des trois jours

  • Jour 1: cadrage, architecture minimale, première boucle jouable.
  • Jour 2: intégration des systèmes, game feel, premiers tests complets.
  • Jour 3: ajustements, corrections bloquantes, documentation courte, livraison du build.

Exemple concret

Sur Minigame Factory, plusieurs prototypes ont été produits avec la même logique: scope court, build jouable, API standardisée. Color Flood, Stack Tower, Orbit Tap.

Ils ne se valaient pas. Certains tenaient assez bien manette en main pour justifier une suite. D'autres ont montré leurs limites en quelques minutes de jeu, et je les ai laissés là. Le format ne rend pas une idée bonne. Il rend juste très rapide le moment où on sait qu'elle ne l'est pas, avant d'y avoir mis des semaines.

Ce que le format ne fait pas

Pas d'assets HD, pas de son custom, pas de backend, pas de polish final. Un prototype fonctionnel n'est pas un produit fini, et le confondre avec ça mène droit à la déception.

Ce qu'il fait, c'est remplacer des semaines de doute par trois jours de vérification. Ce n'est pas rien, mais ce n'est que ça.

Ce que je retiens

La vraie valeur du format n'est pas la vitesse pour elle-même. C'est qu'il oblige à décider tôt, sur du concret, au lieu de repousser la décision derrière encore un peu de préparation.

Un prototype de 72h qui échoue n'est pas un échec: c'est trois jours qui m'ont évité d'en perdre trente. Le seul mauvais résultat, c'est celui qu'on n'a jamais mis entre des mains pour le savoir.