Home
/
Blog
/
Product
Product

L'avenir de la création d'audiences dans SFMC

La création d'audiences dans SFMC passe du SQL manuel au langage naturel. Ce qui change, ce qui reste, et comment garder des segments sendable.

L'avenir de la création d'audiences dans SFMC

Dans Salesforce Marketing Cloud, construire une audience a toujours demandé de la patience. Vous posez la logique, vous écrivez la requête, vous attendez son exécution, puis vous vérifiez les volumes.

Ce fonctionnement a formé toute une génération d'équipes marketing operations. Il commence aussi à évoluer.

Il ne s'agit pas de remplacer SFMC. Les data extensions, les relations d'envoi et les data views restent exactement à leur place. Ce qui change, c'est l'interface entre l'intention d'un marketeur et l'audience qui arrive dans une campagne.

Cet article regarde comment les audiences se créent aujourd'hui dans SFMC, où se niche vraiment la friction, et comment l'IA transforme l'amont de ce flux sans toucher à la mécanique qui le porte.

Comment se créent les audiences dans SFMC aujourd'hui

Les data extensions et la clé d'abonné

La plupart des audiences dans SFMC vivent dans des data extensions. Une data extension sendable porte une relation d'envoi et relie chaque ligne à un abonné via la SubscriberKey.

Salesforce recommande de stocker la SubscriberKey au format texte, ce qui garde cette relation stable quand les données arrivent de sources différentes.

Les data extensions non sendable, elles, contiennent des données de référence : tables de commandes, catalogues produits, ou tout ce qui sert à personnaliser un message plutôt qu'à l'adresser.

La distinction n'a rien d'anecdotique. Un segment n'est utile que si la table finale dans laquelle il écrit est sendable, autrement dit c'est la tuyauterie qui décide si une audience peut réellement partir.

Le rôle du SQL et des data views

Pour construire un segment, la plupart des équipes écrivent une SQL query activity dans Automation Studio. La requête lit dans des data extensions ou dans les data views du système, et écrit son résultat dans une data extension cible.

Les data views exposent un historique d'engagement qui ne figure dans aucune data extension classique. Des tables comme _Sent, _Open, _Click et _Bounce permettent de filtrer sur le comportement, et non plus seulement sur les attributs.

C'est ainsi qu'une demande du type contacts ayant ouvert dans les 30 derniers jours mais sans clic devient une audience réelle. Le comportement vit dans les data views, et la jointure le réunit avec le profil.

Une fois écrite, la requête peut être planifiée dans Automation Studio pour que l'audience se rafraîchisse seule. Cette planification est précieuse, mais elle suppose que la requête était juste au départ, et c'est précisément là que se trouve le vrai travail.

Pourquoi ce modèle ralentit les équipes

La dépendance aux compétences techniques

La logique décrite plus haut n'est pas difficile à formuler. Elle est difficile à écrire correctement.

Un marketeur sait quelle audience il veut. La transformer en jointures indexées à travers les data views relève d'un autre métier, et dans la plupart des organisations ce métier repose sur quelques personnes.

La demande part donc dans une file d'attente. Le marketeur patiente, le spécialiste s'interrompt dans un travail plus profond, et une campagne prête sur le papier reste inactive en pratique.

Ce n'est presque jamais la faute de quelqu'un. C'est simplement la forme de l'outil.

Le coût de chaque petite modification

La file pèse surtout sur l'itération. Décaler une fenêtre de dates, ajouter une exclusion ou scinder un segment en deux, chaque geste implique un nouvel aller-retour.

Chaque changement est minime pris isolément. Sur un trimestre, l'attente cumulée devient l'un des coûts les plus discrets et les plus lourds d'une organisation marketing.

Elle décourage aussi les tests, car chaque essai porte une taxe de coordination qu'une idée rapide juge rarement justifiée.

Ce qui change : l'IA entre dans le flux de travail

La création de segments en langage naturel

Salesforce a commencé à orienter la création d'audiences vers le langage naturel. La création de segments Einstein dans Data Cloud vous laisse décrire l'audience voulue en mots simples et génère pour vous la définition du segment.

Les expériences plus récentes de Marketing Cloud prolongent la même idée, en proposant une construction de segment assistée par l'IA à la place d'un éditeur de requête vide.

