Prototypage jetable

Objectif

Le prototypage jetable sert à trancher une question ouverte sur ce qu'il faut construire, au prix le plus bas possible et avant que l'engagement ne soit pris. On fabrique un artefact, on le met devant des gens, on observe, on écrit ce que l'on a appris, et on le détruit. La décision qu'il soutient est celle qui coûte le plus cher quand on la prend mal: la forme même de la solution, à un moment où personne ne la connaît encore.

Le BABOK décrit l'élément en une phrase dont chaque terme porte: le prototype est produit avec des outils simples, papier et crayon, tableau blanc ou logiciel, pour découvrir et clarifier des exigences, il peut être mis à jour et évoluer au fil de la discussion et il ne devient pas du code exploitable et n'est pas maintenu comme un livrable une fois le système ou le processus en place. La dernière clause est la technique tout entière. Elle dit ce qu'il advient de l'artefact, et elle s'en tient là: le médium, la fidélité et la taille restent ouverts.

La valeur résiduelle nulle est l'objectif de conception, et c'est elle qui achète la vitesse. Parce que rien ne survivra, la maquette peut légitimement se passer d'architecture, de gestion des erreurs, de sécurité, de persistance et de tests. La facture qu'elle refuse est celle que le prototypage évolutif ne peut pas refuser, puisque son artefact à lui est la solution livrée. Le livrable du prototypage jetable est donc une connaissance écrite: une exigence, une décision, l'option écartée et la raison de l'avoir écartée.

Usage

Quand l'utiliser

• Question ouverte sur ce qu'il faut construire: une maquette tranche en jours ce qu'un atelier discute en semaines.
• Fonctionnalité difficile à éliciter autrement: la montrer obtient ce que la décrire n'obtient pas.
• Points de vue contradictoires entre parties prenantes: l'artefact déplace le désaccord des mots vers un objet commun.
• Plusieurs options de conception à comparer: en construire trois et en détruire deux coûte moins cher que de choisir mal.
• Risque de conception ou de faisabilité élevé, engagement imminent: un prototype vertical, étroit et profond, sur l'axe exact du doute.
• Règles ou données contestées: la technique porte au-delà de l'interface, jusqu'aux processus et aux règles métier.

Quand ne pas l'utiliser

• L'artefact doit devenir la solution livrée: prendre le prototypage évolutif, qui paie le socle dès l'incrément zéro.
• Aucune décision n'attend le résultat: obtenir la réponse par un entretien ou un focus group et prototyper ensuite.
• Le désaccord porte sur le processus, ses rôles et ses délais: rien à manipuler, modéliser les flux de travail.

Description

Deux axes indépendants

Le BABOK range les prototypes sur deux éléments distincts. L'approche dit ce que l'artefact devient: on le détruit, ou on le fait grandir jusqu'à la solution. La méthode dit de quoi il est fait et ce que quelqu'un en fait: on lit un storyboard, on opère un prototype papier, une machine exécute une simulation ou l'on modélise les flux de travail, méthode empruntée à la modélisation des processus. Tout prototype porte une réponse sur chacun des deux axes, et les deux réponses sont libres l'une de l'autre. Le prototypage jetable est une réponse sur l'axe de l'approche: il fixe le sort de l'artefact et laisse le médium ouvert. Un prototype jetable est un dessin au tableau blanc, un jeu de vignettes, une feuille de calcul, un écran cliquable ou un bout de code. L'aiguillage entre les deux axes appartient au prototypage pris dans son ensemble.

Ce que l'abandon achète

Deux propriétés découlent de l'abandon. La première est que l'artefact est bon marché à tuer. Tuer une option coûte ce que l'option a coûté, et l'option n'a presque rien coûté. C'est ce qui rend rationnel d'en construire plusieurs et de les détruire toutes sauf une: on compare des objets plutôt que des opinions sur des objets.

