DOCS/kanban/cards/5-planifie/280-module-studio-generation-d-images-sous-identi.md

title, area, horizon, tags, flag, src

title	area	horizon	tags	flag	src
Module Studio — génération d'images sous identité visuelle	backend manager	v2	Studio IA	good | V2 · lots 0-6 codés, calibrage fait le 15/09, gate conservateur à passer	v2/studio-plan.md — §8 (exécutable lots 0-4), §9 (catalogue v0), décisions 22-23

✅ 15/09 : lots 5 et 6 codés, calibrage §9.4 fait. 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 ; unité arrêtée : 1 crédit = 0,015 $ de coût, vendu avec marge (≈ 0,05 €). Planches dans outputs/studio-calibrage-2026-09-15/. Reste : jugement visuel de Thomas, test du conservateur (gate lot 4), push de la branche.

🛠️ Lots 0 à 4 codés le 13/09 sur la branche studio (manager-service, manager-app, mymuseum-visitapp) : ingestion serveur, crédits, identité visuelle (menu Studio), génération fal.ai derrière IGenerationProvider (fournisseur interchangeable), onglet Générer dans le sélecteur de ressource, image d'étape rattachée à une ressource. Reste avant le gate : bucket de dev + CORS, clé fal.ai (Studio__Fal__Key), migrations appliquées, calibrage et prix (§9.4), puis le test du conservateur.

✅ Plan consolidé le 13/09. 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 : upload par URL signée + ingestion serveur (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 Grant manuel, une recharge qui prolonge tout le solde, plafonds d'upload prudents, catalogue calibré au lot 3. Le webhook fal.ai est signé en ED25519, pas en HMAC.

Le produit n'est pas l'accès aux modèles, c'est la cohérence. 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 VisualIdentity par instance (style verrouillé, époque, palette, exclusions, 1-5 images de référence) + surcharge optionnelle par configuration — le parcours Halloween a sa propre identité, exactement comme Configuration porte déjà ses PrimaryColor/Languages. Injectée côté serveur dans chaque prompt, jamais retapée. Boutons « Générer » dans l'éditeur de contenu, pas dans un playground ; gabarits métier, prompt libre en mode avancé seulement.

⛔ Prérequis dur, carte séparée : le backend ne sait pas écrire dans le bucket. Sans le lot 0, rien du Studio ne tourne.

⚠️ Quatre pièges déjà tranchés. Une URL Firebase à jeton est publique — un brouillon dans pictures/ serait servable au visiteur : préfixe studio-drafts/ + proxy authentifié. Le quota IA existant ne tient pas sur des jobs parallèles (CheckQuota avant / incrément après : dix jobs Hangfire passent avant le premier débit) → réservation en deux temps sur un CreditLedger. Le plafond dur n'arrête pas le stagiaire — c'est un plafond par utilisateur et par jour qu'il faut, pas un plafond organisation. Et GuidedStep.ImageUrl est une URL, pas un ResourceId : les images générées de l'escape game ne partiraient pas offline (GuidedStep.cs:74) — migration à faire dans le lot MVP.

🚫 Pas de watermark gravé dans les pixels (tranché le 01/09) : irréversible, et laid sur une illustration de musée. L'AI Act exige que le visiteur soit informé, pas que l'image soit tatouée. Provenance complète en Resource.AiProvenance (modèle, prompt effectif, refs, auteur, version d'identité, rightsHolder = le client) + badge « image générée par IA » dans l'UI visiteur, traduit dans les langues de la configuration. Gravure en option par instance pour l'institution qui l'exigerait par écrit.

MVP = escape game, images seulement. Faible enjeu scientifique, fort besoin de cohérence, gros volume. Crédits en monnaie dédiée, distincte des tokens IA — griller son quota d'images ne doit pas priver les visiteurs du guide. Catalogue de modèles en base, pas dans le code (fal.ai comme passerelle unique : FLUX.2 pro, Nano Banana Pro, Recraft V3 ; Kling/Veo et Meshy/Tripo plus tard). 🧪 Le test de réussite se joue à la fin du lot 4 : 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. Gros volume de test à prévoir.

👤 Trois entrées distinctes dans le panneau de génération, à ne pas confondre (précisé le 02/09) : l'identité visuelle donne le style du projet, l'image source donne cet objet-ci (la vraie pièce de la collection, avec un curseur de fidélité : rien / le sujet / sujet + pose / cadrage exact), et le personnage donne cette figure récurrente — « c'est Léon qui est dans le donjon ». Le canon part en référence et ses paramètres (époque, costume, âge) sont injectés en texte : une image de référence seule ne porte pas « capote d'officier ».

⚠️ Deux personnages dans une image coûtent la cohérence du style. 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 = 9/10, mais deux personnages font tronquer l'identité — 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. Un personnage par image, et on compose la scène autour de lui.

🖼️ Attention aux personnes identifiables. « 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 rediriger vers les personnages — un avatar généré n'est le portrait de personne.