Claude pour traduire et localiser ton catalogue ecommerce

Ce blog existe en trois langues, et l’erreur qui m’a pris le plus de temps à repérer n’était pas de traduction. C’était de recherche. Une de mes pages anglaises était impeccablement écrite et ne recevait aucune impression, parce que j’avais traduit le mot-clé espagnol au lieu de chercher ce que tape vraiment quelqu’un au Royaume-Uni. La phrase était juste. Le terme n’existait pas.

Dans un catalogue ecommerce, ce raté se multiplie par le nombre de références, et il ne voyage jamais seul : tailles qui ne correspondent pas, prix mal ponctués, délais de rétractation copiés d’une autre réglementation. Ce billet raconte comment j’utilise Claude pour traduire et localiser du contenu ecommerce à grande échelle sans produire la copie plate qui se repère à la lecture. Ce n’est pas le guide de content ops, ni la configuration des marchés Shopify. C’est la partie qualité.

En 30 secondes :

• Traduire change les mots. Localiser change ce qu’il y a dedans : unités, tailles, devise, délais légaux et saison.
• Google ne considère les versions localisées d’une page comme des doublons que si son contenu principal n’est pas traduit.
• Un mot-clé traduit n’est pas un mot-clé recherché, et cet écart décide si la page traduite reçoit du trafic.
• Le glossaire de termes verrouillés évite le plus d’erreurs dès que tu passes de vingt fiches à deux mille.
• L’API de lots accepte 100 000 requêtes à moitié prix : le goulot n’est plus la génération, c’est la relecture.

Quelle différence entre traduire et localiser un catalogue ?

Traduire change la langue. Localiser change les données contenues dans le texte pour qu’elles restent vraies sur le marché visé. Distinction ennuyeuse, jusqu’au jour où tu la vois casser en production.

Un exemple d’une boutique de mode que j’ai auditée, qui vendait en France et au Royaume-Uni : les fiches anglaises indiquaient « size 38 » parce que la fiche d’origine disait « taille 38 ». Grammaticalement parfait. Commercialement, un retour garanti : le système britannique ne correspond pas. Personne n’a vérifié ce champ parce que le texte se lisait bien.

Avant de toucher à quoi que ce soit, je sépare le contenu en deux : ce qui se traduit et ce qui se convertit. Le premier est de la prose et supporte la liberté. Le second est une donnée : il lui faut une règle explicite par marché. Mélange les deux dans le même prompt et le modèle aura raison la plupart du temps, ce qui dans un gros catalogue est précisément le problème.

Qu’est-ce qui casse quand tu traduis mot à mot ?

Tout ce qui n’est pas de la prose. La description longue survit. Ce qui ne survit pas, ce sont les champs qui portent une donnée : une taille, une mesure, un délai, un prix, parce que le texte se traduit aussi bien pendant que la donnée cesse d’être vraie sur le marché visé.

La ligne saisonnalité a l’air anecdotique. C’est celle que j’ai le plus vu saboter un lancement : si tu vends en France et en Australie depuis le même catalogue, tes soldes d’été arrivent dans un pays en plein hiver. Le modèle traduit « été » par « été » parce que tu le lui as demandé. Inverser le calendrier, c’est ta décision.

Les retours portent un autre risque, plus coûteux. Un délai de rétractation n’est pas du copy : c’est une obligation en forme de phrase. Je la sors du flux automatique.

Comment monter le flux pour un catalogue entier ?

Avec quatre pièces : un glossaire figé, un prompt avec de vrais exemples, un traitement par lots et un diff relisible. Dans cet ordre, chacune dépendant de la précédente.