La seconde est que l'artefact est sûr à critiquer, et le BABOK l'inscrit lui-même dans les forces de la technique: face à une maquette jetable ou papier, les utilisateurs peuvent se sentir plus à l'aise de la critiquer parce qu'elle n'est ni finie ni prête à être livrée. Le mot compte: ce sont les utilisateurs, la personne qui a l'objet sous les yeux et qui devra s'en servir. Le comité de pilotage, lui, donne un avis sur un objet dont il ne se servira pas. Un écran fini appelle la politesse. Une esquisse appelle la contradiction, et la contradiction est le produit que l'on est venu chercher.

Explorer ou expérimenter

Christiane Floyd a posé en 1984 la taxonomie qui donne au prototypage jetable la structure interne que le mot jetable ne laisse pas deviner. Elle distingue trois buts: l'exploration, l'expérimentation et l'évolution. Le troisième produit un artefact que l'on garde et que l'on adapte à des exigences qui ne pouvaient pas être anticipées, et c'est le prototypage évolutif. Les deux premiers produisent un artefact que l'on détruit, et ce sont les deux formes du prototypage jetable.

L'exploration demande « que faut-il construire? ». Les alternatives sont explorées avant qu'une solution ne soit choisie, l'artefact porte donc plusieurs variantes, il est aussi bon marché et aussi peu fidèle que la question le permet, et il est achevé quand l'ambiguïté a disparu: l'option est choisie, la raison du choix est écrite. Son produit est une décision.

L'expérimentation demande « la conception proposée tient-elle? ». Une solution est déjà sur la table et il s'agit d'établir son adéquation avant de lancer la réalisation complète. L'artefact est donc une seule variante, construite étroite et profonde sur l'aspect que l'on met à l'épreuve: c'est le prototype vertical que le BABOK range dans ses forces, celui qui sert aux études de faisabilité technique et aux preuves de concept. Il est achevé quand la proposition a été montrée adéquate ou inadéquate, et une expérimentation honnête peut rendre un verdict négatif. Son produit est un verdict.

Le même écran sépare les deux buts. Une école qui ignore encore si ses étudiants composent leur semestre par module ou par créneau horaire construit deux maquettes bon marché et regarde laquelle tient: c'est une exploration, et elle s'achève le jour où la question est tranchée. La même école, ayant retenu le modèle par créneau, qui veut savoir si un étudiant remplit seul une grille hebdomadaire en moins de cinq minutes, construit une seule maquette, étroite et profonde sur la grille et l'observe jusqu'à ce que la conception proposée soit jugée adéquate ou inadéquate: c'est une expérimentation. Même artefact bon marché, même abandon, autre définition de l'achèvement.

Le praticien qui ignore lequel des deux il conduit ne sait pas quand s'arrêter et continuera de polir un artefact qui a déjà fait son travail. La confusion coûte aussi dans l'autre sens: on réunit huit utilisateurs pour une question de faisabilité technique qu'un développeur aurait tranchée seul en une journée, ou l'on confie à un seul architecte le choix d'une forme d'écran que seuls les usagers pouvaient départager. Le but commande la salle autant que l'artefact. Nommer le but est donc la première décision de la technique, avant le médium et avant la fidélité.

La fidélité est la variable de commande

Le BABOK donne les deux extrémités d'un même axe. D'un côté, la maquette non polie est librement critiquée. De l'autre, un prototype très élaboré et détaillé fait naître chez les parties prenantes des attentes irréalistes pour la solution finale, sur les dates d'achèvement autant que sur la performance, la fiabilité et l'utilisabilité.

La fidélité est donc un coût, et elle se paie deux fois: une fois pour la produire, une fois en crédibilité prêtée à un artefact qui doit rester tuable. Prendre la fidélité la plus basse qui réponde à la question. Chaque point au-dessus achète de l'engagement là où l'on voulait acheter de l'information.

Acheter la réduction du risque avant l'engagement

