QAiry 3.1 : un bond en avant pour vos audiences Salesforce Marketing Cloud

Construire une audience dans Salesforce Marketing Cloud reste, en 2026, un exercice de patience : une requête SQL à écrire, des Data Extensions à joindre de tête, une Automation à programmer, et l’espoir que la chaîne de rafraîchissement tienne jusqu’au bout. QAiry 3.1 s’attaque à ces trois frictions en même temps : une IA qui comprend réellement votre modèle de données, un mode de construction visuel devenu un véritable builder, et une automatisation en cascade qui va au-delà de ce que permet Automation Studio. Voici ce que change cette version, fonctionnalité par fonctionnalité, et ce qu’elle résout concrètement dans une équipe CRM.

Ce que 3.1 change, en une phrase

QAiry cesse d’être un outil où l’on demande une audience à une IA pour devenir un espace de travail où l’on construit une audience, par le chemin qui vous convient. Trois portes d’entrée coexistent désormais dans le même écran : le Chat, le Manual Edit et le SQL. Vous pouvez commencer par l’une, continuer avec une autre, et revenir à la première sans rien perdre.

C’est un changement de posture important. Les équipes SFMC ne sont pas homogènes : un data analyst veut écrire son SQL, un chef de projet CRM veut assembler des filtres, un marketeur veut décrire son besoin en français. Jusqu’ici, les outils forçaient un seul de ces profils. 3.1 arrête de choisir à votre place.

Un chat qui comprend enfin votre modèle de données

La première brique de la version porte sur la pertinence des réponses. QAiry 3.1 interprète votre demande dans le contexte de votre environnement Salesforce Marketing Cloud, et non dans l’absolu. La différence se voit surtout sur les modèles complexes : l’outil comprend mieux vos Data Extensions, leurs champs et surtout les relations qui les lient.

C’est ce dernier point qui fait basculer l’expérience. Un modèle SFMC réaliste, ce n’est pas trois tables : c’est Clients, Orders, Products, Invoices, Payments, Optin, Events, avec des cardinalités 1:1, 1:N et M:N qui ne demandent qu’à produire des doublons si la jointure est mal choisie. Une IA qui ignore ces cardinalités génère du SQL syntaxiquement correct et fonctionnellement faux. C’est exactement le problème que 3.1 adresse.

S’y ajoute une guidance plus fine : QAiry identifie ce que vous cherchez à obtenir et vous oriente vers l’étape suivante pertinente pendant que vous affinez votre audience, au lieu de se contenter de répondre à la question posée.

Connecter une Data Extension sans quitter la conversation

Le détail le plus appréciable au quotidien est ailleurs. Lorsque QAiry a besoin d’une Data Extension qui n’est pas encore connectée, vous pouvez la rechercher, la sélectionner et la connecter directement depuis la conversation. Fini l’aller-retour vers l’écran de configuration, le retour au chat, la reformulation du prompt et la perte du fil.

Sur une session de construction d’audience réelle, ce sont trois ou quatre interruptions évitées. Le gain n’est pas spectaculaire en démo ; il l’est en production.

Quatre types de Data Extensions, un seul workspace

QAiry 3.1 élargit ce que vous pouvez faire entrer dans votre logique d’audience. Quatre familles de Data Extensions sont désormais exploitables :

Type	Ce que vous y gagnez
Data Extensions	Les DE connectées à votre Business Unit, socle habituel de vos audiences.
Shared Data Extensions	Les données partagées entrent dans la logique d’audience : vous travaillez enfin entre Business Units.
Synchronized Data Extensions	Les données CRM synchronisées depuis Salesforce, utilisables directement dans le workflow.
Salesforce Data Extensions	Les DE générées par Salesforce, pour faire remonter encore plus de données CRM dans vos ciblages.

Pour les organisations multi-BU, c’est la nouveauté la plus structurante de la liste. La segmentation cross-BU se faisait jusqu’ici par recopie de données, avec les décalages de fraîcheur que tout le monde connaît. La traiter au niveau de la logique d’audience élimine une étape de duplication et une source d’erreur.

Manual Edit devient un vrai builder

Dans les versions précédentes, Manual Edit servait à corriger ce que l’IA avait produit. En 3.1, c’est un point de départ à part entière : vous ouvrez Manual Edit et vous concevez la logique étape par étape, sans avoir écrit un seul prompt.

Le parcours tient en cinq étapes :

Sélectionner les Data Extensions connectées que vous voulez utiliser.
Choisir la logique de jointure entre ces Data Extensions.
Ajouter les filtres que vos contacts doivent satisfaire pour être inclus.
Appliquer les exclusions, c’est-à-dire définir qui doit être écarté.
Relire la sortie et organiser les champs de l’audience finale.

