Comment les équipes marketing françaises utilisent l'IA dans SFMC

‍

En France, Salesforce Marketing Cloud se pratique dans un cadre bien particulier. Les tables portent des noms anglais, la documentation est surtout en anglais, mais les campagnes se rédigent en français.

Cet écart entre la langue de l'outil et celle des équipes pèse sur le quotidien plus qu'on ne le reconnaît.

‍

Les assistants d'IA commencent à le réduire. Voici où les équipes francophones perdent du temps dans SFMC, et ce que change une approche conversationnelle.

‍

Nous passerons en revue les points de friction, le rôle du SQL, la forme d'une demande en français et la manière de déployer l'approche sans risque.

‍

Où les équipes françaises perdent du temps

‍

Un outil en anglais pour un travail en français

Email Studio, Automation Studio et Journey Builder affichent des libellés et des tables système en anglais. La documentation Salesforce suit la même logique.

Un responsable marketing raisonne en « clients inactifs depuis six mois ». La plateforme, elle, attend _Subscribers, _Open et un filtre de date écrit en SQL.

Les supports de formation et les réponses de la communauté sont eux aussi surtout rédigés en anglais, ce qui relève la barrière d'entrée pour les nouveaux arrivants.

Rien de tout cela n'empêche d'utiliser SFMC efficacement. Simplement, certaines tâches prennent plus de temps qu'elles ne le devraient.

‍

L'étape de traduction que personne ne mesure

Chaque demande d'audience passe par une traduction invisible. Le besoin métier est formulé en français, converti en noms de champs anglais, puis en requête.

Chaque étape ouvre la porte à un malentendu, et la personne qui comprend l'objectif business n'est presque jamais celle qui écrit la requête.

Dans une petite équipe, le marketeur et l'analyste sont voisins de bureau. Dans un grand groupe, ils peuvent travailler dans deux pays différents.

Résultat : une file d'attente de demandes, chacune suspendue à la disponibilité d'un profil capable d'écrire du SQL.

‍

Pourquoi le SQL creuse l'écart

‍

Ce qu'exige réellement une SQL Query Activity

Dans Automation Studio, une SQL Query Activity exécute une instruction SELECT et écrit le résultat dans une data extension. Salesforce précise que ces requêtes expirent au bout de 30 minutes et que seul SELECT est pris en charge.

Pour en écrire une, il faut connaître les noms de tables, les clés de jointure comme SubscriberKey et des fonctions de date telles que GETDATE().

Le marketeur qui apprend le SQL devient souvent la référence informelle de toute l'équipe. Ce schéma est fragile dès qu'il part en congé ou change de poste.

‍

Les data views et leur fenêtre de six mois

Les data views système comme _Sent, _Open et _Click conservent l'historique d'engagement. D'après l'aide Salesforce, les données de suivi de ces vues sont en général conservées six mois.

Ce point compte pour toute équipe qui construit une audience de réactivation ou d'exclusion. Une demande du type « inactifs depuis un an » ne peut pas être satisfaite avec ces seules vues.

Les historiques plus longs passent généralement par des data extensions maintenues par l'équipe. Savoir où se trouve chaque type d'historique fait partie d'une requête correcte.

‍

À quoi ressemble une demande en français

‍

De la phrase à la requête

Un assistant conversationnel accepte la demande telle que le marketeur la formulerait. Par exemple : contacts qui n'ont pas ouvert d'email depuis 90 jours, hors désabonnés.

L'assistant associe l'intention aux bonnes data views, construit les jointures et renvoie une requête que l'équipe peut relire.

L'entrée étant du langage naturel, inutile de mémoriser les noms de champs. C'est l'assistant qui fait le lien entre le vocabulaire français et le schéma anglais.

Le marketeur peut ensuite affiner dans la même conversation, en passant par exemple de 90 à 120 jours ou en ajoutant un filtre par pays.

‍

Garder l'humain dans la boucle