Le prototype jetable a une théorie: le modèle en spirale, publié par Barry Boehm en 1988. Le prototype y tient un rôle nommé, celui d'instrument de rachat du risque. Un projet porte à chaque instant une incertitude dominante, celle dont une réponse fausse coûterait le plus cher: l'écran que personne ne sait dessiner, la règle métier que deux services énoncent différemment, la charge dont on ignore si l'architecture la supporte. On construit alors l'artefact le moins cher qui sache lever cette incertitude-là seule. Le risque une fois levé, et à ce moment seulement, on engage le niveau d'élaboration suivant. La règle que la spirale impose tient en une ligne: rien ne s'engage sur une hypothèse. Le prototypage jetable est le moyen de la tenir, et c'est ce raisonnement qui fait d'un artefact construit pour être détruit un investissement. La dépense achète de l'information, et une information obtenue avant l'engagement vaut plus cher que la même information obtenue après lui, parce qu'elle est encore actionnable.

Brooks et sa rétractation de 1975

La formule qui a donné son nom à l'approche est de Frederick Brooks, en 1975: « Plan to throw one away; you will, anyhow. » Son analogie est celle de l'usine pilote: un procédé chimique qui fonctionne au laboratoire ne se transporte pas d'un bond dans une usine, on construit d'abord une installation intermédiaire, en sachant qu'elle sera démontée. Sa formulation de la décision a bien vieilli: un système que l'on jette sera construit de toute façon. La question est de savoir si on l'avait prévu ou si on l'a livré au client.

Vingt ans plus tard, Brooks retire ce conseil: « Je perçois maintenant que c'est faux, non parce que c'est trop radical, mais parce que c'est trop simpliste. » La rétractation fait partie de ce qu'un praticien doit savoir pour se servir de la phrase de 1975, parce qu'elle en fixe la portée.

Ce qu'il a retiré se lit: construire deux fois le système entier, sous le modèle en cascade, un premier système complet que personne n'utilisera. Ce qu'il embrasse à la place est la croissance incrémentale du produit. Ce qu'il n'a jamais retiré, c'est de construire quelque chose de bon marché pour en apprendre avant de s'engager, et c'est cela, le prototypage jetable. L'usine pilote de Brooks était un système entier. Une maquette est une question à laquelle on a donné une forme. Brooks ne se laisse donc enrôler par aucune des deux approches, et ce qu'il laisse au praticien est plus utile qu'un verdict: le premier objet construit sera faux, quoi qu'il arrive, et il reste à décider d'avance qui le paiera. L'équipe qui l'efface ou le client qui l'exploite. Le prototypage jetable est la réponse qui l'efface, et cette réponse se donne avant la première ligne.

Conduire un prototypage jetable

1. Écrire la question, en une phrase, avant de dessiner quoi que ce soit
   Avec elle s'écrit la décision qui attend la réponse. « L'étudiant choisit-il par module ou par créneau horaire? » est une question. « Montrer à quoi pourrait ressembler l'écran d'inscription » n'en est pas une: elle n'a pas de critère d'achèvement, donc l'artefact ne peut jamais être terminé, donc il ne sera jamais détruit.
2. Nommer le but: exploration ou expérimentation
   Ce choix commande le critère d'achèvement, le nombre de variantes et la fidélité, et il se fait avant eux. Exploration: plusieurs variantes bon marché, en largeur, achevées quand l'ambiguïté tombe. Expérimentation: une variante, étroite et profonde sur l'aspect en cause, achevée quand la conception proposée a été jugée.
3. Choisir la fidélité comme un coût et prendre la plus basse qui réponde à la question
   Le tableau blanc avant l'outil de maquettage, l'outil de maquettage avant le code. Monter d'un cran est une décision.
4. Annoncer l'abandon à haute voix, au début, à tous ceux qui verront l'artefact
   Dire aussi ce qui manque: pas d'architecture, pas de gestion des erreurs, pas de sécurité, pas de persistance, pas de tests. Cette phrase est ce qui autorise les raccourcis, et c'est la même phrase qui rend l'artefact sûr à critiquer. Non prononcée, elle reste une hypothèse privée, et elle sera démentie par le premier qui demandera pourquoi on ne peut pas livrer ça.
