Un personnage peut être reconnaissable dans une illustration, puis changer de visage, de coiffure ou de vêtements dès la scène suivante. Le problème apparaît vite dès qu'on veut raconter une histoire en plusieurs images - ou enchaîner des plans façon vidéo. On pense souvent que le modèle manque de constance et qu'il faut en essayer un autre. Pourtant, le défaut vient parfois d'abord du système autour : une image de référence absente, un nom mal repéré, ou des instructions qui finissent par contredire la fiche associée.
Un retour d'expérience mené sur un studio de création d'histoires montre bien cette différence. Pour garder l'apparence d'un personnage d'un plan à l'autre, son concepteur a ajusté ce qu'il envoyait en référence, la façon de lier les personnages, et l'organisation des prompts. Il a aussi testé la génération séquentielle avant d'opter pour des plans indépendants. Voici une méthode simple pour reprendre ces choix, comprendre les compromis et repérer les incohérences avant de changer de modèle.
Pourquoi un personnage change d'apparence d'une image à l'autre
La génération d'images ne conserve pas automatiquement la « mémoire visuelle » d'une requête à l'autre. Si vous demandez plusieurs images à partir d'une description, le modèle traite chaque demande dans son contexte. Il peut reprendre l'idée générale du personnage, mais pas forcément son visage, ses proportions ou ses vêtements. Et plus les scènes changent (cadrage, éclairage, angle, tenue), plus les écarts deviennent visibles.
C'est tentant d'attribuer ça aux limites du modèle. Parfois, oui. Mais dans beaucoup de cas, cette explication n'aide pas vraiment à corriger. Avant de blâmer le modèle, il vaut mieux vérifier ce qui a réellement été envoyé à chaque génération. Dans l'exemple étudié, un premier plan montrait un héros avec une tenue différente de celle du plan suivant. L'hypothèse de départ était un manque de stabilité. L'enquête a montré quelque chose de plus banal : la fiche d'image n'était jointe que si l'auteur cochait une option. La plupart des personnes ne le faisaient pas, même si l'interface affichait la fiche à côté du plan.
L'interface ne prouve pas que la référence est utilisée
Le point à retenir : une image visible dans l'application ne veut pas dire qu'elle a été réellement transmise dans la requête envoyée au service de génération. Il faut tracer la charge utile réelle : quels fichiers sont ajoutés, avec quelles instructions, et pour quels plans. Cette vérification devient vite précieuse quand le résultat semble varier « sans raison ».
La correction retenue était pragmatique : joindre automatiquement la fiche du personnage à chaque plan où il apparaît, tout en gardant la possibilité de la retirer. En pratique, le réglage par défaut évite les oublis ; l'option de retrait permet de garder un contrôle éditorial quand un personnage doit être déguisé, vu de dos, ou volontairement différent.
Un nom n'est pas toujours une identité unique
Les récits utilisent des prénoms, des noms complets, des surnoms et des titres. Un personnage appelé Cael dans la fiche peut être mentionné « Cael » dans un plan, alors que la fiche est indexée sous son nom complet. Si le système demande une correspondance exacte, il risque de ne pas retrouver la bonne référence et de générer l'image uniquement à partir du texte.
La solution consiste à séparer l'identité et le libellé utilisé à l'écran. Une fiche devrait garder un identifiant stable, plus une liste de noms ou d'alias. Le système peut alors relier les variantes au même personnage. Et pour limiter les erreurs quand deux personnages partagent un alias, prévoyez une validation plutôt que de coller une fiche au hasard.
À vérifier avant de changer de modèle : la référence est-elle présente dans la requête ? Le personnage a-t-il été reconnu sous le bon nom ? Le système envoie-t-il une fiche, ou plusieurs images contradictoires ? Ce contrôle rapide évite de payer des essais qui traitent le mauvais problème.
Comment construire et transmettre une fiche de référence
Une fiche de référence doit donner assez d'éléments visuels pour identifier le personnage dans plusieurs situations, sans transformer chaque génération en dossier d'archives. Dans l'approche décrite, un personnage principal utilise une seule fiche regroupant plusieurs vues de la même personne. Ça coûte moins cher que plusieurs images séparées, et surtout ça limite les variations : les vues proviennent du même document de référence.
Concrètement, la fiche peut inclure le visage de face et en trois-quarts, la silhouette, et quelques éléments distinctifs. Le bon contenu dépend du type de scènes à produire : un récit en gros plans n'a pas les mêmes besoins qu'une séquence où le personnage est souvent vu en pied. L'objectif n'est pas d'empiler tous les angles possibles, mais de couvrir les changements de cadrage qui comptent vraiment.
Une fiche par personnage, pas une planche de casting
Une grille de plusieurs vues peut aussi créer un nouveau souci. Parfois, une planche ressemble à un « groupe » pour le modèle, surtout si un même plan réunit plusieurs personnages et qu'on joint plusieurs fiches. Le modèle peut confondre des vues, attribuer le mauvais visage, ou interpréter l'ensemble comme une foule.
Une instruction courte et claire aide à lever cette ambiguïté : indiquez que chaque fiche correspond à un personnage, puis respectez le même ordre entre la scène et la liste des fiches. Par exemple : « Fiches de personnages jointes, une par personne : A ; B. » Ce n'est pas une garantie absolue, mais ça donne une relation nette entre références et rôles.
Côté workflow, la structure peut renforcer la règle : au lieu de joindre des images « brutes » sans contexte, transmettez une liste d'objets cohérente - identifiant du personnage, alias reconnus, fiche associée et rôle dans le plan. C'est plus facile à déboguer, et ça aide à vérifier que la référence n'a pas été perdue entre l'interface et l'API.
Automatiser le défaut, laisser une exception
Pour une production répétée, ajouter les fiches manuellement plan par plan finit par devenir fragile. Un oubli isolé suffit à produire un plan incohérent et à générer une retouche évitable. L'ajout automatique par défaut réduit ce risque. Garder le retrait manuel est utile quand l'histoire impose une variation (déguisement, vue de dos, apparence volontairement différente).
Mais il faut éviter de confondre « référence visuelle » et « contrainte absolue ». Une fiche sert de guide : elle n'empêche pas la pose, l'éclairage, le cadrage ou le style de modifier l'image. D'où l'intérêt de définir ce qui doit rester stable - souvent le visage et les signes distinctifs - et ce qui peut bouger selon la scène.
Comment écrire un prompt sans brouiller l'apparence
Ajouter plus de texte ne rend pas forcément la demande plus précise. Une approche du studio consistait à coller la biographie complète dans chaque prompt. Sur le papier, tout était documenté. En pratique, la description écrite finissait par entrer en contradiction avec la fiche : longueur des cheveux, manteau, détails du visage. Le modèle tentait alors de « concilier » les deux sources et finissait par produire une version intermédiaire.
Une séparation plus nette fonctionne mieux : la fiche décrit l'apparence, le prompt décrit l'action, le dialogue, le cadre et les conditions de la scène. Cette règle réduit les contradictions, et rend les prompts plus simples à relire. En cas d'échec, vous identifiez plus vite si le problème vient de l'identité, de la mise en scène, ou de la direction artistique.
Séparer l'identité de la scène
Un prompt peut suivre une structure simple en quatre blocs :
- Personnages présents : noms et correspondance avec les fiches jointes.
- Action : ce que chacun fait au moment représenté.
- Mise en scène : cadrage, position dans l'espace, ambiance lumineuse utile.
- Style : consigne visuelle commune à toutes les images.
Cette décomposition évite de répéter la biographie à chaque requête. Elle aide aussi à modifier sans casser : changer une action ne devrait pas modifier les traits du personnage. Dans un outil d'écriture, gardez la fiche comme source de vérité pour l'apparence, et gardez le texte de la scène comme source de vérité pour ce qui se passe.
Ne pas demander un accessoire absent de la référence
Cette séparation ne veut pas dire que la fiche doit contenir tout ce qui apparaît dans la scène. Elle veut dire que vous devez repérer les contradictions. Dans l'exemple du studio, une épée a posé problème : comme la fiche ne la montrait pas, l'objet a fini par ressembler à une sacoche de livre. Le modèle avait une image claire du personnage à copier, mais pas de référence visuelle pour l'accessoire.
Si un accessoire compte vraiment, donnez une description distincte et suffisamment précise, ou ajoutez une référence dédiée si l'outil le permet. Ne surchargez pas non plus la fiche avec tous les objets possibles : ça la rend moins réutilisable et peut brouiller l'identité visuelle. La question utile est simple : l'objet doit-il rester cohérent sur toute l'histoire, ou seulement dans cette scène ? Dans le premier cas, une référence stable est logique ; dans le second, une instruction locale peut suffire.
Garder un style commun sans multiplier les images de style
La direction artistique est une autre couche. Le studio visait une illustration éditoriale plutôt « plate », avec des arrière-plans simples. Au lieu d'ajouter une image de style à chaque requête, le concepteur a gardé une description textuelle courte, réutilisée pour les fiches et les images de scènes.
Ça limite le risque qu'une référence de style finisse par influer sur les traits des personnages. Et c'est plus simple à maintenir : une consigne stockée à un seul endroit reste cohérente. Une vérification automatique peut aussi s'assurer que l'application web et l'API utilisent exactement la même formulation. Sans ça, les images produites dans deux parties du produit peuvent dériver, même si l'interface ne change pas.
Faut-il générer les plans en chaîne ou en parallèle
La méthode la plus intuitive consiste à fournir, pour chaque plan, l'image du plan précédent. On gagne alors un peu de continuité immédiate : le résultat reprend certains détails de l'image précédente. Mais ça crée une dépendance séquentielle. Chaque génération doit attendre la précédente, ce qui rallonge le temps total. Et si un plan contient une erreur, cette erreur peut « contaminer » les suivants.
Le concepteur du studio a testé. Les visages étaient un peu plus stables, mais la chaîne ralentissait le traitement et rendait les erreurs plus coûteuses à corriger. Au final, il a préféré générer chaque plan en parallèle : tous ancrés sur les mêmes fiches de personnages. Sur une scène de 31 secondes découpée en sept plans, chaque image a été produite indépendamment, à partir des mêmes références.
Le bon choix dépend du coût de l'erreur
La génération séquentielle peut marcher si la continuité entre deux images est prioritaire et que le nombre de plans reste faible. Elle devient moins intéressante quand vous devez produire vite beaucoup de variantes, ou quand une erreur en amont risque de ruiner le reste. À l'inverse, le traitement en parallèle réduit le délai global et isole les échecs : un plan raté peut être régénéré sans refaire l'ensemble de la scène.
Le compromis, c'est que les plans parallèles n'héritent pas automatiquement des micro-détails du plan précédent. Il faut donc une référence commune assez claire et des descriptions de scène qui ne se contredisent pas. Et si la transition exige une continuité très précise (un personnage se lève, saisit un objet, puis sort du cadre), une validation de montage ou une référence plus ciblée peut rester nécessaire.
Organiser un flux de production réparable
La qualité d'un workflow se mesure aussi à sa capacité à se corriger. Un processus robuste doit permettre de savoir, pour chaque image, quelles fiches et quelles consignes ont été envoyées. Il doit aussi conserver les résultats plan par plan, pour relancer uniquement la génération qui a échoué. Au départ, régénérer toute la séquence semble simple ; ensuite, dès que les scènes s'allongent, le coût explose.
Une séquence opérationnelle raisonnable ressemble à ceci :
- Identifiez les personnages de chaque plan à partir de leurs noms et alias.
- Joignez automatiquement leurs fiches de référence.
- Envoyez une consigne de scène distincte de la description physique.
- Générez les plans en parallèle si l'indépendance et la vitesse priment.
- Vérifiez les visages, les vêtements et les objets importants.
- Ne relancez que les plans qui échouent au contrôle.
Ce workflow ne supprime pas les limites du modèle. Il rend les erreurs plus visibles, plus localisées, et moins chères à corriger. Et, dans beaucoup de cas, c'est un gain plus concret qu'un changement de fournisseur.
Conclusion
La cohérence des personnages générés par IA tient moins à une « formule magique » qu'à un système bien raccordé. Les fiches doivent être envoyées par défaut, les noms et alias doivent mener à la bonne identité, et les prompts doivent distinguer clairement l'apparence de l'action. Une consigne de style centralisée et un flux de génération réparable limitent aussi les dérives.
Avant de changer de modèle, inspectez donc ce qui est réellement envoyé dans vos requêtes, et comment les références sont associées aux plans. Ensuite, testez votre workflow sur une scène courte : quelques personnages, plusieurs cadrages, et un accessoire important. Vous verrez vite si le problème vient du modèle, des données, ou de la structure de production - et vous pourrez corriger la couche qui compte vraiment.