L'intention derrière ces fonctionnalités reste cohérente : laisser le marketeur énoncer l'objectif en mots, et laisser le système gérer la structure.

Les signaux Einstein et Data Cloud

L'IA fait plus que traduire une phrase en filtre. Einstein engagement scoring et les modèles associés classent les contacts selon leur probabilité d'ouvrir ou de cliquer, ce qui alimente des segments plus riches que ne le permettent les attributs statiques.

Couplée à Data Cloud, cette approche pointe vers des audiences décrites une fois et rafraîchies en continu, plutôt que reconstruites à la main à chaque exécution de campagne.

La description devient l'objet durable, et ce sont les données sous-jacentes qui se mettent à jour.

Il faut toutefois être clair sur les limites. Ces fonctionnalités brillent quand les données de base sont bien organisées, et elles demandent encore à une personne de valider ce que le modèle propose avant qu'il ne pilote un envoi.

Ce qui ne change pas en profondeur

Les data extensions sendable restent indispensables

Rien de tout cela ne supprime la tuyauterie. Quelle que soit la façon de décrire une audience, la campagne a toujours besoin d'une data extension sendable avec une SubscriberKey valide avant le moindre envoi.

Un segment généré par l'IA qui ne peut pas être envoyé reste un brouillon, pas une audience. Le dernier kilomètre demeure du côté de SFMC, et la relation d'envoi doit toujours être correcte.

La qualité des données et l'indexation décident de la performance

Le SQL dans SFMC est le plus performant quand les champs utilisés dans JOIN, WHERE, GROUP BY et ORDER BY sont indexés. Cette règle ne disparaît pas parce qu'une machine écrit la requête.

Elle compte même davantage, car la logique générée s'exécute sur les mêmes tables, les mêmes volumes et les mêmes limites de traitement que le travail écrit à la main.

Des clés propres et des index pensés restent ce qui sépare une requête qui aboutit d'une requête qui expire.

Comment le langage naturel se traduit en SQL

D'une phrase à une requête

La bonne manière d'y penser, c'est la traduction. Un marketeur écrit acheteurs actifs en France sans ouverture depuis 60 jours, et le système produit le SQL qui l'exprime.

Derrière la phrase se cache une forme familière : une jointure entre une table d'achats et _Open, un filtre de date construit avec GETDATE(), et une écriture dans une data extension sendable clée sur SubscriberKey.

Les mots changent, mais la structure dessous est exactement celle qu'un spécialiste aurait écrite.

Garder des requêtes prêtes pour la production

Une requête générée n'a de valeur que si elle est sûre à exécuter. Prête pour la production signifie les bons champs indexés, une logique de date fiable aux bornes, et un résultat qui respecte la relation d'envoi.

L'objectif n'est pas une requête qui semble correcte dans un aperçu. C'est une requête qu'une équipe peut planifier, relancer et suivre semaine après semaine.

Ce niveau d'exigence sépare un brouillon utile de ce qu'un marketeur peut vraiment placer dans une automation.

Relire le SQL généré est aussi une bonne habitude pour une autre raison. Cela garde l'équipe marketing fluente sur le sens de ses propres audiences, si bien que la logique reste comprise au lieu de se cacher dans une boîte noire.

Ce que cela change au quotidien

Pour la plupart des équipes, le premier gain est la rapidité. Le marketeur décrit l'audience, relit la logique, puis avance sans ouvrir de ticket.

Le spécialiste se libère pour le travail qui réclame vraiment son jugement, comme la modélisation des données et les cas limites épineux.

Découvrez QAiry en action

QAiry se place exactement à cette couche. Vous décrivez l'audience voulue en langage naturel, et il génère un SQL prêt pour la production dans SFMC, qui respecte vos data extensions et vos data views.

Voyez comment cela fonctionne sur qairy.com/fr/product-demos, ou construisez votre première audience sur qairy.com/fr/try-it-free.

Share this article
QAiry for SFMC

Skip the SQL. Build segments by chatting.

QAiry turns plain English requests into Salesforce Marketing Cloud audience segments and data extensions — no SQL, no IT ticket, no waiting.

Built for SFMC · ISV Partner · GDPR-ready