5. Faire la séance avec de vrais utilisateurs, sur une tâche réelle
   On observe, on ne vend pas. L'artefact est là pour être attaqué, et une démonstration est le seul format dans lequel personne ne l'attaque. Le rôle de l'animateur est de ramener la salle à la question écrite au début.
6. Capter l'apprentissage pendant que l'artefact est encore vivant
   Écrire l'exigence, la décision, l'option écartée et la raison de son rejet, à l'endroit où vit la spécification. Le prototype ne produit que de la connaissance: celle qui n'est pas écrite avant l'abandon est détruite avec l'artefact.
7. Détruire l'artefact et le dire
   L'abandon est un acte explicite, inscrit dans le plan comme les autres. Supprimer la maquette est ce qui tient l'arrangement entier honnête: rien de ce qu'elle contenait n'était un engagement, et personne ne pourra revenir dans trois mois demander pourquoi on ne la met pas en production.

Ce qui fait échouer un prototypage jetable

Le prototype jetable que l'on ne jette pas

C'est le mode d'échec majeur. Un responsable voit un artefact qui a l'air de fonctionner et demande pourquoi on ne le livrerait pas tel quel. Les raccourcis qui ont acheté la vitesse, pas d'architecture, pas de gestion des erreurs, pas de sécurité, pas de tests, deviennent alors les fondations du vrai système. Livrer la maquette n'économise pas la facture: elle la reporte au moment où elle est la plus lourde, quand les raccourcis sont devenus porteurs et que tout ce qui repose dessus doit être démonté pour les corriger. La maquette saute le socle de production pour une raison unique: elle ne va pas en production. Retirez l'abandon, et l'autorisation des raccourcis disparaît rétroactivement, tandis que les raccourcis, eux, restent.

Le prototype sans question

Construit « pour montrer quelque chose », pour occuper un comité de pilotage, pour débloquer un budget. Il n'a pas de critère d'achèvement, donc il n'est jamais fini, donc il n'est jamais détruit, donc il est encore là le jour où quelqu'un demande pourquoi on ne le livre pas. Le mode d'échec précédent commence presque toujours ici.

La montée en fidélité

On range la maquette pour le public suivant, et chaque passage de polissage retire un peu de la liberté de la critiquer. Le piège est que polir ressemble à progresser. La fidélité s'achète contre la question seule.

L'apprentissage qui meurt avec l'artefact

Par construction, rien ne survit. Si l'exigence n'est pas écrite avant la suppression, l'abandon détruit le seul produit que la technique ait jamais eu. La discipline se dit dans l'ordre: on capte d'abord, on supprime ensuite.

La séance qui glisse du « quoi » vers le « comment »

Première limite que le BABOK énonce: sur un système complexe, la discussion s'enlise dans le comment au lieu de porter sur le quoi, ce qui coûte du temps, de l'effort et du talent d'animation. La maquette qui ressemble à un logiciel accélère ce glissement, et la question écrite au début reste alors sans réponse à la fin.

La maquette prise pour la spécification

Le BABOK le formule sans détour: les parties prenantes se fixent sur les spécifications de conception plutôt que sur les exigences auxquelles toute solution devra répondre, ce qui contraint ensuite la conception; et les développeurs croient devoir fournir une interface qui reproduit exactement le prototype, même lorsqu'il existe des technologies et des approches d'interface plus élégantes. L'artefact devait poser une question. Il a fini par répondre à des questions que personne n'avait posées.

Considérations IA

L'économie du prototypage jetable tient en deux termes: ce que coûte la production d'une option et ce que coûte sa destruction. Les générateurs attaquent le premier terme, et ce bénéfice est propre à cette technique. Produire plusieurs variantes en minutes plutôt qu'en jours desserre la contrainte qui limite le but d'exploration: le nombre d'options qu'une équipe peut se permettre de construire et de détruire. Plus une équipe peut en tuer, meilleure est la décision qui reste. S'y ajoutent les besognes qui rendent une maquette lisible sans rien apprendre à personne: fabriquer le jeu de données factice, les douze modules plausibles, les noms crédibles, la grille horaire; rédiger le code jetable quand la question exige réellement une exécution, le code étant destiné à la suppression, ce qui est le seul contexte où sa provenance importe peu; et recomposer les observations de la séance face à la question écrite au départ.

