5 contrôles de santé Salesforce que chaque administrateur devrait effectuer

La plupart des orgs Salesforce ne tombent pas en panne brutalement — elles se dégradent silencieusement. Un flux qui fonctionnait très bien à 500 enregistrements commence à dépasser les limites à 50 000. Un ensemble de permissions qui avait du sens il y a deux ans accorde maintenant des accès qu’il ne devrait pas. Une automatisation dont personne ne se souvient s’exécute à chaque modification et ralentit le chargement des pages.

Ces cinq vérifications prennent une après-midi. Elles font remonter les problèmes qui coûtent silencieusement du temps et de la confiance à votre équipe.

1. Audit d’exposition aux limites de gouverneur

Consultez vos journaux d’exécution Apex dans Configuration → Travaux Apex et repérez tout ce qui utilise régulièrement plus de 50 % des limites CPU ou SOQL. Ce ne sont pas encore des échecs — mais ils ne sont qu’un chargement de données loin d’en devenir un.

Ce qu’il faut chercher :

Les automatisations déclenchées sur des objets à fort volume (requêtes, commandes, journaux)
Les requêtes SOQL dans des boucles (l’erreur classique — une requête par enregistrement au lieu d’une seule pour tous)
Les appels synchrones bloquant la transaction

Gain rapide : Activez les journaux de débogage sur votre utilisateur d’intégration pendant une heure chargée et analysez-les à la recherche d’avertissements Maximum CPU time. Si vous en voyez, vous avez une bombe à retardement.

2. Révision du modèle de sécurité

Le modèle de sécurité de Salesforce est puissant, mais il est facile d’accorder trop de droits. Exécutez l’Analyseur d’ensembles de permissions (disponible dans le Centre de sécurité si vous y avez accès, sinon manuellement via SOQL) et vérifiez :

Tout profil ou ensemble de permissions avec « Modifier toutes les données » ou « Afficher toutes les données » qui n’est pas un utilisateur d’intégration système
Les utilisateurs avec un accès en modification sur des champs qu’ils n’ont besoin que de consulter
Les groupes publics ayant accès à des types d’enregistrements sensibles

Une vérification SOQL rapide à exécuter dans la Console du développeur :

SELECT Name, PermissionsModifyAllData, PermissionsViewAllData
FROM PermissionSet
WHERE PermissionsModifyAllData = true OR PermissionsViewAllData = true

Si des utilisateurs non intégrateurs apparaissent ici, creusez la question. Le principe du moindre privilège n’est pas qu’une bonne pratique — c’est votre défense en cas d’audit.

3. Inventaire des automatisations inactives

Chaque org Salesforce contient des automatisations qui ont été « temporairement » désactivées et ensuite oubliées. Elles ne causent pas de tort à rester là, mais elles créent de la confusion — et sont parfois réactivées accidentellement lors des déploiements.

Exécutez ceci dans la Console du développeur :

SELECT DeveloperName, ProcessType, Status, LastModifiedDate
FROM Flow
WHERE Status = 'Obsolete' OR Status = 'InvalidDraft'
ORDER BY LastModifiedDate ASC

Supprimez ce qui est vraiment mort. Pour tout ce dont vous n’êtes pas certain : ajoutez une description, notez le responsable et fixez une date de révision. Les automatisations non documentées sont un ticket de support en attente.

4. Vérification rapide de la qualité des données

La mauvaise qualité des données est le tueur silencieux du retour sur investissement Salesforce. Un audit rapide par échantillon :

Leads sans courriel ni téléphone — à quoi sert cet enregistrement ?
Comptes sans contacts associés — enregistrements orphelins issus d’importations
Opportunités bloquées au même stade depuis plus de 90 jours — illusion de pipeline
Taux de détection des doublons — exécutez le rapport de travaux de doublons et voyez quel pourcentage de nouveaux enregistrements est signalé

Vous n’avez pas besoin de tout corriger aujourd’hui. Mais connaître la forme de votre problème de qualité de données vous dit où investir en règles de validation, en correspondance de doublons ou en projet de nettoyage.

5. Gestion des versions et suivi des modifications

Celui-ci est procédural, pas technique — mais c’est le contrôle que la plupart des orgs sautent. Posez-vous les questions suivantes :

Avez-vous un journal des modifications (même une simple feuille de calcul) de ce qui a été déployé au cours des 6 derniers mois ?
Vos flows et classes Apex sont-ils déployés via CI/CD ou des ensembles de changements — ou des modifications directes en production ?
Quand quelque chose casse, pouvez-vous identifier en moins de 10 minutes ce qui a changé et qui l’a changé ?

Si la réponse à l’une de ces questions est « non », vous opérez sans filet de sécurité. Le premier pas consiste simplement à exiger que chaque modification en production passe d’abord par un bac à sable, avec un billet ou un message Slack notant ce qui a été fait et pourquoi.

En faire une routine

Aucun de ces contrôles n’est à faire une seule fois. Les orgs qui restent saines sont celles où quelqu’un effectue cette liste (ou une version de celle-ci) tous les trimestres. Mettez-la dans votre agenda. Partagez les résultats avec les parties prenantes. C’est la différence entre gérer votre org et être géré par elle.

Besoin d’une revue professionnelle de votre org ? Nous offrons des audits Salesforce structurés — contactez-nous pour savoir ce que le vôtre cache.