Configurer les portes d'approbation et les pistes d'audit des déploiements Salesforce

Réponse courte : une porte d'approbation est une règle qui bloque une promotion tant qu'une personne nommée, autre que l'auteur, n'a pas validé. Elle devient une piste d'audit quand l'approbation est enregistrée sur le commit exact et l'org cible, sans possibilité de modification ultérieure. Configurez cela une fois par environnement et vous cessez d'assembler des captures d'écran.

Qu'est-ce qui rend une porte d'approbation auditable ?

Une porte qui n'existe que dans les habitudes de quelqu'un n'est pas un contrôle. Quatre propriétés en font une preuve :

• Imposée. La promotion est techniquement impossible sans l'approbation, pas seulement déconseillée.
• Attribuée. L'approbateur est une identité authentifiée, pas un nom tapé dans un ticket.
• Liée. L'approbation pointe vers un commit précis et une org cible précise, donc elle ne peut pas servir pour un autre contenu.
• Immuable. Personne, administrateurs compris, ne peut modifier l'enregistrement après coup.

S'il en manque une, l'auditeur jugera tout le contrôle peu fiable, aussi beau que soit le processus sur une diapositive.

Qui approuve quoi, et à quel environnement ?

La plupart des équipes ne mettent aucune porte ou en mettent partout, et les deux échouent. Filtrez par risque, et écrivez-le :

• Org de feature ou scratch : pas de porte. La vitesse prime ici, et rien en aval ne s'y fie.
• Intégration ou QA : contrôles automatisés seulement. Tests, couverture et analyse statique ou revue de code par IA doivent passer. Pas de validation humaine.
• UAT ou préproduction : un approbateur humain, en général le tech lead, plus les contrôles automatisés. C'est là que les erreurs de conception coûtent encore peu.
• Production : deux approbateurs. Un relecteur technique différent de l'auteur, plus le responsable métier du processus concerné. Ajoutez une fenêtre de release, pour que les approbations ne se collectent pas à 23h un vendredi.
• Hotfix en production : un approbateur, avec un work item rétrospectif obligatoire sous 24 heures. Définissez le chemin plutôt que de prétendre qu'il ne servira pas.

Deux approbations en production, ce n'est pas de la bureaucratie. C'est la plus petite configuration qui tienne face à un test de séparation des tâches de type SOX, et cela coûte environ cinq minutes.

Comment configurer les portes ?

1. Retirez les droits de déploiement aux humains en production. Seule l'identité d'intégration du pipeline y détient Modify Metadata et Modify All Data. Ce seul changement rend toutes les autres portes réelles, car il n'y a plus de contournement.
2. Activez la protection de branche sur la branche liée à la production. Exigez des pull requests, au moins une revue approuvée, et désactivez l'auto-approbation.
3. Rendez les contrôles obligatoires, pas indicatifs. Tests Apex, seuil de couverture, analyse statique ou revue de code automatisée doivent être des status checks bloquants. Un contrôle qu'on peut ignorer n'est pas une porte.
4. Ajoutez une approbation au niveau de l'environnement pour la production. La protection de branche couvre le merge, la porte d'environnement couvre le déploiement. Vous voulez les deux, car elles répondent à des questions différentes.
5. Invalidez les approbations obsolètes à chaque nouveau commit. Sinon une pull request approuvée peut être modifiée après validation, ce qui casse discrètement la propriété de liaison ci-dessus.
6. Nommez les groupes d'approbateurs par rôle, pas par personne. Les gens partent. Les rôles sont ce que l'auditeur échantillonne.

Toutes les plateformes DevOps Salesforce courantes supportent ce schéma, dont Copado, Gearset, AutoRABIT, Flosum, Blue Canvas et Serpent, tout comme GitHub ou GitLab devant la CLI. C'est la configuration qui compte, pas le logo.

Que doit contenir l'enregistrement de déploiement ?

Quand un auditeur échantillonne dix releases, chacune doit se résoudre en un enregistrement portant :

• Le work item et sa raison métier.
• Le SHA du commit et le diff de métadonnées.
• Les identités des approbateurs, horodatées, et si l'auteur en fait partie.
• Le résultat des tests et la couverture au moment du déploiement, pas le chiffre d'aujourd'hui.
• L'org cible, le deploy ID et le résultat, y compris les échecs partiels.
• Tout marqueur d'exception, comme une release en break-glass.

Stockez cela hors de l'org. Les enregistrements qui ne vivent que dans Salesforce expirent, et les cycles d'audit sont annuels.

Pourquoi les journaux natifs ne suffisent pas

Ils valent la peine d'être activés, mais connaissez leurs limites :

• Setup Audit Trail garde 180 jours, n'affiche que les entrées les plus récentes dans l'interface et n'enregistre pas les valeurs avant et après. Téléchargez le CSV régulièrement ou interrogez l'objet SetupAuditTrail.
• Le Field History Tracking est limité à 20 champs par objet, conserve environ 18 mois dans l'interface et 24 via l'API, et ne suit ni les champs de formule, ni les roll-up summary, ni les numéros automatiques. Field Audit Trail avec Shield prolonge la rétention par politique.
• Aucun des deux ne dit si un changement a été approuvé. Ils enregistrent qu'une chose a changé, pas qu'elle était autorisée.

Cette dernière ligne explique pourquoi l'enregistrement du pipeline est la preuve principale et les journaux de l'org une corroboration.

Comment empêcher les changements qui contournent la porte ?

Le constat le plus fréquent n'est pas une mauvaise approbation, c'est un changement qui n'est jamais passé par le pipeline : un administrateur qui modifie une règle de validation en production un mardi après-midi. Fermez cela avec trois habitudes.

1. Lancez la détection de dérive régulièrement et comparez l'org de production à la branche. Tout ce qui est dans l'org et absent de Git est soit un changement non approuvé, soit une lacune de votre capture.
2. Rapprochez chaque semaine avec le Setup Audit Trail. Chaque entrée doit correspondre à un déploiement ou à une exception documentée.
3. Traitez une dérive répétée comme un bug de processus. Si les administrateurs contournent le pipeline, c'est qu'il est trop lent pour leur travail. Corrigez la friction, pas les personnes.

Avec ces trois habitudes, l'audit annuel cesse d'être un projet. D'autres guides de configuration vivent dans notre bibliothèque SF Guides.

FAQ

Combien d'approbateurs faut-il pour un déploiement en production ?

Deux est le standard pratique : un relecteur technique différent de l'auteur, plus le responsable métier du processus concerné. Un seul suffit pour un hotfix documenté.

L'auteur du changement peut-il l'approuver ?

Non. Cela casse la séparation des tâches et c'est la première chose que teste un auditeur. Désactivez l'auto-approbation dans la protection de branche, pour que la règle soit imposée et non mémorisée.

Les portes d'approbation ralentissent-elles les releases ?

Rarement, si vous filtrez par environnement. Les environnements bas restent sans porte, avec seulement des contrôles automatisés, donc l'étape humaine n'arrive qu'une fois, là où l'erreur coûte cher.

Le Setup Audit Trail suffit-il comme preuve ?

Non. Il garde 180 jours, omet les valeurs avant et après, et montre qu'un changement a eu lieu, pas qu'il était approuvé. Utilisez-le pour corroborer vos enregistrements de pipeline.