Claude Opus 5.5 pour l'e-commerce : rédaction de fiches produits et réponses au service client

Sur la fiche modèle de hiapi, claude-opus-5-5 indique text à la fois pour les modalités d'entrée et de sortie — aucune génération d'images, aucune mention d'entrée d'images. Donc quand une demande mentionne « photos produits », la réponse honnête est la même qu'avec n'importe quel LLM purement textuel : ce n'est pas le bon outil. Ce qu'il réussit vraiment dans une boutique en ligne, c'est l'écriture : descriptions de produits, textes de fiches produits et réponses au service client. Il possède aussi un paramètre reasoning que la plupart des gens n'ont jamais touché, et ce paramètre a un effet secondaire concret et facturé qu'il vaut la peine de connaître avant de le brancher dans une chaîne de production. Voici quatre appels réels à l'API hiapi, avec de vraies sorties, de vrais comptages de tokens, et un piège découvert à ses dépens.

Le paramètre reasoning.effort, et ce qu'il vous apporte réellement

La fiche modèle de claude-opus-5-5 liste cinq niveaux de reasoning effort : low, medium, high, xhigh, max. La structure de la requête est la suivante :

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "high"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Write a 60-word product description. No superlatives."},
      {"role": "user", "content": "Product: insulated water bottle. 750ml, stainless steel, double-wall vacuum insulation, leak-proof lid, matte finish. Keeps drinks cold 24h, hot 12h."}
    ]
  }'

Deux autres structures de requête semblent également plausibles, mais elles échouent toutes les deux : le champ de premier niveau reasoning_effort et le bloc natif Anthropic thinking: {"type": "enabled", "budget_tokens": ...} retournent tous deux invalid_request. Sur cette route, la seule structure valide est reasoning: {"effort": "..."}.

L'hypothèse de départ était : un niveau d'effort plus élevé coûte plus de tokens en échange d'une réponse plus réfléchie. Avec exactement le même prompt de description de 60 mots, à max_tokens: 500, envoyé successivement avec minimal (non documenté, voir plus bas), low, medium, high et max, le résultat est tout autre :

effort	prompt_tokens	completion_tokens	finish_reason
minimal	130	499	stop
low	130	499	stop
medium	130	499	stop
high	130	499	stop
max	130	499	stop

Chaque niveau a facturé pour le même prompt exactement 499 completion tokens. Pas à peu près — exactement pareil. Ce qui change vraiment, c'est le contenu écrit :

minimal : Restez hydraté où que vous soyez avec cette bouteille en acier inoxydable de 750 ml. La double paroi isotherme garde vos boissons fraîches 24 heures et chaudes 12 heures, pour que votre eau reste fraîche du sentier à la salle de sport. Le couvercle étanche scelle bien dans le sac à dos, la finition mate résiste aux rayures et reste bien en main. Sans BPA, durable, adaptée à chaque entraînement et à chaque aventure en plein air.

high : Bouteille isotherme en acier inoxydable, 750 ml. Conçue pour les longs sentiers et les entraînements prolongés. La double paroi en acier inoxydable garde vos boissons fraîches 24 heures ou chaudes 12 heures, pour que votre eau reste fraîche jusqu'à la dernière gorgée. Le couvercle étanche se ferme bien dans un sac à dos ou un sac de sport. La finition mate résiste à l'usure et aux mains moites. 750 ml suffisent pour tout un trajet à vélo sans vous alourdir.

high ajoute une ligne de titre en gras et réorganise l'ordre des arguments ; minimal entre directement dans les arguments. Les deux tiennent en 60 mots, respectent tous deux la règle « pas de superlatifs », et coûtent la même chose. low et medium se situent entre les deux, avec une structure de moins en moins marquée. Remarquez que minimal ne figure pas dans les cinq niveaux documentés — il n'est pas rejeté, mais considérez les valeurs non documentées comme non prises en charge et ne vous appuyez pas dessus en production ; utilisez l'un des cinq niveaux listés (low/medium/high/xhigh/max).

La vraie leçon : reasoning.effort change le style, pas le prix. Avec un max_tokens fixe, le coût dépend de la limite que vous fixez, pas de la chaîne d'effort. Si vous budgétez votre chaîne de rédaction par niveau d'effort en pensant que low est l'option bon marché, ce n'est pas le cas — max_tokens est le seul levier qui change la facture.

Le piège : le reasoning consomme silencieusement votre budget max_tokens

