Lorsqu’une référence de personnage approuvée change, ne régénérez pas toute la BD et ne vous fiez pas à votre mémoire.
À la place, effectuez un audit des dépendances inverses :
référence modifiée
-> chaque page qui l’a utilisée
-> chaque case où le détail modifié est visible
-> chaque image ultérieure dérivée de ces cases
-> réparer, revoir ou laisser intact
Dans l’exemple détaillé de 40 pages de ce guide, un personnage apparaît sur 29 pages. L’audit trouve :
14 pages / 38 cases qui nécessitent une réparation
9 pages / 34 cases qui nécessitent une revue humaine
6 pages / 22 cases vérifiées comme inchangées
11 pages / 74 cases où le personnage est absent
Cela signifie que 96 cases sur 168 restent intactes. Le but de l’audit est de protéger le travail approuvé au lieu de transformer une simple mise à jour de référence en redémarrage de 40 pages.
Si votre histoire existe déjà sous forme de script, PDF, DOCX ou manuscrit, vous pouvez démarrer un projet long format via LlamaGen.AI Upload. Gardez le registre d’audit à côté du projet jusqu’à ce que chaque référence modifiée et chaque ressource en aval soient clôturées.
Le visuel ci-dessus explique le concept de dépendance. Les comptes exacts des 40 pages sont enregistrés dans la matrice de pages ci-dessous, et non déduits de l’illustration.
Le problème de production que ce guide résout
Une distinction utile issue de la communauté des créateurs de BD IA est que savoir comment une image a été générée n’est pas la même chose que savoir ce qui dépend d’elle.
Le post Reddit d’origine décrit une BD de 40 pages dans laquelle une référence de personnage approuvée pour Mira est utilisée aux pages 3, 6, 9, 14, 18 et 27. Quand le design de Mira change, les prompts, seeds, modèles et l’historique du workflow peuvent expliquer d’où vient une ressource, mais ils ne répondent pas automatiquement à ces questions :
Journal des modifications
Faites naître des rêves chez les jeunes Là où des millions d’histoires prennent vie
Un aperçu des dernières fonctionnalités de LlamaGen, des améliorations produit, des mises à jour de design et des corrections de bugs importantes.
✦
✧
✦
✧
Un nouveau support pour la narration
Créez instantanément des histoires, comics, animations, jeux et bien plus encore, en phase avec les publics modernes
Quelles pages sont désormais obsolètes ?
Quelles scènes approuvées nécessitent un nouvel examen ?
Quelles pages ne sont pas affectées ?
Quelles images sont devenues des références pour des images ultérieures ?
Les commentaires suggèrent des métadonnées pratiques : noms de références versionnés, un fichier par épisode ou par page, et des champs de frontmatter pour les personnages, références, plage narrative, statut et dépendances.
Ce guide transforme cette douleur de production en une méthode d’audit reproductible.
Ce n’est pas seulement une checklist de cohérence des personnages
La Checklist de cohérence des personnages de BD vous aide à définir un verrou de personnage, détecter les dérives visuelles et réparer une case qui ne correspond plus au design approuvé.
Cet article commence une étape plus tard :
L’ancien design a été approuvé et utilisé correctement. Puis la référence source elle-même a changé. Quel travail existant doit maintenant être réexaminé ?
C’est un problème de gestion du changement, pas seulement un problème de qualité de prompt.
Le projet test de 40 pages
Le projet d’exemple est une BD policière fictive de 40 pages appelée The Observatory Key.
Champ du projet
Valeur de test
Nombre total de pages
40
Nombre total de cases
168
Personnage principal
Mira Vale
Pages contenant Mira
29
Cases contenant Mira
94
Ancienne référence approuvée
mira-v03-approved
Nouvelle référence approuvée
mira-v04-approved
Ticket de modification
CR-017
Ressources directes en aval
Couverture de chapitre, vignette, teaser social, image de pitch deck
Date d’audit
26 octobre 2026
Il s’agit d’une simulation de registre de production. Elle teste si la méthode se clôt mathématiquement et opérationnellement ; elle ne prétend pas que les 40 pages finales ont toutes été générées en une seule exécution automatisée.
Ce qui a changé dans Mira v04
Le directeur créatif a approuvé trois corrections :
Champ
v03
v04
Pourquoi c’est important
Repère du visage
Cicatrice sous l’œil droit
Cicatrice sous l’œil gauche
visible en plans rapprochés et moyens
Fermeture du manteau
Quatre boutons ronds argentés
Une attache diagonale en laiton
visible dès que le torse fait face à la caméra
Accessoire narratif
Boussole ronde en laiton
Boussole octogonale en laiton
objet récurrent de l’intrigue et point d’ancrage des ressources dérivées
Tout le reste reste verrouillé : forme du visage, carré cuivré, proportions du corps, manteau sarcelle, chemise anthracite et palette de couleurs.
Il s’agit d’une correction d’identité, pas d’une autorisation de redessiner le personnage. Une réparation qui modifie le visage, l’âge, la coiffure, la pose, la caméra, l’éclairage ou l’arrière-plan de Mira crée un nouveau risque de continuité.
Première règle : n’écrasez jamais l’ancienne référence
Ne remplacez pas mira-approved.png par une autre image sous le même nom de fichier. Cela supprime la preuve nécessaire pour déterminer quelles pages ont utilisé quel design.
Utilisez des identifiants immuables et versionnés :
Sans from_ref, vous ne pouvez pas distinguer de manière fiable une page obsolète d’une page déjà générée avec v04.
Les quatre états d’impact
Chaque page reçoit exactement un état.
Code
État
Signification
Action par défaut
X
Réparation requise
Un champ modifié est clairement visible, ou la page alimente une ressource en aval obsolète
modifier ou régénérer la case affectée
R
Revue requise
Mira apparaît, mais l’éclairage, l’échelle, le cadrage, le reflet ou l’occlusion rendent l’impact incertain
vérification visuelle humaine
K
Vérifiée inchangée
Mira apparaît, mais aucun des champs modifiés n’est visible
conserver l’illustration approuvée
A
Personnage absent
Mira n’apparaît pas et la page n’hérite pas d’une ressource obsolète
aucune action
Utilisez un état K explicite. Le silence est ambigu : cela peut signifier « vérifié et sûr » ou « oublié ».
Carte d’impact complète des 40 pages
L’audit au niveau des pages est :
01 K | 02 R | 03 X | 04 A | 05 X | 06 X | 07 R | 08 K
09 X | 10 A | 11 R | 12 X | 13 A | 14 X | 15 K | 16 X
17 R | 18 X | 19 A | 20 X | 21 A | 22 R | 23 K | 24 X
25 A | 26 R | 27 X | 28 A | 29 K | 30 X | 31 R | 32 A
33 A | 34 X | 35 A | 36 R | 37 K | 38 A | 39 X | 40 R
Mira apparaît sur les 29 pages X, R et K, couvrant 94 cases. Aucune page ne peut être dans deux états, et aucune page n’est laissée sans classification.
Le tableau d’impact dont vous avez réellement besoin
Un tableau utile suit plus que le nom du personnage.
Page
Cases
Dépendance
Détail modifié visible ?
Ressource dérivée
État
Action
3
2, 4
direct mira-v03
visage et attache
aucune
X
modifier les deux cases
6
1, 3, 4
direct mira-v03
visage, torse, boussole
vignette de chapitre
X
réparer les cases, actualiser la vignette
8
2
direct mira-v03
vue de dos seulement
aucune
K
enregistrer comme vérifiée inchangée
9
1–4
direct mira-v03
les trois champs
aucune
X
régénérer la case 4, modifier 1–3
14
5
hérité de la page 3 case 4
cicatrice visible
aucune
X
réparer la case héritée
18
2–4
direct mira-v03
gros plan sur la boussole
teaser social
X
réparer, reconstruire le teaser
22
1–5
direct mira-v03
faible lumière et pluie
aucune
R
inspection visuelle à 200 %
27
2, 3
direct mira-v03
visage et boussole
couverture de chapitre
X
réparer, reconstruire la couverture
31
1–4
direct mira-v03
scène de groupe éloignée
aucune
R
comparer en taille impression et mobile
37
3
direct mira-v03
silhouette uniquement
aucune
K
conserver l’illustration
40
2
reflet dérivé de la page 27
incertain
image de pitch deck
R
inspecter la source et le reflet
La ligne critique est la page 14. Elle n’a jamais utilisé mira-v03 directement ; elle a utilisé une case antérieure comme référence visuelle. Une recherche basée uniquement sur l’ancien nom de fichier la manquerait.
Suivez séparément la provenance et la dépendance
Utilisez deux champs pour deux questions différentes.
generated_with enregistre la provenance : comment cette case a été créée.
depends_on enregistre la dépendance : quelle ressource approuvée l’a influencée.
Si la page 3 case 4 est réparée, l’audit suit la liaison jusqu’à la page 14 case 5 même si le prompt ultérieur n’a pas joint la référence originale de Mira.
Construisez un index inversé avant de réparer quoi que ce soit
Créez une recherche inversée de l’ancienne référence vers chaque consommateur :
mira-v03-approved
├─ pages directes : 01, 02, 03, 05, 06 ...
├─ cases héritées : P14.5, P40.2
├─ vignette de chapitre : dérivée de P06.4
├─ teaser social : dérivé de P18.3
├─ couverture de chapitre : dérivée de P27.2
└─ image de pitch deck : dérivée de P40.2
Le sens est important. Un journal de prompts vous indique généralement ce qu’une page a utilisé. Un index inversé vous indique chaque page qui doit être revisitée lorsqu’une source change.
Classifiez la visibilité, pas seulement la présence
La phrase « Mira apparaît sur cette page » ne suffit pas.
Pour chaque case, enregistrez si le champ modifié est réellement visible :
Visibilité
Exemple
Impact
Rapproché
le visage occupe une grande partie de la case
la correction de la cicatrice est obligatoire
Moyen
visage et torse visibles
la cicatrice et l’attache peuvent toutes deux nécessiter une réparation
Insert d’objet
la boussole remplit le cadre
la correction de la boussole est obligatoire
Large
le personnage est petit
revoir à la taille de sortie finale
Vue de dos
visage et fermeture avant cachés
généralement vérifiée inchangée
Silhouette
aucun détail interne
vérifiée inchangée sauf si la silhouette a changé
Reflet
l’image peut hériter d’une case antérieure
inspecter la dépendance source
Occluse
manteau ou visage partiellement caché
revue humaine
Cela évite deux erreurs opposées : réparer des pages où le changement ne peut pas être vu, et manquer des pages où un petit accessoire pourtant crucial pour l’histoire est visible.
Choisissez la plus petite réparation sûre
Les 38 cases obsolètes de cet exemple ne nécessitent pas toutes la même opération.
Mode de réparation
Cases
À utiliser quand
Édition ciblée
23
la composition, le jeu, l’éclairage et l’arrière-plan sont déjà approuvés
Régénération de case
15
la référence modifiée affecte la pose, le contact main-objet ou une trop grande partie du design visible
Revue humaine uniquement
34
l’impact est incertain jusqu’à inspection à la taille de sortie
Ne commencez pas avec les 38 cases obsolètes. Réparez d’abord trois cas représentatifs :
Un gros plan de visage pour la cicatrice.
Un plan moyen pour l’attache du manteau.
Un insert main-et-objet pour la boussole.
Le canari ne réussit que si :
Mira ressemble toujours à la même personne.
Les trois champs corrigés correspondent à v04.
La pose, le cadrage, l’éclairage, l’arrière-plan et les autres personnages restent stables.
La case réparée s’enchaîne toujours proprement avec la case précédente et la suivante.
Aucun faux texte, logo ou redesign accidentel de costume n’apparaît.
Le canari est un test contractuel pour le prompt de réparation. S’il échoue, modifiez le prompt ou la méthode d’édition avant de toucher au reste du projet.
Prompt de réparation à copier-coller
Repair only the selected comic panel using the approved character reference:
mira-v04-approved.
Required corrections:
- scar under Mira's LEFT eye
- one diagonal BRASS coat clasp
- OCTAGONAL brass compass
Identity lock:
- same face shape, age, copper chin-length bob, body proportions
- same teal coat and charcoal shirt
- same expression and acting intent
Preserve exactly:
- panel composition and crop
- camera angle and focal length
- pose and hand placement
- lighting and color grade
- background and other characters
- speech-bubble safe areas
Do not redesign Mira.
Do not change the story beat.
Do not add text, logos, or watermarks.
Return one repaired panel only.
Pour les cases où une main tient la boussole, régénérez plutôt que de forcer une édition locale si la nouvelle forme octogonale casse le contact des doigts ou la perspective.
Réparez par lots, puis relisez dans l’ordre
Utilisez de petits lots regroupés par type d’échec :
Batch A: scar close-ups
Batch B: coat-clasp medium shots
Batch C: compass inserts and hand contact
Batch D: panels with two or three changed fields
Après chaque lot, lisez la séquence environnante, pas seulement les images réparées isolément. Une case techniquement correcte peut quand même échouer si le regard, le mouvement, la météo ou la progression émotionnelle de Mira ne s’enchaînent plus.
Ordre de revue recommandé :
Comparez la case réparée avec v04.
Comparez-la avec les cases précédente et suivante.
Lisez la page complète à taille normale.
Lisez la double page ou la séquence de défilement.
Revérifiez la page à taille mobile.
Marquez la ligne du registre repaired, verified ou reopen.
Actualisez chaque ressource dérivée
Les pages ne sont pas la fin du graphe.
Dans le projet d’exemple :
La page 6 case 4 alimente une vignette de chapitre.
La page 18 case 3 alimente un teaser social.
La page 27 case 2 alimente la couverture du chapitre.
La page 40 case 2 alimente une image de pitch deck.
Une fois la case source réparée, reconstruisez la ressource dérivée. Ne retouchez pas seulement le recadrage exporté, car l’export suivant pourrait recréer silencieusement la version obsolète.
Utilisez cet ordre de clôture :
source reference
-> source panel
-> page export
-> chapter PDF or webtoon package
-> cover / thumbnail / teaser / pitch frame
-> final publication QA
Un workflow pratique avec LlamaGen.AI
LlamaGen.AI peut aider à créer et réparer des ressources visuelles, mais le projet a toujours besoin d’un contrôle du changement explicite.
Importez le manuscrit, script, PDF ou la source du projet via LlamaGen.AI Upload.
Verrouillez la fiche personnage actuelle avant de générer de longues séquences.
Stockez l’ID de version de la référence dans le brief de page ou dans un registre externe.
Quand la référence change, créez une nouvelle version au lieu de remplacer l’ancienne ressource.
Construisez le tableau d’impact avant d’ouvrir les outils de génération.
Réparez uniquement les cases X ; inspectez visuellement les cases R.
Laissez les cases K et A intactes.
Reconstruisez les ressources dérivées à partir des cases sources réparées.
N’exportez qu’après avoir clôturé les vérifications de page, de chapitre et de promotion.
Pour un projet qui doit réutiliser la même distribution sur des sorties page, webtoon et storyboard, lisez aussi One Character Sheet, Three Formats.
Modes d’échec courants
Écraser le fichier approuvé
Si les deux designs s’appellent mira-approved.png, l’audit ne peut pas prouver quelle version une page a utilisée.
Rechercher dans les prompts mais ignorer les images héritées
Une page ultérieure peut utiliser une case antérieure comme référence. Suivez les dépendances image-vers-image, pas seulement les attaches directes de personnage.
Régénérer chaque page
Cela modifie la composition approuvée et crée de nouvelles erreurs de continuité. Dans le cas test, 96 cases sur 168 n’ont besoin d’aucune modification.
Réparer seulement les gros plans évidents
Le visage peut être corrigé tandis que l’ancienne boussole survit dans un insert, une couverture, une vignette ou un reflet.
Traiter « non relu » comme « non affecté »
Utilisez des états explicites. K signifie inspecté et sûr ; une cellule vide signifie travail inachevé.
Mettre à jour le recadrage au lieu de la source
Corriger une image sociale obsolète sans corriger sa case source laisse la dépendance cassée.
Laisser les métadonnées dériver par rapport à l’illustration
Exécutez à la fois une requête de métadonnées et une revue visuelle en planche contact. Si leurs nombres de pages diffèrent, l’audit n’est pas clôturé.
Critères de fin d’audit
Le ticket de modification n’est clôturé que lorsque tous ces points sont vrais :
Les anciennes et nouvelles références ont des identifiants de version immuables.
Chaque page est classée exactement une fois.
Les totaux de pages et de cases se ferment.
Les dépendances directes et héritées ont été recherchées.
Trois cases canari représentatives réussissent.
Toutes les cases X sont réparées et revérifiées dans la séquence.
Toutes les cases R ont un relecteur nommé et une décision.
Chaque case K a un enregistrement de vérification.
Toutes les ressources dérivées ont été reconstruites à partir de sources réparées.
Les exports finaux ne contiennent plus aucune apparence obsolète de v03.
L’ancienne référence reste archivée pour la provenance.
Note sur la génération d’images
Les visuels explicatifs de cet article ont été générés le 26 octobre 2026 avec Vertex AI en utilisant Gemini Nano Banana 2.1, identifiant de modèle gemini-nano-banana-2.1, puis compressés en WebP et téléversés sur le CDN de LlamaGen.AI. La couverture a reçu le filigrane de marque standard de LlamaGen.AI.
Google décrit Nano Banana 2.1 comme un modèle de génération d’images et d’édition conversationnelle à haute efficacité, avec une cohérence multi-tours améliorée. Voir la documentation officielle du modèle. Ces images sont des explications éditoriales, pas des captures produit ni un benchmark du suivi automatique des dépendances.
FAQ
Dois-je régénérer chaque page après avoir modifié une référence de personnage ?
Non. Faites d’abord un audit. Réparez les pages où un champ modifié est visible, relisez les pages incertaines et laissez intact le travail vérifié comme non affecté.
Un journal de prompts suffit-il ?
Non. Un journal de prompts enregistre la provenance. Vous avez aussi besoin des dépendances, y compris les pages qui ont utilisé une case générée antérieure au lieu de la référence de personnage d’origine.
Que faire si je n’ai pas enregistré les versions des références ?
Créez une planche contact visuelle, identifiez les signatures anciennes et nouvelles, puis classez manuellement chaque apparition. Ensuite, ajoutez des identifiants de version avant le prochain cycle de génération.
Combien de cases canari dois-je tester ?
Trois est un minimum utile lorsque le changement touche le visage, les vêtements et un accessoire. Choisissez des cases représentatives, pas les plus faciles.
Dois-je modifier ou régénérer une case affectée ?
Modifiez lorsque la composition approuvée peut être préservée proprement. Régénérez lorsque le changement affecte l’anatomie, le contact de la main, la perspective ou une grande partie du personnage.
Cette méthode peut-elle aussi suivre les lieux et les accessoires ?
Oui. Le même modèle de dépendance fonctionne pour une refonte de pièce, une mise à jour de véhicule, une suppression de logo, un changement de costume ou un objet narratif récurrent.
Workflow final
freeze change request
-> create versioned reference
-> build reverse dependency index
-> classify all 40 pages
-> test three canary repairs
-> repair only stale panels
-> review uncertain panels
-> rebuild derived assets
-> verify sequential continuity
-> close the change ticket
Une BD longue doit se comporter comme une production gérée, pas comme un amas de prompts déconnectés. Le but n’est pas d’empêcher tout changement de design. C’est de rendre l’effet d’un changement visible avant qu’il ne devienne coûteux.
Vous pouvez démarrer le projet source avec LlamaGen.AI Upload, verrouiller chaque référence de personnage approuvée par version, et garder le registre d’impact à côté de la BD jusqu’à ce que l’export final soit validé.
