12 — La fabrication des images et du son
Origine. Cette fiche part d'une contribution de Dom (2026-09-17), qui propose à la fois une doctrine de fabrication (tout est généré, rien n'est photographié) et se déclare prêt à prendre en charge la génération. Elle instruit la troisième des questions prioritaires de
08-open-questions.md— les visios — et referme au passage la question 10 de06-ui-desktop-metaphor.md.
Le jeu a besoin de beaucoup d'images : un visage par professionnel de l'annuaire, des lieux de repérage, du matériel, des planches de storyboard, des photos de plateau, des affiches. Une production classique irait chercher des banques d'images — et se heurterait au droit à l'image, aux licences et à l'hétérogénéité de style. La contribution de Dom renverse le problème.
1. La doctrine : tout est généré, rien n'est photographié
Décision de design proposée. Aucune image du jeu ne vient d'une photo de personne réelle ni d'une banque d'images sous licence. Tout est généré, puis recomposé par des procédés déterministes (un fond + une mosaïque de photos + une punaise posée dessus).
Trois raisons, dans l'ordre d'importance :
- Le droit à l'image disparaît. C'est la raison décisive. Un jeu qui montre
des dizaines de visages de comédien·ne·s, dont certains portent des traits
négatifs (
data-model/people.md), ne peut pas se permettre de ressembler à quelqu'un de réel. Le problème est le même que celui des noms fictifs (06-ui-desktop-metaphor.md§7) — et il se résout de la même façon. - Le style est homogène et pilotable. Une banque d'images donne vingt photographes différents ; un moteur donne une direction artistique.
- Le volume cesse d'être un obstacle. Générer trois cents visages coûte le même travail que d'en générer trente : c'est le processus qu'on fabrique, pas les images une par une.
Le corollaire, qui est aussi la charge de travail réelle. Ce qu'on fabrique
n'est pas un lot d'images, c'est une chaîne de fabrication : des recettes de
prompts, une graine, une étape de recomposition, une relecture humaine. Cela
appartient à l'éditeur (05-backoffice-editor.md) et non au moteur de jeu :
rien n'est généré à l'exécution — la décision 5 de
README.md (« le LLM écrit le contenu, la graine choisit
dedans ») s'étend telle quelle aux images et aux sons.
⚠️ À vérifier avant toute publication : la licence des moteurs de génération retenus, et ce qu'elle dit de l'usage commercial ou pédagogique des images produites. La doctrine supprime le droit à l'image ; elle ne supprime pas la question des conditions d'utilisation du moteur.
2. Les visages : de l'inconnu au book
Le cas le plus délicat, parce que c'est celui qui porte le plus de sens.
Étage 1 — le visage nu. Pour les gens derrière la caméra — l'équipe
technique, dont le visage n'a pas vocation à être « glamour » — un générateur de
portraits type thispersondoesnotexist
suffit : Dom note que les portraits y sont « très crédibles et uniques à chaque
rafraîchissement ». Un visage, une fiche d'annuaire, personne derrière.
Étage 2 — le book. Pour les comédien·ne·s, un portrait nu ne suffit pas : leur fiche doit raconter une carrière. À partir du même visage servant de référence, un moteur image-à-image décline le même personnage dans des contextes qui parlent le cinéma :
| Déclinaison | Ce que ça dit au joueur |
|---|---|
| Portrait studio (type Harcourt) | le standing, l'agence, le tarif |
| Photo de plateau / extrait de film | les genres qu'iel a tournés |
| Remise d'un César | la reconnaissance — et le prix qui va avec |
| Photo de festival, tapis rouge | la notoriété perçue |
| Photo plus ancienne, plus jeune | l'ancienneté, le passé |
C'est la cohérence d'identité qui fait le travail : le même visage sous cinq
angles devient une personne. Et ce book n'est pas décoratif — il encode des
stats. Un Rated (perçu vs réel, data-model/README.md) peut se lire dans les
images : un book flatteur, un CV qui ne suit pas.
La limite à tenir. Un visage généré peut ressembler à quelqu'un par hasard.
La règle de 06-ui-desktop-metaphor.md §7 s'applique : pas de trait négatif
sur une fiche dont le portrait évoque une personne identifiable. C'est un
point de relecture humaine, pas une contrainte automatisable.
3. Les affiches de films fictifs
Idée de Dom, et c'est la meilleure du lot : générer beaucoup d'affiches de films inventés.
Une affiche de cinéma est un objet massivement codifié — le polar est bleu nuit et contrasté, la comédie est blanche et sur-typographiée, le film indépendant est photographique et centré, le nanar est une collision. Un joueur lit le genre d'un film en un dixième de seconde, sans jamais avoir appris comment. C'est un canal d'information gratuit.
Où elles servent, par ordre d'utilité :
- Le CV des comédien·ne·s. « Elle a tourné ça » devient une rangée d'affiches. Une filmographie lue en une seconde, là où une liste de titres demande un effort. C'est l'usage principal.
- Le mur du bureau du joueur. Quelques affiches encadrées — les films que le personnage a produits avant celui-ci. Un passé, sans une ligne de texte.
- L'annuaire et les sociétés. Ce qu'un labo, un loueur, un studio a fait.
La chaîne proposée. Générer le titre d'abord (le genre est induit par le
titre, ou explicitement posé), puis en dériver le prompt de l'affiche. Ça branche
directement sur le générateur de noms familiers de 06 §7 et sur l'assistance
LLM de l'éditeur (05-backoffice-editor.md). Définition d'écran suffit — ces
images ne sont jamais imprimées.
4. Le reste des images
Le même procédé couvre, sans problème de droits :
- les planches de storyboard (
06§2) — ce qui referme la question 11 de06§10 : de vraies planches dessinées deviennent abordables ; - les photos de repérage des lieux ;
- les photos de matériel — caméras, optiques, machinerie — pour les
catalogues des loueurs (
data-model/production-elements.md) ; - les photos de tournage, pour le grand tableau et le débrief.
5. La pièce : trois vues fixes, pas un point-and-click
Dom tranche la question laissée ouverte en 06 §1 (« le tableau sur le mur, ou
la pièce navigable ? ») par une troisième voie, et c'est la bonne :
« L'idée n'est pas d'offrir au joueur une navigation dans un univers 3D une fois sorti de son écran d'ordinateur, mais d'avoir une petite respiration immersive. »
Concrètement : la vue bureau n'est pas un espace, c'est un jeu de trois images fixes en vue subjective grand-angle, reliées par des clics.
| Vue | Ce qu'on y voit | Ce qu'on y fait |
|---|---|---|
| Le bureau (centre) | l'écran et ses post-it collés au cadre, le fouillis de paperasse (le scénario s'ouvre au clic), le pot à crayons, le téléphone, la fenêtre derrière | zoomer sur l'écran, prendre un appel, lire le scénario |
| La machine à café (fond gauche) | de temps en temps, le vieux briscard qui sirote le sien | la conversation informelle (data-model/people.md §7) — et au retour, le travail s'est accumulé |
| Le grand tableau (fond droit) | la mosaïque punaisée du casting, des décors, des essais | voir l'ensemble, dépunaiser quelqu'un |
Pourquoi c'est le bon compromis. L'option (b) de 06 §1 — la pièce
navigable — donnait un corps au vieux briscard mais faisait glisser le jeu vers
le point-and-click. Trois images fixes gardent le corps et laissent la
navigation : on ne se déplace pas, on regarde ailleurs. Le coût de
fabrication est celui de trois images (déclinées, cf. §6), pas d'un décor.
Décision de design proposée : retenir cette option (c) — trois vues
fixes cliquables — et considérer la question 10 de 06 §10 comme close.
6. Le temps qui passe, sans une horloge
Deux mécanismes, tous deux dans la vue bureau, tous deux purement visuels — donc
diégétiques, conformément à la décision 10 de README.md.
Le désordre croissant. Une demi-douzaine d'états du bureau, du premier jour
de préparation au dernier jour de tournage. C'est déjà la « dégradation
progressive » de 06 §6 ; Dom la chiffre : 6 états. À l'usage c'est une
jauge de stress qu'on ne peut pas optimiser, ce qui est exactement ce qu'on veut.
La fenêtre. Derrière l'écran, une fenêtre sur une vue urbaine parisienne —
l'immeuble d'en face. 3 ou 4 états selon l'heure : matin, midi, fin de
journée, nuit avec les fenêtres allumées. C'est la façon la moins chère de faire
sentir qu'il est 23 h, et elle se combine avec la météo du jour (06 §2).
Ce que ça coûte. 6 états de désordre × 4 états de lumière = 24 variantes si l'on génère tout. On ne le fera pas : la fenêtre est une couche recomposée par-dessus l'image de bureau — 6 + 4 images, pas 24. C'est le principe de recomposition du §1, et il faut le tenir dès la première image générée : ce qui varie indépendamment se fabrique séparément.
7. Le son : du charabia qui a une intention
Dom propose, pour les voix, le procédé des Sims : des borborygmes incompréhensibles, pas de langue.
La structure : plusieurs types de voix distincts (masculins, féminins, âges), et pour chacun un jeu d'intentions — gentil, interrogatif, mielleux, paniqué, sec, furieux, désagréable. Le texte, lui, s'affiche en clair sur l'interface du téléphone, comme des sous-titres.
Trois qualités, et elles sont rares ensemble :
- Le coût ne dépend pas du casting. La banque de sons est partagée : elle ne grandit pas quand le jeu gagne cinquante personnages. C'est ce qui la distingue de tout doublage.
- L'internationalisation est gratuite. Le jeu est FR-first avec i18n
(
00-vision.md) : du charabia n'a pas à être traduit. Un doublage français condamnerait la version anglaise. - L'émotion passe quand même. « Se faire enguirlander au téléphone » se ressent au ton, pas aux mots — et le joueur lit les mots par-dessous.
Ça rend aussi l'accessibilité facile : le texte étant la source, le son est un
supplément qu'on peut couper sans rien perdre (06 §9).
⚠️ À vérifier : l'articulation avec la bande-son diégétique (08 §D, « la
radio du bureau »). Deux couches sonores qui parlent en même temps, c'est une
décision de mixage, pas un détail.
8. La décision : les visios
C'est la troisième question prioritaire. Elle engage des semaines de production d'assets — ou aucune. Voici les options, du moins cher au plus cher, avec ce qu'elles coûtent en volume d'assets, la seule unité honnête à ce stade.
Hypothèse de volume pour le jalon 0 : une quinzaine d'interlocuteurs ; pour le jeu complet, 60 à 80.
| Option | Volume d'assets | Ce que le joueur ressent | Recoût quand le casting change | |
|---|---|---|---|---|
| 1 | Portrait fixe + texte — le défaut actuel de 08 §D | 1 image / personne | correct, un peu mort | 1 image |
| 2 | Appel audio + icône — la proposition de Dom : pas de visio, un appel téléphonique, le visage en icône, le texte en sous-titre, le charabia intentionnel par-dessus (§7) | 1 image / personne + une banque de sons partagée (≈ 6 voix × 8 intentions × 3 variantes ≈ 150 clips, une fois) | on se fait engueuler pour de vrai | 1 image |
| 3 | Portrait légèrement animé — micro-mouvements, clignements, boucle courte | 1 clip / personne, à regénérer à chaque retouche | présence, au prix de l'uncanny valley | 1 clip + contrôle |
| 4 | Vidéo synthétisée par réplique | combinatoire : personne × réplique | crédibilité maximale, coût non borné | tout |
Recommandation : l'option 2, et elle est nettement meilleure que les autres.
- Elle coûte le prix de l'option 1 côté image — un portrait fixe — et achète la présence par le son, dont le coût est fixe, payé une fois, partagé par tout le casting. C'est la seule option dont le coût ne croît pas avec le contenu.
- Elle est plus juste métier. Un directeur de production passe ses journées
au téléphone, pas en visioconférence — surtout sur un plateau. Le canal
téléphone est déjà le canal humain du modèle (
06§1, §3). - Elle résout le problème plutôt que de le déplacer. La question « vidéo ou pas » supposait qu'il fallait un visage qui parle. En passant à l'audio, la question disparaît.
- Elle laisse une porte de sortie : l'option 3 pourra être ajoutée plus tard pour 3 à 5 personnages récurrents seulement (le réalisateur, le premier assistant, le vieux briscard) sans rien rejouer, puisque le portrait fixe reste la base.
Ce que ça ferme. Adopter l'option 2 referme la question 🔴 des visios dans
08 §D et la question 6 de 06 §10, et déplace le sujet « bande-son » (§7)
d'une décoration vers une dépendance du jalon 0 : sans la banque de voix,
l'option 2 se dégrade en option 1.
Ce que ça n'engage pas. La génération de vidéo — les rushes du tournage que Dom évoque — reste hors périmètre : Dom note lui-même le saut de ressources de calcul et de stockage, et la combinatoire (chaque comédien jouant la même scène) la rend non bornée. À rouvrir bien après le jalon 0, si jamais.
9. Qui fabrique, et quand
Dom propose de prendre en charge la génération des images. C'est la contribution la plus lourde d'un collaborateur à ce jour, et elle change le plan de fabrication : la direction artistique cesse d'être un risque de calendrier pour devenir un chantier parallèle.
Ce qui reste à cadrer avec lui — sans urgence avant que le scope soit figé :
- le format de livraison (dimensions, nommage, où ça atterrit dans le
contenu versionné en git,
01-architecture.md) ; - l'ordre : le jalon 0 (
07-roadmap.md) n'a besoin que d'une quinzaine de visages, trois lieux et trois vues de la pièce — pas du book complet ; - le placeholder : tant que les images ne sont pas là, le jalon 0 tourne sur des aplats de couleur avec le nom écrit dessus. Aucun développement ne doit attendre une image.
10. Ce qui reste à trancher
- Les visios (§8) — option 2 recommandée. Décision de Gabriel attendue.
- Le moteur de génération retenu, et surtout sa licence (§1) — ⚠️ à vérifier avant publication, pas avant le prototype.
- L'articulation charabia / bande-son diégétique (§7).
- Le nombre de types de voix : 6 suffit-il pour que deux interlocuteurs consécutifs ne sonnent pas pareil ? À tester, pas à décider.
- La génération de vidéo (rushes) : confirmée hors périmètre v1 (§8).
- Jusqu'où le book d'un·e comédien·ne encode des stats plutôt que de les illustrer (§2) — c'est un sujet de game design, pas de fabrication.