Gérer ses audiences à l'échelle de plusieurs business units

‍

Un processus de segmentation calibré pour une marque tient rarement le choc face à cinq.

La logique de la requête n'est presque jamais en cause. Ce qui casse, c'est le contexte : l'emplacement réel des données, les droits de lecture, et le compte depuis lequel la requête s'exécute.

‍

Salesforce Marketing Cloud répond aux organisations multimarques et multipays avec les business units, une structure hiérarchique disponible dans les comptes Enterprise et Enterprise 2.0 qui pilote l'accès aux informations et leur partage.

Cette architecture a de vraies vertus. Elle cloisonne les marques, protège la réputation d'envoi et laisse aux équipes régionales une marge de manœuvre réelle.

Elle explique aussi pourquoi la gestion des audiences ralentit, au lieu d'accélérer, à mesure que l'organisation grandit.

‍

Voici ce qui change concrètement quand le travail d'audience passe d'une business unit à plusieurs, les règles SFMC qui pèsent le plus lourd, et les modèles de gouvernance qui résistent au passage à l'échelle.

‍

Pourquoi les business units morcellent le travail d'audience

‍

Le cloisonnement est la règle, pas l'exception

Chaque business unit possède ses propres abonnés, ses propres data extensions et sa propre configuration d'envoi.

C'est précisément l'objectif recherché. Ce cloisonnement empêche l'équipe allemande d'adresser par erreur la base espagnole, et évite qu'un taux de plainte élevé sur une marque ne contamine les autres.

‍

Revers de la médaille : une définition d'audience n'est jamais portable. C'est un objet local, avec des dépendances locales : un nom de data extension précis, un champ précis, un chemin de dossier précis.

Recopiez la requête dans une unité voisine et elle échoue, avec un message d'erreur qui pointe le symptôme plutôt que la cause.

‍

La même question posée cinq fois

Prenons une demande banale : les clients ayant acheté dans les 90 derniers jours et n'ayant ouvert aucun email depuis 60 jours.

Une seule question métier. Répartie sur cinq business units, elle devient cinq requêtes distinctes, chacune s'appuyant sur des data extensions nommées différemment, chacune maintenue par la personne qui l'a écrite.

‍

Le jour où la définition du « client actif » évolue, les cinq doivent évoluer aussi. En pratique, trois seulement le font.

Personne n'a décidé cela. C'est le résultat mécanique d'équipes compétentes qui résolvent le même problème chacune de leur côté, sans vocabulaire commun.

‍

Ce que partagent réellement les data extensions partagées

‍

Le fonctionnement

Marketing Cloud permet de partager des data extensions avec d'autres business units en les plaçant dans des dossiers de data extensions partagées, au niveau du compte parent.

Le partage ne se limite pas aux données. Emails, templates, éléments de portfolio et zones de contenu peuvent eux aussi être déposés dans des dossiers partagés, puis consultés par des utilisateurs extérieurs à la business unit propriétaire, sous réserve des rôles et permissions adéquats.

‍

C'est le socle de la plupart des architectures SFMC en entreprise. Il fonctionne bien lorsqu'il est conçu volontairement, beaucoup moins lorsqu'il s'accumule par sédimentation.

‍

Des permissions plus fines que ce que les équipes exploitent

Dans les comptes Enterprise 2.0, l'outil Data Extension Permissions détermine quelles business units atteignent une data extension partagée dans Email Studio, et quelles actions chacune peut y mener.

Vous autorisez ou refusez action par action, unité par unité, plutôt que d'accorder un accès global.

‍

Il est également possible de définir une date de début et une date de fin de partage. L'option est précieuse pour un jeu de données lié à une campagne, une audience saisonnière, ou un partage temporaire avec une agence.

Rares sont les équipes qui l'utilisent. La configuration est posée pendant le déploiement, puis jamais réexaminée.

‍

Trois ans plus tard, un dossier partagé aux droits trop larges devient un dossier que plus personne ne maîtrise et que personne ne veut nettoyer.

‍

Les règles SQL qui changent d'une business unit à l'autre

‍

SELECT uniquement, sur votre compte ou son parent

Une SQL Query Activity dans Automation Studio n'accepte que des instructions SELECT, et uniquement sur des data extensions ou des data views du compte courant ou de son compte parent.

Aucun accès latéral n'existe. Une business unit enfant ne peut pas lire directement les données d'une unité sœur, quelle que soit l'écriture de la requête.

‍

Cette seule contrainte dicte une bonne part de l'architecture. Tout jeu de données destiné à être lu par l'ensemble de l'organisation doit remonter dans le compte parent puis redescendre par partage, jamais transiter entre pairs.

‍

Le préfixe ent.

Pour interroger une data extension hébergée dans le dossier partagé du compte parent, préfixez son nom par ent. dans la requête.

