Prototyper et piloter la construction

Tu as une spec signée et une feuille de route. Il faut faire construire le premier prototype et le piloter jusqu’aux critères d’acceptation. Point capital et libérateur : tu n’as pas besoin de savoir coder. Ton métier ici, c’est diriger, tester et donner un retour utile — pas taper du code. Tu es le chef d’orchestre, pas le musicien : tu écoutes et tu dis précisément quelle note sonne faux. Un prototype est un brouillon, pas le livre final ; son rôle est de révéler les problèmes à bas coût. On ne le juge pas à son vernis (« ça a l’air bien »), mais à son respect du contrat : les critères d’acceptation.

Tu choisis qui construit, parmi trois voies : un développeur humain (que tu pilotes avec la spec), une plateforme no-code (tu assembles via une interface), ou un assistant de codage IA (tu décris en langage clair, il génère). Dans les trois cas, tu diriges, tu ne tapes pas le code. La boucle de pilotage va par petits tours, jamais un grand saut : spécifier → construire un prototype mince → tester en rejouant tout le jeu de référence (pas deux questions au hasard : le « vibe check » ne prouve rien) → donner un retour actionnable → re-tester.

Un bon retour contient quatre éléments : ce que j’ai fait (l’entrée exacte, reproductible), ce que j’attendais (selon la spec / le critère), ce qui s’est passé (le résultat réel), et l’impact + la priorité. « C’est nul, corrige » est inactionnable ; « pour la question X, j’attendais Y, j’ai obtenu Z, impact élevé » est actionnable. Reste dans ton rôle : tu signales l’écart au critère, le constructeur choisit le correctif technique — tu ne dictes pas le code (fonctionnel ≠ technique). On choisit le constructeur le plus simple qui convient à l’approche : on ne prend pas une équipe de dev pour un prototype d’une semaine.