Marketing Cloud : ce qui change vraiment quand le SQL disparaît

‍

Le discours habituel sur l'IA dans Salesforce Marketing Cloud insiste surtout sur ce qui disparaît. Fini l'éditeur de requêtes, fini l'attente d'un collègue technique, fini le débogage d'une jointure la veille d'un envoi.

Ce cadrage reste incomplet. Retirer le SQL du quotidien d'un profil marketing ne supprime pas une tâche : cela la déplace, et cela redistribue les responsabilités.

‍

La vraie question n'est donc pas de savoir si les équipes marketing peuvent se passer de SQL. Dans la plupart des grandes organisations, une large part d'entre elles n'en a jamais écrit.

La question porte plutôt sur le modèle opérationnel qui prend le relais.

‍

Cet article détaille ce qui bouge réellement lorsque le langage naturel devient le mode principal de création d'audiences dans SFMC : les compétences qui perdent leur intérêt, celles qui en gagnent, et les garde-fous qu'il faut déplacer avec le travail.

‍

Le rôle réel du SQL dans la chaîne de production

‍

Une couche de traduction, pas une compétence métier

Pour la plupart des équipes marketing, le SQL dans SFMC n'a jamais été une finalité. C'était simplement le seul moyen d'exprimer une définition d'audience que la plateforme sache exécuter.

Un responsable de campagne raisonne en « personnes ayant ouvert un message ces 60 derniers jours mais n'ayant plus cliqué depuis le printemps ». La plateforme, elle, raisonne en _Open, _Click, SubscriberKey et fonctions de date.

Le SQL faisait le pont entre ces deux vocabulaires. Autrement dit : un coût de traduction, pas une source de valeur.

‍

Un mécanisme de filtrage involontaire

Ce coût de traduction étant élevé, il se concentrait sur très peu de personnes. Dans une organisation d'envergure, il s'agit généralement de deux ou trois profils qui savent où résident les données et quelle data extension est réellement à jour.

Cette concentration avait un mérite : elle imposait une étape de relecture. Chaque audience passait entre les mains de quelqu'un qui maîtrisait le schéma.

Elle produisait aussi le goulot d'étranglement que tout le monde dénonce. Les deux constats sont vrais simultanément, ce qui explique pourquoi supprimer le SQL n'est pas un gain net évident.

‍

Les contraintes techniques survivent à la syntaxe

‍

Les limites de la plateforme restent identiques

La SQL Query Activity de SFMC s'appuie sur les capacités de SQL Server 2016, sans y correspondre exactement. Elle accepte uniquement des instructions SELECT sur des data extensions et des data views du compte ou de son compte parent. Ni INSERT, ni UPDATE, ni SELECT INTO.

Les requêtes expirent au bout de 30 minutes. Salesforce recommande d'ailleurs de transformer les données ailleurs dès qu'une requête dépasse régulièrement dix minutes d'exécution.

Une requête combinant une jointure et un SELECT * est purement et simplement refusée.

‍

La rétention borne ce que vous pouvez demander

Les data views système conservent environ six mois d'historique d'engagement, interrogeables via Automation Studio. Les ouvertures comme les clics tiennent dans cette fenêtre.

La nuance compte davantage qu'il n'y paraît. « Contacts n'ayant jamais interagi » et « contacts sans interaction sur la période interrogeable » désignent deux populations distinctes, et SFMC ne sait répondre qu'à la seconde.

Une couche d'IA qui génère du SQL hérite intégralement de ces frontières. Elle ne les négocie pas.

‍

Le quotidien après la bascule

‍

Le changement visible tient à la vitesse. Une audience qui mobilisait un ticket, une file d'attente et deux jours se traite désormais en une phrase et une relecture.

Le changement moins visible est plus structurant : l'itération redevient assez peu coûteuse pour valoir la peine. À deux jours par segment, vous livrez la première version. À deux minutes, vous vérifiez le volume, constatez qu'il est plus faible que prévu, et corrigez l'hypothèse de départ.

‍

C'est ce second effet qui se lit dans la performance des campagnes. La plupart des erreurs de segmentation dans SFMC ne sont pas des erreurs de syntaxe, mais des hypothèses plausibles que personne n'avait le budget de vérifier.

Un troisième effet, plus discret, mérite d'être signalé : les demandes qui n'étaient jamais formulées, faute de justifier un ticket, finissent par l'être.

