ki-fwi/docs/sessions/03-pipeline-assets.md

Session 3 — Pipeline d'assets

Date : 2026-07-27 · Livrable : deux pipelines, un par filière.

Porte de sortie

Critère	Cible	Mesuré
Assets non validés dans le build	0	0 — le pipeline refuse les 39 médias non validés ✅
Assets de filière B dans une épreuve	0	refusé par validate:data, prouvé par test:porte ✅
Reproductibilité des seeds	deux exécutions identiques	vérifié avec PYTHONHASHSEED différent ✅
Poids par image	≤ 200 Ko	AVIF 1200 px à 106 Ko, 800 px à 79 Ko, 480 px à 36 Ko ✅
Appels réseau au runtime	0	les médias sont rapatriés au build, jamais chargés depuis Commons ✅
Compositing sur média SA ou NC	0	refusé par validate:data ✅

Filière A — npm run fetch:medias

Rapatrie les photographies validées depuis Commons, les encode en AVIF et WebP à trois largeurs (480, 800, 1200), et inscrit fichier_local dans les données.

Deux raisons de ne pas pointer vers les URLs de Commons dans le jeu : le projet s'interdit toute requête tierce au runtime, et un jeu qui doit fonctionner hors ligne ne peut pas dépendre d'un serveur distant.

Le script ne télécharge que ce qui est validé. Aujourd'hui : 0 traité, 39 ignorés. Le pipeline ne contourne pas la porte, il la respecte.

Vérifié sur une copie de travail, sans toucher aux données réelles : source de 256 Ko → 106 Ko en AVIF 1200 px, 36 Ko en 480 px. La qualité baisse d'un cran tant que le budget de 200 Ko est dépassé.

ImageMagick est une dépendance système, pas un paquet npm : l'outil existe sur la machine de build et n'a rien à faire dans le bundle.

Filière B — tools/assets/comfyui_client.py

Client ComfyUI en bibliothèque standard seule, hors bundle, avec son requirements.txt.

Les trois défauts du pack d'origine sont corrigés, et le premier est le plus grave : le pack calculait ses seeds avec hash(), randomisé à chaque exécution depuis Python 3.3, tout en vendant l'argument « même seed = même style ». Ses seeds ne l'étaient pas.

Remplacé par zlib.crc32. Prouvé empiriquement : deux processus lancés avec des PYTHONHASHSEED différents produisent exactement les mêmes valeurs.

copy.deepcopy remplace json.loads(json.dumps(...)). Et rembg reste commenté dans requirements.txt avec l'avertissement qui manquait : le paquet est sous MIT, les poids du modèle ne le sont pas nécessairement.

Ce qui reste

Le plan d'assets et les workflows ComfyUI ne sont pas écrits : ils dépendent de choix graphiques qui appartiennent au porteur, et générer du décor avant d'avoir un jeu jouable serait mettre la charrue avant les bœufs.

---

Addendum — pipeline confronté au ComfyUI réel

Le porteur a ouvert l'accès à son instance (127.0.0.1:8188, ComfyUI 0.27.1, deux GPU AMD). Le pipeline a donc été exécuté pour de vrai, pas simulé.

Reproductibilité prouvée au bit près

Exécution	seed	SHA-256 de l'image
1	3475989105	b7007a7a1088cb359a06ddaaff358e92…
2	3475989105	b7007a7a1088cb359a06ddaaff358e92…

Images bit-identiques. C'est précisément ce que le pack d'origine annonçait sans y parvenir, et c'est maintenant vérifié plutôt qu'affirmé. Workflow de référence : workflows/decor-sdxl.json (SDXL 1.0, 1024×576, 20 pas, dpmpp_2m/karras).

Deux défauts de mon propre client, révélés par le réel

1. Le prompt négatif était concaténé au prompt positif — travers hérité du pack. Sur SDXL, cela revient à demander au modèle de produire ce qu'on voulait exclure. Il a désormais son propre nœud.
2. Les images n'étaient pas rapatriées. Elles restaient dans le dossier de sortie de ComfyUI, et le manifeste référençait des chemins inexistants. Ajout de recuperer() via /view.

Un pipeline qu'on n'exécute pas est un pipeline qu'on croit correct.

Krea 2 — disponible, mais trois questions à trancher

Deux choses portent ce nom sur la machine, et elles n'ont rien à voir :

	ce que c'est	état
krea2_turbo_nvfp4.safetensors	poids locaux, chargés par UNETLoader	nvfp4 = format FP4 NVIDIA Blackwell, sur deux GPU AMD : très probablement inexploitable
Krea2ImageNode	nœud api_node: True, catégorie partner/image/Krea	appel à un service tiers payant

Le workflow transmis est au format interface (nodes, links, widgets_values) et non au format API que consomme /prompt. Sa conversion bute sur le champ model, de type COMFY_DYNAMICCOMBO_V3, dont la forme sérialisée ne se devine pas sans risque.

Trois points à trancher par le porteur avant de câbler Krea 2 :

1. Export au format API. Dans ComfyUI : menu → Save (API Format). C'est le seul format que /prompt accepte, et il lève toute incertitude sur le champ model.
2. Doctrine. Krea2ImageNode envoie les prompts à un serveur tiers. C'est toléré parce que la génération a lieu au build, jamais au runtime (playbook P2) — mais c'est un écart au « zéro service tiers » qui mérite d'être inscrit, pas subi.
3. Licence des sorties. Les conditions d'utilisation de Krea déterminent ce qu'on a le droit de faire des images produites. Tant qu'elles ne sont pas vérifiées, ces images ne peuvent pas être publiées sous CC BY-SA 4.0 avec le reste du contenu (ADR 0001).

En attendant, SDXL 1.0 en local reste le workflow par défaut : aucun coût, aucune donnée qui sort de la machine, et une reproductibilité démontrée.

Réserve sur le rendu

Le fond produit est graphiquement juste — aplats, angles nets, aucun texte, aucun visage — mais sa palette tire vers l'orange-rouge, plus chaude que la charte OKI (noir profond, or, vert, rouge en ponctuation). À reprendre en session 6 si ces fonds sont retenus.