Le jugement, lui, ne se délègue pas: nommer la question, choisir le critère d'achèvement, décider que l'artefact est fini et lire ce que les utilisateurs ont réellement fait plutôt que ce qu'ils ont dit. Un modèle produit un écran pour n'importe quelle amorce, y compris pour une amorce qui ne contient aucune question, ce qui en fait un excellent fabricant de prototypes sans question, à grande échelle.

L'IA rend les artefacts jetables si peu coûteux qu'ils sortent en ayant l'air prêts pour la production, ce qui aggrave la pression à les livrer. Une esquisse au crayon annonce elle-même qu'elle est jetable. Une application engendrée compile, s'exécute, possède un style et une base de données plausible et n'annonce rien. L'artefact qui a désormais le plus l'air livrable est celui dont les raccourcis sont les moins visibles. Et les raccourcis sont bien là: un écran d'authentification qui n'authentifie personne, un schéma de données que personne n'a revu, aucun modèle de menace, aucune base légale du traitement, aucun chemin d'erreur, aucun test. Rien de tout cela ne se voit depuis la surface, et la surface est tout ce que regarde celui qui demande pourquoi on ne livre pas ça: il voit un écran qui s'ouvre, un bouton qui répond, une liste qui se remplit, et il en conclut que l'essentiel est fait. L'essentiel est ce qui n'a pas été construit. La discipline que cette technique exige, annoncer l'abandon, capter l'apprentissage, supprimer l'artefact, devient donc plus nécessaire à mesure que l'artefact devient bon marché. Le coût de production était le frottement qui imposait l'abandon de lui-même. Il a baissé, et il faut désormais imposer l'abandon explicitement.

Exemples

Une HES refait l'écran sur lequel les étudiants composent leur semestre à partir des modules à option. Une question commande toute la suite, et la salle ne s'accorde pas sur la réponse: l'étudiant choisit-il par module ou par créneau horaire? Les deux réponses produisent deux écrans, deux modèles de données et deux traitements des collisions, et le choix ne se renverse pas à bon compte une fois construit. Le prototype existe pour trancher cela.

La séance réunit huit étudiants sur une tâche réelle: « composez votre semestre, 30 crédits ECTS, vous travaillez le mercredi et le jeudi ». La moitié de la volée étudie en emploi, ce qui est la situation ordinaire d'une HES. On observe vers quelle variante chacun se tourne et où il bute. Personne ne reçoit de démonstration.

Les étudiants à plein temps travaillent sans peine dans la variante A et traitent l'horaire comme une conséquence. Ceux qui travaillent deux jours par semaine l'abandonnent: elle les laisse investir cinq modules, puis leur signale en rouge que trois d'entre eux tombent un jour où ils ne sont pas là. Dans la variante B, ils terminent en quatre minutes et ne produisent aucune collision.

Les deux variantes sont supprimées le jour même. Aucune vignette n'est conservée, aucun balisage n'est repris, les douze faux modules partent avec le reste. Ce qui survit est une exigence, et elle est écrite avant que quoi que ce soit ne soit effacé:

L'écran d'inscription recueille les indisponibilités de l'étudiant avant de lui présenter le catalogue et ne lui propose jamais un module qui ne peut pas entrer dans son horaire. La collision est empêchée à l'affichage du catalogue.

S'y ajoutent l'option écartée et la raison de l'avoir écartée, qui sont la seconde moitié du produit et celle que l'on oublie. Ce prototype-ci poursuivait le but d'exploration: la question était « que faut-il construire? », et il était achevé au moment où l'ambiguïté a disparu.

Visualisations

La figure de l'abandon a un second usage. Posée à côté d'un plan de prototypage réel, elle sert d'instrument de contrôle, et trois questions s'y lisent.

