Pourquoi le SQL de SFMC complique la vie des équipes non anglophones

‍

Salesforce Marketing Cloud est utilisé par des équipes marketing dans de nombreux pays. L'interface, le portail d'aide et une bonne partie des formations existent en plusieurs langues.

Le SQL, lui, reste en anglais. Dès qu'une équipe a besoin d'un segment qu'aucun filtre ne sait construire, tout bascule vers des mots-clés, des noms de tables et une documentation en anglais.

‍

Cet article décrit où se situent les frictions pour les équipes qui ne travaillent pas en anglais au quotidien. Il présente aussi des pistes concrètes, sans embaucher une équipe technique plus large.

‍

Pourquoi le SQL reste une compétence anglophone dans SFMC

‍

Une interface localisée, mais des requêtes en anglais

Marketing Cloud Engagement fonctionne en plusieurs langues. Le portail d'aide de Salesforce propose notamment le français, l'allemand, l'italien, l'espagnol, le japonais ou le coréen, et les rapports sont disponibles dans toutes les langues prises en charge.

Une activité de requête SQL, en revanche, ne se traduit pas. SELECT, JOIN et WHERE sont des mots anglais, tout comme le nom des tables système.

‍

Des data views dont il faut retenir les noms

Marketing Cloud expose l'historique d'engagement via des data views comme _Sent, _Open, _Click et _Bounce. Les champs qu'elles contiennent, par exemple SubscriberKey ou EventDate, sont tout aussi figés.

Un marketeur qui raisonne en français doit donc convertir sa question métier dans ce vocabulaire avant d'écrire la première ligne. Pour un développeur, l'effort est minime. Pour tous les autres, il est considérable.

Sur un trimestre, ces conversions représentent de nombreuses heures. Leur coût passe pourtant inaperçu, car il est dilué dans une multitude de petits retards.

‍

Les frictions du quotidien

‍

Une documentation surtout rédigée en anglais

Les modules Trailhead, les guides pour développeurs et les réponses de la communauté sur le SQL sont majoritairement en anglais. Une page d'aide traduite peut expliquer le principe, mais l'exemple trouvé sur un forum correspond rarement à votre modèle de données.

Chercher dans sa langue donne en général moins de résultats, et les meilleures réponses datent souvent de plusieurs années.

Les équipes finissent par copier des extraits qu'elles ne comprennent qu'à moitié. Cela fonctionne jusqu'au jour où un champ change de nom.

‍

Des messages d'erreur dans une langue qu'on n'a pas choisie

Quand une requête échoue, le message est bref et technique. Pour le déchiffrer, il faut à la fois connaître le SQL et maîtriser le vocabulaire technique anglais.

Un développeur y est habitué. Un responsable CRM qui écrit du SQL une fois par mois ouvrira plutôt un ticket.

Le ticket attend alors dans une file, alors que la date de campagne, elle, ne bouge pas. Peu à peu, les marketeurs apprennent à demander des audiences plus simples que celles dont ils ont besoin.

‍

Des limites de plateforme qui rendent l'erreur coûteuse

‍

Peu de marge pour tâtonner

Salesforce documente une durée d'exécution maximale de 30 minutes par requête et recommande de rester sous les cinq minutes. Des plafonds quotidiens existent aussi selon l'édition : 100 requêtes pour Pro, 1 000 pour Corporate et 3 000 pour Enterprise, sous forme de limites souples par identifiant d'entreprise.

Les recommandations suggèrent par ailleurs de ne pas dépasser cinq data extensions par requête et quatre jointures, moins étant préférable. Une équipe qui procède par essais successifs atteindra ces seuils plus vite.

Dépasser une limite souple ne provoque pas toujours une erreur visible. L'automatisation ralentit ou un envoi est retardé, et la cause reste difficile à identifier sans solide expérience du SQL.

‍

Un mauvais segment coûte plus cher qu'une requête en échec

Une requête qui échoue se voit. Une requête qui s'exécute et renvoie les mauvaises personnes passe inaperçue.