La découverte « le coût dépend de max_tokens » a un effet secondaire aigu. claude-opus-5-5 effectue un raisonnement interne avant d'écrire sa réponse visible, et ce raisonnement interne partage la même limite max_tokens que la réponse elle-même. Si vous augmentez l'effort sans relever la limite, le modèle peut épuiser son budget en pleine réponse — ou avant même d'avoir écrit quoi que ce soit de visible.

Premier cas : un prompt de rédaction ordinaire avec effort: xhigh et max_tokens: 500 :

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 500,
    "reasoning": {"effort": "xhigh"},
    "messages": [
      {"role": "system", "content": "You are an e-commerce copywriter. Given a product spec, write a title (max 70 characters), 3 bullet features, and a 2-3 sentence description. No superlatives, no exclamation marks."},
      {"role": "user", "content": "Product: insulated travel mug. Material: 18/8 stainless steel, double-wall vacuum insulation. Capacity: 16oz. Lid: leak-proof slide lock. Keeps drinks hot 6 hours, cold 12 hours."}
    ]
  }'

La réponse réelle, non éditée — elle s'est coupée en pleine phrase :

Titre : Mug de voyage isotherme en acier inoxydable 16 oz avec couvercle à glissière étanche

Caractéristiques :

• Chaud et froid : La double paroi sous vide garde vos boissons chaudes 6 heures et froides 12 heures.
• Construction durable : Fabriqué en acier inoxydable 18/8, résistant à la rouille et sans rétention d'odeurs.
• Couvercle étanche : Le loquet à glissière scelle l'ouverture, vous pouvez jeter le mug dans votre sac sans craindre les fuites.

Description : Ce mug de voyage de 16 oz à double paroi sous vide garde votre café chaud toute la matinée, ou votre

finish_reason: "length", 500 completion tokens facturés, et la subordonnée de la description s'arrête net à « ou votre » — aucune ponctuation finale, aucune erreur, aucun champ d'avertissement. Une chaîne qui ne vérifie que le HTTP 200 publierait cette demi-phrase directement sur la fiche produit.

Le second cas est pire : un prompt de réponse au service client avec max_tokens: 300 et le reasoning par défaut a renvoyé une réponse totalement vide.

{
  "finish_reason": "length",
  "usage": {"prompt_tokens": 157, "completion_tokens": 300, "total_tokens": 457},
  "message": {"content": "", "reasoning_details": [{"text": "", "type": "reasoning.text"}]}
}

content est une chaîne vide. Le champ reasoning_details confirme la cause : le modèle a dépensé tout le budget de 300 tokens en raisonnement interne ("text": "" — même la trace de raisonnement n'est pas exposée, seulement un bloc opaque signature chiffré), sans espace restant pour écrire la réponse proprement dite. hiapi a tout de même facturé l'intégralité des 300 completion tokens pour cet appel — que la réponse visible existe ou non, vous payez pour la réflexion.

Le correctif est le même dans les deux cas : fixez max_tokens avec une vraie marge au-dessus de ce que demande la réponse visible, surtout avec un effort high/xhigh/max. Et ne croyez pas non plus que finish_reason: "stop" prouve une bonne réponse — avant d'écrire en base, vérifiez que content n'est pas vide et exprime bien une idée complète.

Cas d'usage : rédaction de réponses au service client

Donnez-lui votre politique et un vrai message client :

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 400,
    "reasoning": {"effort": "medium"},
    "messages": [
      {
        "role": "system",
        "content": "You are a customer support agent for an online water bottle store. Policy: 30-day return window from delivery. Manufacturing defects reported after the window should be referred to the manufacturer'\''s own warranty. Reply in under 100 words, empathetic but concise, end with a clear next step."
      },
      {
        "role": "user",
        "content": "I bought a water bottle 35 days ago and the seal is already leaking. Can I get a refund or exchange?"
      }
    ]
  }'

La réponse réelle, non éditée :

Je suis désolé d'apprendre le problème de fuite. Comme 35 jours se sont écoulés, la commande dépasse notre fenêtre de retour de 30 jours, je ne peux donc pas procéder à un retour ou à un échange de notre côté. Beaucoup de marques de bouteilles d'eau offrent une garantie sur les défauts de jointure en usage normal, je vous conseille donc de contacter directement le fabricant. Si vous me donnez votre numéro de commande, je peux vous fournir les coordonnées de la marque pour vous aider à faire valoir votre demande.

