Health Check, Security Center, audit manuel, OrgGuardian : ce que chacun voit, et ce qu'aucun ne voit

Que voit chacun des quatre ?

Chaque ligne est un plan d'observation, pas une fonctionnalité, et chaque cellule ne prend que trois valeurs. oui : le plan est couvert. partiel : une facette seulement, et la réserve est écrite noir sur blanc dans la section de l'outil plus bas. non : aucune couverture décrite pour ce plan — ce qui dit ce que nous avons trouvé, pas ce dont l'outil serait incapable.

Deux lectures sautent aux yeux, et elles vont dans les deux sens. La colonne audit manuel est presque pleine : un humain compétent, avec assez de temps, n'a quasiment aucun angle mort de capacité. Et la dernière ligne est la seule où OrgGuardian dit non quand Security Center dit oui — c'est délibéré, et c'est expliqué plus bas.

Health Check : la seule source sur les réglages

Le Health Check natif note des réglages de session et de mot de passe contre une base de référence, en quatre niveaux de risque, et accepte des bases de référence personnalisées si votre standard interne diffère de celui de Salesforce. Il est inclus, il ne s'installe pas, et il se lit en une minute. Health Check (aide Salesforce).

Il ne fait pas que lire. Son bouton « Fix Risks » applique plusieurs réglages de sécurité — voire tous — en une seule action, contre la base de référence retenue. C'est la raison du partiel qu'il reçoit sur la ligne « déploiement d'une politique de sécurité », et la réserve tient en une phrase : il applique une base dans une org, là où Security Center pousse une politique vers un parc. Configurer Health Check (atelier Salesforce).

Sur ce plan précis, il lit ce qu'OrgGuardian ne lit pas. Longueur minimale de mot de passe, expiration, délai d'expiration de session, verrouillage de session sur l'adresse IP, réauthentification forcée, protection contre le détournement de clic, plages IP de connexion, heures de connexion : ces réglages ne sont pas exposés à une requête SOQL. Ils ne se lisent que par l'API Metadata, ce qu'OrgGuardian a choisi de ne pas faire par défaut. Dix contrôles sont explicitement différés dans son code pour cette raison.

Sa limite est celle de son périmètre, pas de sa qualité : il ne regarde ni les droits effectifs, ni les applications connectées, ni les intégrations sortantes, ni le code. Un score de 90 % au Health Check est compatible avec un compte d'intégration qui cumule Modifier toutes les données et une API sans MFA. Il est aussi ponctuel : un score dit l'état du moment où on a cliqué.

Les deux réserves qui valent un « partiel » et non un « non » — relevées au sourçage du 2026-09-08, et qui corrigent deux affirmations fausses de ce tableau. Accès invités : depuis Winter ’24, Health Check expose deux réglages nommés Number of Objects to which Guest User Profiles have Read Access et … Edit Access. Il compte des objets exposés ; il ne dit ni quel site, ni quel profil, ni quel enregistrement — d’où le partiel. Partage par défaut (OWD) : Health Check embarque bien un contrôle, Number of Objects with Default External Access Set to Public, classé à haut risque. Là encore c’est un compte d’objets, pas la matrice de partage : ni la hiérarchie de rôles, ni les règles de partage, ni le partage manuel. Vérifié hors documentation, par requête Tooling API en lecture seule sur notre propre org : SELECT RiskType, SettingGroup, Setting FROM SecurityHealthCheckRisks.

Security Center : la flotte, et la politique qu'on pousse

Security Center agrège la sécurité de plusieurs orgs dans une vue unique : des orgs enfants remontent leurs données à une org parente. C'est sa raison d'être, et sur ce terrain il est plus direct qu'OrgGuardian. Il expose plus de quatre-vingts métriques de sécurité et de gouvernance — méthodes d'authentification, attributions de permissions, paquets installés, données de Health Check — avec des notifications personnalisables quand l'une d'elles bouge. Security Center (aide Salesforce).

Deux capacités méritent d'être nommées sans les diminuer. La première : il montre quand un utilisateur gagne ou perd une permission, et par quel profil ou quel ensemble d'autorisations il l'a obtenue. La seconde : il déploie une politique — délais d'expiration de session, plages IP de confiance, configuration des mots de passe, base de référence Health Check — vers les orgs concernées.

