Équipes marketing multilingues : comment travailler dans SFMC

‍

Diffuser une campagne dans une seule langue relève de la production de contenu. La diffuser dans sept langues relève de la gestion de données.

La plupart des équipes le découvrent en production. Les traductions arrivent dans les temps, et l’envoi part malgré tout avec la version allemande adressée à l’audience française.

Le problème vient rarement de la traduction. Il vient de la couche audience située en dessous.

‍

Salesforce Marketing Cloud fournit les briques nécessaires : paramètres de locale, culture code, encodage des envois internationaux, data extensions partagées entre business units. En revanche, aucune de ces briques ne centralise la notion de langue.

Celle-ci se retrouve dispersée entre des attributs abonnés, des frontières de business units, des règles de contenu dynamique et des filtres SQL écrits à plusieurs mois d’intervalle par des personnes différentes.

‍

Cet article décrit le fonctionnement réel des équipes multilingues dans SFMC, les endroits où la structure tient, et ceux où elle cède sans bruit.

‍

Ce que multilingue signifie concrètement dans SFMC

‍

La langue est une donnée avant d’être du contenu

Dans SFMC, la langue d’un abonné n’est pas une propriété native de la plateforme. C’est le champ que vous avez décidé d’utiliser pour la stocker.

Cela peut être Language dans une data extension sendable, Country employé comme approximation, ou une valeur de locale héritée d’une source de données synchronisée.

‍

Ce choix devient l’ossature de toutes vos campagnes multilingues ultérieures. Le modifier plus tard revient à réécrire chaque requête qui s’appuyait dessus.

Les équipes qui traitent la langue comme une décision éditoriale, et non comme une décision de modèle de données, finissent avec trois ou quatre versions concurrentes du même champ.

‍

Où la langue est réellement déterminée

Trois endroits reviennent systématiquement : l’audience de l’envoi, le contenu de l’email, et la landing page.

Chacun peut résoudre la langue selon une logique différente, et rien ne les oblige à être cohérents entre eux.

‍

Un email peut s’appuyer sur des blocs de contenu dynamique conditionnés par un attribut abonné. La page qui suit, elle, peut se fonder sur la langue du navigateur.

Salesforce le documente pour les pages de support traduites : elles existent en 21 langues et s’affichent selon la préférence linguistique du navigateur de l’abonné, même lorsque celle-ci diffère de la langue de l’email.

‍

Locale et culture code : qui contrôle quoi

‍

Le culture code concerne le compte et l’utilisateur

Le culture code de Marketing Cloud Engagement définit la langue et les formats par défaut au niveau du compte et de chaque utilisateur.

Il pilote l’affichage des dates et des nombres dans l’interface, et il influence désormais la génération de contenu. Einstein produit des objets et des corps de message en français, allemand, italien, japonais, portugais et espagnol lorsque le culture code de l’utilisateur correspond à une langue prise en charge.

‍

Utile, mais il faut être précis sur la portée. Le culture code décrit l’utilisateur ou le compte, pas l’abonné qui reçoit le message.

Certaines équipes supposent qu’en changeant le culture code d’un utilisateur elles changeront ce que reçoit un contact. En réalité, non.

‍

La locale, elle, décrit l’abonné

L’objet locale dans Marketing Cloud Engagement représente une locale précise et indique la localisation d’un abonné.

Salesforce publie une liste de locales valides pour les envois depuis une data extension, ce qui devient structurant dès lors que vous n’envoyez plus depuis des listes.

‍

Si vos valeurs s’écartent de cet ensemble pris en charge, l’envoi n’échoue pas toujours de façon visible. Il bascule sur une valeur par défaut, et ce basculement passe facilement au travers d’une recette.

‍

Localiser le contenu dans Email Studio

‍

Envois internationaux et encodage

La fonctionnalité International Sends d’Email Studio permet de choisir l’encodage linguistique d’un email et de servir aux abonnés des pages de support traduites.

Salesforce recommande l’Unicode UTF-8 pour la majorité des audiences internationales, tout en précisant qu’un encodage local spécifique peut mieux convenir à tout ou partie d’une base.

‍

L’encodage n’a rien de cosmétique. Salesforce le présente comme affectant à la fois la délivrabilité et la capacité du client de messagerie à afficher correctement les caractères.

