Générer des images produits e-commerce avec wan2.7-image/text-to-image via l'API HiAPI

Pourquoi les modèles text-to-image ont leur place dans votre workflow de packshots

Les équipes catalogue ne sont généralement pas confrontées à un problème de photographie, mais de capacité. Un seul SKU exige une vue de face propre, parfois des variantes sous d'autres angles, et souvent une version conforme aux spécifications des plateformes marketplace. Pour les visuels principaux et tout contenu qui doit correspondre au pixel près au produit physique, la photographie réelle reste supérieure. Le packshot génératif répond à un ensemble de cas plus restreint et plus concret : visuels provisoires en attendant les photos, variantes d'arrière-plan pour les tests A/B des fiches produit, rendus conceptuels pendant la planification des catégories, et composition cohérente pour les SKU à longue traîne qui ne méritent jamais de réserver un créneau studio.

Le modèle mental utile est celui-ci : la génération se situe entre les données produit et la mise en ligne, elle ne remplace pas le photographe. Votre catalogue contient déjà des faits structurés — nom du produit, matériau, couleur, forme, emballage. Le modèle text-to-image transforme ces faits en candidats visuels. La question de pipeline est la suivante : comment y parvenir de manière reproductible à l'échelle du catalogue sans réécrire manuellement les prompts SKU par SKU.

Ce guide traite précisément de ce problème. Nous verrons comment structurer les prompts pour qu'un catalogue entier produise des packshots visuellement cohérents, comment diagnostiquer la dérive des prompts, quand la sortie 4K en vaut réellement la peine, et comment encapsuler l'ensemble dans un service léger afin que le code produit n'interagisse jamais directement avec le modèle d'image. Le modèle utilisé ici est wan2.7-image/text-to-image sur HiAPI, via un appel API unifié.

Configurer wan2.7-image/text-to-image sur HiAPI

wan2.7-image/text-to-image est le point de terminaison text-to-image sur HiAPI : vous envoyez un prompt et recevez une image. Pas de compte séparé par modèle, pas de SDK fournisseur à installer, pas de second jeu d'identifiants à gérer — HiAPI s'occupe du routage, de sorte que la surface d'intégration reste identique que vous ajoutiez ou remplaciez des modèles.

Le chemin de zéro au premier rendu est le suivant :

Obtenir une clé API et confirmer le nom du modèle

Créez une clé dans votre compte HiAPI, puis confirmez l'identifiant exact du modèle wan2.7-image/text-to-image dans la liste des modèles. Traitez l'identifiant comme de la configuration plutôt que comme une chaîne codée en dur — placez-le dans une variable d'environnement ou un fichier de configuration pour pouvoir pointer vers un autre modèle d'image plus tard sans modifier le point d'appel.

Envoyer une requête minimale

La forme de l'appel reste volontairement simple : un prompt, plus le nom du modèle. Commencez par une seule phrase décrivant un produit sur fond uni et vérifiez le résultat. Ne construisez pas encore de template — confirmez d'abord que l'authentification fonctionne, que la réponse contient des données d'image décodables ou récupérables, et que vous savez quelles métadonnées la réponse transporte (dimensions, format).

Stocker la réponse comme artefact

Écrivez l'image renvoyée dans un stockage objet, avec une clé déterministe, plutôt que de conserver les octets en mémoire ou en base de données. Dès le premier appel, considérez chaque rendu comme un asset doté d'un nom, d'une version de template et d'un horodatage — le rattrapage ultérieur est très douloureux.

Journaliser le prompt avec l'image

La métadonnée la plus précieuse est la chaîne de prompt exacte qui a produit l'image acceptée. Enregistrez-la. Quand un relecteur demande « pourquoi celle-ci est-elle différente ? », le prompt est la réponse.

Anatomie d'un prompt de packshot

Un prompt de packshot qui fonctionne une fois est un accident ; un prompt qui fonctionne sur tout le catalogue est une structure. Utilisez cinq composants, toujours dans le même ordre, afin que seul le contenu injecté change d'un SKU à l'autre :

Le sujet

L'objet précis, avec sa catégorie et une ou deux propriétés qui définissent sa silhouette. « Un filtre à café pour méthode douce en céramique mate » dit plus au modèle que « machine à café ». Nommez le type de produit, pas son nom marketing.

Matériau et finition

Le comportement de surface détermine le réalisme d'une image produit. Précisez le matériau et la finition : mat, brossé, brillant, verre dépoli, papier non couché, métal anodisé. Si le produit réel a une texture subtile, décrivez-la aussi — la dérive commence souvent ici.

Éclairage

Un packshot produit exige un éclairage prévisible. Choisissez un petit vocabulaire et tenez-vous-y sur tout le catalogue : lumière studio douce et uniforme, une seule lumière principale diffuse venant du haut à gauche, dégradé doux. Évitez un langage dramatique sauf si vous voulez une sortie dramatique ; pour les fiches produit, la cohérence l'emporte sur l'artistique.

Arrière-plan

