Localisation d'e-mails : comment traduire vos campagnes sur les principaux ESP

Je dirige le marketing de cycle de vie, j'ai donc passé une bonne partie de ma vie dans les éditeurs de campagnes, et la localisation d'e-mails est l'aspect que j'ai le plus longtemps sous-estimé. Traduire une page de destination est une tâche toujours identique. Traduire une campagne d'e-mailing est un travail différent pour chaque outil utilisé, car chaque plateforme a sa propre conception de ce qu'est, au fond, une « langue ».

Certaines plateformes traduisent le contenu pour vous. D'autres vous fournissent des emplacements vides à remplir. L'une d'entre elles vous demande même d'écrire une logique conditionnelle directement dans le corps de l'e-mail. Mais derrière ces approches se cache un danger commun : vos textes sont truffés de balises de template qui doivent revenir intactes de la traduction, au caractère près, sous peine de bloquer l'envoi.

Ce guide détaille le fonctionnement réel des principales plateformes, la méthode pour extraire et réimporter vos textes, ainsi que les aspects de la tâche qui restent identiques partout.

Trois façons dont une plateforme d'e-mailing gère les langues

Avant d'entrer dans le détail par plateforme, il est utile de savoir à laquelle des trois architectures vous avez affaire. Elle détermine l'intégralité de votre flux de travail et il est généralement impossible d'en changer.

La ligne intermédiaire correspond à la majorité des programmes multilingues d'envergure, et c'est celle sur laquelle ce guide s'attarde le plus : c'est précisément quand « la plateforme vous fournit une grille de langues vide » qu'un flux de travail de traduction devient indispensable.

Localisation des e-mails dans Braze

Braze repose sur le modèle « baliser et remplir » et présente la syntaxe la plus singulière du lot. Chaque segment traduisible d'un e-mail doit être encadré par une balise Liquid dotée d'un identifiant :

{% translation greeting %}Hello!{% endtranslation %}

La forme générale est {% translation votre_id_ici %}texte par défaut{% endtranslation %}, et les identifiants doivent être uniques au sein d'un message. L'éditeur propose un raccourci pour encadrer une sélection (Cmd+Alt+L sur macOS, Ctrl+Alt+L sur Windows). Braze ne traduit rien par lui-même : vous fournissez les traductions en important un fichier CSV ou via l'API de traduction, laquelle est en accès anticipé au moment de la rédaction de ce guide.

Ces limites documentées prennent toute leur importance dès qu'une campagne devient concrète :

L'imbrication des balises de traduction n'est pas prise en charge. Les paramètres régionaux (locale) proviennent du profil utilisateur, configuré sous Paramètres → Paramètres de localisation, soit à partir des attributs par défaut language et country, soit à partir d'un attribut personnalisé ; si les deux s'appliquent, l'attribut personnalisé prime.

Il est utile de connaître deux particularités de Braze avant de commencer :

L'encadrement d'une URL rompt le suivi des clics, à moins que la partie encadrée ne se termine par ? ou &. Braze documente directement cette solution de contournement :

<a href="https://{% translation id_1 %}example.com{% endtranslation %}?">Shop Now</a>

N'ouvrez pas le fichier CSV de traduction dans Excel. La documentation de Braze elle-même le déconseille en raison de problèmes d'affichage des caractères internationaux. C'est de loin la cause la plus fréquente de corruption d'une localisation Braze à l'insu de tous. La faute n'en revient pas à Braze, mais à Excel : le logiciel tente de deviner l'encodage du CSV et se trompe systématiquement.

Les blocs de contenu de Braze peuvent intégrer leurs propres traductions, ce qui permet de localiser un pied de page partagé une seule fois pour toutes les campagnes. Appelez-les via {{content_blocks.${votre_bloc}}} ; les blocs insérés via Liquid restent liés et se mettent à jour automatiquement, contrairement à ceux ajoutés via le menu déroulant de l'éditeur. Si un bloc ne dispose d'aucune traduction pour une langue donnée, il s'affiche dans sa langue d'origine au lieu de provoquer une erreur.