• La poubelle est-elle sur le plan, à une date? Un prototype dont l'abandon n'est pas planifié est une première version, et il sera traité comme telle.
• La flèche qui survit a-t-elle une destination nommée? Quel document, quelle section, qui l'écrit et quand. Une flèche qui pointe vers la spécification en général ne pointe vers rien.
• Le but est-il écrit quelque part, exploration ou expérimentation? S'il ne l'est pas, personne ne peut dire quand l'artefact sera fini, et un artefact qui n'est jamais fini finit par être livré.

La grille des deux axes se lit en colonne, et c'est le contrôle le plus rapide à faire passer au même plan. Si personne dans l'équipe ne peut dire à la fois ce que l'artefact deviendra et ce que quelqu'un en fera, l'une des deux décisions n'a pas été prise, et c'est presque toujours la première.

Coût

Outils

Une règle commande le choix de l'outil: prendre le médium le moins cher qui puisse répondre à la question.

Papier, crayon, tableau blanc

Le BABOK les nomme lui-même comme les outils de la technique. Ce sont les plus rapides, les moins chers et les plus critiquables: personne n'est intimidé par un tableau blanc. C'est là qu'un prototype d'exploration devrait commencer, sauf raison contraire.

Outils de maquettage

Figma, Penpot, Balsamiq, Excalidraw: plusieurs variantes, faciles à partager, faciles à jeter. Ils franchissent vite la ligne de fidélité, et plus l'artefact ressemble à une vraie interface, plus il devient difficile à tuer. Rester du côté du trait esquissé est une décision de méthode.

Diapositives ou PDF cliquable

Quand la question porte sur l'enchaînement des écrans.

Tableur

Quand la question porte sur des règles ou sur des données plutôt que sur un écran, ce qui est explicitement dans le périmètre de la technique: le BABOK note que ces prototypes sont un outil peu coûteux pour découvrir ou confirmer des exigences qui vont au-delà de l'interface, jusqu'aux processus, aux données et aux règles métier. Une feuille de calcul est un prototype jetable d'un jeu de règles.

Code jetable

Un script, une page unique, un carnet de calcul. Réservé au cas où la question ne peut pas être simulée et où le comportement doit réellement s'exécuter: c'est le but d'expérimentation, et c'est la forme du prototype vertical, étroit et profond. Ce code est supprimé sans jamais être fusionné. Le réflexe de le conserver croît en proportion de l'effort qu'il a coûté, ce qui est la raison pour laquelle l'abandon se déclare avant d'écrire la première ligne.

Générateurs assistés par IA

Ils produisent les variantes en minutes, et ils portent le piège de la fidélité dans sa forme la plus aiguë, puisque leur production ressemble à un logiciel fini sans en être un.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.36 Prototyping: l'élément jetable (des outils simples, un artefact qui ne devient pas du code exploitable et n'est pas maintenu comme livrable), les forces (l'utilisateur qui critique librement une maquette non finie, le prototype vertical étroit et profond, les exigences au-delà de l'interface) et les limites (l'enlisement dans le « comment », les attentes irréalistes nées d'un prototype trop détaillé, l'interface que les développeurs croient devoir reproduire).
• Christiane Floyd, A Systematic Look at Prototyping, dans Approaches to Prototyping, Springer, 1984, pp. 1-18: les trois buts du prototypage, exploration, expérimentation et évolution, dont les deux premiers produisent un artefact destiné à être détruit.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, ch. 11 Plan to Throw One Away, Addison-Wesley, 1975: l'usine pilote et la question qui est de savoir si le système que l'on jette était prévu ou s'il a été livré au client.
• Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, ch. 19 The Mythical Man-Month after 20 Years, Addison-Wesley, 1995: la rétractation du conseil de 1975 et la croissance incrémentale du produit qu'il lui substitue.
• Barry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988, pp. 61-72: le cycle piloté par le risque, le prototype comme instrument de résolution du risque et l'engagement pris seulement une fois le risque racheté.