Indiquez une couleur unie et neutre, et nommez la couleur : blanc pur sans raccord, gris chaud clair, neutre dit transparent. Un arrière-plan flou produit des arrière-plans désordonnés. Si la marketplace exige du blanc, écrivez blanc.

Composition

Précisez le cadrage et la position de la caméra : centré, produit occupant environ deux tiers de l'image, vue frontale à hauteur des yeux, léger angle à trois quarts, aucun élément coupé. La composition détermine si une grille de SKU ressemble à un ensemble de produits ou à un bric-à-brac.

Un template construit sur ces cinq emplacements permet de générer une catégorie entière à partir d'un tableau de lignes produit structurées, et réduit la section suivante — corriger la dérive — à une édition emplacement par emplacement.

Améliorer le respect du prompt

Quand un rendu s'écarte de la description produit, le réflexe est de réécrire le prompt. Retenez-vous. L'approche efficace consiste à identifier quel composant échoue et à ne changer que cette variable à chaque itération.

Diagnostiquer avant de réécrire

Comparez le rendu à vos cinq emplacements. Le matériau est faux mais la composition correcte ? Seule la phrase sur le matériau doit être ajustée. Le produit est correct mais flotte dans une scène encombrée ? La clause d'arrière-plan est trop faible. Nommer l'emplacement en échec transforme un vague « pas tout à fait » en édition précise.

Énoncer explicitement les contraintes, y compris négatives

Le modèle répond à ce que vous dites, alors dites ce qui compte. Si le produit ne doit pas avoir de logo visible, pas de reflet disgracieux, pas de main qui le tient, écrivez ces exclusions dans le prompt. Des contraintes explicites réduisent l'espace des rendus plausibles, ce qui est précisément le sens du respect du prompt.

Réduire le nombre d'idées par prompt

Chaque élément ajouté — accessoire, ombre d'un autre objet, surface décorative — se dispute l'attention du modèle. Pour un packshot, supprimez complètement les accessoires. Un prompt décrivant un objet dans une scène est bien plus fiable qu'un prompt qui demande aussi une scène stylisée.

Maintenir un petit ensemble de test et une référence de comparaison fixe

Choisissez cinq SKU représentatifs dans le catalogue — un matériau difficile, un matériau réfléchissant, un petit format, un grand format, un emballage imprimé. Quand vous modifiez le template, re-rendez ces cinq et comparez. Cela révèle l'échec courant : une correction pour une catégorie de produits en casse discrètement une autre. Enregistrez la version du template avec chaque rendu afin de pouvoir attribuer les changements de qualité de sortie aux changements de prompt.

Améliorer la structure, pas les adjectifs

Si un emplacement échoue systématiquement, la correction demande généralement plus de structure, pas plus d'adjectifs. Remplacez « belle lumière studio » par l'éclairage précis que vous voulez. Remplacez « joli fond » par une couleur et une surface. Le respect du prompt s'améliore quand le prompt se lit comme une fiche technique plutôt que comme un souhait.

Utiliser la sortie 4K

Une résolution plus élevée est une décision de diffusion, pas une valeur par défaut. wan2.7-image/text-to-image prend en charge les sorties haute résolution, mais chaque rendu 4K coûte plus de temps, plus de stockage et plus de traitement en aval qu'un rendu standard. Traitez ce choix comme une règle de routage selon l'emplacement de l'image.

Faire correspondre la résolution au cas d'usage

Les visuels principaux des fiches produit et toute image destinée au zoom méritent le palier le plus élevé — c'est là que les acheteurs inspectent coutures, textures et étiquettes. Les vignettes de grille, les carreaux de catégorie et les résultats de recherche n'en ont pas besoin ; générer en 4K puis réduire est du gaspillage. Les tableaux de spécifications des marketplaces publient généralement leurs propres dimensions minimales, donc fixez le plancher selon les exigences de la marketplace, pas selon le maximum du modèle. Tout le reste — rendus de relecture interne, variantes de test A/B, visuels provisoires — relève du palier standard.

Planifier pour le cycle de vie des assets, pas seulement pour la requête

Une image 4K est un gros fichier. Décidez à l'avance si vous stockez l'original pleine résolution et dérivez des variantes plus petites à la livraison, ou si vous ne stockez que le palier nécessaire à chaque emplacement. Stocker l'original plus des dérivés générés est généralement plus simple à comprendre et vous permet de re-rendre les tailles de livraison sans rappeler le modèle. Budgétez le stockage et la sortie CDN en conséquence, et assurez-vous que le nommage des assets encode le palier de résolution, pour qu'un service en aval n'envoie pas accidentellement un original 4K dans un emplacement de vignette.

Rendre la haute résolution plus tard

Pendant l'itération des prompts, rendez en résolution standard. Les problèmes de respect du prompt sont visibles à toutes les tailles, et itérer en 4K multiplie les temps de cycle sans apport diagnostique. Ne passez en haute résolution qu'une fois une variante de prompt approuvée — un rendu haute résolution par asset approuvé, pas par expérience.