1. Fige le glossaire avant de traduire la première fiche. Noms de produits, matériaux propriétaires, collections, allégations réglementées et tout terme identique dans toutes les langues. Ce fichier entre dans chaque requête.
2. Écris les règles de conversion par marché. Tailles, unités, format de prix, saisonnalité : la règle notée, pas supposée.
3. Construis le prompt à partir d’exemples, pas d’adjectifs. La documentation d’Anthropic est directe : les exemples sont l’un des moyens les plus fiables d’orienter le format, le ton et la structure de la sortie, et elle recommande d’en inclure trois à cinq. Trois fiches déjà validées valent mieux qu’un paragraphe sur ton ton de voix.
4. Structure l’entrée avec des balises XML. Le même guide explique qu’elles aident le modèle à interpréter sans ambiguïté des prompts qui mélangent instructions, contexte, exemples et données variables. Un <glossaire>, un <regles_marche> et une <fiche> par requête.
5. Traite par lots. L’API de lots est plafonnée à 100 000 requêtes ou 256 Mo par lot, la plupart finissent en moins d’une heure et coûtent moitié prix.
6. Sors un diff relisible, pas un nouveau CSV. Source et traduction côte à côte, champs convertis signalés. Si ça ne se lit pas en diagonale, personne ne le relira.

Un détail de coût : si tu répètes le même bloc de glossaire dans chaque requête, le prompt caching réutilise ce préfixe et réduit temps de traitement et coût. Sa durée par défaut est de cinq minutes, donc ça ne paie que si tu enchaînes. Le reste de la machinerie est dans mon guide Claude pour le content ops en ecommerce.

Pourquoi le glossaire est-il la pièce la plus rentable ?

Parce que c’est la seule chose qui empêche le même concept d’être traduit de trois façons sur trois fiches consécutives. Un modèle n’a pas de mémoire entre requêtes indépendantes, et dans un lot de deux mille appels parallèles, chacun décide dans son coin.

Dans un catalogue de décoration, j’ai vu la même finition en « brushed brass », « burnished brass » et « antique brass » au sein d’une seule famille. Les trois se défendaient. Le problème n’était pas la qualité : le filtre de la page collection a cassé, l’attribut n’ayant plus de valeur unique.

Mon glossaire tient en trois blocs :

• Verrouillé. Termes qui ne se traduisent jamais. Marque, collection, matériau propriétaire.
• Fixé. Termes qui se traduisent, mais avec une seule traduction validée par langue. Finitions, tissus, catégories et tout ce qui alimente un filtre de navigation.
• Interdit. Mots que je ne veux pas voir en sortie, calques et faux amis déjà repérés.

Le troisième bloc grossit le plus vite : c’est la façon la moins chère que je connaisse de transformer le retour du relecteur en règle permanente. Toute correction qui revient deux fois devient une ligne. La troisième fois, elle n’arrive plus jusqu’au relecteur.

Faut-il encore un relecteur natif ?

Oui, et pas par méfiance envers le modèle. L’erreur qui va te coûter de l’argent n’est pas la faute de grammaire, qui se voit, mais celle qui se lit parfaitement sans correspondre à ce que ta catégorie appelle ainsi sur ce marché.

Alors, que repère un natif qu’un modèle bien briefé ne repère pas ? Le registre, surtout. Si ta marque tutoie en français et que la traduction allemande sort le « Sie » d’une banque privée, aucune phrase n’est fausse et le ton est raté. Il repère aussi la convention de catégorie : comment le métier nomme une chose face à ce qu’elle est. Et l’allégation qui ici relève du marketing et là-bas frôle le réglementé.

Mon approche : échantillonnage stratifié. Cent pour cent des gabarits et du texte légal, cent pour cent des pages catégorie parce qu’elles concentrent le trafic, un échantillon par famille sur les fiches. Si une famille remonte trois corrections, elle est relue en entier.

Ça dépend de la ressemblance entre tes fiches. En mode, avec des descriptions gabarisées, l’échantillonnage marche. En produit technique, il faut relire nettement plus.

Et le SEO des pages traduites ?

Il leur faut deux choses que la traduction ne donne pas : leur recherche de mots-clés propre et des hreflang bien posés.

La bonne nouvelle d’abord. Google est explicite : les versions localisées d’une page ne sont considérées comme des doublons que si le contenu principal de la page n’est pas traduit. Traduire vraiment le corps ne crée pas de duplication. Ce qui en crée, c’est traduire le gabarit et laisser le contenu en langue source, ce qui arrive quand on « internationalise » une boutique en changeant menu et pied de page.