Les caractères accentués, les trémas allemands et les alphabets non latins sont les premiers révélateurs d’un encodage mal choisi.

‍

Contenu dynamique ou assets séparés

Deux approches dominent, et les deux se défendent.

• Un email unique avec des blocs dynamiques conditionnés par un attribut de langue
• Un asset email par langue, avec sa propre send definition
• Un modèle hybride : template commun, blocs localisés par marché

‍

Le contenu dynamique limite le nombre d’envois et unifie le reporting. Les assets séparés donnent aux équipes locales une vraie autonomie éditoriale.

L’arbitrage tient généralement à une question simple : vos équipes locales doivent-elles modifier la mise en page, ou seulement les mots ?

‍

Business units et données partagées

‍

Data extensions partagées en Enterprise 2.0

Un programme multilingue est presque toujours aussi un programme multi business units. Les comptes Enterprise 2.0 permettent de partager des data extensions en les stockant dans des dossiers dédiés au partage.

La segmentation entre business units suit un chemin assez stable. Une query ou une filter activity alimente une data extension partagée depuis une source de données synchronisée, puis cette data extension est mise à disposition des unités concernées.

‍

En pratique, c’est dans cette couche partagée que réside la logique d’audience multilingue.

‍

Permissions et fenêtres de partage

Data Extension Permissions détermine ce que chaque business unit peut faire d’une data extension partagée dans Email Studio.

Vous autorisez ou refusez des actions unité par unité, et vous pouvez définir une date de début et de fin de partage.

‍

C’est un vrai levier de gouvernance. C’est aussi une source classique de confusion : une équipe régionale signale une audience « disparue » alors que la cause réelle est une fenêtre de partage arrivée à échéance.

‍

Là où la segmentation multilingue se casse

‍

Le SQL ignore la notion de langue

Une Query Activity n’a aucune notion de dimension linguistique. Elle ne connaît que la colonne que vous lui indiquez.

Une requête qui joint _Open et _Sent pour isoler les contacts engagés renverra donc un résultat multilingue si personne n’a pensé à ajouter le filtre.

‍

Multipliez par le nombre de marchés et par le nombre de requêtes présentes dans votre compte. Le problème cesse d’être anecdotique et devient statistique.

Ce n’est presque jamais une requête cassée. Ce sont cinquante requêtes dont trois ont oublié la clause de langue.

‍

Les filtres de langue dérivent

Les valeurs de langue sont rarement homogènes selon les sources. fr, FR, fr-FR, French et Francais peuvent cohabiter dans une même instance.

Une requête écrite selon une convention exclut alors silencieusement les contacts enregistrés selon une autre.

‍

Les contacts ne sont pas absents. Ils sont simplement invisibles pour cette clause WHERE précise.

‍

Les pratiques qui tiennent dans la durée

‍

Normaliser l’attribut de langue une bonne fois

Choisissez un champ canonique et un format canonique, puis normalisez à l’ingestion plutôt qu’au moment de la requête.

Aligner ce format sur les locales prises en charge par Salesforce pour les envois depuis data extension vous évite une conversion supplémentaire par la suite.

‍

La normalisation à l’ingestion coûte davantage au départ. Elle supprime ensuite toute une famille d’anomalies de segmentation.

‍

Une seule audience, un branchement final

Plutôt que de maintenir sept requêtes quasi identiques, construisez une requête d’audience portant la logique métier, et traitez la langue comme une dernière étape de segmentation.

Quand la définition de l’engagement évolue, vous modifiez une requête au lieu de sept.

‍

Cela rend aussi la relecture possible. Une requête unique avec un branchement linguistique lisible peut être challengée par un marketeur régional, même sans maîtrise du SQL.

‍

Voir QAiry en action

‍

Les équipes multilingues perdent rarement du temps sur la traduction. Elles en perdent sur l’aller-retour entre le marketeur qui connaît son marché et la ressource technique qui détient la requête.

Chaque variante linguistique ajoute un tour de boucle, et c’est ce tour de boucle qui coûte, pas le SQL.

‍

QAiry vous permet de décrire une audience en langage naturel et renvoie du SQL SFMC prêt pour la production, en français comme en anglais, sur vos propres data extensions et data views.

Si vos campagnes couvrent plusieurs marchés, l’exercice vaut le détour : qairy.com/fr/product-demos, ou commencez par qairy.com/fr/try-it-free.