La Réponse Courte
Le "Health Check" est un diagnostic basé sur des preuves, d'une durée de deux à six semaines, aboutissant à trois livrables : une liste de constatations classées par gravité, un plan de "Quick Wins" sur 30 jours, et une feuille de route pour des investissements plus profonds. Son utilité ne réside pas dans l'étendue de l'analyse, mais dans la preuve fournie pour chaque constatation — un chiffre, un journal d'événements, ou un enregistrement d'écran. Sans ces preuves, la discussion dégénère trop souvent en un affrontement d'opinions.
Les Sept Axes d'Analyse
| Axe | Ce qui est effectivement analysé | Source de la preuve |
|---|---|---|
| Processus et Adoption | Le processus documenté est-il celui qui est exécuté ? | Login History, utilisation des champs, observation des utilisateurs |
| Modèle de Données | Objets inutiles, champs non utilisés, relations dupliquées | Field Usage, Metadata API, requêtes d'échantillonnage |
| Automatisations | Chevauchements entre Flows, Triggers et anciens Process Builders | Metadata, Debug Logs, analyse de l'ordre d'exécution |
| Permissions et Sécurité | Profils surchargés, règles de partage contradictoires, accès excessifs | Security Health Check, Permission Set Assignments |
| Intégrations | Limites API, échecs récurrents, gestion des erreurs | Event Monitoring, logs de Middleware |
| Performances | Temps de chargement, requêtes lourdes, lots bloqués | Lightning Usage App, Apex Jobs |
| Coûts et Licences | Licences sous-utilisées, stockage, services redondants | Rapport de licences, facture comparée à l'utilisation réelle |
Comment Classer la Gravité
Un classement arbitraire rend le rapport insignifiant. La méthode efficace est la suivante : chaque constatation reçoit deux scores entre 1 et 5 — Impact (ce qui arrive à l'entreprise si le problème n'est pas résolu) et Fréquence (combien de fois par mois le problème se manifeste). Le produit de ces deux scores détermine la priorité, plutôt que l'évaluation subjective de la "laideur" du code. Une constatation avec un score de 20 ou plus est traitée immédiatement ; entre 12 et 19, elle est planifiée pour le prochain trimestre ; en dessous de 12, elle est enregistrée mais non traitée, à moins que sa correction ne soit bon marché lors d'une autre intervention.
La distinction la plus cruciale dans le rapport est entre le symptôme et la cause racine. "Les utilisateurs ne remplissent pas le champ raison de la perte" est un symptôme ; la cause racine peut être que le champ n'est pas obligatoire, que les valeurs ne sont pas pertinentes pour le domaine, ou que personne n'examine le rapport basé sur ce champ. Corriger uniquement le symptôme — en rendant le champ obligatoire — générerait de mauvaises données au lieu de données manquantes.
Contenu des Livrables Finaux
Un livrable de qualité comprend un document de constatations avec une preuve pour chaque ligne, une matrice de gravité, un plan sur 30 jours dont chaque élément est réalisable sans modification architecturale majeure, et une feuille de route pour un à deux trimestres avec des estimations d'effort. Il faut également un "Decision Log" de trois à cinq décisions que l'organisation doit prendre — par exemple, si deux unités commerciales doivent fusionner en une seule Org — car sans elles, la feuille de route resterait en suspens.
Une discussion plus approfondie sur les décisions post-diagnostic est disponible dans Réarchitecture ou Refactorisation Salesforce et Priorisation de la Dette Technique Salesforce.
Risques Courants et Actions Préventives
Le premier risque est un rapport perçu comme une liste d'accusations. Si les constatations sont formulées comme des critiques envers l'équipe interne, l'organisation se met en mode défensif et ne corrige pas. Une formulation correcte se concentre sur la situation et les coûts futurs, et non sur la responsabilité historique.
Le deuxième risque est qu'une analyse se termine sans propriétaire. Chaque constatation doit avoir un nom de personne et une date, sinon le rapport rejoindrait un dossier que personne n'ouvrira. Le troisième risque est une portée excessive : un diagnostic qui tente de couvrir sept axes en profondeur en seulement deux semaines produit une image superficielle de chacun. Il est préférable de choisir trois axes à approfondir et de laisser les autres pour le cycle suivant.
Comment Mesurer le Succès
Un "Health Check" est considéré comme réussi si, dans les 60 jours, au moins 70 % des éléments du plan de 30 jours ont été exécutés, si la direction a approuvé un budget pour au moins un investissement profond, et si deux indicateurs opérationnels — par exemple, le taux d'échec d'intégration ou le temps de chargement d'un écran central — se sont améliorés de manière mesurable par rapport à la base de référence établie au début du diagnostic.
La Prochaine Étape
Avant de commander une analyse, il est conseillé de préparer trois éléments : une liste des processus métier critiques, un accès en lecture aux journaux et aux métadonnées, et les noms de trois utilisateurs réels dont le travail peut être observé. Ces trois éléments peuvent réduire la durée du diagnostic d'environ une semaine et améliorer considérablement la qualité des constatations.