Cimulate RGPD : ce que les DSI doivent anticiper

L’acquisition de Cimulate par Salesforce n’est pas une annonce de roadmap produit. C’est un signal architectural. Pour les DSI français, la question n’est pas de savoir si la découverte conversationnelle va transformer le commerce. C’est de savoir si votre gouvernance des données produits est prête à opérer sous contraintes Cimulate RGPD dans un environnement où l’IA génère des recommandations à partir de catalogues produits enrichis de données comportementales.

La réponse, dans la majorité des organisations enterprise françaises, est non.

Ce que Cimulate change concrètement dans l’architecture Salesforce

Cimulate apporte à Salesforce une capacité de recherche et de découverte produit pilotée par des modèles de langage. L’idée : remplacer la recherche par mots-clés par une interface conversationnelle qui comprend l’intention d’achat et retourne des résultats contextualisés. Sur le papier, c’est une évolution naturelle d’Agentforce Commerce.

En pratique, cela signifie que le moteur de recommandation ne travaille plus uniquement sur des attributs produits statiques. Il travaille sur des signaux comportementaux, des historiques de navigation, des préférences inférées, potentiellement des données de profil unifiées via Data Cloud. C’est là que l’architecture bascule d’un problème de catalogue à un problème de données personnelles.

Un catalogue produit enrichi de métadonnées commerciales, c’est une donnée maîtrisée. Un catalogue produit croisé avec des profils comportementaux pour alimenter un agent conversationnel, c’est une donnée personnelle au sens du RGPD, avec toutes les obligations qui en découlent : base légale, durée de conservation, droit d’opposition, traçabilité des traitements.

La plupart des architectures Commerce Cloud existantes n’ont pas été conçues avec cette distinction en tête. Elles ont été conçues pour vendre.

Le problème de gouvernance que les DSI français sous-estiment

Dans les organisations avec plusieurs milliers de références produits et des flux de données comportementales actifs, la question n’est pas technique au départ. C’est une question de registre des traitements.

Avant d’intégrer Cimulate dans votre stack Salesforce, trois points doivent être clarifiés avec votre DPO.

Quelle est la base légale du traitement comportemental ? Si vous utilisez des données de navigation ou d’historique d’achat pour alimenter les recommandations conversationnelles, l’intérêt légitime ne suffit pas systématiquement. Dans les contextes B2C, le consentement reste la base la plus solide, et il doit être granulaire : consentir à recevoir des recommandations personnalisées via un agent IA n’est pas équivalent à consentir à la personnalisation d’une page catalogue.

Où les données sont-elles traitées ? Cimulate est une acquisition récente. La localisation des infrastructures de traitement, les sous-traitants impliqués, les éventuels transferts hors UE : tout cela doit être documenté avant mise en production. Salesforce dispose d’un DPA (Data Processing Agreement) standard, mais il ne couvre pas automatiquement les capacités acquises via M&A tant que leur intégration dans la plateforme principale n’est pas finalisée.

Comment les droits des personnes s’exercent-ils sur les données qui alimentent l’agent ? Si un utilisateur demande la suppression de ses données, cela doit se propager aux profils Data Cloud, aux Calculated Insights, aux Data Graphs qui ont pu servir à entraîner ou contextualiser les recommandations. Dans les architectures multi-cloud Salesforce, cette propagation n’est pas automatique. Elle se configure. Et dans la majorité des déploiements observés, elle n’est pas configurée.

L’architecture de gouvernance à mettre en place

Le problème n’est pas Cimulate en tant que tel. Le problème, c’est que Cimulate va accélérer l’adoption de patterns d’IA conversationnelle dans Commerce Cloud, et que ces patterns supposent une maturité de gouvernance des données que peu d’organisations françaises ont atteinte.

L’architecture qui fonctionne ici repose sur trois couches distinctes.

Couche 1 : Séparation des données produits et des données comportementales dans Data Cloud. Les Data Model Objects doivent distinguer clairement ce qui relève du catalogue (données non personnelles, gérées par le PIM) de ce qui relève du profil comportemental (données personnelles, soumises au RGPD). Cette séparation n’est pas seulement une bonne pratique de modélisation. C’est ce qui permet d’appliquer des politiques de rétention différenciées et de répondre aux droits d’accès sans exposer l’intégralité du profil unifié.

