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é en une seule action, contre la base de référence retenue — pas tous : Salesforce précise que certains ne se corrigent pas par ce bouton. 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 reste la référence. 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 confiance : ces réglages ne sont pas exposés à une requête SOQL. Ils se lisent par l'API Tooling, un appel vers l'org elle-même qu'OrgGuardian laisse fermé par défaut. Une fois que l'administrateur a câblé l'identifiant nommé OS_SelfOrg vers son org (adresse de l'org et identifiants d'une application cliente) et ouvert la découverte par l'API Tooling, OrgGuardian lit le Health Check lui-même : son score, sa base de référence active et le verdict de chacun de ses réglages, puis signale une baisse du score. Cette configuration est ouverte à toutes les offres, Découverte comprise : Salesforce publie Health Check gratuitement, nous ne faisons pas payer le chemin qui le lit. Sans cet accès, OrgGuardian n'en recalcule que quatre, en SOQL, sans configuration et dès la première analyse, offre Découverte comprise : la part d'administrateurs système parmi les utilisateurs internes actifs, les objets lisibles et les objets modifiables par les profils invités, et les objets dont l'accès externe par défaut est public.

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 le code ; des intégrations sortantes, il ne voit que les certificats et les sites distants. 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 n'est plus tout à fait ponctuel : depuis le 15 avril 2026, Salesforce notifie chaque semaine, par défaut, les administrateurs système des orgs de production quand le score baisse. La notification porte sur le score global ; la tendance du score sur 30 jours, et les réglages qui ont pesé sur le score d'un jour donné, se lisent gratuitement dans Security Center Essentials (voir plus bas). Notifications Health Check (aide Salesforce, lue le 22 octobre 2026).

Les quatre réserves qui valent un « partiel » et non un « non » — relues le 22 octobre 2026. Écart entre deux mesures : la notification hebdomadaire d’une baisse du score, active par défaut depuis le 15 avril 2026, compare un score global d’une semaine à l’autre ; la tendance sur 30 jours et le détail par réglage relèvent de Security Center Essentials — d’où le partiel pour Health Check lui-même. Intégrations sortantes et certificats : Health Check note les certificats expirés, la taille de clé et l’échéance des certificats, ainsi que les sites distants dont l’option Désactiver la sécurité de protocole (Disable Protocol Security) est cochée. Il ne voit ni les identifiants nommés, ni les services externes, ni les appels réellement émis — d’où le partiel. 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 — authentification et MFA, attributions de permissions, paquets installés, applications connectées et applications clientes externes, certificats, usage des licences, politiques de chiffrement, mobiles et Transaction Security, agents Agentforce et serveurs MCP (en bêta), données de Health Check, et vos propres métriques personnalisées — 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 : les droits effectifs. Depuis l'intégration d'Own Secure, l'abonnement comprend une extension (Security Center Extension, paquet géré à installer) dont l'explorateur Who Sees What détaille, pour un utilisateur, son accès à chaque objet et chaque champ, ses permissions système et la raison de chacune — profils, ensembles et groupes d'ensembles, règles de partage, hiérarchie de rôles. Salesforce l'écrit : « viewing permissions for any user across any org » (salesforce.com/platform/own-integration/, lue le 22 octobre 2026). Il montre aussi quand un utilisateur gagne ou perd une permission. 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 — sa page produit l'écrit : « Take critical actions based on agentic recommendations, like freezing user accounts, resetting passwords, and more » (salesforce.com/platform/security-center/, lue le 22 octobre 2026) ; OrgGuardian constate et documente. Cet agent de sécurité (Security Center with Agentforce) demande, selon Trailhead, Security Center et Event Monitoring en place ainsi qu'un abonnement Agentforce Platform add-on ; l'aide Salesforce le présente encore en bêta. 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, relue le 22 octobre 2026 : la supervision des identifiants nommés, des services externes et des appels réellement émis ; une mesure de la dette du code — il n'analyse pas le code lui-même, mais depuis le 14 septembre 2026 Security Mesh, adossé à Data 360, y ingère les résultats de DigitSec, sous abonnement tiers ; le rattachement article par article à DORA ou NIS2, que Salesforce cite comme contexte d'alerte centralisée sans rattachement ; un chiffrage du risque en euros — il note le risque de 0 à 4, sans montant ; et la marge restante sur les limites de la plateforme — il suit l'usage des licences et accepte vos métriques personnalisées, mais ne décrit pas la consommation des limites. D'où les non et les partiels de sa colonne, au sens que ce tableau donne à ces mots : aucune couverture décrite, et non une incapacité. C'est un produit sous licence, vendu en pourcentage de votre dépense chez Salesforce ; nous ne comparons pas ce prix.