Une condition inversée ou une exclusion oubliée suffit à envoyer un message à un public qui n'était pas visé. Le risque augmente quand la personne chargée de relire le SQL ne le lit pas non plus aisément.

La relecture compte donc autant que l'écriture. Un second regard n'a de valeur que s'il peut suivre la logique.

‍

La dépendance cachée envers quelques spécialistes bilingues

‍

Un seul collègue devient le point de passage obligé

De nombreuses équipes internationales s'appuient sur une personne à la fois à l'aise en anglais et en SQL. Chaque demande de segment passe par elle.

Le calendrier des campagnes dépend alors de son agenda, et son absence bloque tout. Ce savoir est rarement documenté dans la langue de l'équipe.

Lorsque cette personne change de poste, l'équipe mesure souvent à quel point son fonctionnement reposait sur une seule tête.

‍

Équipe centrale et équipes locales se comprennent mal

L'équipe CRM centrale écrit souvent les requêtes, tandis que les équipes locales décrivent l'audience dans leur langue. Des nuances se perdent dans les deux sens.

Un « client inactif » peut signifier six mois sans ouverture sur un marché et douze sur un autre. Sans définition partagée, le SQL traduit une supposition.

S'accorder sur les définitions prend du temps au départ, puis en fait gagner beaucoup. Les résultats deviennent en outre comparables d'un marché à l'autre.

‍

Comment réduire la barrière de la langue en pratique

‍

Construire un glossaire d'audiences partagé

Décrivez d'abord chaque audience récurrente en langage courant, dans la langue locale, avec sa règle exacte. Par exemple : les contacts sans ouverture ni clic depuis 180 jours, hors acheteurs récents.

Rattachez ensuite à cette définition le SQL validé ou la Filtered Data Extension correspondante. Le glossaire sert alors de référence commune aux équipes locales et à l'équipe centrale.

Révisez-le chaque trimestre, car les règles métier évoluent. Une définition périmée est pire que l'absence de définition, puisque chacun lui fait confiance.

‍

Standardiser avec des requêtes réutilisables et Automation Studio

Conservez les requêtes testées et planifiez-les dans Automation Studio, afin que les audiences courantes se mettent à jour sans que personne ne les réécrive.

Adoptez une convention de nommage simple pour les data extensions, respectée par tous quelle que soit leur langue. La relecture d'une construction en devient bien plus facile.

Ajoutez une courte note sur l'objectif de chaque requête, dans la langue locale. Vos futurs collègues vous en seront reconnaissants.

‍

Ce que l'IA change dans l'équation

‍

Décrire l'audience plutôt que la coder

Un assistant conversationnel permet de décrire l'audience avec ses propres mots, par exemple les clients qui ont acheté ces 90 derniers jours mais n'ont ouvert aucun e-mail ce mois-ci. L'assistant produit la requête, et le marketeur en vérifie la logique.

La barrière de la langue se déplace ainsi de la syntaxe SQL vers une description simple, c'est-à-dire là où se trouve déjà l'expertise du marketeur.

Un même assistant peut en outre servir plusieurs marchés, puisque la question métier s'exprime naturellement plutôt qu'à travers un vocabulaire imposé.

‍

Garder une relecture humaine

Le SQL généré doit toujours être comparé à la définition visée, puis testé sur un petit échantillon avant l'envoi. L'objectif est de supprimer la saisie, pas le jugement.

Les équipes qui traitent le résultat comme un brouillon à relire gagnent en rapidité sans perdre le contrôle. Avec le temps, les relecteurs apprennent aussi à lire la logique produite, ce qui développe la culture SQL progressivement plutôt que de l'exiger d'emblée.

‍

Voir QAiry en action

‍

Si votre équipe travaille en plusieurs langues et attend encore que quelqu'un écrive ses requêtes SQL, l'alternative mérite un coup d'œil.

Vous pouvez regarder une démonstration sur qairy.com/fr/product-demos ou l'essayer directement sur qairy.com/fr/try-it-free.