Cette seconde capacité est celle qu'OrgGuardian n'aura pas. Security Center agit ; OrgGuardian constate et documente. Si votre besoin est d'appliquer un standard de configuration sur un parc d'orgs, c'est l'outil de Salesforce qui le fait, et aucune page de comparaison n'y changera rien.

Ce que nous n'avons pas trouvé décrit dans sa documentation publique : la supervision des intégrations sortantes et des endpoints de callout, l'analyse du code Apex déployé, le rattachement article par article à DORA ou NIS2, le chiffrage du risque en euros, et la marge restante sur les limites de la plateforme — ses métriques documentées portent l'authentification, les attributions de permissions, les paquets installés et les données de Health Check, pas la consommation des limites. C'est pourquoi cette ligne lui vaut un non, au sens que ce tableau donne à ce mot : aucune couverture décrite, et non une incapacité. C'est un produit sous licence, dont nous ne commentons pas le prix.

Quatre réserves, relevées au sourçage du 2026-09-08 — trois d’entre elles corrigent un « oui » que ce tableau n’aurait pas dû écrire. Droits effectifs : la documentation décrit la consolidation des permissions système critiques (View All Data, Modify All Data), pas la résolution complète profil + ensembles cumulés pour un utilisateur donné. Comptes d’intégration sans MFA : les deux facettes existent séparément — une carte Authentication by Type, et le suivi des utilisateurs sans MFA — mais rien ne documente leur croisement sur les comptes d’intégration. Applications connectées : l’inventaire est documenté (quelles apps, installées par qui, quand), pas les portées OAuth ni les jetons dormants. Certificats : l’objet TenantSecurityCertificate porte ExpirationDate et KeySize — deux des trois attributs de ce plan. En revanche, l’énumération de la famille TenantSecurity* ne rend aucun objet Named Credential, External Credential, Remote Site Setting ni endpoint de callout : les intégrations sortantes, elles, restent non décrites.

L'audit manuel : le seul des quatre qui a du jugement

Un auditeur humain est le seul à pouvoir demander pourquoi un droit existe. Il appelle la personne qui l'a accordé, il apprend que le compte sert à un flux de facturation trimestriel, et il décide. Aucun outil ne fait ça. Il est aussi le seul à voir ce qui vit hors de l'org : le middleware, l'entrepôt de données, le poste de travail où l'export a atterri.

Son angle mort n'est donc pas la couverture, c'est le calendrier. Le droit effectif d'un compte est la somme de son profil et de tous ses ensembles d'autorisations, et cette somme change entre deux revues. Sur une org de quelques centaines d'utilisateurs, une revue sérieuse se compte en jours — et elle est périmée le lendemain. Le produit cartésien profils × ensembles × utilisateurs dépasse ce qu'une revue trimestrielle peut couvrir.

C'est pour ça que la bonne question n'est jamais « outil ou humain » : la première passe se fait très bien à la main, c'est la répétition qui demande de l'outillage.

OrgGuardian : les plans qu'il mesure, et ceux qu'il ne mesure pas

OrgGuardian s'installe dans l'org et mesure ce qui est interrogeable depuis Apex. Concrètement, et c'est vérifiable dans son code : le droit effectif de chaque utilisateur actif, calculé comme l'union de son profil et de tous ses ensembles d'autorisations, avec détection d'escalade entre deux scans ; les comptes — humains et d'intégration — non couverts par une permission imposant le MFA ; les applications connectées avec leurs portées, leur volume d'usage et la date de dernier emploi de leurs jetons ; les droits objet réellement portés par chaque profil invité Experience Cloud ; les valeurs par défaut de partage qui exposent des enregistrements en lecture ou en écriture, en interne comme à l'externe ; les identifiants nommés et les sites de confiance CSP ; la marge sur les limites de la plateforme ; les actions d'administration à risque des sept derniers jours ; la dérive de configuration par empreinte entre deux mesures ; et les postures de sécurité de chaque source Apex de premier rang — classes comme déclencheurs — avec la note de dette qui en découle.