Si vous préférez utiliser des branchements plutôt que des balises, Braze permet également de procéder manuellement :

{% if ${language} == 'en' %}
English content
{% elsif ${language} == 'es' %}
Spanish content
{% else %}
Fallback content
{% endif %}

Notez qu'au sein d'une balise Liquid, l'attribut s'utilise seul, ${language}, alors qu'il doit être encadré dans le corps du message : {{${language}}}. Braze recommande de toujours inclure une branche {% else %}, car certains utilisateurs n'ont aucune langue définie, utilisent une langue non prise en charge ou disposent d'un appareil dont la langue est indétectable.

Docs : Localisation dans Braze

Localisation des e-mails dans Customer.io

Customer.io a pris le contre-pied : la localisation y est native, intégrée directement à l'éditeur, et propose un bouton de traduction automatique par IA. Vous concevez votre message dans une langue par défaut, puis ajoutez des variantes linguistiques sans multiplier les branches de votre campagne. Cette approche s'applique à l'e-mail, au SMS, à WhatsApp, au push et aux messages in-app.

C'est à vous de choisir le nom de l'attribut de langue. Dans Paramètres de l'espace de travail → Paramètres de langue, vous indiquez à Customer.io quel attribut de profil contient la langue ; il peut s'agir de language, locale ou de n'importe quel terme déjà utilisé par votre CRM. Les valeurs doivent être soit un code à deux lettres (en), soit un couple langue-région séparé par un tiret (en-US). La casse n'a pas d'importance — es-MX et es-mx fonctionnent donc toutes deux — mais le tiret est obligatoire.

La traduction automatique couvre le corps du texte, les objets et le texte de pré-en-tête. Voici en revanche la liste de ce qu'elle ne prend pas en charge, à garder bien en vue :

• Les images, bien qu'elle traduise le texte alternatif
• Les mises en page d'e-mails dans les éditeurs de texte enrichi et de code
• Le texte statique Liquid, les valeurs d'attributs et les valeurs de filtres
• Les snippets
• Le texte des composants personnalisés, sauf si vous détachez le composant au préalable

Ce troisième point mérite un exemple, car c'est le plus piégeux. La propre documentation de Customer.io sur la localisation utilise cette ligne :

Bonjour {{ customer.first_name | default:"ami" }}

Le mot ami sert de valeur de repli si le prénom est manquant. C'est un texte bien réel, visible par vos lecteurs, niché dans un filtre Liquid que la traduction automatique ignore. Si vous envoyez ce message à une audience allemande, une partie de vos destinataires sera saluée par un « ami ». Chaque texte de repli dans chaque filtre default: doit être traduit à la main pour chaque variante, sans que l'interface ne vienne vous le rappeler.

Deux autres contraintes sont à prévoir : les traductions ne se mettent pas à jour automatiquement quand vous modifiez le modèle par défaut, et les tests A/B multilingues fonctionnent pour les envois ponctuels, mais pas pour les diffusions via API ou les automatisations.

Un mot sur les snippets : ce mécanisme de contenu réutilisable ({{snippets.votre_snippet}}, 16 Ko par défaut) est ignoré par la traduction automatique. Customer.io recommande donc d'intégrer les conditions directement au sein du snippet :

{% if customer.language == 'fr' %}
  Se désabonner
{% elsif customer.language == 'de' %}
  Abmelden
{% else %}
  Unsubscribe
{% endif %}

En résumé, une campagne Customer.io repose généralement sur des variantes natives pour le corps des messages, complétées par des conditions gérées manuellement dans chaque snippet partagé. Mieux vaut le savoir avant de s'imaginer que le bouton IA s'occupe de tout.

Docs : Localisation dans Customer.io

Localisation des e-mails dans Klaviyo

