Générer des visuels produits e-commerce avec qwen-image-2.1-pro : utilisation de l'API et recettes de prompts

Pourquoi qwen-image-2.1-pro mérite d'être considéré pour les visuels produits e-commerce

Le travail sur les images e-commerce ne se limite rarement à une seule tâche. Il peut s'agir d'un shooting catalogue pour un nouveau SKU, d'un détourage pour une fiche produit sur une place de marché, d'une scène de vie pour une landing page, puis d'une bannière avec un badge promotionnel — le tout souvent à livrer dans la même semaine. Ce qui rend qwen-image-2.1-pro intéressant à évaluer, c'est que lorsque votre pipeline doit produire tout cela à partir des mêmes données produit, il peut assurer dans un seul modèle la génération, l'édition d'assets existants, la sortie de PNG transparents et le rendu de texte dans l'image, au lieu de dépendre d'une chaîne d'outils spécialisés.

Trois types de tâches couvrent l'essentiel du volume :

• Détourage transparent — le produit est proprement isolé sur un fond transparent, prêt à être placé dans n'importe quel emplacement du CMS.
• Composition de scène — le produit est placé dans un environnement de vie ou de studio crédible, généré à partir d'une description textuelle et d'une image de référence.
• Mise en page avec texte — étiquettes, badges et bannières, dont le texte doit être lisible et correctement positionné.

Là où il ne remplace pas le studio : les visuels principaux soumis à des exigences strictes d'éclairage de marque, et tout asset dont la géométrie du produit est encadrée par la réglementation (par exemple les emballages réglementés). Considérez la génération comme un moyen d'élargir la couverture et d'accélérer les itérations, puis conservez un point de validation humaine — c'est précisément à cela que sert la boucle de revue décrite plus loin dans ce guide.

La raison pratique de trancher tôt est l'architecture des prompts. Si vous savez dès le départ que le même modèle servira au détourage, aux scènes et aux mises en page avec texte, vous pouvez mettre en place un petit ensemble de modèles de prompts versionnés au lieu d'écrire des prompts à la volée à chaque requête. Cette décision ne coûte rien au départ et évite de tout réécrire plus tard.

Requêtes exécutables : curl et Python

Avant de concevoir des prompts, commencez par obtenir une image avec succès. Sur HiAPI, la forme des requêtes est identique d'un modèle à l'autre : une clé API, un nom de modèle et les paramètres d'entrée dans le corps de la requête. Le paramètre minimal requis par qwen-image-2.1-pro est le prompt, auquel s'ajoute l'image d'entrée à éditer si la tâche est une édition plutôt qu'une génération ex nihilo.

curl

curl -X POST "https://api.hiapi.ai/v1/images/generations" \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen-image-2.1-pro",
    "prompt": "Photo produit en studio d'une tasse à café en céramique noire mate, vue de trois quarts, lumière principale douce et diffuse venant de la gauche, léger reflet sur un fond sans couture gris clair, sans texte",
    "size": "1024x1024"
  }'

Python requests

import os
import requests

resp = requests.post(
    "https://api.hiapi.ai/v1/images/generations",
    headers={
        "Authorization": f"Bearer {os.environ['HIAPI_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "model": "qwen-image-2.1-pro",
        "prompt": "Photo produit en studio d'une tasse à café en céramique noire mate, "
                  "vue de trois quarts, lumière principale douce et diffuse venant de la gauche, "
                  "léger reflet sur un fond sans couture gris clair, sans texte",
        "size": "1024x1024",
    },
    timeout=120,
)
resp.raise_for_status()
print(resp.json())

Deux habitudes méritent d'être prises dès cette étape. Premièrement, lisez la clé API depuis une variable d'environnement, ne la codez jamais en dur — vous l'exécuterez très vite depuis des tâches batch. Deuxièmement, conservez le corps complet de la réponse dans les logs, y compris tout champ d'usage renvoyé par l'endpoint ; c'est ce qui vous servira ensuite à mesurer le « coût par asset approuvé » plutôt qu'à le deviner.

Lancez d'abord une requête avec un prompt générique comme celui ci-dessus. Vérifiez que vous obtenez bien une image et que la structure de la réponse correspond à ce qu'attend votre code en aval. Passez ensuite aux recettes — la conception de prompts demande du temps, vous ne voulez pas découvrir un problème de pipeline en cours de route.

Recettes de prompts pour PNG transparents et scènes produit

Les prompts improvisés dérivent facilement. Les équipes catalogue obtiennent des résultats cohérents en maintenant un petit ensemble de modèles à emplacements variables explicites, versionnés dans le dépôt aux côtés du code qui appelle l'API, et en ne remplaçant les emplacements que par SKU à chaque fois.

Recette 1 : détourage transparent

