Conformité SOX et RGPD dans un processus de release Salesforce

Réponse courte : SOX exige de prouver que l'auteur d'un changement ne l'a pas mis en production lui-même, et que chaque changement en production remonte à une demande approuvée. Le RGPD exige de prouver que les données personnelles ont été minimisées et protégées, y compris dans les sandbox. Un pipeline normal produit déjà l'essentiel de ces preuves : le travail consiste à lui faire imposer les contrôles, plutôt qu'à les reconstituer à la main une fois par an.

Qu'exigent réellement SOX et le RGPD d'un processus de release ?

Deux lois différentes, une exigence commune : des contrôles conçus, appliqués et prouvés.

• SOX (Sarbanes-Oxley) s'applique aux sociétés cotées aux États-Unis. La section 404 impose à la direction d'évaluer le contrôle interne de l'information financière. En pratique, l'auditeur teste les contrôles généraux informatiques : qui peut modifier les systèmes qui produisent les chiffres financiers, comment ces changements sont approuvés, et si les accès sont appropriés.
• Le RGPD s'applique dès que vous traitez des données personnelles de personnes situées dans l'UE. Pour un processus de release, les obligations pertinentes sont la minimisation des données (article 5), la protection des données dès la conception et par défaut (article 25) et la sécurité du traitement (article 32).

Aucune des deux ne nomme d'outil. Les deux demandent les mêmes trois choses : un contrôle, la preuve qu'il s'est exécuté, et la preuve qu'il s'est exécuté à chaque fois.

Quelles parties d'une org Salesforce sont dans le périmètre ?

Pas la totalité, et trancher tôt est ce qui garde l'audit petit. Le périmètre SOX suit les chiffres financiers :

• Les objets et l'automatisation qui alimentent la reconnaissance du revenu, la facturation, le devis et le forecast : Opportunity, Order, Product, Price Book, configuration CPQ ou Revenue Cloud, processus d'approbation des remises.
• Tout ce qui peut modifier ces valeurs sans intervention humaine : Flows, triggers Apex, règles de validation, utilisateurs d'intégration.
• Les profils, permission sets et permission set groups qui accordent un accès en écriture sur ce qui précède.

Le périmètre RGPD a la forme inverse : il suit les données personnelles où qu'elles se trouvent, donc généralement Contact, Lead, Case, Person Account, transcriptions de chat et chaque copie sandbox de ces donnees.

Écrivez le périmètre avant l'audit. Répondre à cette question pour la première fois en pleine réunion d'audit, c'est ainsi qu'une revue se transforme en deux semaines de panique.

Comment imposer la séparation des tâches sans ralentir les releases ?

La séparation des tâches signifie que l'auteur d'un changement ne peut pas être celui qui le promeut en production. Les change sets ne savent pas l'imposer : quiconque peut déployer peut aussi construire. Placez donc le contrôle dans le pipeline :

1. Retirez les droits de déploiement aux humains en production. Seule l'identité d'intégration du pipeline déploie. Modify All Data et Modify Metadata en production appartiennent à cette identité, pas aux développeurs ni aux administrateurs.
2. Faites de la pull request le point de contrôle. Exigez au moins une revue approuvée par quelqu'un d'autre que l'auteur et désactivez l'auto-approbation dans la protection de branche.
3. Découpez l'approbation par environnement. Une promotion vers l'UAT peut être validée par le tech lead. Une release en production requiert en plus le responsable métier du processus concerné.
4. Tracez le chemin d'urgence au lieu de l'interdire. Les déploiements en break-glass arrivent. Définissez qui peut en déclencher un, exigez un work item rétrospectif sous 24 heures et enregistrez-le comme exception. Un auditeur accepte une exception documentée, jamais une exception invisible.

Quelles preuves de changement un auditeur accepte-t-il ?

Les auditeurs échantillonnent. Ils choisissent quelques changements en production et vous demandent de dérouler chacun, de la demande à la mise en production. Un pipeline répond par des liens, pas par des captures d'écran :