‍

Les compétences qui prennent de la valeur

‍

Formuler une intention précise

Le langage naturel déplace la difficulté : de la syntaxe vers la spécification. Les clients ayant acheté récemment ne constitue pas une définition d'audience. Aucune fenêtre temporelle, aucun périmètre produit, aucune règle sur le traitement des retours.

Les profils qui tirent le meilleur parti d'une interface conversationnelle sont ceux qui définissaient déjà leurs audiences avec rigueur. Le prompt ne fait que rendre cette rigueur visible.

‍

Savoir lire une requête pour pouvoir la refuser

Personne n'a besoin de rédiger GETDATE() de mémoire. En revanche, il faut savoir repérer qu'une requête générée s'appuie sur l'adresse email plutôt que sur SubscriberKey, ou qu'un filtre de date est inclusif du mauvais côté.

Le profil de compétences se déplace donc de la production vers la relecture. Or la lecture s'enseigne beaucoup plus facilement à l'échelle d'une équipe que l'écriture, ce qui explique qu'elle passe à l'échelle là où le SQL échouait.

‍

Connaître son propre modèle de données

Aucune couche de langage naturel ne vous signalera que Purchases_Master n'est plus alimentée depuis mars et que tout le monde est passé sans bruit sur une autre extension.

Cette connaissance est organisationnelle avant d'être technique. Elle gagne en valeur une fois la barrière syntaxique levée.

Elle mérite par ailleurs d'être documentée. Tant que trois personnes construisaient les audiences, le modèle de données pouvait rester dans leurs têtes. Dès que trente personnes s'y mettent, il doit exister par écrit.

‍

Là où la gouvernance doit se déplacer

‍

L'ancienne relecture disparaît par défaut

Quand le SQL était rare, la relecture s'opérait mécaniquement, puisque tout transitait par les deux mêmes personnes. Supprimez ce passage obligé et une audience peut aller de l'idée à l'envoi sans second regard.

Les équipes qui gèrent bien cette transition remplacent le point de contrôle implicite par un point de contrôle explicite. En pratique : une vérification de volume et un valideur nommé au-delà d'un certain seuil.

‍

Les exclusions méritent un traitement plus strict

Une erreur d'inclusion se voit : vous envoyez aux mauvaises personnes et quelqu'un le signale. Une erreur d'exclusion reste silencieuse, car personne ne se plaint d'un email qu'il n'a pas reçu.

Les listes de suppression globales, de consentement et d'exclusion légale doivent rester des composants relus et réutilisables, plutôt que d'être régénérées conversationnellement à chaque campagne.

‍

La traçabilité devient une exigence

Si une audience naît d'une phrase, cette phrase doit être stockée aux côtés du SQL qu'elle a produit. Six mois plus tard, la question « pourquoi cette campagne ciblait-elle ces 40 000 personnes ? » doit trouver une réponse.

La démarche de Salesforce avec Marketing Cloud Growth va dans le même sens : des prompts en langage naturel génèrent les segments, l'Einstein Trust Layer encadrant la gouvernance des données autour du modèle.

‍

Qui y gagne réellement

‍

Les équipes techniques, plus qu'on ne le croit

La crainte classique consiste à penser que retirer le SQL retire la raison d'être de l'équipe technique. En réalité, c'est plutôt l'inverse qui se produit.

Ces profils cessent de consacrer leur semaine à des tickets de segmentation routiniers pour travailler sur le modèle de données, le schéma et les automatisations qui rendent une bonne segmentation possible. Un travail toujours plus utile, et toujours repoussé.

‍

Les équipes jusqu'ici bloquées

Les entités régionales et les business units de taille modeste le ressentent en premier. Leurs demandes stagnaient en bas d'une file partagée, derrière le marché disposant du plus gros budget.

Le changement ne tient pas seulement à la vitesse. Il tient au fait que leur ambition de campagne cesse d'être plafonnée par la capacité de quelqu'un d'autre.

‍

Découvrir QAiry en conditions réelles

‍

QAiry produit du SQL SFMC directement exploitable à partir d'une description en langage courant de l'audience visée. L'étape de relecture reste ainsi entre les mains de la personne qui connaît la campagne.

Pour voir ce que cela donne sur votre propre modèle de données, rendez-vous sur qairy.com/fr/product-demos ou commencez par qairy.com/fr/try-it-free.