Ce détail minuscule consomme un temps de débogage étonnant. Une requête impeccable dans le compte parent échoue dans une unité enfant simplement parce que le préfixe manque, et le message d'erreur le dit rarement clairement.

‍

Il génère par ailleurs un coût d'intégration. Chaque nouvel arrivant amené à écrire du SQL dans une organisation multi-unités doit apprendre quels objets sont locaux, lesquels sont hérités, et comment les distinguer au simple examen du nom.

‍

Là où les data views cessent d'aider

‍

Le mur des six mois

Les data views d'engagement telles que _Sent et _Open ne conservent en règle générale que les six derniers mois d'activité.

Salesforce a fait évoluer sa politique de rétention en juin 2025 : les données d'engagement des abonnés et des journeys restent accessibles pendant 730 jours. Cette évolution n'a toutefois pas élargi la fenêtre de six mois exposée par la plupart des data views.

‍

Si votre logique de réactivation regarde douze ou dix-huit mois en arrière, la data view seule ne répondra pas. Il faut une data extension d'historisation glissante, qui capture l'engagement avant qu'il ne disparaisse.

Construire cette historisation pour une business unit reste raisonnable. La construire et la surveiller dans quinze unités revient à maintenir un petit produit interne.

‍

Périmètre, timeouts et capacité nocturne

Les query activities s'interrompent au bout de 30 minutes, et un SELECT * sur une data extension volumineuse est un moyen fiable d'atteindre cette limite.

La recommandation de Salesforce est explicite : restreindre le périmètre autant que possible, découper les requêtes qui renvoient de gros volumes, et limiter les fenêtres d'analyse à environ six mois.

‍

Sur une marque unique, cela ressemble à un conseil de performance. Réparti sur quinze business units dont les automations nocturnes se chevauchent, cela devient une contrainte de capacité qui conditionne les créneaux de production des campagnes.

‍

Trois réflexes allègent nettement la pression :

• Nommer chaque colonne utile plutôt que tout sélectionner
• Filtrer sur les dates avant la jointure, pas après
• Décaler les plannings d'automation pour éviter la concurrence sur un même créneau

‍

Les modèles de gouvernance qui tiennent

‍

Centraliser la donnée, distribuer les requêtes

Le modèle qui passe le mieux à l'échelle repose sur une couche partagée mince. Les données de référence (client, produit, consentement) résident dans le compte parent, et chaque business unit construit ses audiences par-dessus.

Les équipes locales conservent l'autonomie totale sur la logique de segmentation, c'est-à-dire sur ce qu'elles doivent réellement maîtriser. Elles cessent d'assumer la tuyauterie, c'est-à-dire ce qui casse.

‍

L'approche inverse, où chaque unité entretient sa propre copie des données client, paraît plus rapide le premier mois et devient ingérable au douzième.

‍

Nommer pour être compris par un inconnu

Les conventions de nommage passent pour un sujet secondaire jusqu'au jour où une personne dans un autre pays doit deviner si DE_Cust_Act_v2 est encore maintenue, et par qui.

Un minimum praticable pour les objets partagés :

• Un préfixe identifiant la business unit propriétaire ou la couche partagée
• Un terme décrivant le contenu de l'objet, pas sa méthode de construction
• Un suffixe de fréquence de rafraîchissement : quotidien, hebdomadaire ou statique

‍

Le test tient en une phrase. Une personne arrivée le mois prochain doit pouvoir lire le nom et savoir si elle peut faire confiance au contenu.

‍

Auditer les partages à intervalle fixe

Les dossiers partagés s'accumulent en silence. Inscrivez une revue trimestrielle au calendrier, listez chaque data extension partagée et retirez tout ce qui n'a plus ni propriétaire identifié ni usage actif.

Lorsque le partage est réellement temporaire, appuyez-vous sur la date de fin de partage plutôt que sur la mémoire de quelqu'un.

‍

Ce que cela change au quotidien

‍

Le véritable goulot d'étranglement dans une organisation multimarques tient rarement au niveau SQL. Il tient à la traduction : convertir une question métier unique en la requête correcte pour le schéma, les permissions et les préfixes de chaque business unit.

Ce travail est répétitif et mécanique. C'est aussi là que se loge l'essentiel du délai.

‍

Dès lors qu'un marketeur peut décrire une audience en langage naturel, par exemple « les acheteurs du dernier trimestre qui n'ont rien ouvert depuis 60 jours », et récupérer une requête qui intègre déjà le schéma local et le préfixe ent., le problème des cinq requêtes cesse de mobiliser cinq après-midi.

‍

Découvrir QAiry en conditions réelles

‍

QAiry produit du SQL SFMC directement exploitable à partir d'une description en langage naturel, et s'appuie sur la structure réelle de la business unit dans laquelle il travaille plutôt que sur un schéma générique.

Vous pouvez observer son comportement sur des environnements multi-unités sur qairy.com/fr/product-demos, ou l'essayer sur votre propre org via qairy.com/fr/try-it-free.