La même documentation indique trois façons de les déclarer, HTML, en-têtes HTTP et sitemap, et que chaque version linguistique doit se référencer elle-même en plus de toutes les autres. Cet autoréférencement est le défaut que je croise le plus. La configuration Shopify est traitée dans Shopify international : hreflang, marchés et traductions. Google recommande aussi d’éviter les redirections automatiques d’une version linguistique vers une autre.

Et la partie inconfortable. Le mot-clé de ta page traduite ne devrait pas sortir du traducteur. Je traite chaque marché comme un nouveau site : recherche propre, puis la traduction s’écrit autour de ce terme. C’est la différence entre une page traduite et une page qui se positionne. Même logique pour les meta descriptions à l’échelle : le snippet affronte des résultats locaux, pas la traduction du snippet espagnol.

Une raison de plus de ne pas tout automatiser. Les règles anti-spam de Google incluent, au titre de l’abus de contenu à grande échelle, le fait de générer beaucoup de pages via des transformations automatisées comme la synonymisation ou la traduction quand elles apportent peu de valeur. La lecture pratique n’est pas « n’utilise pas l’IA » : c’est que la valeur doit être là. Au niveau page, j’ai le SEO des fiches produit Shopify et le SEO des pages collection.

Questions fréquentes

Google pénalise-t-il le contenu traduit par IA ?

Pas pour l’usage de l’IA. Ses règles anti-spam visent la génération de nombreuses pages par transformations automatisées, traduction comprise, quand la valeur apportée est faible. La différence tient à ceci : la page répond-elle vraiment à la requête sur ce marché ? Traduction relue et localisée : aucun souci. Production de masse non relue : risque réel.

Puis-je réutiliser le même mot-clé traduit dans chaque langue ?

Ça marche rarement. Le terme le plus cherché sur le marché visé diffère souvent de la traduction littérale, et parfois ce n’est même pas le mot que tu choisirais. Fais ta recherche par marché et écris la traduction autour de ce terme. Sinon tu obtiens une page correcte que personne ne cherche.

Combien coûte la traduction d’un gros catalogue avec Claude ?

Ça dépend de la longueur de tes fiches et du modèle : tout chiffre annoncé sans voir ton catalogue est inventé. Ce qui est fixe : l’API de lots coûte moitié prix et accepte 100 000 requêtes par lot. D’expérience, le coût dominant devient le temps de ton relecteur natif.

Traduire le titre et la meta description suffit-il ?

Non. Google précise que les versions localisées ne comptent comme doublons que si le contenu principal n’est pas traduit, et c’est ce qui arrive si tu ne traduis que métadonnées et gabarit. Une fiche avec un titre français et un corps espagnol convertit très mal. Traduis le contenu principal ou ne publie pas cette version.

Que relire en premier si je ne peux pas tout relire ?

Dans cet ordre : texte légal et retours, gabarits partagés, pages catégorie, puis un échantillon par famille de produits. Gabarits et catégories se répètent sur des milliers d’URL : une erreur y est multipliée. Une fiche mal traduite coûte une vente ; un gabarit, le marché.

Traduire, c’est la partie bon marché

Traduire un catalogue a cessé d’être le goulot d’étranglement. Un lot bien monté te rend deux mille fiches en une après-midi. Ce qui coûte encore, c’est le reste : règles par marché, glossaire à maintenir vivant, relecture de ce qui doit l’être, recherche de mots-clés refaite dans chaque langue.

C’est pour ça que je me méfie de ceux qui vendent « on traduit ta boutique avec l’IA en une semaine ». La traduction se fait en une après-midi. La localisation est un projet : hreflang, recherche par marché et relecture native en constituent l’essentiel. Quand on saute ces étapes, le résultat se repère vite : des fiches qui se lisent bien, ne se positionnent sur rien et génèrent des retours de taille. Avant de t’étendre, l’audit SEO Shopify avec Claude est un bon départ.

Sur mon site, la règle n’a pas bougé en trois langues : rien ne se publie sans un mot-clé recherché dans cette langue et sans relecture complète par quelqu’un qui parle comme ça. Si tu veux que je regarde ton catalogue multilingue, ton hreflang et ton flux de traduction, réserve 30 minutes de consulting et on le voit ensemble.