Dans la revue d’un contrat Salesforce en Corée, la phrase la plus risquée est : « l’org sera utilisée en Corée, il suffit donc de vérifier la région ». Il faut vérifier le lieu de stockage, mais ce n’est qu’un point de départ. Une décision de transfert hors de Corée au titre de la loi coréenne sur la protection des données personnelles (PIPA) demande quel processus envoie quelles données personnelles à quel destinataire, et qui approuve et modifie ce chemin. Cette note est une liste de contrôle à préparer avec vos juristes et le DPO. Ce n’est pas un conseil juridique.
La région est un point de départ
Le texte anglais de la loi et l’avis de la Commission de protection des données personnelles sur la loi modifiée montrent que les conditions de transfert ne se réduisent pas au seul consentement, et que la réforme a créé une base légale pour ordonner la suspension d’un transfert.
La région où tourne l’instance compte, mais elle ne prouve pas que le stockage, le traitement, le support, les journaux et les intégrations externes restent tous dans le même pays. Salesforce renvoie d’ailleurs ses clients aux documents service par service de sa Trust and Compliance Documentation. Une mention de région dans une proposition commerciale ne démontre rien du chemin de traitement d’une org.
L’unité de revue, c’est le flux métier. Un conseiller qui traite un Case, un portail qui crée un Contact, un système externe qui lit des enregistrements par API : trois flux, trois revues. Avant la liste des fonctionnalités, établissez donc la liste des flux de données. Pour chaque flux, notez le système source et le destinataire, les champs identifiants, la finalité, le stockage ou non, le moment de l’envoi et le responsable opérationnel. Sans cette liste, le DPA, l’annexe sécurité, la politique de confidentialité et les écrans de paramétrage finissent par décrire des objets différents.
Sept points à clore avant le contrat
- Finalité métier. « Faire tourner le CRM » n’est pas une finalité. Découpez en unités de travail : classement des demandes, relances de renouvellement, connexion au portail partenaires. Une finalité trop large ne laisse aucun critère pour réduire les champs.
- Données concernées. Regardez les champs, pas les noms d’objets. Nom, coordonnées, numéro client, contenu des échanges, pièces jointes et commentaires libres ne portent pas le même risque. Mettez aussi sur la liste les copies de sandbox et les journaux d’erreurs.
- Destinataires et rôles. Salesforce, ses filiales, les sous-traitants ultérieurs, l’intégrateur et les services que le client contracte directement peuvent jouer des rôles différents. Le contrat doit dire qui fixe la finalité et les moyens, qui traite sur instruction, et qui notifie incidents et changements.
- Le chemin réel. Au-delà du stockage, vérifiez les appels API, les fichiers batch, le middleware d’intégration, les files de reprise des messages en échec et les pièces jointes aux demandes de support. C’est parfois hors de la base principale que les données personnelles restent le plus longtemps.
- Base légale et information. La voie applicable au titre de l’article 28-8 dépend de la relation contractuelle, du destinataire, du mode de transfert, de la finalité et des faits. Ce sont les juristes qui tranchent. L’équipe technique leur fournit, sous une forme vérifiable, les données transférées, le pays ou la région, le moment, le destinataire et la finalité.
- Conservation et suppression. Historiques de conversation, journaux d’audit, files d’erreurs d’intégration, sauvegardes et copies de sandbox peuvent suivre leurs propres règles de conservation. La matrice de responsabilités doit dire ce qui est supprimé en fin de contrat, comment, et quel enregistrement le prouve.
- Contrôle des changements. Un nouvel utilisateur d’intégration, une nouvelle Connected App, un nouveau Flow, un champ ajouté ou une action externe peuvent modifier un flux. Ajoutez à la demande de changement une case « données personnelles et impact transfrontalier », et une règle qui envoie les changements concernés en revue juridique et sécurité.
Ce septième point compte plus qu’une mise à jour annuelle des documents : le chemin réel change d’abord par les déploiements et le paramétrage.
Quand on active Agentforce et l’IA générative
Activer Agentforce ou Prompt Builder ajoute des lignes à la liste des flux. Une annonce d’investissement dans un pays ou une plaquette Hyperforce ne prouve pas où sont traités l’inférence, les journaux ou les données Data 360 d’une org donnée. Appliquez les mêmes sept points à trois endroits.
- Ingestion Data 360 et Identity Resolution. Vérifiez les champs ingérés, l’emplacement des sources et du tenant, les clés de rapprochement, la conservation et les accès. Limitez ces clés aux identifiants minimaux, et faites approuver à part tout identifiant sensible, avec sa nécessité et ses garanties.
- Entrées Prompt Builder. Vérifiez les champs qu’un template insère, si le masquage s’applique vraiment, quels fournisseurs de modèles et sous-traitants interviennent, et la durée de conservation des entrées, des sorties et des journaux d’audit. Activer les fonctions du Trust Layer ne clôt pas la revue PIPA.
- Appels externes depuis les actions. Quand MuleSoft, Apex, Flow ou External Services appellent un système extérieur, des sous-traitants et des régions hors du contrat Salesforce peuvent entrer dans le flux. Portez sur le schéma les champs en entrée et en sortie, l’identité qui s’authentifie, les journaux d’erreurs et les files de reprise.
La tokenisation et la pseudonymisation réduisent l’exposition. Selon le risque de réidentification et la gestion des clés, les données peuvent rester personnelles : la revue transfrontalière ne disparaît pas. Les contrôles côté templates sont traités dans la note Gouverner Prompt Builder.
Contrat et paramétrage, une seule preuve
Une liste de clauses ne suffit pas. Pour chaque flux, reliez le sous-traitant et la finalité prévus au contrat, la preuve de paramétrage ou d’intégration, la date à laquelle les appels réels ont été vérifiés, le responsable et la condition de la prochaine revue. Une page qui liste processus approuvés, champs autorisés et interdits, destinataires, durées de conservation et approbateur des changements permet au DSI et au DPO de voir ce que chacun valide.
En 2025, la Commission de protection des données personnelles a sanctionné Kakao Pay, Apple et d’autres pour des manquements liés aux transferts à l’étranger, en relevant que les personnes concernées ne pouvaient pas savoir que leurs données étaient sous-traitées et transférées (annonce de la PIPC). Ce dossier ne dit rien d’un contrat Salesforce, mais il montre le risque de l’argument « le sous-traitant figure au contrat, l’exploitation n’a donc rien à vérifier ».
Confier la réalisation à un intégrateur ne lui transfère pas la responsabilité du client. L’intégrateur produit le schéma des flux et les preuves de paramétrage, le client fixe la finalité et les critères d’approbation, les juristes et l’équipe protection des données se prononcent sur la base légale et l’information des personnes. Si ces livrables ne renvoient pas au même identifiant de flux, la revue reste décousue, RACI ou pas.
Quand un changement rouvre la revue
Une revue archivée comme document de clôture de projet est périmée au changement suivant. Tout changement n’appelle pas une analyse juridique complète, mais le responsable opérationnel doit savoir repérer ceux qui modifient les champs, les destinataires, la finalité, la conservation ou la région.
Ajouter une adresse e-mail à une intégration existante ressemble à un simple ajustement de mapping. Si le flux approuvé avait été conçu pour n’envoyer que le numéro client, les données traitées et le périmètre de l’information ont changé. Une mise en production qui ne touche que des libellés d’écran, avec le même chemin et la même finalité, peut se passer de cette revue. Le critère est de savoir si les faits du traitement ont changé, quelle que soit la taille de la fonctionnalité.