Lancer l'appel API dans le pipeline produit

L'appel lui-même tient en une ligne de logique. Le travail consiste à le garder hors du code produit. Encapsulez-le dans un service interne léger assumant quatre responsabilités :

Le template de prompt comme donnée versionnée

Stockez le template à cinq emplacements hors de l'application, indexé par catégorie. Le service reçoit les données produit structurées, remplit les emplacements et enregistre la version de template qui a produit le rendu. Quand le template est modifié, les anciens assets restent rattachables à la version qui les a fabriqués.

Une fonction de génération aux entrées et sorties explicites

Le service expose une interface du type generatePackshot(productId, category, options), renvoyant une référence d'asset — pas les octets bruts. Les options incluent le palier de résolution et la version de template. Tout ce qui concerne l'appel HiAPI — authentification, identifiant de modèle, forme de la requête — vit à l'intérieur de cette frontière. Si vous changez plus tard la chaîne du modèle ou ajoutez un autre modèle d'image, le code produit ne change pas. Même logique pour les équipes qui utilisent HiAPI pour d'autres modalités : un seul schéma d'intégration, un seul jeu d'identifiants.

Nouvelle tentative avec budget limité

La génération est un appel réseau vers un modèle distant. Réessayez sur échec transitoire, mais limitez le nombre de tentatives avec un backoff et du jitter. Plus important encore, distinguez un échec réessayable d'une requête qui ne réussira jamais — un template mal formé doit échouer vite et clairement, plutôt que consommer le budget de tentatives. Enregistrez le nombre de tentatives sur l'asset pour observer la fréquence à laquelle un rendu nécessite une seconde tentative.

Un nommage d'assets prévisible

Nommez les assets avec les données que vous avez déjà : ID produit, catégorie, version de template, palier de résolution et hash de contenu court. Des noms déterministes rendent l'idempotence possible — une tâche réessayée sur un asset déjà produit peut sauter la régénération — et rendent la recherche de chaque rendu d'un SKU donné triviale.

Gardez le service sans état. Mettez en file les tâches, traitez-les, écrivez les assets, émettez des événements. Ainsi, un backfill à l'échelle du catalogue emprunte le même chemin qu'une requête pour un seul produit.

Contrôles qualité avant que les images n'atteignent la boutique

Les images générées doivent passer une série de paliers dans l'ordre avant publication. Automatisez les contrôles peu coûteux ; laissez les jugements subjectifs à la relecture humaine.

Palier 1 : validité technique

Le fichier doit être décodable, au format attendu et au moins au palier de résolution demandé. Rejetez tout fichier sous-dimensionné ou corrompu avant le stockage. Ce palier est entièrement automatisé et ne doit jamais échouer silencieusement.

Palier 2 : conformité aux exigences de la fiche

Vérifiez l'image selon les règles réelles de la plateforme cible : taille minimale, ratio d'aspect, tolérance de couleur d'arrière-plan quand le blanc est exigé, et limite de taille de fichier. Encodez les spécifications marketplace comme données, pour qu'un changement de spécification devienne un changement de configuration. C'est le palier qui attrape l'échec le plus embarrassant — un beau rendu refusé par la marketplace pour une question de dimensions.

Palier 3 : plausibilité du contenu

L'automatisation est faible ici, mais des heuristiques peu coûteuses aident : confirmez que l'image n'est pas vide ou presque uniforme, que l'arrière-plan dominant correspond à la couleur demandée, que le sujet occupe une proportion raisonnable de l'image. Routez les échecs vers une file de relecture plutôt que de les supprimer ; un faux positif d'heuristique mérite un coup d'œil humain, pas la perte de l'asset.

Palier 4 : échantillonnage humain

Prélevez un pourcentage des rendus pour relecture humaine, par version de template et par catégorie, et relisez 100 % des premiers rendus d'un nouveau template. Une fois le template approuvé, passez à l'échantillonnage. Le relecteur doit voir côte à côte l'image, le prompt et la fiche produit — ce contexte rend la vérification rapide.

Un asset n'est marqué publiable qu'après avoir passé les quatre paliers. Stockez les résultats des paliers avec l'asset pour que les audits n'aient pas à relancer les contrôles.

Par où commencer cette semaine

Choisissez une catégorie comptant au moins une douzaine de SKU et un emplacement qui tolère des images générées. Écrivez le template à cinq emplacements pour cette catégorie, construisez le service de génération léger autour de wan2.7-image/text-to-image sur HiAPI, et passez toute la catégorie en résolution standard. Avant d'automatiser le moindre palier, faites passer manuellement les sorties par les quatre paliers — vous apprendrez plus en relisant les premiers résultats qu'avec n'importe quelle théorie du prompt.

Une fois qu'un template passe sur un parcours de catalogue complet avec un respect du prompt acceptable, versionnez-le, branchez les paliers automatisés, et seulement alors décidez quels emplacements méritent un rendu haute résolution.