Les meilleurs prototypes ne répondent à rien. Ce n’est pas un reproche envers les prototypes qui ne réussissent pas à prouver une thèse — c’est une autre affirmation sur ce à quoi sert vraiment un bon prototype. Son rôle n’est pas de confirmer ce que la présentation annonçait déjà. C’est de permettre à une salle d’être en désaccord sur quelque chose de concret plutôt que d’abstrait — de prendre un débat qui tourne en rond depuis deux trimestres à coups d’adjectifs et de lui donner une forme que les gens peuvent pointer du doigt et discuter directement.
Le désaccord abstrait est confortable, d’une façon bien précise et coûteuse. Deux dirigeants peuvent débattre pendant toute une réunion pour savoir si un assistant agentique « devrait sembler proactif » ou « devrait sembler déférent » sans jamais rien régler, parce que les deux positions sont compatibles avec chaque diapositive de la présentation. Personne n’a à avoir tort. Personne n’a à revoir sa position, parce qu’il n’y a rien d’assez concret pour la confronter. La conversation peut se répéter à la réunion suivante avec la même énergie et le même surplace.
Mettez un prototype fonctionnel devant ces deux mêmes personnes — un prototype qui fait vraiment une suggestion, qui attend vraiment une confirmation, qui se comporte vraiment d’une façon plutôt que de l’autre — et le débat change aussitôt de forme. Quelqu’un peut maintenant dire « c’était insistant » ou « ça m’a fait attendre trop longtemps » à propos d’une interaction réelle qui vient de se produire, pas d’une hypothèse. Le désaccord devient plus petit et plus précis, ce qui est exactement l’inverse de ce qu’on pourrait croire : un vague désaccord philosophique est en réalité bien plus difficile à régler qu’un désaccord précis sur une interaction concrète, parce que celui-ci peut être testé, ajusté et réessayé sur place.
C’est toute la logique derrière l’idée de bâtir vite, étroit et réel plutôt qu’exhaustif et théorique. Un Rapid Launch de deux semaines ne cherche pas à prouver la version finale de quoi que ce soit. Il cherche à produire le plus petit objet capable de contenir le vrai désaccord — un seul prototype fonctionnel, au périmètre assez serré pour être bâti en deux semaines, assez réel pour que les gens y réagissent comme ils réagiraient au produit fini, et non comme à une maquette qu’ils savent fausse. Une maquette récolte des commentaires polis. Un prototype fonctionnel récolte des réactions honnêtes, parce que les gens réagissent à ce qui se comporte comme si ça allait vraiment être livré.
Sauter cette étape a un coût qui se manifeste rarement avant bien plus tard. Les équipes qui passent directement de la présentation stratégique à la construction complète finissent par plaider les mêmes désaccords abstraits en pleine mise en œuvre, quand changer de cap est coûteux et lent. Le débat proactif contre déférent, qui aurait pu être réglé avec un prototype de deux semaines, se règle plutôt — mal — six mois plus tard, après qu’un vrai budget et une vraie crédibilité ont été dépensés à défendre le camp qui avait gagné le débat initial autour des diapositives.
Un prototype qu’on peut toucher n’élimine pas le désaccord. Il le déplace vers l’endroit le moins coûteux pour l’avoir.
Un prototype qu’on peut toucher n’élimine pas le désaccord. Il le déplace vers l’endroit le moins coûteux pour l’avoir — tôt, concret et réversible — plutôt que vers le plus coûteux, c’est-à-dire en production, une fois la chose livrée, quand le désaccord est devenu un post-mortem plutôt qu’une conversation.