J'ai testé 13 modèles d'IA d'images pour la cohérence des personnages. La plupart ont échoué de la même façon.
Vous générez une image pour la couverture de votre article. Parfait, ça claque. Article suivant, même personnage, même style, prompt quasi identique. Visage complètement différent. Pas une variation. Une autre personne. Le modèle a décidé que votre personnage avait besoin d'une nouvelle identité, comme un programme de protection des témoins mais pour pixels.
Sur un article isolé, on s'en fiche. Sur une publication où les mêmes personnages apparaissent sur des dizaines de posts, c'est un problème de branding qu'on ne remarque que quand un lecteur demande "attends, c'est censé être le même mec ?" Pixar ne peut pas sortir Woody avec un visage différent dans chaque scène. Une BD non plus. Votre blog non plus, si vous voulez vraiment que les gens reconnaissent vos couvertures quand ils scrollent.
TLDR : J'ai testé 13 modèles d'IA image pour la cohérence des personnages. Deux ont survécu. Le moins cher a gagné. Et la raison n'a rien à voir avec le prompting.
Le Problème Que Personne Ne Mentionne Quand On Ship des Visuels Générés par IA
Chaque démo de modèle vous montre une image époustouflante. Personne ne vous montre le même personnage généré dix fois d'affilée. Parce que c'est là que ça se casse la gueule.
Mon setup : deux personnages récurrents sur chaque couverture d'article, générés via un pipeline automatisé sur fal.ai. Un employé de bureau avec cravate et expression perpétuellement blasée, et un héros en cape. Mêmes personnages, même univers, même identité visuelle sur chaque contenu. Premiers articles, nickel. Puis les visages ont commencé à dériver. Subtilement d'abord (mâchoire légèrement décalée, raie des cheveux du mauvais côté), puis plus du tout subtilement (être humain complètement différent qui me fixait).
Je pouvais continuer à ajuster les prompts à la main à chaque fois, comme une sorte de chuchoteur de prompts espérant que la prochaine génération tomberait juste. Ou je pouvais tester tous les modèles disponibles sur la plateforme et déterminer lesquels tiennent vraiment la route.
J'ai donc testé les treize. Un template de prompt partagé. Mêmes deux références de personnages injectées à chaque fois. Systématique, pas au feeling.
Sans cohérence, chaque image est un one-shot. Avec un pipeline, c'est une fuite qu'on ne voit que quand les lecteurs la voient.
La Cohérence des Personnages N'est Pas un Problème de Prompt. C'est un Problème d'Endpoint.
La plupart des gens dépannent la cohérence des personnages en réécrivant les prompts. Ajouter plus de détails, peaufiner la description du style, jouer avec les seeds. J'ai fait pareil pendant trois semaines. C'était comme accorder une guitare sans cordes.
Le mécanisme réel est plus simple et plus brutal : injection de référence positionnelle via les endpoints /edit avec plusieurs image_urls. Pas une astuce de prompt. Pas un paramètre. Un endpoint.
Vos images de référence de personnages sont envoyées comme data URIs dans le champ image_urls. Le modèle mappe les placeholders comme @image1 et @image2 sur ces références. Le prompt dit "mets @image1 à gauche", le modèle sait exactement quel visage utiliser. Deux références en entrée, deux personnages cohérents en sortie.
Les modèles qui foirent ? Tous la même raison architecturale : ils ne supportent pas deux références d'image simultanées. Kontext Pro prend une référence max. Ideogram Character, même histoire. Ideogram V3 prend zéro référence (description textuelle uniquement). Quand le pipeline tombe sur un modèle qui ne peut pas prendre deux refs, il se rabat sur adaptPromptForModel(), qui remplace @image2 par quelque chose comme "un personnage employé de bureau avec cravate et expression blasée."
Vous pouvez décrire un visage en quarante mots. Le modèle générera quand même un visage différent à chaque fois. Cette partie est réglée.
Le modèle ne foire pas sur la qualité. Il foire avant même de lire votre prompt.
Le Benchmark : 13 Modèles, 3 Tiers, Un Gagnant à 0,012$
Deux modèles ont eu cinq étoiles. Sept ont eu zéro.
Tier S (5 étoiles, en production) : Flux 2 Dev à 0,012$/MP et Nano Banana 2 à environ 0,01$/MP. Les deux supportent plusieurs image_urls en mode /edit, les deux maintiennent les personnages sur des générations consécutives.
Tier A (4 étoiles, utilisable) : Flux 2 Pro, GPT Image 1.5, Flux 2 Turbo, Flux 2 Flash. Ils gèrent le mécanisme de double référence mais avec une dérive mineure entre les exécutions.
Tier F (0-1 étoile, rejetés) : Flux 2 Max, Flux 2 Flex, Kontext Pro/Multi/Max, Ideogram V3/Character. Tous foirent pour la raison architecturale ci-dessus.
Deux résultats qui méritent qu'on s'y attarde.
Flux 2 Max : 1 étoile à 0,07$/MP. Presque 6x le prix de Dev. Et c'était pire. Il a ajouté des gants à un personnage qui n'en avait jamais eu. Des effets de foudre derrière un héros qui était censé rester immobile. Le modèle premium hallucine des éléments de costume pendant que celui du budget fait juste ce qu'on lui demande. (Karen de la Compta aurait deux mots à dire sur ce ROI.)
Kontext et Ideogram : tous deux ont eu zéro malgré un marketing spécifiquement axé sur la référence de personnages. Leur endpoint n'accepte simplement pas deux image_urls simultanées. Une ref, d'accord. Deux refs pour deux personnages dans la même scène ? L'architecture dit non. La page marketing n'est pas d'accord avec la doc API, et je sais laquelle je fais plus confiance.
Ce benchmark couvre un cas spécifique : deux personnages récurrents, style BD années 90, pipeline automatisé. Midjourney n'a pas été testé (pas d'API fal.ai). Les résultats peuvent différer sur d'autres styles. Mais le /edit avec plusieurs image_urls est la condition nécessaire quoi qu'il arrive.
Payer 6x plus m'a donné des gants de super-héros que je n'avais jamais demandés.
Quatre Pièges Qui Cassent la Cohérence des Personnages Même Avec le Bon Modèle
Bon modèle, mauvais setup. Je suis tombé dans chacun de ces pièges, et chacun m'a coûté plus de temps que de trouver le bon modèle au départ.
Le swap @image1/@image2. Un lundi j'ai remarqué que toutes les couvertures générées avaient les personnages du mauvais côté. L'employé de bureau avait la cape. Le héros portait une cravate. Comme un buddy movie où les costumiers ont mélangé les acteurs. Même prompt, mêmes refs, mais @image1 et @image2 étaient inversés dans le template. J'ai trouvé le commit (6c70e20), réalisé que le mapping avait été silencieusement swappé pendant un refactor. Aucun test ne l'a attrapé parce que personne ne teste "est-ce que le bon personnage porte la bonne tenue." Maintenant si.
Les dimensions dans le prompt. Quand le LLM génère le prompt d'image, il écrit parfois "scène cinématique 1536x1024px." Le modèle d'image essaie alors de rendre "1536x1024px" comme texte littéral dans l'image. Magnifique. Fix : sanitizePrompt() supprime les patterns de dimensions via regex. Les vraies dimensions passent uniquement par le paramètre API image_size.
Data URI vs HTTP URL. Certains modèles (Kontext, Ideogram) plantent silencieusement avec les data URIs base64. Ils ont besoin d'URLs HTTP pointant vers des fichiers publiquement accessibles. Fix : ensureHttpUrl() upload la référence vers le cloud storage avant l'appel API. Deux lignes de code qui ont nécessité trois jours de debug pour découvrir qu'elles étaient nécessaires.
Cher signifie sur-interprétation. Flux 2 Max ne génère pas juste ce que vous demandez. Il améliore votre demande en ajoutant des éléments qu'il pense devoir appartenir à une scène de BD. Ce n'est pas un bug, c'est une philosophie de design. Et cette philosophie de design est incompatible avec l'usage en pipeline où vous avez besoin exactement du même style de sortie à chaque fois. Même raisonnement spec-first que j'utilise avec les prompt contracts s'applique : tester les assumptions avant de construire autour d'un modèle, pas après.
Quatre lignes de code coûtent moins que trois semaines d'ajustement au feeling.
Six Règles de Prompting Qui Bougent Vraiment les Lignes
Une fois que le modèle et le pipeline sont bons, ces six règles ont fait une différence visible. Toutes découvertes en testant.
1. Sujet d'abord.
"Illustration style BD années 90 de deux personnages
debout dans une salle serveur"
"Deux personnages debout dans une salle serveur, @image1
à gauche pointant un écran, style bande dessinée"
Les modèles Flux pondèrent plus lourdement le début du prompt. Ce qui vient en premier reçoit le plus d'attention. Mettez la scène et l'action avant le style.
2. Nommez les personnages en plus des refs. @image1 injecte le visage, mais ajouter un nom ("Phil le développeur", "Capitaine Compliance") ancre la pose et l'expression. Le modèle traite les entités nommées différemment des références anonymes. Je ne m'attendais pas à ce que ça compte, mais si.
3. Limitez la complexité. Max trois panels, deux bulles de dialogue, huit mots par bulle. Au-delà le modèle sacrifie la cohérence des personnages pour respecter la composition. Il ne peut pas tout faire donc il lâche la partie la plus dure en premier. La partie la plus dure, c'est toujours les visages.
4. Zéro dimension dans le texte du prompt. Déjà mentionné dans les pièges. Ça vaut le coup de répéter : n'écrivez jamais les dimensions en pixels dans le prompt. Utilisez le paramètre API image_size. Toujours.
5. Branding in-world, pas overlay.
"watermark @rentierdigital en bas à droite"
"@rentierdigital gravé sur le cadran d'un moniteur
en arrière-plan"
Faites de la marque une partie de la scène, pas une instruction de post-processing. Le modèle ne comprend pas "overlay." Il comprend les objets dans une scène.
6. guidance_scale à 3.5 pour Flux 2 Dev. En dessous de 2, le modèle ignore la moitié de votre prompt. Au-dessus de 5, artefacts et sur-saturation. Pour les variantes rapides (Turbo, Flash), 2.5 avec 8 steps suffit. J'ai trouvé ça en générant le même prompt à chaque valeur de 1 à 7. Pas glamour, mais ça marche.
Un prompt qui essaie de tout spécifier donne au modèle la permission de choisir quelles parties ignorer. Choisissez vos batailles.
Le Bottom Line
Deux modèles sur treize. C'est le ratio. Pas parce qu'ils sont "meilleurs" dans un sens général, mais parce qu'ils supportent nativement /edit avec plusieurs image_urls. Tout le classement découle de ce seul détail d'API. Pas de la qualité d'image, pas du prix, pas de la réputation du modèle.
Avant de choisir un modèle d'image pour n'importe quel pipeline de contenu, une question : est-ce que l'endpoint accepte plusieurs image_urls en mode /edit ? Si non, tout le reste c'est du temps cramé. Testez avec le même prompt, les mêmes références, trois générations consécutives. Pas une.
La seule façon d'avoir des personnages cohérents c'est de nourrir le modèle avec une image de référence. Sinon vous pouvez passer deux jours à écrire le prompt parfait. Ça ne changera rien. La réponse était dans la doc API, page 2, paramètre image_urls. La cohérence des personnages n'est pas un problème de prompting. C'est un problème de lecture de documentation.
Sources : documentation des modèles fal.ai pour les specs d'endpoints et les prix.
(*) La couverture est générée par IA. Ce qui, vu l'article, vous vous en doutiez probablement déjà. L'ironie c'est qu'il a fallu trois essais pour avoir les personnages corrects sur celle-ci aussi.