Tout ce qui précède se lit par simple requête, sans le moindre appel sortant, et sans aucune configuration à poser : il n'y a ni identifiant à créer, ni connecteur à autoriser.

Une précision que nous préférons écrire plutôt que vous laisser découvrir. Ce pack de sécurité relève de l'offre TPE et au-delà. Sur l'offre Découverte — gratuite, celle avec laquelle on installe pour évaluer — il ne produit rien : le scan sort sans émettre de constat. Ce que vous voyez le jour 1 en Découverte, ce sont la supervision, les limites de plateforme et l'inventaire des endpoints. La liste ci-dessus décrit donc ce que le produit SAIT faire, pas ce qu'une installation gratuite affiche : demandez un accès si vous voulez l'évaluer sur votre org.

Ce qu'il ne fait pas — la liste complète

1. Il ne remédie jamais. C'est une posture de conception, pas une version 1 incomplète. Une remédiation prend la forme d'un texte d'impact métier, d'un niveau de risque du changement, d'étapes numérotées et d'un lien vers le bon écran de Setup. L'action reste humaine, de bout en bout.
2. Il ne lit pas les réglages de session et de mot de passe. Dix contrôles — longueur et expiration de mot de passe, expiration de session, verrouillage sur IP, réauthentification, HttpOnly, détournement de clic, confirmation d'identité par SMS, plages IP et heures de connexion — sont différés dans le code parce qu'ils ne sont pas exposés à SOQL. Une porte optionnelle (Org_Hardening_Audit) les fait basculer vers une lecture réelle de la configuration ; ils restent différés tant qu'elle est fermée, et elle l'est par défaut. C'est exactement le domaine du Health Check, et c'est la raison la plus simple de garder les deux.
3. Il ne voit pas ce qui sort de l'org. Il voit l'endpoint déclaré et la portée OAuth accordée. Il ne voit pas le système de l'autre côté, ni ce que celui-ci fait de la donnée une fois qu'elle y est arrivée.
4. Une grande partie de l'inventaire sortant est éteinte à la livraison. Remote Site Settings, services externes, messages sortants, identifiants externes, échéances de certificats, sonde d'endpoints : aucun de ces objets n'est exposé à une requête. Il faut passer par l'API Tooling, c'est-à-dire par un appel sortant vers votre propre org. Ces détecteurs existent, ils sont derrière des interrupteurs, et ces interrupteurs sont éteints par défaut pour qu'une installation standard ne produise aucun flux sortant. Les activer est une décision d'administrateur, pas un réglage d'usine.
5. L'analyse du code Apex est un détecteur de motifs, pas un analyseur statique. Elle lit chaque classe et chaque déclencheur de premier rang, repère les postures de sécurité manquantes sur le code déployé et mesure la dette. Elle ne prouve pas l'absence de faille logique : elle reconnaît des formes, elle ne suit pas une valeur à travers un graphe d'appels. C'est une limite de PROFONDEUR, pas de périmètre — un humain qui lit le même code y voit des choses qu'elle ne verra pas.
6. Le rattachement réglementaire n'est pas une garantie de conformité. 95 rattachements sur 118, tous référentiels confondus, sont déclarés partiels : ils n'observent que la facette nommée par leur preuve. La portée de chaque rattachement est affichée dans le produit.
7. L'agrégation multi-org est une option, pas le mode par défaut. Elle est réservée au palier haut, désactivée à l'installation, et demande un identifiant nommé inter-org par org reliée. Security Center part de là ; OrgGuardian y arrive.
8. Les textes de constat sont rédigés en français. Impact métier, étapes de remédiation, synthèses : il n'existe pas encore de variante anglaise de ces textes dans le package.

Et Shield ? Ce qu'il chiffre, ce qu'il journalise