• Le work item, avec la raison métier et le demandeur.
• Les commits, montrant exactement quelles métadonnées ont changé.
• La pull request, avec l'identité du relecteur et l'horodatage.
• La preuve de test : tests Apex, couverture, analyse statique ou sortie de la revue de code automatisée.
• L'enregistrement du déploiement : org cible, deploy ID, déclencheur et résultat.

Deux propriétés font passer ces preuves : elles doivent être immuables et complètes, c'est-à-dire qu'aucune route vers la production ne les contourne. Un pipeline qui couvre 90% des changements échoue quand même, car l'échantillon peut tomber sur les 10% restants.

Comment gérer les données personnelles en sandbox sans enfreindre le RGPD ?

Un refresh de sandbox complète copie des données personnelles de production vers un environnement aux accès plus larges et aux utilisateurs plus nombreux. C'est un traitement, et il demande la même justification que n'importe quel autre.

• Semez, ne clonez pas. Prenez un échantillon représentatif plutôt que toute la base. Moins de données, c'est moins d'exposition et un refresh plus rapide.
• Masquez à l'arrivée. Anonymisez ou pseudonymisez les champs personnels dans le refresh lui-même, jamais en tâche de suivi dont quelqu'un doit se souvenir. Salesforce Data Mask couvre les schémas standards.
• Restreignez l'accès aux sandbox comme en production. Mêmes profils, même discipline sur les permission sets, même sortie des collaborateurs. Une sandbox partielle avec de vrais e-mails et un profil permissif est le constat que nous voyons le plus souvent.

Combien de temps faut-il conserver les preuves ?

Plus longtemps que Salesforce ne les conserve pour vous. Le Setup Audit Trail garde une fenêtre glissante de 180 jours, téléchargeable en CSV. Le Field History Tracking conserve environ 18 mois dans l'interface et 24 via l'API, sauf si vous souscrivez Field Audit Trail avec Shield et définissez une politique de rétention. Les cycles SOX sont annuels et les preuves sont demandées sur toute la période : les fenêtres natives ne suffisent pas.

Git et votre plateforme DevOps règlent cela : l'historique du dépôt est permanent et les enregistrements de déploiement vivent hors de l'org.

À quoi ressemble un pipeline conforme de bout en bout ?

1. Chaque changement commence par un work item porteur d'une raison métier et atterrit dans le contrôle de version.
2. Revue automatisée et tests s'exécutent sur la pull request, avant tout regard humain.
3. Un approbateur autre que l'auteur valide, avec un second approbateur à la porte de production.
4. Seule l'identité du pipeline déploie, et chaque déploiement écrit un enregistrement immuable.
5. Les refresh de sandbox sont semés et masqués par la même automatisation, et les preuves s'exportent à la demande.

Rien de tout cela n'exige un produit de conformité séparé, mais le processus de release que vous vouliez déjà, configuré pour que les contrôles soient l'unique chemin. La plupart des plateformes le permettent, dont Copado, Gearset, AutoRABIT, Flosum et Serpent. D'autres guides vivent dans notre bibliothèque SF Guides.

FAQ

SOX s'applique-t-il à toute notre org Salesforce ?

Non. Le périmètre suit l'information financière : devis, commandes, facturation, objets de revenu et l'automatisation qui les touche. Documentez la frontière vous-même, avant que l'auditeur ne l'élargisse.

Peut-on être conforme SOX avec des change sets ?

C'est très difficile. Les change sets ne séparent pas l'auteur du déployeur et ne laissent aucun enregistrement d'approbation lié : vous finissez par bâtir une couche de preuves manuelle à côté.

Une sandbox complète avec des données de production viole-t-elle le RGPD ?

Pas automatiquement, mais c'est un traitement qu'il faut justifier, minimiser et sécuriser. Semer un sous-ensemble et masquer les champs personnels au refresh est la voie pratique.

Qui doit approuver une release en production ?

Quelqu'un d'autre que l'auteur, plus le responsable métier du processus concerné pour tout ce qui est dans le périmètre SOX. Enregistrez les deux approbations sur le changement.