Salesforce Health Check
Le système existe déjà.
La question est de savoir s'il est toujours bien construit.
Un examen systématique de votre environnement Salesforce existant pour identifier les risques, la dette technique, les problèmes d'utilisabilité, les données peu fiables et les opportunités d'amélioration — avant de lancer un autre projet.
Signes qu'un Health Check est recommandé
Quand l'évaluation est rentable
- Les utilisateurs travaillent en dehors du système.
- Il est difficile de produire des rapports fiables.
- De petits changements entraînent des dysfonctionnements.
- Il existe des Flows ou du code sans propriété claire.
- Les autorisations se sont accumulées au fil du temps.
- Données en double ou manquantes.
- Les intégrations échouent.
- Les temps de chargement ou les performances sont affectés.
- Les coûts augmentent sans amélioration de la valeur.
- Il n'y a pas de feuille de route claire.
- Personne n'est sûr de ce qui peut être supprimé ou modifié.
- Différentes équipes utilisent le système de différentes manières.
Problèmes résolus par le service
Quand l'évaluation change la donne
Incertitude avant un nouveau projet
Avant une phase, une intégration ou une migration vers Agentforce, un Health Check répond à la question : La base est-elle suffisamment stable ? Si non, que faut-il réparer en premier ?
Dette technique accumulée discrètement
Flows en double, code ancien, champs abandonnés et profils ouverts. L'audit révèle la dette, la hiérarchise et propose un plan de correction échelonné.
Faible adoption par les utilisateurs
Lorsque le système existe mais que personne ne l'utilise réellement. L'audit combine des entretiens avec les utilisateurs et une analyse de l'utilisation réelle.
Coûts de licence non clairs
Utilisateurs inactifs, capacités acquises non mises en œuvre et modules en double. L'audit identifie de réelles économies.
Ce qui est vérifié
Huit domaines d'évaluation
Architecture
Modèle de données, Objects, Relationships, Scalability, Technical Debt.
Automatisations et code
Flows, Apex, Triggers, LWC, dépendances, erreurs et maintenabilité.
Autorisations et sécurité
Profils, ensembles d'autorisations, partage, rôles, accès aux informations sensibles, autorisations superflues.
Données
Doublons, champs vides, structure des données, qualité des informations, sources de vérité et politique de conservation.
Facilité d'utilisation et adoption
Écrans, nombre d'étapes, champs superflus, utilisation réelle et processus qui contournent le système.
Rapports et indicateurs
Fiabilité des rapports, KPIs, tableaux de bord et cohérence entre les départements.
Intégrations
Pannes, surveillance, tentatives, propriétés, sécurité et limites d'API.
Licences et coûts
Utilisation des licences, utilisateurs inactifs, capacités acquises et non utilisées.
Le processus de travail
Sept étapes organisées
- 01Lancement et accès à l'environnement
- 02Analyse automatique des métadonnées
- 03Entretiens avec les parties prenantes
- 04Analyse de l'utilisation réelle
- 05Vérification des intégrations et des journaux
- 06Rédaction du rapport et des recommandations
- 07Réunion de présentation à la direction
Qu'obtenez-vous
Produits clairs pour la prise de décision
Executive Summary
Résumé exécutif pour la prise de décision.
Rapport de constatations classé
Par gravité, impact et effort.
Quick Wins
Améliorations à valeur ajoutée rapide.
Risques clés
Lacunes nécessitant une attention préalable.
Recommandations d'architecture
Orientations pour l'amélioration structurelle du système.
Feuille de route pour l'amélioration
Division en phases et priorisation.
Point de décision
Vérification rapide de l'adéquation avant de commander un bilan de santé complet
Un bref entretien nous permettra de déterminer si un bilan de santé express, un examen approfondi ou un accompagnement sur une décision unique est préférable.
Considérations pour la décision
Trois décisions qui déterminent la valeur de l'examen
Profondeur de l'examen
Express en une semaine pour un aperçu général, contre un examen approfondi de quatre semaines comprenant l'analyse du code et de l'architecture. Le choix dépend de la taille du système et des questions ouvertes.
Quand effectuer un Bilan de Santé
Avant une nouvelle phase, avant de passer à Agentforce, après un changement de fournisseur, ou lorsque les taux d'adoption sont faibles sur une longue période.
Qui met en œuvre les corrections
La mise en œuvre peut être effectuée en interne, par un autre partenaire ou en poursuivant avec nous. Nous rédigeons le rapport de manière à ce que tout professionnel puisse agir en conséquence.
Erreurs courantes
Ce qu'il est important de préserver pendant l'examen
- Se fier uniquement au bilan de santé intégré de Salesforce sans vérifier l'aspect processuel.
- Corriger une seule constatation sans comprendre la racine architecturale.
- Lancer un grand projet d'extension avant de connaître l'état de la base.
- Se fier uniquement à un administrateur interne pour l'auto-diagnostic — il est difficile de critiquer le système que l'on maintient.
28. Questions fréquentes
Salesforce Health Check — Questions fréquemment posées
L'étape suivante