Détourage produit de {product_name}, {distinguishing_detail}, entièrement isolé sur un fond transparent.
Vue {view_angle}, produit centré et entièrement dans le cadre, avec une petite marge tout autour.
Éclairage de studio doux et uniforme, sans ombre dure projetée sur le fond, seulement une légère ombre de contact juste sous le produit.
Photorealiste, bords nets, sans texte, sans accessoires, sans éléments de fond.

Emplacements : {product_name} (« une tasse à café en céramique noire mate »), {distinguishing_detail} (« l'épaisseur visible du rebord et une petite anse »), {view_angle} (« trois quarts », « face », « plongée »). Les clauses de transparence et « aucune ombre projetée sur le fond » doivent être conservées telles quelles ; ces deux lignes font l'essentiel du travail sur les tâches de détourage.

Recette 2 : scène de vie

Photo produit lifestyle de {product_name} dans {scene_description}.
Le produit est le sujet : netteté sur le produit, proportions correctes, {brand_color_note}.
{lighting_note}. Faible profondeur de champ, arrière-plan doucement flouté.
Style naturel et éditorial. Sans texte, sans logo, aucun marquage de marque visible sur l'arrière-plan.

Emplacements : {scene_description} (« un plan de travail de cuisine minimaliste et lumineux, avec une serviette en lin et une fenêtre au petit matin »), {brand_color_note} (« couleurs non modifiées, aucun virage colorimétrique appliqué »), {lighting_note} (« lumière du matin chaude et directionnelle venant de la droite »).

Recette 3 : visuel principal en studio

Photo produit en studio de {product_name}, vue {view_angle}.
{background_description}. Lumière principale venant de {key_light_direction}, éclairage d'appoint doux, reflets maîtrisés.
Photorealiste, matériaux et textures de surface détaillés. Sans texte.

Deux règles maintiennent la bibliothèque de modèles en bonne santé. Ne modifiez jamais un modèle directement dans le script — modifiez le fichier de modèle, incrémentez le numéro de version et régénérez. Et consignez, pour chaque asset approuvé, la version de recette qui l'a produit, afin de pouvoir déterminer, en cas de changement de modèle, si une ancienne approbation reste valable.

Éditer des visuels produits existants

Les requêtes d'édition sont le point où surviennent la plupart des problèmes de qualité, car un prompt vague amène le modèle à régénérer le produit plutôt qu'à modifier la scène qui l'entoure. Découpez chaque prompt d'édition en trois parties explicites :

1. Ce qu'il faut modifier — la scène, l'arrière-plan, l'éclairage ou les accessoires ajoutés.
2. Ce qu'il faut conserver — la forme, les proportions, le motif de l'étiquette, la matière et la couleur du produit.
3. Ce qu'il faut éviter — nouveau texte, nouveaux logos, géométrie déformée, pièces dupliquées.

Un modèle utilisable :

Modifie cette photo produit.
Modifications : remplace l'arrière-plan par {new_background} ; ajuste l'éclairage selon {new_lighting}.
À conserver : la forme exacte du produit, ses proportions, sa matière de surface et tout motif d'étiquette, strictement inchangés.
À éviter : ajouter du texte, ajouter des logos, modifier la couleur du produit ou altérer sa géométrie.
Résultat photorealiste, qui ressemble à une prise de vue continue.

Exemple de remplissage : {new_background} = « un fond sans couture gris chaud et propre », {new_lighting} = « une lumière diffuse douce venant du dessus, avec un léger dégradé derrière le produit ».

Les clauses de conservation ne sont pas une garantie. Les éditions longues — remplacement d'arrière-plan, ajustement d'éclairage et ajout d'accessoires dans un seul prompt — laissent au modèle plus de marge pour dériver sur le produit lui-même. Découpez : faites d'abord le remplacement d'arrière-plan, vérifiez-le, puis appliquez les modifications secondaires lors d'une édition ultérieure sur le résultat intermédiaire approuvé. Chaque étape est alors une comparaison que le relecteur peut réellement juger.

Conservez également une image de référence standard pour chaque SKU. Lorsque le relecteur se demande si le produit a changé, c'est la référence qui fait foi, pas la dernière génération.

Rendu de texte et contrôle de la mise en page

Le texte dans l'image est la fonctionnalité qui déçoit le plus facilement avec des prompts improvisés. Le texte qui doit apparaître dans l'asset final doit être entre guillemets, positionné et contraint.

Bannière e-commerce pour {product_name}.
Mise en page : produit dans le tiers droit, bloc de texte dans les deux tiers gauches, marges généreuses.
Texte : rends exactement « {headline} » comme titre principal en police sans-serif grasse, et exactement « {subline} » en dessous en graisse plus légère.
Style : {color_scheme}, propre et moderne, contraste élevé pour la lisibilité.
Aucun autre texte ne doit apparaître nulle part ailleurs dans l'image. Tous les mots sont orthographiés exactement tels qu'écrits.

Pourquoi chaque ligne compte :

• Le texte entre guillemets accompagné d'une consigne explicite « exactement » réduit les reformulations et les mots inventés.
• La position et la proportion (« tiers droit », « deux tiers gauches ») empêchent le modèle d'enfouir le produit sous le titre.
• « Aucun autre texte ne doit apparaître nulle part ailleurs dans l'image » est la clause qui réprime le mode d'échec courant : du texte de remplissage plausible dans les coins.
• Un titre court et un sous-titre court sont bien plus fiables qu'un paragraphe. Si votre mise en page exige un texte courant, générez d'abord l'image sans ce texte, puis composez le texte dans le CMS ou l'outil de design.

Pour les badges et les étiquettes (mention « New », marquage de taille), traitez-les comme leurs propres petits prompts plutôt que de les ajouter au visuel principal — un prompt de petit badge contenant un seul mot entre guillemets est bien plus facile à vérifier lors de la revue que toute une bannière. Vérifiez toujours l'orthographe en pleine résolution avant approbation ; une erreur de texte coûte peu à détecter et cher à mettre en ligne.

Revoir les sorties : boucle de comparaison et d'approbation

Un asset généré ne doit pas être mis en boutique sans relecture humaine. La boucle la plus fiable et la moins coûteuse est une comparaison avant/après par asset : placer la photo d'entrée (ou la spécification, pour une génération ex nihilo) à côté de la sortie générée, et consigner la version de la recette de prompt ainsi que les valeurs des variables.

Une boucle exploitable pour une petite équipe :

1. Générez un petit lot — quelques variantes par SKU, pas tout le catalogue.
2. Produisez une table de comparaison côte à côte : l'image source à gauche, la candidate à droite, le prompt consigné en dessous.
3. Relisez selon une checklist courte et fixe : forme du produit inchangée, motif de l'étiquette intact, arrière-plan propre, texte correctement orthographié, marges suffisantes.
4. Marquez chaque candidate comme approuvée ou rejetée, et consignez la version de recette qui a produit les résultats approuvés.
5. Seulement alors, déployez sur tout le lot en réutilisant la recette approuvée. Si la recette change après approbation, considérez les approbations existantes comme provisoires jusqu'à nouvelle vérification.

Gardez la checklist courte et toujours identique. Une checklist de quatre points appliquée de façon constante repère plus de problèmes qu'un long formulaire appliqué inégalement. Conservez aussi les candidates rejetées — elles attestent pourquoi une version de recette a été écartée et évitent au suivant de redécouvrir les mêmes échecs.

Cette boucle est aussi votre levier de maîtrise des coûts. Comme l'approbation est liée à la recette, vous pouvez calculer combien de générations sont nécessaires par asset approuvé et itérer sur les modèles qui consomment le plus d'essais.

Coûts, latence et traitement par lots

Planifiez à partir de vos propres mesures, pas d'hypothèses. Pour les modèles d'image sur HiAPI, la facturation se fait par image de sortie ; la variable qui domine la dépense est donc le « nombre d'essais par asset approuvé » — qui dépend entièrement de la qualité des prompts et de la rigueur de la revue. Les tarifs actuels par image figurent sur la page de tarification du site ; ne figez pas de chiffres dans le code ou les documents budgétaires.

Une méthode de travail raisonnable :

• Mesurez une base de référence. Passez dix SKU avec des recettes approuvées, comptez le total des générations et le total des approbations, et déduisez le nombre d'essais par asset approuvé. Ce ratio en dit plus que n'importe quel benchmark.
• Itérez à l'unité, approuvez puis traitez par lots. L'itération de prompt se fait une image à la fois. Une fois la recette approuvée, traitez par lots avec une concurrence modérée et une stratégie de retry qui journalise les échecs au lieu de refacturer silencieusement.
• Traitez la latence comme un paramètre d'ordonnancement. La génération d'images se compte en secondes, pas en millisecondes. Lancez les tâches en asynchrone, écrivez les résultats dans une file, et laissez les relecteurs traiter la file au lieu de bloquer sur chaque appel.
• Budgétez par ratio, pas par prix unitaire. Une fois le nombre d'essais par asset approuvé connu, l'estimation d'un catalogue devient une simple arithmétique fondée sur vos propres mesures.

Une dernière bonne habitude : versionnez vos recettes et consignez la version de recette dans chaque requête. Cela coûte un champ et transforme « pourquoi cet asset d'il y a un mois est-il différent ? » en une simple requête au lieu d'une enquête.

Mettez en place le pipeline minimal qui vous permet d'exécuter via l'API le détourage, les scènes et les mises en page avec texte, gardez la bibliothèque de prompts versionnée, et laissez la boucle de revue — plutôt que l'espoir — décider de ce qui peut être publié.