Idée principale

Une maquette permet déjà d'itérer : on regarde un écran, on suit un parcours, on repère qu'un bouton n'est pas au bon endroit ou qu'une information manque. Ce qu'elle donne à voir est une intention, et les objections qu'elle appelle portent sur l'intention.

Un produit qui fonctionne donne autre chose. On ne le regarde pas, on l'utilise : on attend qu'une liste charge, on refait trois fois le même geste, on découvre qu'un filtre ne sert à rien parce que la donnée réelle n'a pas la forme prévue. Ces frottements-là ne sont pas des défauts de représentation, ce sont des propriétés du produit, et aucune maquette ne peut les produire puisqu'elle ne contient ni les vraies données, ni les vrais délais, ni la répétition de l'usage.

Le basculement est graduel et il passe presque inaperçu : la chose ressemble d'abord à une maquette, puis elle commence à fonctionner, puis on la montre, puis on demande des évolutions, puis on demande quand on pourra l'utiliser.

Pourquoi c'est important

Cela change ce qu'on construit en premier. Tant que produire une version utilisable coûtait beaucoup plus cher que produire une représentation, la maquette était le seul point d'entrée raisonnable dans une itération. Quand un Product Manager assemble en quatre jours des écrans, des API internes et des modifications de données, la représentation cesse d'être l'étape économique.

Cela déplace aussi le moment du retour utilisateur : il n'arrive plus sur ce qu'on projette de faire, mais sur ce qui existe — donc sur des objections qu'aucune relecture de spécification n'aurait fait remonter.

Nuances et limites

L'avantage tient au réalisme, pas au fait que ce soit du code. Un produit alimenté par un jeu de données de test ne montre pas plus de frottements réels qu'une maquette : il en montre moins, parce qu'il donne l'impression d'avoir été éprouvé.

Et la maquette garde un usage que le produit ne reprend pas : explorer plusieurs directions sans en payer aucune. Un produit qui tourne rend une direction difficile à abandonner, précisément parce qu'elle existe.

Questions ouvertes

• À partir de quel niveau d'enjeu le coût d'abandonner une version utilisable dépasse-t-il le gain de l'avoir construite plutôt que dessinée ?