L’étape des exclusions mérite qu’on s’y arrête. C’est celle que les générateurs SQL traitent le plus mal, et c’est pourtant celle qui protège votre pression commerciale et votre délivrabilité. La traiter comme une étape de premier rang, et non comme une clause à glisser dans un WHERE, change la qualité des audiences produites.

La vraie nouveauté de 3.1 n’est pas que l’IA soit plus intelligente : c’est que vous n’êtes plus obligé de passer par elle. Construire d’abord, demander à l’IA ensuite, ou combiner les deux — c’est vous qui décidez du point d’entrée.

Vous préférez le SQL ? Commencez par là

Troisième porte d’entrée : l’onglet SQL. Vous y écrivez ou collez votre requête, puis vous continuez à affiner l’audience dans QAiry. Le sens de circulation est libre, du SQL vers le Manual Edit puis vers le Chat, ou l’inverse.

Concrètement, une requête de déduplication comme celle-ci — récupérer la dernière commande par client parmi les opt-in — devient un point de départ que vous enrichissez visuellement ensuite :

SELECT t.Clients_Subscriberkey,
       t.Clients_Email,
       t.Orders_Date
FROM (
    SELECT c.Subscriberkey AS Clients_Subscriberkey,
           c.Email         AS Clients_Email,
           o.[Date]        AS Orders_Date,
           ROW_NUMBER() OVER (
               PARTITION BY c.Subscriberkey
               ORDER BY o.[Date] DESC, o.Id DESC
           ) AS RowNum
    FROM Clients c
    INNER JOIN Optin  op ON op.Subscriberkey = c.Subscriberkey
    INNER JOIN Orders o  ON o.Client_id      = c.Subscriberkey
    WHERE op.Optin_email = 'true'
) t
WHERE t.RowNum = 1

C’est le type de requête que personne n’a envie de réécrire à chaque campagne, et que personne n’a envie de confier aveuglément à une IA non plus. Pouvoir l’apporter telle quelle, puis ajouter des exclusions à la souris, est un compromis honnête.

Waterfall automation : rafraîchir dans le bon ordre

La dernière brique est la plus technique, et sans doute la plus utile aux équipes qui exploitent déjà QAiry en production. La Waterfall automation enchaîne les rafraîchissements de Data Extensions dépendantes de manière séquentielle : chaque étape ne démarre que lorsque la précédente est terminée.

Le schéma type ressemble à ceci : audience de base, puis enrichissement (données de profil et comportementales), puis exclusions (règles de suppression), puis audience finale publiée. Chaque maillon attend explicitement que le précédent soit prêt.

Quiconque a déjà tenté de reproduire cette logique dans Automation Studio connaît le procédé habituel : on estime la durée de chaque Query Activity, on insère des marges, on programme les automations à intervalles fixes, et on prie. Le jour où le volume augmente, la première requête déborde sur la seconde et l’audience finale part avec des données partiellement périmées — sans la moindre erreur affichée.

Déclarer une dépendance plutôt qu’un horaire supprime cette classe de panne silencieuse et réduit la pression de timeout sur les longues chaînes de rafraîchissement. C’est complété par un rafraîchissement déclenchable via API, qui permet de brancher ces chaînes sur vos propres événements métier plutôt que sur un calendrier.

Par où commencer

Cartographiez vos relations entre Data Extensions dans QAiry avant tout : la qualité des réponses du chat en dépend directement.
Identifiez vos audiences multi-BU actuellement construites par recopie : ce sont les premières candidates aux Shared Data Extensions.
Reprenez une audience existante dans Manual Edit et isolez ses exclusions : vous découvrirez souvent des règles de suppression enfouies dans un WHERE.
Listez vos chaînes d’automations programmées à heure fixe : chacune est une candidate à la Waterfall automation.
Faites tester le SQL à vos profils techniques et le Chat à vos profils métier, sur la même audience, puis comparez.

À retenir

Trois points d’entrée, un seul workspace. Chat, Manual Edit et SQL cohabitent dans le même écran : chaque profil de votre équipe travaille comme il en a l’habitude, sur la même audience.

Le chat comprend vos relations, pas seulement vos tables. C’est ce qui sépare un SQL syntaxiquement correct d’un SQL fonctionnellement juste sur un modèle à cardinalités multiples.

Le cross-BU devient natif. Shared, Synchronized et Salesforce Data Extensions entrent dans la logique d’audience et suppriment une étape de recopie.

Les exclusions deviennent une étape de premier rang. C’est le meilleur levier disponible sur votre pression commerciale et votre délivrabilité.

La Waterfall automation remplace le pari horaire. Une dépendance déclarée vaut mieux qu’une marge estimée, surtout le jour où vos volumes doublent.

Vous souhaitez évaluer QAiry 3.1 sur votre propre modèle de données Salesforce Marketing Cloud, ou auditer vos chaînes de rafraîchissement actuelles ? Parlons-en avec nos consultants SFMC.