Il a correctement appliqué la clause exacte de la politique — 35 jours dépassent la fenêtre de 30 jours, il a donc refusé le retour direct et renvoyé vers la garantie fabricant, au lieu de s'excuser simplement puis d'accorder quand même un remboursement. 277 completion tokens, finish_reason: "stop", réponse complète, sans troncature. C'est le même modèle, le même compte, le même effort medium que dans le tableau de rédaction ci-dessus — la différence ici, c'est que max_tokens: 400 lui a laissé assez de place pour raisonner et répondre à la fois.

Les capacités visuelles fonctionnent, même si la fiche modèle dit le contraire

Une autre surprise vérifiée sur le terrain : la fiche modèle de claude-opus-5-5 liste Input modalities: text — nulle part il n'est question d'entrée d'images. Et pourtant, lui envoyer une image fonctionne :

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 150,
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "In one sentence, what is in this photo?"},
        {"type": "image_url", "image_url": {"url": "https://example.com/photo.jpg"}}
      ]
    }]
  }'

La réponse réelle, non éditée (tronquée par le même mécanisme max_tokens que plus haut — 150, ce n'est pas assez) :

C'est une photo à plat soignée d'accessoires masculins du quotidien, disposés sur une surface grise, comprenant un portefeuille zippé noir, une paire de lunettes de soleil aviateur, un nœud papillon en tweed, un carnet

Il a correctement lu la photo. La mention de modalité « text » sur la fiche modèle est fausse pour cette route, ou du moins incomplète — le même schéma « la fiche ne correspond pas à la réalité » que l'article sur claude-opus-4-8 a rencontré sur ses déclarations de capacités visuelles. Ne construisez pas de chaînes qui s'appuient sur les listes de modalités publiées pour se restreindre ; comme pour le paramètre reasoning ci-dessus, envoyez de vraies requêtes et lisez de vraies réponses.

Note sur les coûts

Neuf appels réels, tous facturés sur la route unique claude-opus-5-5 (il n'existe pas de variante -aws ou autre tarification pour ce modèle, contrairement à claude-opus-4-8), au tarif de la page de tarification hiapi de 2,02 $ par million de tokens d'entrée et 10,08 $ par million de tokens de sortie :

appel	prompt_tokens	completion_tokens	coût
tableau effort × 5 (minimal/low/medium/high/max)	650	2 495	0,0264 $
piège de troncature xhigh	185	500	0,0054 $
piège de réponse vide	157	300	0,0033 $
réponse au service client	3 590	277	0,0100 $
test visuel	690	150	0,0029 $
total	5 272	3 722	0,0482 $

Ici, aucune génération d'images — claude-opus-5-5 ne génère pas d'images, donc chaque dollar ci-dessus est un coût de tokens, et les deux lignes « piège » méritent un budget supplémentaire : elles ont payé le prix réel de sorties tronquées ou totalement vides.

Questions fréquentes

claude-opus-5-5 peut-il générer des photos produits ? Non. Sa fiche modèle liste des modalités d'entrée et de sortie uniquement textuelles, et chaque réponse ci-dessus est du texte. Si la tâche consiste réellement à générer de nouvelles photos produits, il faut un modèle de génération d'images, pas celui-ci.

Un reasoning.effort plus élevé coûte-t-il plus cher ? En soi, non. À max_tokens fixe, les cinq niveaux documentés testés ci-dessus ont facturé exactement le même nombre de completion tokens — l'effort change l'écriture, pas le nombre de tokens. Ce qui coûte vraiment plus cher, c'est d'augmenter max_tokens pour laisser aux niveaux d'effort supérieurs la place de raisonner et de répondre à la fois.

Pourquoi ai-je obtenu une réponse vide sans erreur ? max_tokens était trop bas pour le raisonnement interne que le modèle effectue avant d'écrire. Ce n'est pas un bug — finish_reason affiche "length", vous payez quand même la totalité des tokens, mais content peut revenir vide ou tronqué. Vérifiez toujours que content est non vide et complet, et pas seulement que l'appel a renvoyé 200.

Prend-il réellement en charge les entrées d'images ? Oui, confirmé en envoyant une vraie image dans la requête ci-dessus et en obtenant une description exacte — même si sa propre fiche modèle liste text comme seule modalité d'entrée.

Pour commencer

Pour essayer vous-même : il vous faut une clé API hiapi, la page modèle claude-opus-5-5 (pour consulter la tarification actuelle et la liste complète des reasoning-effort), et si vous comparez des modèles purement textuels pour les mêmes charges de rédaction e-commerce et de service client, l'article sur claude-opus-4-8 couvre le même sujet sur la génération Opus précédente — avant de basculer une chaîne de production, il vaut la peine de vérifier si le compromis max_tokens/reasoning ci-dessus justifie la mise à niveau.