La fonctionnalité de Klaviyo s'appelle Smart Translations ; elle permet de traduire automatiquement le contenu des messages dans plus de 60 langues directement depuis l'éditeur de campagnes ou de flux. Vous pouvez l'activer dans Paramètres → Compte → Traduction via le bouton « Traduire les messages ». Elle nécessite un compte payant et n'est pas disponible avec l'essai gratuit.

Les éléments que Klaviyo documente comme étant traduits automatiquement se limitent à une liste précise : blocs de texte, libellés et textes alternatifs. Les objets (subject lines) n'en font pas partie : vérifiez donc ce point dans votre compte avant de supposer qu'une campagne est intégralement couverte.

La détermination de la langue s'appuie par défaut sur la locale du profil, ou à défaut, sur le pays ou la langue si ces informations sont renseignées. Klaviyo accepte les codes BCP-47 (en-GB, es-ES) ainsi que les noms de langues en texte brut comme English ou French.

Deux atouts rendent le travail sur Klaviyo agréable. Le premier est la liste « Ne pas traduire » : elle permet de spécifier, une seule fois au niveau du compte, les noms de marque, de produits ou tout autre terme que le modèle ne doit jamais toucher. La plupart des plateformes n'ont pas d'équivalent, et c'est ce qui permet à votre nom de produit de rester intact à travers dix locales au lieu de se transformer en dix mots différents.

Le second est le menu de remplacement par élément. Pour chaque élément traduit, vous disposez des options Retraduire, Identique à la source, Modifier et Ignorer, et vous pouvez naviguer entre les langues grâce aux flèches en haut de l'éditeur. La révision devient alors un simple passage en revue des éléments signalés plutôt qu'une relecture intégrale.

Klaviyo prend également en charge les cycles d'import-export CSV, la solution idéale si vous travaillez avec des traducteurs ou des outils externes. Dans le menu d'actions sous Traduire, vous trouverez l'option Exporter CSV, disponible aux formats Smartling ou Simple. Le fichier comprend les colonnes block_id (l'identifiant unique de chaque chaîne traduisible), source (le texte original), ainsi qu'une colonne par langue nommée selon son code. Les règles sont strictes et pragmatiques : ne modifiez ni ne supprimez les valeurs block_id, n'ajoutez pas de lignes et ne changez pas les valeurs source.

Une chose surprend souvent les utilisateurs venant de Braze ou Customer.io : Klaviyo n'est pas Liquid. Il utilise la syntaxe de template Django.

{% if person|lookup:'Loyalty Points' > 150 %}
Hey VIP! You've always got free shipping & free returns
{% elif person|lookup:'Loyalty Points' > 0 %}
You have {{ person|lookup:'Loyalty Points' }} points, and you just need 150 to become a VIP!
{% else %}
Have you heard about our VIP program? Join today on our website to start earning rewards.
{% endif %}

Les balises ressemblent suffisamment à Liquid pour vous tromper, et la confusion entre elif et elsif peut vous faire perdre un après-midi. La personnalisation avec une valeur de repli se présente comme {{ first_name|default:'friend' }}.

Docs : Smart Translations de Klaviyo · Syntaxe Django

Localisation des e-mails dans Mailchimp

Mailchimp ne propose aucune fonctionnalité native pour les campagnes multilingues. Il s'appuie à la place sur des balises de fusion conditionnelles ; l'approche documentée consiste à intégrer toutes les langues dans un seul e-mail et à laisser les conditions sélectionner la version appropriée.

*|IF:MC_LANGUAGE=es|*
Spanish content here.
*|ELSEIF:MC_LANGUAGE=de|*
German content here.
*|ELSE:|*
Display English content for everyone else.
*|END:IF|*

*|MC_LANGUAGE|* contient le code de langue du contact et *|MC_LANGUAGE_LABEL|* son nom en clair. Mailchimp tente de détecter la langue via le navigateur de l'abonné ; vous pouvez aussi la définir individuellement dans profil → Paramètres → Langue, ou en masse lors de l'importation. Notez que *|END:IF|* ferme aussi bien les blocs IF que IFNOT.