Shield n'est pas un cinquième concurrent, et c'est la raison pour laquelle il manque à la plupart des comparatifs : il ne répond pas à la même question. Les quatre outils ci-dessus disent dans quel état est la configuration. Shield — trois produits vendus ensemble — agit sur la donnée elle-même : Platform Encryption la chiffre au repos, Event Monitoring journalise qui a fait quoi (connexions, exports de rapports, appels d'API, requêtes), et Field Audit Trail conserve l'historique des champs jusqu'à dix ans. Aucun des trois ne dit qu'un profil d'intégration cumule Modifier toutes les données et une API sans MFA ; aucun des quatre autres ne dit qui a exporté un rapport hier soir.

La question réellement posée — « on nous a chiffré Shield, faut-il les deux ? » — a une réponse courte : ils ne se remplacent pas, et l'un enrichit l'autre. Sans Event Monitoring, OrgGuardian déduit l'export de masse d'une capacité (le droit de le faire) ; avec, il l'observe (qui l'a fait, quand, depuis où), et ses détecteurs de journaux — requêtes lentes, erreurs non gérées, concurrence — s'allument. C'est une option désactivée à l'installation, réservée au palier Entreprise, et qui ne crée aucun flux sortant : les fichiers de journal sont lus depuis l'org, dans l'org.

Une exception mérite d'être isolée, parce qu'elle inverse l'arbitrage : les anomalies de connexion ne demandent pas Shield. Pays jamais vu, voyage impossible, connexion hors horaires d'un compte privilégié : ces trois signaux sont dérivés de LoginHistory et LoginGeo, deux objets présents dans toute org, à chaque scan. Là où Security Center rafraîchit ses indicateurs une fois par jour, le signal qui compte le plus — un identifiant d'administrateur qui se met à servir depuis un pays qu'il n'a jamais utilisé — est disponible sans licence supplémentaire et sans attendre le lendemain.

Ce qui tranche l'arbitrage budgétaire, c'est le risque que vous portez. Une obligation de chiffrement au repos ou de conservation d'historique (DORA art. 9, exigences sectorielles) se règle avec Shield, et avec rien d'autre. Un profil d'intégration surprivilégié, un jeton OAuth dormant, un site invité qui expose un objet se règlent avec une mesure de configuration — et Shield, quel que soit son prix, ne les verra jamais. Salesforce ne publie pas le prix de Shield ; nous n'en ferons pas une colonne de tableau.

Que ne voit aucun des quatre ?

La partie honnête d'une comparaison est celle où les quatre colonnes sont vides.

• L'intention. Un droit légitimement utilisé et le même droit détourné ont exactement la même signature dans la configuration. Aucun des quatre ne fait la différence.
• La donnée une fois sortie. Un export peut laisser une trace administrative. Ce qui arrive au fichier ensuite — où il est déposé, qui le rouvre, combien de temps il reste — n'appartient plus à l'org, et échappe aux quatre.
• L'autre côté de l'intégration. L'org sait qu'elle appelle un endpoint. Elle ne sait pas qui l'exploite, ni si ce système est lui-même tenu.
• La criticité métier d'un champ. Qu'une colonne porte une donnée contractuellement sensible est une information qui se déclare. Elle ne se déduit d'aucune métadonnée.
• La conformité elle-même. Les quatre produisent des faits. Le verdict de conformité reste un jugement, rendu par une personne qui engage sa responsabilité.

Comment choisir ? Une phrase par cas

Si vous voulez savoir où vous en êtes sur les réglages : Health Check, ce soir, sans rien installer ni acheter. Si vous gérez un parc d'orgs et voulez y appliquer un standard commun : Security Center. Si vous devez comprendre une situation particulière, avec du contexte et des gens à interroger : un audit manuel, et rien d'autre. Si le problème est que la mesure ne se répète pas assez souvent, qu'elle n'atteint ni les droits effectifs ni les intégrations ni le code, et qu'il faut la présenter à un auditeur : c'est le terrain d'OrgGuardian.

Faut-il désinstaller Health Check si on installe OrgGuardian ?

La question ne se pose pas — Health Check est natif, il ne s'installe ni ne se désinstalle. Et ce serait une mauvaise idée de cesser de le lire : il couvre les dix contrôles de réglages qu'OrgGuardian a explicitement différés.

Security Center et OrgGuardian se recouvrent-ils ?

Sur les droits, les applications connectées et la dérive, oui, en partie. Pas sur les intégrations sortantes, le code, le rattachement réglementaire ni le chiffrage. Et pas du tout sur la nature de l'outil : l'un déploie une politique, l'autre reste en lecture seule.