L’évolution de Salesforce Marketing Cloud vers Agentforce Marketing et Marketing Cloud Next ouvre de nouvelles possibilités autour de la donnée, de l’automatisation et de l’IA. Mais pour les entreprises qui exploitent déjà Marketing Cloud Engagement — encore largement appelé SFMC — le véritable enjeu n’est pas d’activer de nouvelles fonctionnalités.

Il est de savoir comment faire évoluer une architecture Marketing Cloud existante sans repartir de zéro ni ajouter une nouvelle couche de complexité.

Après plusieurs années d’exploitation, un environnement Marketing Cloud Engagement peut comporter plusieurs Business Units, de nombreuses Data Extensions, des journeys critiques, des automatisations, des intégrations CRM et SI, ainsi que des règles historiques autour du Contact Key, du consentement ou de la segmentation.

Dans ce contexte, Agentforce Marketing n’est pas simplement un nouveau produit à déployer. Son adoption devient un sujet d’architecture Salesforce.

Pour une entreprise déjà équipée de Marketing Cloud Engagement, la question n’est pas nécessairement de remplacer l’existant. Salesforce permet une adoption progressive des capacités de Marketing Cloud Next tout en conservant des composants existants dans Marketing Cloud Engagement. Les entreprises peuvent ainsi continuer à exploiter leurs journeys et leurs données tout en introduisant progressivement Data 360, Flow et les nouvelles capacités d’Agentforce Marketing.

Cette coexistence est intéressante, mais elle impose une première décision structurante :

quelles fonctions doivent rester dans Marketing Cloud Engagement et lesquelles doivent progressivement évoluer vers la nouvelle architecture ?

Un journey mature, stable et critique n’a pas nécessairement intérêt à être reconstruit. À l’inverse, un nouveau cas d’usage nécessitant des données issues de plusieurs clouds Salesforce peut être un bon candidat pour Marketing Cloud Next. L’enjeu n’est donc pas de tout migrer, mais de définir une architecture cible et une trajectoire d’adoption cohérentes.

C’est souvent ici que se situe le véritable travail. Au fil des années, les environnements Marketing Cloud Engagement accumulent des Data Extensions créées pour des campagnes, des tables intermédiaires alimentées par SQL, des automations, des scripts et des interfaces avec différents systèmes. Certaines données sont structurantes. D’autres ne sont plus utilisées. Certaines Data Extensions dupliquent des informations déjà disponibles ailleurs dans le SI. Connecter cet ensemble à Data 360 sans analyse préalable risque simplement de transporter la dette historique Marketing Cloud dans la nouvelle architecture. Un audit doit donc identifier les Business Units, les Data Extensions réellement structurantes, les Contact Keys et Subscriber Keys utilisés, les principaux journeys, les automations, les APIs et les dépendances avec Salesforce CRM ou des systèmes externes.

L’objectif n’est pas de documenter chaque objet existant. Il est de comprendre quelles données et quels processus doivent réellement faire partie de l’architecture cible.

Salesforce permet de synchroniser des Data Extensions de Marketing Cloud Engagement avec Marketing Cloud Next via Data 360. Mais techniquement possible ne signifie pas architecturalement pertinent. Une Data Extension peut être une véritable source métier, mais elle peut aussi n’être qu’une table intermédiaire créée plusieurs années auparavant pour alimenter une automation ou une campagne spécifique.

Dans Data 360, les données doivent être intégrées dans un modèle cohérent et mappées vers les objets appropriés. Cela oblige à revenir à une question fondamentale : que représente réellement cette donnée dans le modèle client de l’entreprise ?

C’est particulièrement important pour l’identité. Un environnement SFMC peut contenir différents identifiants issus du CRM, de l’e-commerce, d’applications métier ou de systèmes externes. Leur rapprochement ne doit pas être improvisé au moment de l’intégration avec Data 360. La qualité des données devient alors directement liée à la qualité des segmentations, des personnalisations et, à terme, des décisions prises par les agents IA.

L’adoption d’Agentforce Marketing est donc aussi l’occasion de remettre à plat certaines décisions historiques concernant le modèle de données et l’identité client.