Couche 2 : Traçabilité des traitements via les Data Streams. Chaque flux d’ingestion qui alimente les recommandations conversationnelles doit être documenté dans le registre des traitements. Les Data Streams de Data Cloud offrent une granularité suffisante pour identifier l’origine des données, leur fréquence de mise à jour et leur durée de vie. Cette traçabilité doit être exportable vers votre outil de gestion des traitements (OneTrust, Didomi, ou équivalent) et non maintenue manuellement dans un tableur.

Couche 3 : Gouvernance des prompts et des contextes dans Agentforce. Quand Cimulate s’intègre à Agentforce, les Topics et Actions de l’agent vont définir quelles données sont injectées dans le contexte de la conversation. Prompt Builder permet de contrôler ce qui est transmis au modèle. C’est à ce niveau que la minimisation des données s’applique concrètement : l’agent n’a pas besoin de connaître l’intégralité du profil unifié pour faire une recommandation pertinente. Il a besoin des Calculated Insights pertinents, pas des données brutes.

Un pattern courant dans les organisations enterprise qui déploient des agents IA sur des données clients : ils transmettent trop de contexte par défaut, parce que c’est plus simple à configurer. Cela fonctionne jusqu’au moment où un audit RGPD ou une demande de droit d’accès révèle que le modèle a reçu des données qu’il n’aurait pas dû recevoir. À cette échelle, le risque n’est pas théorique.

Ce que les ESN Salesforce doivent comprendre

Pour les ESN qui accompagnent des clients sur des projets Commerce Cloud, l’intégration de Cimulate va créer une nouvelle catégorie de risque projet. Les équipes techniques vont vouloir activer les capacités conversationnelles rapidement. Les équipes juridiques et conformité vont freiner, souvent sans comprendre précisément pourquoi.

Le rôle de l’architecte solution dans ce contexte est de traduire. Pas de choisir un camp.

La traduction concrète : avant de démarrer un chantier d’intégration Cimulate, produire une cartographie des flux de données personnelles impliqués. Identifier les traitements nouveaux par rapport à l’existant. Qualifier la base légale pour chacun. Soumettre à validation DPO avant la phase de build, pas après.

Ce séquençage coûte deux à trois semaines en amont. Il évite des refontes architecturales en cours de projet, qui coûtent dix fois plus.

Pour les ETI françaises qui n’ont pas de DPO interne à temps plein, la question se pose différemment. L’architecte solution doit être capable de produire une analyse de risque RGPD suffisamment structurée pour qu’un DPO externe puisse se prononcer rapidement. Ce n’est pas un travail juridique. C’est un travail de documentation architecturale avec les bonnes questions posées aux bonnes personnes.

Ce que la décision actuelle détermine

Salesforce va intégrer Cimulate progressivement dans Commerce Cloud et Agentforce. La roadmap exacte n’est pas encore publique, mais le pattern d’intégration post-acquisition Salesforce est prévisible : d’abord une intégration via API, ensuite une intégration native dans la plateforme, enfin une convergence avec Data Cloud pour les profils unifiés.

La décision actuelle détermine si votre organisation aborde cette intégration avec une gouvernance des données produits déjà en place, ou si elle la construit en urgence sous pression d’un audit ou d’une mise en production qui dérape.

Dans 18 mois, les organisations qui auront structuré leur registre des traitements, séparé leurs données produits de leurs données comportementales dans Data Cloud, et configuré la propagation des droits des personnes auront un avantage opérationnel réel. Pas un avantage concurrentiel abstrait. Un avantage concret : elles pourront activer les nouvelles capacités Salesforce sans bloquer sur la conformité à chaque itération.

Les autres passeront ce temps à rattraper une dette de gouvernance qui s’accumule à chaque déploiement.

Points clés

• L’acquisition Cimulate déplace le périmètre RGPD des données produits vers les données comportementales : ce qui était un problème de catalogue devient un problème de données personnelles dès que l’IA conversationnelle entre dans la boucle.
• Dans les architectures Data Cloud existantes, la propagation des droits des personnes (suppression, accès, opposition) n’est pas automatique. Elle se configure explicitement, et dans la majorité des déploiements observés, elle ne l’est pas.
• La séparation des Data Model Objects entre données catalogue et données comportementales est le prérequis architectural à toute intégration Cimulate conforme.
• Prompt Builder est le point de contrôle de la minimisation des données dans Agentforce : c’est là que se décide ce que l’agent reçoit comme contexte, et donc ce qui est transmis au modèle.
• Les ESN qui séquencent la cartographie RGPD avant la phase de build économisent en moyenne dix fois le coût d’une refonte architecturale en cours de projet.