Audit Trail : suivre les changements de configuration

Qui a modifié ce profil hier ? Qui a désactivé cette règle de validation la semaine dernière ? Ces questions, posées après un incident ou lors d'un audit de conformité, trouvent leur réponse dans le Setup Audit Trail, le journal natif et gratuit de Salesforce qui trace les modifications de configuration. Il ne faut cependant pas le confondre avec Field Audit Trail, module Shield distinct qui trace les modifications de données.

1. Setup Audit Trail : la configuration, pas les données

Accessible via Configuration > Sécurité > Historique des configurations (Setup Audit Trail), ce journal enregistre automatiquement, sans configuration préalable, les 20 dernières modifications... ou plutôt tout l'historique disponible en téléchargement CSV complet sur 6 mois glissants (accessible via le lien "Télécharger tout l'historique des paramètres"). Sont tracés :

• Création/modification/suppression de profils, permission sets, rôles.
• Changements de règles de partage, OWD, hiérarchies.
• Activation/désactivation de Flows, Apex Triggers, règles de validation.
• Modifications de champs (création, suppression, changement de type).
• Changements des paramètres de sécurité eux-mêmes (session, MFA, IP).

Chaque ligne indique la date, l'utilisateur responsable, et une description de l'action. C'est gratuit, activé par défaut, sans aucune configuration — la première chose à consulter lors de toute investigation sur un changement de comportement inattendu de l'org.

2. Les limites du Setup Audit Trail natif

Le Setup Audit Trail ne conserve que 6 mois d'historique en téléchargement, et l'affichage UI standard n'en montre qu'un sous-ensemble limité. Pour une conservation longue durée requise par une obligation réglementaire (7 ans en finance par exemple), il faut exporter régulièrement ces données vers un stockage externe (data warehouse, SIEM) via un job planifié.

Autre limite importante : il ne trace que la configuration, pas les modifications des enregistrements métier eux-mêmes (un compte, une opportunité modifiée). Pour ça, il faut soit les champs standards LastModifiedBy/LastModifiedDate (insuffisants pour un historique complet des valeurs successives), soit activer le suivi d'historique des champs, soit Field Audit Trail pour aller plus loin.

3. Le suivi d'historique des champs standard

Pour un objet donné, Configuration > Objets > [Objet] > Suivi de l'historique des champs permet d'activer le suivi champ par champ (limité à 20 champs suivis par objet en standard). Chaque modification génère une ligne dans la liste associée "Historique" visible sur l'enregistrement, avec l'ancienne et la nouvelle valeur. Rétention : 18 mois par défaut dans l'objet lui-même.

4. Field Audit Trail (Shield) : au-delà des 20 champs et 18 mois

Field Audit Trail, module payant de Shield, lève ces deux limites :

• Jusqu'à 60 champs suivis par objet (au lieu de 20).
• Conservation configurable jusqu'à 10 ans, avec archivage automatique dans Big Object plutôt que dans la liste associée standard, ce qui préserve les performances de l'org.
• Politique de rétention définissable par objet via des Field Audit Trail Retention Policies, activables en Apex ou Metadata API.

C'est le module recommandé pour les secteurs réglementés (santé, finance, assurance) où la preuve de non-altération des données sur plusieurs années est une exigence de conformité explicite (traçabilité opposable en cas de contrôle).

5. Construire une routine d'audit efficace

1. Export automatisé mensuel du Setup Audit Trail complet vers un stockage externe pérenne, avant expiration des 6 mois.
2. Revue périodique (trimestrielle a minima) des modifications de profils, permission sets et règles de partage — pas seulement en réaction à un incident.
3. Alerte automatique sur les changements critiques : modification du profil Administrateur système, désactivation de MFA, changement d'OWD — via un Flow déclenché sur un objet de journalisation ou une intégration SIEM en Real-Time Event Monitoring.
4. Corrélation entre Setup Audit Trail (qui a changé la config) et Event Monitoring (qui a exploité ce changement ensuite) pour une vision complète en cas d'incident.

Un Audit Trail non consulté n'a aucune valeur préventive : sa richesse ne compense jamais l'absence de processus de revue régulier — c'est le processus, pas seulement l'outil, qui fait la sécurité.