La coexistence introduit également une nouvelle problématique d’architecture. Marketing Cloud Engagement dispose déjà de Journey Builder et d’Automation Studio. L’écosystème Salesforce dispose parallèlement de Flow, tandis que Marketing Cloud Next apporte de nouvelles capacités d’orchestration et d’activation. Sans règles d’architecture claires, une entreprise peut rapidement se retrouver avec plusieurs moteurs capables d’exécuter des automatisations marketing.

Le risque est de reproduire un phénomène déjà fréquent sur les plateformes Salesforce : empiler les outils plutôt que rationaliser les usages. Pour chaque nouveau processus, il faut donc déterminer où la logique doit résider. Un parcours marketing mature peut continuer à être exécuté dans Journey Builder. Une orchestration impliquant Sales Cloud, Service Cloud et plusieurs objets Salesforce peut davantage relever de Flow. Certains nouveaux cas d’usage marketing peuvent être construits directement avec les capacités de Marketing Cloud Next.

Ce choix doit dépendre du processus métier, des données nécessaires, des systèmes concernés et surtout de la capacité des équipes à maintenir la solution dans le temps.

L’arrivée d’Agentforce Marketing peut être une opportunité de modernisation. Elle peut aussi produire l’effet inverse. Une entreprise peut conserver toutes ses Data Extensions historiques, maintenir ses automations existantes, ajouter Data 360, créer de nouveaux Flows et commencer parallèlement à développer des cas d’usage Agentforce.

Chaque composant fonctionne alors individuellement, mais l’architecture globale devient progressivement plus difficile à comprendre et à gouverner. C’est pourquoi une trajectoire Agentforce Marketing doit également comporter une logique de rationalisation. Certaines Data Extensions peuvent être supprimées. Certains flux historiques peuvent être simplifiés. Certaines intégrations peuvent évoluer. Certains journeys doivent rester en place tandis que d’autres peuvent progressivement être modernisés. L’objectif n’est pas d’utiliser toutes les nouvelles capacités Salesforce.

Il est de construire une architecture Marketing Cloud plus simple, mieux gouvernée et capable d’évoluer.t dans la qualité de leur plateforme que dans les capacités offertes par l’IA.

Pour une entreprise déjà équipée de Marketing Cloud Engagement, le projet devrait rarement commencer par la question : « quels cas d’usage Agentforce pouvons-nous activer ? ». Il devrait commencer par une analyse de l’existant.

La première étape consiste à cartographier les données, journeys, automatisations et intégrations réellement structurants. La deuxième consiste à définir le modèle cible dans Data 360 et les données qui doivent y être exposées. La troisième consiste à décider ce qui restera dans Marketing Cloud Engagement et ce qui bénéficiera progressivement de Marketing Cloud Next. Ce n’est qu’ensuite qu’une roadmap d’adoption peut être construite.

Cette approche permet d’éviter une erreur classique des transformations Salesforce : ajouter une nouvelle technologie à une architecture qui aurait d’abord eu besoin d’être simplifiée.

Agentforce Marketing ne doit donc pas être considéré uniquement comme un projet d’IA ou de marketing automation. Pour les entreprises déjà équipées de SFMC, il s’agit avant tout d’un projet de données, d’architecture et de gouvernance Salesforce.

Chez NeurovIA Consulting, nous accompagnons les entreprises dans l’audit et l’évolution de leurs environnements Salesforce, notamment lorsqu’une architecture Marketing Cloud Engagement doit intégrer les nouvelles capacités d’Agentforce Marketing et de Data 360. Nos consultants interviennent sur l’analyse de l’existant, la rationalisation des données et automatisations, la définition de l’architecture cible et la construction d’une trajectoire d’adoption adaptée aux processus déjà en production. L’objectif est de faire évoluer Salesforce sans reconstruire inutilement ce qui fonctionne, tout en évitant de transférer la dette technique existante vers la nouvelle génération de la plateforme.

L’évolution vers Agentforce Marketing ne peut pas être dissociée de la qualité et de la gouvernance des données utilisées par les agents IA. Modèle d’identité, données CRM incomplètes, doublons ou informations obsolètes peuvent directement limiter la pertinence des automatisations et décisions produites par Agentforce. Pour approfondir ce sujet, découvrez également notre article : Salesforce Agentforce : pourquoi la qualité des données est la clé du succès de l’IA.