DOCS/kanban/cards/5-planifie/280-module-studio-generation-d-images-sous-identi.md
Thomas Fransolet b9f1a692ab Studio : lots 5-6 et calibrage §9.4 consignés, unité de crédit, lot 7 en cours
Résultats du calibrage (61 générations, coûts recoupés sur l'export fal),
trois corrections de prompt, unité 1 crédit = 0,015 $ vendue avec marge,
échantillons et figures d'archétypes embarqués ; planches contact dans
outputs/studio-calibrage-2026-09-15. STATUS, roadmap, cartes 280 et 310 à jour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011VxSQeGQYUvPmSEoGdnidA
2026-09-15 20:09:53 +02:00

20 lines
7.0 KiB
Markdown

---
title: Module Studio — génération d'images sous identité visuelle
area: backend manager
horizon: v2
tags: Studio IA
flag: good | V2 · lots 0-6 codés, calibrage fait le 15/09, gate conservateur à passer
src: v2/studio-plan.md — §8 (exécutable lots 0-4), §9 (catalogue v0), décisions 22-23
---
<p><strong>15/09 : lots 5 et 6 codés, calibrage §9.4 fait.</strong> Mention IA dans le fichier (XMP IPTC) + gravure en option. Calibrage sur 61 générations (Fourneau en gravure, Fort en aquarelle) : trois défauts corrigés avant tout client — négatif en double négation, titre de fiche recopié en légende, date d'un objet effacée. Coût réel fal : 0,03 $ l'image + 0,015 $ par référence ; <strong>unité arrêtée : 1 crédit = 0,015 $ de coût</strong>, vendu avec marge (≈ 0,05 €). Planches dans <code>outputs/studio-calibrage-2026-09-15/</code>. <strong>Reste</strong> : jugement visuel de Thomas, test du conservateur (gate lot 4), push de la branche.</p>
<p>🛠️ <strong>Lots 0 à 4 codés le 13/09</strong> sur la branche <code>studio</code> (manager-service, manager-app, mymuseum-visitapp) : ingestion serveur, crédits, identité visuelle (menu <strong>Studio</strong>), génération fal.ai derrière <code>IGenerationProvider</code> (fournisseur interchangeable), onglet <strong>Générer</strong> dans le sélecteur de ressource, image d'étape rattachée à une ressource. <strong>Reste avant le gate</strong> : bucket de dev + CORS, clé fal.ai (<code>Studio__Fal__Key</code>), migrations appliquées, calibrage et prix (§9.4), puis le test du conservateur.</p>
<p><strong>Plan consolidé le 13/09.</strong> Le §8 donne, pour les lots 0 à 4, les prérequis, les étapes, les vérifications et le gate. Le §9 contient un catalogue v0 (8 styles, règle de préambule, 3 gabarits) à calibrer en fin de lot 3. Six décisions ont été prises : <strong>upload par URL signée + ingestion serveur</strong> (bucket fermé aux clients, gros fichiers hors VPS), MVP limité à « depuis le texte » et « depuis une image » (objets et lieux), prix différés avec <code>Grant</code> manuel, une recharge qui prolonge tout le solde, plafonds d'upload prudents, catalogue calibré au lot 3. Le webhook fal.ai est signé en <strong>ED25519, pas en HMAC</strong>.</p>
<p><strong>Le produit n'est pas l'accès aux modèles, c'est la cohérence.</strong> N'importe qui peut générer une image ailleurs. La valeur : qu'un conservateur qui ne sait pas prompter obtienne, en trois champs, une image raccord avec les quarante autres du même parcours. Une <code>VisualIdentity</code> par instance (style verrouillé, époque, palette, exclusions, 1-5 images de référence) + <strong>surcharge optionnelle par configuration</strong> — le parcours Halloween a sa propre identité, exactement comme <code>Configuration</code> porte déjà ses <code>PrimaryColor</code>/<code>Languages</code>. Injectée côté serveur dans chaque prompt, <strong>jamais retapée</strong>. Boutons « Générer » dans l'éditeur de contenu, pas dans un playground ; gabarits métier, prompt libre en mode avancé seulement.</p>
<p><strong>Prérequis dur, carte séparée</strong> : le backend ne sait pas écrire dans le bucket. Sans le lot 0, rien du Studio ne tourne.</p>
<p>⚠️ <strong>Quatre pièges déjà tranchés.</strong> Une <strong>URL Firebase à jeton est publique</strong> — un brouillon dans <code>pictures/</code> serait servable au visiteur : préfixe <code>studio-drafts/</code> + proxy authentifié. Le <strong>quota IA existant ne tient pas</strong> sur des jobs parallèles (<code>CheckQuota</code> avant / incrément après : dix jobs Hangfire passent avant le premier débit) → réservation en deux temps sur un <code>CreditLedger</code>. Le <strong>plafond dur n'arrête pas le stagiaire</strong> — c'est un plafond <em>par utilisateur et par jour</em> qu'il faut, pas un plafond organisation. Et <code>GuidedStep.ImageUrl</code> <strong>est une URL, pas un <code>ResourceId</code></strong> : les images générées de l'escape game <em>ne partiraient pas offline</em> (<code>GuidedStep.cs:74</code>) — migration à faire dans le lot MVP.</p>
<p>🚫 <strong>Pas de watermark gravé dans les pixels</strong> (tranché le 01/09) : irréversible, et laid sur une illustration de musée. L'AI Act exige que le visiteur soit <em>informé</em>, pas que l'image soit tatouée. Provenance complète en <code>Resource.AiProvenance</code> (modèle, prompt effectif, refs, auteur, version d'identité, <code>rightsHolder</code> = le client) + badge « image générée par IA » dans l'UI visiteur, traduit dans les langues de la configuration. Gravure en <strong>option par instance</strong> pour l'institution qui l'exigerait par écrit.</p>
<p><strong>MVP = escape game, images seulement.</strong> Faible enjeu scientifique, fort besoin de cohérence, gros volume. Crédits en <strong>monnaie dédiée</strong>, distincte des tokens IA — griller son quota d'images ne doit pas priver les visiteurs du guide. Catalogue de modèles <strong>en base, pas dans le code</strong> (fal.ai comme passerelle unique : FLUX.2 pro, Nano Banana Pro, Recraft V3 ; Kling/Veo et Meshy/Tripo plus tard). 🧪 <strong>Le test de réussite se joue à la fin du lot 4</strong> : installer un conservateur devant l'écran et le laisser produire 10 images cohérentes seul. Si je dois prompter à sa place, l'UX a échoué — les lots suivants n'y changeront rien. <strong>Gros volume de test à prévoir.</strong></p>
<p>👤 <strong>Trois entrées distinctes dans le panneau de génération</strong>, à ne pas confondre (précisé le 02/09) : l'<strong>identité visuelle</strong> donne le style du projet, l'<strong>image source</strong> donne <em>cet objet-ci</em> (la vraie pièce de la collection, avec un curseur de fidélité : rien / le sujet / sujet + pose / cadrage exact), et le <strong>personnage</strong> donne <em>cette figure récurrente</em> — « c'est Léon qui est dans le donjon ». Le canon part en référence <em>et</em> ses paramètres (époque, costume, âge) sont injectés en texte : une image de référence seule ne porte pas « capote d'officier ».</p>
<p>⚠️ <strong>Deux personnages dans une image coûtent la cohérence du style.</strong> Le plafond de références est celui du modèle (10 pour FLUX.2) : un personnage à 4 vues + 4 références d'identité + 1 source = <strong>9/10</strong>, mais deux personnages font <strong>tronquer l'identité</strong> — donc le style dérive précisément sur l'image la plus ambitieuse. Priorité serveur au canon, troncature de l'identité ensuite, jauge visible dans l'UI et avertissement dès le deuxième. <strong>Un personnage par image</strong>, et on compose la scène autour de lui.</p>
<p>🖼️ <strong>Attention aux personnes identifiables.</strong> « Modifier une image » sur la photo d'une personne réelle, chez des institutions publiques, c'est du traitement de ressemblance : consentement écrit et tracé. La réponse produit est de <strong>rediriger vers les personnages</strong> — un avatar généré n'est le portrait de personne.</p>