Une photo d'un bâtiment du Fourneau → sa version d'époque → un personnage en boucle de 8 s. Le but n'est pas de produire un asset, c'est de répondre à la seule question dont dépend tout le reste : est-ce que ça a l'air crédible, ou est-ce que ça décroche ? En patrimoine la crédibilité est la valeur — si le rendu est inquiétant, la fonctionnalité n'existe pas, quels que soient le prix et la facilité.
Le principe à valider : le text-to-video pur est écarté (il invente la géométrie du lieu). Le lieu réel reste la base, l'IA n'ajoute que le mouvement — c'est « Point de départ » du Studio transposé à la vidéo, donc aucun mécanisme nouveau en base : Kind = Video et sourceFidelity existent déjà, c'est un gabarit de plus.
Respecter les contraintes pendant le test, sinon il ne prouve rien : 6-10 s en boucle, une seule personne, mouvements simples, caméra calme, plan large ou moyen, jamais de gros plan sur les mains ou le visage.
⚠️ Deux choses déjà tranchées, à ne pas rejouer. Le motion transfer part en prestation Unov, pas dans le produit : il demande un tournage et un consentement écrit, ce qui échoue par construction le critère du §0 (« un conservateur produit sans intervention »). Et le cadrage de vente est resserré à « là où il ne reste rien » — bâtiment disparu, métier éteint, site réduit à ses fondations : partout où des archives existent, une vraie photo d'époque bat une boucle générée.
⛔ Ne bloque rien et n'est bloqué par rien — c'est justement l'intérêt de le faire tôt. Mais la fonctionnalité, elle, reste derrière le prérequis dur du Studio : IResourceBlobService n'expose toujours que IsConfigured et DeleteAsync, le backend ne sait pas écrire dans le bucket.