Un SQL généré ne doit jamais rester une boîte noire. La bonne pratique consiste à afficher la requête, les tables lues et une estimation de la taille de l'audience avant toute exécution.

Un marketeur qui n'écrit pas de SQL peut tout de même vérifier que la logique correspond à son intention. C'est là que se situe la valeur.

Cela crée aussi un vocabulaire commun. Avec le temps, les équipes reconnaissent la forme d'une bonne requête, même sans jamais en écrire.

‍

Cas d'usage concrets pour les équipes francophones

‍

Réactivation et exclusion

La réactivation est un cas d'école. Il faut des contacts engagés par le passé mais silencieux depuis peu, en excluant les désabonnés et les acheteurs récents.

Les listes d'exclusion suivent la logique inverse. Les deux se décrivent facilement en français et se traduisent laborieusement en jointures.

Leur version dynamique est encore plus utile, car elle se met à jour à chaque exécution de l'automation au lieu de vieillir dans une data extension statique.

‍

Segments régionaux et multilingues

Beaucoup d'équipes françaises adressent aussi la Belgique, la Suisse, le Québec ou plusieurs marchés européens. Les segments dépendent alors de la langue, du pays et des champs de consentement.

Décrire ces règles en langage naturel limite les allers-retours avec la personne qui maîtrise le modèle de données.

L'ouverture d'un nouveau marché s'en trouve simplifiée : on décrit le segment, on vérifie la logique générée et on réutilise le modèle.

‍

Gouvernance, consentement et qualité des données

‍

Le consentement d'abord

Les équipes françaises travaillent sous le RGPD et les attentes de la CNIL. Le consentement et la gestion des désinscriptions font donc partie de chaque audience, et tout workflow assisté par IA doit les respecter par défaut.

Un bon réflexe : énoncer l'exclusion dans la demande, puis la confirmer dans la requête générée.

La traçabilité compte aussi. Conserver la demande et la requête associée fournit un historique clair de la construction de chaque audience.

‍

Des données propres, de meilleures réponses

Un assistant n'est précis que si la structure qu'il lit l'est aussi. Des noms de data extensions clairs, des clés documentées et des types de champs cohérents améliorent les résultats tout de suite.

Les équipes qui nettoient leur modèle de données avant de se lancer accordent en général plus vite leur confiance aux résultats.

Un court document de conventions de nommage suffit souvent pour démarrer. Il s'enrichit au fil des questions les plus fréquentes.

‍

Déployer l'approche dans votre équipe

‍

Commencez par une audience récurrente

Choisissez une demande qui arrive chaque mois chez l'équipe data et reconstruisez-la en mode conversationnel. Comparez la requête générée avec celle que rédigerait votre analyste.

Vous obtenez ainsi un point de comparaison concret plutôt qu'une promesse abstraite.

Mesurez le délai entre la demande et l'audience validée, avant puis après. Appuyez-vous sur vos propres chiffres plutôt que sur des affirmations générales.

‍

Définissez qui relit quoi

Décidez quelles audiences un marketeur peut valider seul et lesquelles nécessitent encore un contrôle technique. Notez cette règle et réexaminez-la après quelques semaines.

Peu à peu, l'équipe technique consacre moins d'énergie aux requêtes courantes et davantage à la qualité des données et à l'architecture.

Les marketeurs gagnent en autonomie pour tester davantage d'idées. Un segment qui exigeait un ticket peut s'explorer en une seule conversation.

L'objectif n'est pas d'écarter l'expertise technique, mais de la réserver aux problèmes qui la méritent vraiment.

Le changement est progressif, mais la direction est claire : moins de traduction, plus de décision.

‍

Découvrir QAiry en action

‍

QAiry est un assistant conversationnel pour Salesforce Marketing Cloud qui transforme des demandes en langage courant en SQL que vous pouvez relire.

Voyez-le à l'œuvre sur des demandes d'audience réelles sur qairy.com/fr/product-demos, ou essayez-le vous-même sur qairy.com/fr/try-it-free.