Les réserves de sa colonne, relues le 22 octobre 2026 — elles tiennent les partiels, et la relecture a fait monter quatre cellules de ce tableau (droits effectifs, partage par défaut, code, écart entre deux mesures côté Health Check). Comptes d’intégration sans MFA : les métriques No MFA, API Only User Access et MFA & OAuth existent, suivies séparément ; leur croisement sur les comptes d’intégration n’est pas décrit. Applications connectées : l’inventaire (quelles apps, installées par qui, quand), les applications clientes externes et une alerte à l’ajout sont décrits ; ni les portées OAuth ni les jetons dormants. Accès invités : les comptes d’objets exposés de Health Check, par org, les anomalies invité de Threat Detection (avec Event Monitoring) et l’accès de n’importe quel profil par l’extension ; ni vue par site ni lecture dédiée aux profils invités. Partage par défaut : il relaie le contrôle Health Check de chaque org et explique l’accès d’un utilisateur à un enregistrement ; aucune vue des valeurs par défaut, objet par objet. Intégrations sortantes et certificats : les certificats, les sites distants non sécurisés et les URL suspectes de serveurs MCP (en bêta) sont décrits ; ni identifiants nommés, ni services externes, ni appels émis. Code : les résultats de DigitSec, ingérés par Security Mesh ; aucune mesure de dette.

Et Security Center Essentials, gratuit depuis juillet 2026 ?

Depuis juillet 2026, Salesforce propose Security Center Essentials, version de base de Security Center, « at no additional cost ». Elle porte sur une seule org et sept métriques : score et bases de référence Health Check, applications connectées, paquets gérés et non gérés, plages IP de confiance et de connexion. La collecte est hebdomadaire, actualisable à la demande, et l’historique conservé 30 jours ; le multi-org, les métriques supplémentaires et les politiques personnalisées restent au Security Center sous licence. Une divergence que nous préférons écrire : Trailhead et l’aide Salesforce la disent disponible dans toutes les éditions, le billet d’annonce du 15 juillet 2026 la dit incluse dans les éditions Enterprise, Unlimited et Performance ; et Trailhead mentionne aussi des « permission metrics », que le billet et l’aide ne listent pas. Annonce Salesforce, 15 juillet 2026 · Trailhead, lus le 22 octobre 2026.

Face à l’offre Découverte d’OrgGuardian, la différence tient au périmètre et au rythme : Essentials montre sept métriques de configuration, collectées chaque semaine ; Découverte analyse toutes les heures la santé, les limites et un socle de sécurité (comptes sans MFA, invités, liens publics, applications OAuth, porteurs de Modify All Data / View All Data). Essentials garde 30 jours d’historique, Découverte 7. Les deux se complètent : rien n’empêche de les faire tourner ensemble.