C'est généralement cette seule limite qui fait pencher la balance. Un e-mail localisé dont l'objet reste dans la mauvaise langue est condamné avant même d'être ouvert, et le contenu n'a alors plus aucune importance. Résultat : la plupart des équipes gérant plus de deux langues sur Mailchimp finissent par créer des campagnes distinctes, et l'approche par balises de fusion conditionnelles ne leur a finalement rien apporté. Mieux vaut le savoir dès la phase de planification plutôt qu'après avoir conçu le template.

Docs : Traduire le contenu dans Mailchimp

Localisation des e-mails dans Iterable

Iterable propose une véritable fonctionnalité de « locales » (paramètres régionaux), et sa documentation est d'une franchise désarmante sur ce que cela implique ou non :

Les locales ne traduisent pas le contenu.

La plateforme fournit la structure des variantes ; à vous de fournir les traductions. En contrepartie, toutes les variantes partagent un même templateId, ce qui permet d'unifier vos indicateurs au lieu de les disperser sur dix templates distincts. Pour quiconque a déjà tenté d'analyser les rapports d'une campagne divisée en copies par langue, cet avantage justifie à lui seul la configuration.

Le champ doit impérativement s'appeler locale. Iterable souligne que si vous utilisez languagePreference ou tout autre nom, le système ne pourra pas associer les utilisateurs aux variantes. Le nommage des locales suit les normes ISO-639 et ISO-3166 (fr-CA, fr-FR), et les codes à trois lettres sont également acceptés. Notez qu**'il est impossible de renommer une locale après sa création** ; définissez donc votre convention de nommage avant d'en créer une vingtaine. Une locale vide reçoit la version par défaut ; en cas de non-correspondance, un paramètre au niveau du projet permet de choisir entre l'annulation de l'envoi et l'utilisation de la version par défaut.

Iterable déconseille également de recourir à une solution « maison » :

Bien qu'Iterable soit une plateforme flexible et que vous puissiez techniquement créer du contenu multilingue avec Handlebars ou Catalog, ces méthodes ne respectent pas les bonnes pratiques de localisation.

Le moteur de template est Handlebars, et les noms de champs sont sensibles à la casse. Une subtilité pourrait vous jouer des tours dans l'éditeur WYSIWYG : les conditions doivent être entourées de commentaires HTML, sous peine d'être corrompues par l'éditeur.