Un autre outil gratuit est apparu en janvier 2026 : ForceGuard AI: Security Auditor, publié par Salesforce Labs sur AppExchange. C’est un agent Agentforce livré en paquet non géré, qui « requires Agentforce to be enabled in your Salesforce org » : notes de sécurité de A à F, chemins d’accès aux enregistrements, source des permissions, comparaison d’utilisateurs et de profils. Gratuit à installer, il tourne sur Agentforce, facturé en crédits, en conversations ou par utilisateur ; Salesforce Labs décrit ses applications comme « not official salesforce.com products ». Fiche AppExchange, lue le 22 octobre 2026.

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 URL approuvées (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é est inclus en entier dans toute offre payante. Sur l'offre Découverte — gratuite, celle avec laquelle on installe pour évaluer — il tourne pour un socle de cinq familles : comptes sans MFA, exposition des invités, liens publics de fichiers, applications connectées et jetons OAuth, porteurs de Modify All Data et de View All Data. Le Health Check s'y ajoute de deux façons. La première ne demande aucune configuration : les quatre réglages qui se recalculent en SOQL (part d'administrateurs système, objets lisibles et modifiables par les invités, accès externe public par défaut) tournent dès la première analyse. La seconde demande une configuration d'administrateur, sans changer d'offre : câbler l'identifiant nommé OS_SelfOrg vers l'org (adresse et identifiants d'une application cliente), puis ouvrir la découverte par l'API Tooling. OrgGuardian lit alors le Health Check lui-même — son score, sa base de référence active et le verdict de chacun de ses réglages — sur l'offre Découverte aussi. Ce que l'offre Découverte affiche sans rien configurer — à la fin de l'essai de 30 jours que la première ouverture de la console arme — ce sont la supervision, les limites de plateforme, l'inventaire des endpoints, ce socle de sécurité et ces quatre réglages. 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 sans accès Tooling. 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 de confiance : ces réglages ne sont pas exposés à SOQL. OrgGuardian les lit par l'API Tooling, derrière une porte fermée par défaut et l'identifiant nommé OS_SelfOrg à configurer ; tant qu'elle est fermée, il ne les mesure pas. Et quand elle est ouverte, c'est encore le verdict du Health Check qu'il relit : 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é. 100 rattachements sur 126, 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 incluse dans toute offre payante, 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. Deux langues seulement. Les messages de constat sont stockés en anglais, la langue de livraison du produit, et un pack de langue les recompose en français à l'affichage : c'est la seule autre langue livrée. La traduction d'une phrase est en tout ou rien : s'il manque un fragment, la phrase anglaise sort telle quelle.

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 — quatre produits vendus ensemble, « Event Monitoring, Field Audit Trail, Platform Encryption, and Data Detect in one suite » selon sa page de prix lue le 20 octobre 2026 — 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), Field Audit Trail conserve l'historique des champs jusqu'à dix ans, et Data Detect repère les données sensibles. Aucun des quatre ne dit qu'un profil d'intégration cumule Modifier toutes les données et une API sans MFA ; et sans les journaux d'Event Monitoring, aucun des outils comparés plus haut ne dit qui a exporté un rapport hier soir — OrgGuardian le lit quand la licence est là, depuis la version 1.0.0.5.

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 la licence (Shield ou l'option Event Monitoring), il l'observe : depuis la version 1.0.0.5, la fonction Event Monitoring security events, fermée à l'installation et activée par un administrateur dans toute offre payante, lit dans l'org les exports de rapport, les travaux Bulk API 2.0, les sessions « Login As » et les anomalies Threat Detection des sept derniers jours, et nomme l'utilisateur, le volume et le réseau d'origine. Deux réglages de Setup la précèdent : la permission View Real-Time Event Monitoring Data pour l'utilisateur qui lance l'analyse, et le stockage de ces événements dans Event Manager. Sans licence, elle ne lit rien ; une famille sans aucun événement est déclarée non mesurée, jamais « rien à signaler ». Les détecteurs de journaux — requêtes lentes, erreurs non gérées, concurrence — sont une autre option, désactivée à l'installation et incluse dans toute offre payante : ils lisent les fichiers de journal par l'API de votre propre org, un appel de l'org vers elle-même qui demande le câblage de la connexion OS_SelfOrg. Rien ne part vers un tiers.

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 chiffrer au repos ou de conserver l'historique des champs se règle avec Shield (Platform Encryption, Field Audit Trail) : OrgGuardian ne chiffre rien et ne conserve pas l'historique de vos champs. Un profil d'intégration surprivilégié, un jeton OAuth dormant, un site invité qui expose un objet relèvent d'une mesure de configuration : nous n'en avons pas trouvé dans la documentation publique de Shield, qui journalise ce qui se passe plutôt qu'il ne dit comment l'org est réglée. Le prix de Shield s'exprime en pourcentage de votre dépense chez Salesforce (voir plus haut) ; 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 il reste la référence sur les réglages : quand l'accès Tooling est branché, OrgGuardian lit son score et ses verdicts au lieu de les recalculer ; sans cet accès, il n'en recalcule que quatre.

Security Center et OrgGuardian se recouvrent-ils ?

Oui, et davantage depuis 2026. Sur les droits effectifs, Security Center et son extension vont aussi loin qu'OrgGuardian ; sur les applications connectées et la dérive, en partie ; sur les certificats et le code, en partie aussi, le code par les résultats de DigitSec sous abonnement tiers. Pas sur la supervision des appels sortants, le rattachement réglementaire article par article, ni le chiffrage en euros. Et pas du tout sur la nature de l'outil : l'un déploie une politique, l'autre reste en lecture seule.