<!--{{#if activeUser}}-->
    <div>Hi active user!</div>
<!--{{else}}-->
    <div>Hi inactive user</div>
<!--{{/if}}-->

Pour le flux d'exportation/importation, l'appel GET /api/templates/email/get permet d'extraire le contenu du template pour les traducteurs.

Docs : Iterable en plusieurs langues

Localisation des e-mails dans Brevo

Brevo fait partie des plateformes qui gèrent la traduction pour vous, et c'est le concurrent le plus direct de Mailchimp sur cette fonctionnalité spécifique. Vous créez une campagne unique qui s'adapte au code langue ou pays du contact, vous cliquez sur Ajouter des langues, et Brevo duplique la campagne pour chaque langue afin que vous puissiez la traduire, manuellement ou avec Aura, son assistant IA.

La liste des éléments modulables par langue est plus étendue que la moyenne : nom de l'expéditeur, objet, texte de prévisualisation, design de l'e-mail, ainsi que l'adresse de réponse, le suivi Google Analytics et une page de désinscription personnalisée. La possibilité de traduire l'objet est le point fort, car c'est précisément ce que Mailchimp ne permet pas de faire.

Les limites documentées : les traductions basées sur des fichiers ne sont pas prises en charge (donc pas d'aller-retour CSV, ce qui exclut Brevo si vous travaillez avec un prestataire de traduction externe), le système ne fonctionne pas avec les campagnes d'A/B testing, et les sections enregistrées doivent être créées pour chaque langue. Les contacts dont l'attribut de langue ne correspond à aucune configuration reçoivent la version par défaut.

Docs : Campagnes multilingues Brevo

Liquid, Handlebars et balises de fusion : les éléments à préserver

Quelle que soit la plateforme utilisée, l'étape de traduction proprement dite comporte une exigence absolue. Votre texte contient de la syntaxe de template, et chaque caractère doit être restitué exactement tel quel. Un {% endif %} traduit, et c'est l'envoi qui échoue.

Voici à quoi ressemble cette syntaxe sur les différentes plateformes présentées dans ce guide :

Trois types d'erreurs expliquent presque tout ce qui peut mal tourner ici.

Le modèle traduit le jeton. Vous obtenez {{ prénom }} ou {% si %}, et l'envoi échoue ou affiche le texte brut. Tout outil sérieux masque les jetons avant que le texte ne parvienne au modèle, puis les restaure ensuite, de sorte que le modèle ne les traite jamais comme des mots.

Le modèle déplace le jeton. L'ordre des mots change légitimement d'une langue à l'autre, il est donc normal qu'un jeton se déplace. Le problème survient lorsqu'il atterrit dans la mauvaise proposition, ou qu'un {% if %} et son {% endif %} se retrouvent dans le désordre. L'emplacement est porteur de sens ; la solution consiste à vérifier que l'ensemble des jetons en sortie correspond à celui de l'entrée, et à relancer le bloc si ce n'est pas le cas.

Le nombre de jetons change. L'oubli d'un jeton est le cas le plus dangereux, car l'e-mail s'affiche tout de même, mais avec un nom ou une branche manquante. C'est pourquoi le comptage est bien plus fiable qu'un simple contrôle visuel.

Et la règle qui s'applique à ces trois cas est la suivante : les branches conditionnelles sont des chaînes de caractères distinctes. Cette ligne contient deux segments de texte indépendants ; si l'on confie l'ensemble d'un seul bloc à un traducteur ou à un modèle, le résultat sera moins bon pour chacun d'eux que si on les lui présentait séparément, avec leur contexte :

{% if ${loyalty_tier} == 'gold' %}Gold members get an extra 10%.{% else %}Join Gold for an extra 10%.{% endif %}

E-mails HTML et tables de chaînes : deux approches bien distinctes

Il y a ici un embranchement qui détermine toute votre configuration, et on ne s'en aperçoit généralement qu'à mi-parcours.

Certains contenus d'e-mails constituent un véritable document : un template HTML, un e-mail généré, un ensemble structuré qui se lit de haut en bas. Vous voulez que ce contenu soit traduit comme une prose suivie, car le titre et le corps du message sont indissociables ; un traducteur qui a les deux sous les yeux prendra de meilleures décisions que s'il ne voyait que l'un ou l'autre.

D'autres contenus d'e-mails constituent une table de chaînes : une liste indexée par des clés où chaque ligne est indépendante. cta_button, subject_line, footer_unsub. Elles s'accompagnent de métadonnées dont l'importance prime sur celle du texte : une clé qui ne doit jamais changer, une note de contexte et, souvent, une limite de caractères, car un objet trop long finit par être tronqué dans la boîte de réception.

Les fichiers CSV de Braze et Klaviyo, ainsi que tous les formats de localisation issus du monde du logiciel (gettext PO, XLIFF), sont des tables de chaînes. Vos templates HTML sont des documents. Traitez une table de chaînes comme un document et vous perdrez les clés ; traitez un document comme une table de chaînes et vous déchiquetterez la prose en fragments décousus.

C'est pourquoi nous avons conçu la prise en charge des fichiers de chaînes dans Transept comme un flux distinct, plutôt que de l'intégrer à l'importation de documents. Un CSV de textes d'e-mails se présente sous forme de grille : clé, source, traduction, avec la limite de caractères affichée par un compteur en temps réel et la note de contexte associée à chaque ligne.

L'intérêt majeur est que le fichier conserve sa structure d'origine à la sortie. Vous exportez le fichier initial traduit, avec vos clés et vos colonnes placées exactement là où la plateforme les attend, plutôt que d'exporter un fichier qu'il vous faudrait ensuite remodeler manuellement.

Ce que nous avons appris en intégrant la prise en charge des e-mails dans Transept

Nous avons lancé l'importation de fichiers de chaînes précisément pour ce workflow, et ce travail a mis en lumière des points que je n'ai jamais vus documentés ailleurs. Voici nos propres constats, issus de notre code et de nos tests.

« 50% off » est, techniquement, une conversion printf

Les chaînes de caractères utilisent souvent des marqueurs printf : %s, %d, %1$s. Si vous les masquez avant la traduction, une regex standard accepte tout le jeu d'indicateurs printf, y compris le drapeau espace (% d insère un espace devant les nombres positifs). C'est une syntaxe printf parfaitement valide, et il est donc tout à fait légitime de l'accepter.

C’est aussi une catastrophe pour les textes marketing. Si le drapeau espace est accepté, 50% off contient une correspondance : % o est interprété comme une conversion octale avec drapeau espace. Il en va de même pour 100% organic. Idem pour Up to 70% off, qui est pourtant la structure la plus fréquente dans les e-mails promotionnels.

Nous avons testé les deux approches :

Masquer % o transforme votre ligne de réduction en un marqueur et livre une phrase mutilée au modèle. Nous refusons délibérément le drapeau espace, et nous n'y perdons rien : aucune table de chaînes réelle ne l'utilise.

La balise de personnalisation de Braze comporte trois accolades fermantes

Nous avons découvert ce cas précis en rédigeant ce guide, ce qui est un excellent argument en faveur de la rédaction de guides.

La syntaxe de Braze est {{${first_name}}}. Comptez les accolades fermantes : celle de l'attribut (}), puis les deux qui ferment la balise de sortie Liquid. Trois à la suite.

La quasi-totalité des analyseurs Liquid effectuent une recherche non gourmande jusqu'au premier }}. Face à {{${first_name}}}, la fermeture intervient une accolade trop tôt : l'analyseur capture {{${first_name}} et laisse une accolade } isolée dans le texte à traduire. Le jeton semble pourtant traité. L'accolade orpheline est envoyée au modèle comme du texte brut, et revient déplacée, dupliquée ou disparue.

{{${first_name}}}, your spring sale starts now

  non-greedy scan  →  token: {{${first_name}}     leftover: "}, your spring sale starts now"
  brace-aware scan →  token: {{${first_name}}}    leftover: ", your spring sale starts now"

C'est précisément ce qui est arrivé au nôtre. Nous avons repéré le problème, l'avons corrigé pour autoriser un niveau d'imbrication au sein du jeton, et avons ajouté la syntaxe exacte de Braze à notre suite de tests. Si vous gérez vos propres outils d'e-mailing, testez-les spécifiquement avec {{${attribute}}}, car la forme simple {{ attribute }} fonctionne parfaitement et dissimule totalement le bug.

Les guillemets à l'intérieur des marqueurs corrompent les réponses JSON

Lorsque vous envoyez un lot de chaînes à un modèle en imposant une réponse au format JSON, un `"` non échappé au sein d'une chaîne de réponse la ferme prématurément et fait sauter le reste du lot. Nous avons rencontré ce problème avec des marqueurs contenant des attributs entre guillemets, et l'avons reproduit dans environ 58 % des essais sur un modèle donné.

La solution ne consiste pas à améliorer les instructions d'échappement dans le prompt, mais à supprimer les guillemets du format de transfert pour rendre l'erreur impossible : le modèle ne traite que des marqueurs sans guillemets, et la forme canonique est restaurée a posteriori. Demander à un modèle de ne pas corrompre le JSON fonctionne la plupart du temps, ce qui constitue le pire profil de fiabilité possible, car les échecs passent inaperçus.

Les entrées « fuzzy » sont un signal, pas une traduction

Si vos chaînes proviennent de fichiers PO gettext, les entrées comportent un marqueur fuzzy signifiant : « ceci a été mis en correspondance automatiquement, un humain ne l'a pas encore validé ». Considérer les entrées « fuzzy » comme des traductions finalisées revient à valider une série de suppositions comme du travail approuvé.

Nous les excluons de l'importation initiale pour les traduire à nouveau, puis nous supprimons le marqueur « fuzzy » lors de l'exportation, car l'entrée a alors été révisée et le marqueur n'a plus lieu d'être.

Bonnes pratiques pour la localisation de campagnes d'e-mailing

Les habitudes qui font la différence entre un programme fluide et un processus laborieux, classées approximativement selon l'ampleur des tracas qu'elles permettent d'éviter.

Définissez vos codes de langue une fois pour toutes, au niveau du profil. Qu'ils soient à deux lettres ou spécifiés par région, ils doivent être cohérents partout. La plupart des incidents où « la traduction ne s'affiche pas » proviennent d'un profil nl-BE associé à un message nl.

Donnez du contexte pour chaque chaîne avant de l'envoyer en traduction. Un traducteur qui voit Shop the sale dans une feuille de calcul n'a aucune idée s'il s'agit d'un bouton, d'un titre ou d'un lien, ni qu'il dispose de seulement dix-huit caractères. Toutes les plateformes proposant un champ de contexte ou de description vous demandent l'élément qui améliore le plus la qualité du résultat, et pourtant, presque personne ne le remplit.

Faites des limites de caractères une contrainte prioritaire. L'allemand est environ 1,5 à 2 fois plus long que l'anglais. Un CTA qui tient en anglais risque de déborder, et un objet d'e-mail parfaitement calibré peut se retrouver tronqué en plein milieu d'un mot dans la boîte de réception. Transmettez la limite avec la chaîne pour que la personne qui traduit puisse voir le compteur.

Établissez une liste de termes à ne pas traduire. Noms de produits, termes de marque, noms de fonctionnalités. Klaviyo intègre cette fonction ; sur d'autres plateformes, cela se gère dans votre glossaire. Dans tous les cas, fixez cette liste avant le premier envoi, plutôt que d'attendre de découvrir votre nom de produit décliné en six variantes.

Traduisez les valeurs de repli. Chaque filtre default:, chaque branche {% else %}, chaque « Bonjour » qui s'affiche lorsque le nom est manquant. Ce sont des chaînes qui n'apparaissent jamais dans un aperçu et ne sont donc jamais révisées, alors qu'elles sont envoyées aux destinataires sur lesquels vous avez le moins d'informations.

Réutilisez vos décisions d'un envoi à l'autre. Le contenu des campagnes se répète sans cesse : le même pied de page, la même mention de désabonnement, la même accroche saisonnière chaque année. Une mémoire de traduction vous permet de valider une fois pour toutes « Profitez des soldes » et de conserver cette version pour toutes les campagnes suivantes, au lieu de vous retrouver avec trois variantes parce que trois processus différents ont abouti à trois choix distincts.

Effectuez un envoi de test dans chaque langue avant l'envoi réel. Générez le modèle avec un profil réel pour chaque langue. Des structures conditionnelles qui semblent correctes dans l'éditeur peuvent comporter des erreurs que seul le rendu final permet de déceler ; c'est l'étape qui permet de repérer une valeur de repli non traduite ou une branche corrompue tant qu'il est encore temps de corriger sans frais.

Foire aux questions

Qu'est-ce que la localisation d'e-mails ?

La localisation d'e-mails consiste à adapter une campagne d'e-mailing à une autre langue et à un autre marché : le contenu, l'objet et le pré-en-tête, les valeurs de repli de personnalisation, ainsi que les conventions de formatage de la région cible. Elle se distingue de la simple traduction car un e-mail contient une syntaxe de modèle (balises de fusion, structures conditionnelles Liquid ou Handlebars) qui doit rester intacte, tout en imposant des contraintes — comme la longueur de l'objet — que la traduction doit impérativement respecter.

Quelles plateformes d'e-mailing traduisent les campagnes automatiquement ?

Klaviyo (Smart Translations, plus de 60 langues), Customer.io (traduction automatique par IA pour les e-mails, SMS, WhatsApp, notifications push et messages in-app) et Brevo (via son assistant Aura) génèrent des traductions directement dans l'éditeur. Braze et Iterable fournissent une structure de localisation mais comptent sur vous pour fournir les traductions. Mailchimp ne dispose d'aucune fonctionnalité native pour les campagnes multilingues et s'appuie sur des balises de fusion conditionnelles.

Puis-je traduire l'objet d'un e-mail Mailchimp ?

Non. La documentation de Mailchimp précise qu'il est impossible de traduire l'objet, car les balises de fusion conditionnelles ne fonctionnent pas dans ce champ. Pour envoyer des objets localisés avec Mailchimp, vous devez créer une campagne par langue, segmentée selon le champ de langue du contact.

Comment empêcher la traduction d'altérer mes balises Liquid ?

Masquez les jetons avant que le texte n'atteigne le modèle de traduction pour qu'il ne les traite jamais comme des mots. Restaurez-les ensuite et vérifiez que l'ensemble des jetons en sortie correspond à celui en entrée avant de valider le résultat. Traduire chaque branche conditionnelle comme une chaîne distincte, plutôt que de soumettre l'intégralité de la ligne {% if %}...{% endif %} d'un seul bloc, améliore également la qualité, car chaque branche est ainsi traduite comme la phrase autonome qu'elle est.

Quelle est la différence entre un e-mail HTML et une table de chaînes ?

Un e-mail HTML est un document : il s'agit d'une prose structurée et suivie, qu'il est préférable de traduire dans son ensemble pour maintenir la cohérence contextuelle entre le titre et le corps du texte. Une table de chaînes est une liste indexée par des clés où chaque ligne est indépendante, comportant une clé immuable, généralement une note de contexte et souvent une limite de caractères. Les exports CSV de Braze et Klaviyo, les fichiers PO de gettext et le format XLIFF sont tous des tables de chaînes. Ces deux formats requièrent des approches différentes : traiter une table de chaînes comme un document fait perdre les clés, tandis que traiter un document comme une table de chaînes fragmente la prose.

Dois-je utiliser l'export CSV ou l'API de la plateforme pour les traductions ?

Le format CSV est la solution la plus pratique lorsqu'une personne ou un prestataire externe se charge de la traduction ; c'est d'ailleurs la méthode documentée par Braze et Klaviyo. Un flux via API est préférable lorsque le processus s'effectue de manière régulière ou que le volume est tel que la gestion manuelle des fichiers devient un goulot d'étranglement. Braze propose une API de traduction (en accès anticipé au moment de la rédaction) et Iterable expose le contenu de ses modèles via GET /api/templates/email/get. Brevo ne prend en charge aucune de ces deux options : il ne permet pas la traduction par fichier, ce qui oblige à traduire les campagnes directement dans l'interface.

Combien de langues une seule campagne d'e-mailing peut-elle prendre en charge ?

Cela dépend de la plateforme. Braze autorise jusqu'à 200 paramètres régionaux par espace de travail et 200 balises de traduction par message. Klaviyo couvre plus de 60 langues grâce à Smart Translations. Customer.io accepte plusieurs centaines de codes de langue et de région. En pratique, la contrainte réside rarement dans les limites de la plateforme ; elle tient plutôt au nombre de langues que vous pouvez faire réviser et maintenir à jour à mesure que le texte source évolue.