Beaucoup de revues d’org finissent en rapport que personne n’exploite, et six mois plus tard les mêmes problèmes reviennent sous forme d’incident de production. Une revue qui vaut son prix fait quelque chose de plus étroit : elle repère les décisions qui provoqueront des pannes à l’étape suivante (un deuxième cloud, une migration, une acquisition) et les classe pour que quelqu’un puisse agir. Cette grille s’adresse au sponsor qui commande la revue et doit en lire le résultat.
Les outils mesurent des seuils
Les outils de health check mesurent des seuils : limites d’API, stockage, utilisateurs inactifs qui gardent des droits d’administrateur. Ces constats comptent et coûtent en général peu à corriger. Ils ne montrent pas les choix de conception qui ne font mal qu’en charge : chaque nouvelle fonctionnalité ajoutée sur Account parce que les données y sont déjà, des automatisations construites par des équipes différentes sans conception commune, des intégrations que personne ne sait expliquer.
Une org peut passer tous les seuils et n’être qu’à un projet des ennuis. La revue lit donc la configuration et interroge aussi ceux qui l’ont modifiée : qui a décidé, quand, et pourquoi. Pour les automatisations, demandez une carte des dépendances (ce que chaque Flow, trigger et intégration lit, écrit et appelle) plutôt qu’un décompte. Quelques Flows enchevêtrés peuvent être plus difficiles à faire évoluer que beaucoup de Flows indépendants.
Cinq domaines à lire
1. Modèle de données
Regardez les relations et leur cardinalité, la croissance du nombre de champs sur les objets cœur (Account, Contact, Opportunity), les objets custom qui doublonnent des objets standard, comme un objet Contrat custom à côté du Contract standard, et si le modèle reflète le métier ou l’historique des projets passés.
Le mode de défaillance est la surcharge d’objet. Quand Account porte des champs des ventes, du service client, de la finance et du marketing sans séparation, on obtient des permissions emmêlées, des rapports ambigus et des conflits d’automatisation, et la correction devient une migration de données plutôt qu’un changement de configuration. Vérifiez aussi que les objets utilisés dans des intégrations portent des champs External ID. Une intégration qui s’appuie sur les ID d’enregistrement Salesforce casse dès que les données sont rechargées ou déplacées dans une autre org.
2. Automatisations
Si Process Builder ou des Workflow Rules portent encore de la logique métier, c’est un constat : Salesforce a mis fin au support des deux et oriente ses clients vers Flow, et en sortir demande une refonte plutôt qu’une conversion.
La vraie question est la cohérence. Plusieurs Flows déclenchés sur le même objet, écrits par des personnes différentes sans ordre documenté, donnent des résultats qui dépendent de celui qui s’exécute en dernier. Cherchez les déclenchements récursifs sans condition d’arrêt, les mises à jour en base à l’intérieur de boucles, et les Flows qui doublonnent une logique déjà portée par Apex, résultat typique du turnover : quelqu’un construit un Flow parce que personne ne lui a dit que la classe Apex existait.
3. Intégrations
Cartographiez chaque système externe qui touche l’org, y compris ceux qui ne sont pas documentés : Connected Apps, Named Credentials et External Services, rapprochés de l’usage réel des API. Pour chaque connexion, notez le propriétaire, la méthode d’authentification, le volume de données et la gestion des erreurs.
Deux constats méritent l’attention. Des intégrations que personne ne sait expliquer, mais qui tournent et consomment des appels API, sont à la fois une surface d’attaque et une ponction sur les limites. Des intégrations qui tournent avec les identifiants d’une personne nommée dépendent de son compte, et personne n’a décidé de ce qui se passe quand elle part. L’opportunité d’une couche middleware dépend du nombre de systèmes et de la logique de transformation ; la revue doit consigner cette décision et son propriétaire plutôt que supposer une réponse.
4. Sécurité et accès
Les modèles d’accès accumulent une dette que personne ne voit : quelques profils larges et une liste croissante de permission sets que personne n’a revus. Comptez les utilisateurs sur le profil System Administrator et demandez pourquoi chacun y est. Comparez les paramètres de partage par défaut (org-wide defaults) et les règles de partage avec le besoin métier réel ; resserrer plus tard un modèle ouvert est douloureux, alors qu’ouvrir un modèle restrictif est facile. Si les affectations de permission sets augmentent plus vite que le nombre d’utilisateurs, le modèle d’accès dérive.
Si des agents sont prévus, la même question s’étend à chaque action qu’un agent peut appeler : avec quelles permissions elle s’exécute, et qui a validé ce périmètre.
5. Discipline de déploiement
La façon dont les changements arrivent en production en dit autant que le contenu de l’org. Vérifiez que le contrôle de version tient l’état de référence, qu’une sandbox reflète la production pour la validation finale, que les changements sont revus avant la mise en production, et que chaque mise en production a un plan de retour arrière. L’écart entre sandboxes et production, quand personne ne sait lequel fait foi, transforme une mise en production de routine en long retour arrière. Demandez à l’équipe de nommer l’environnement de référence. Une hésitation est un constat.
Classer les constats par rayon d’impact et effort
Une liste de constats n’est pas un plan. Classez chacun sur deux axes. Le rayon d’impact, c’est le nombre d’utilisateurs, d’enregistrements ou de systèmes aval touchés en cas de panne, et la fréquence à laquelle les conditions se présentent : une erreur de logique à chaque mise à jour d’Account passe devant une mauvaise configuration sur un objet utilisé deux fois par an. L’effort, c’est la difficulté de la correction.
| Effort faible | Effort élevé | |
|---|---|---|
| Rayon d’impact large | À corriger tout de suite : erreurs de configuration de sécurité, automatisations retirées qu’un travail ciblé peut migrer | Chantier de niveau programme, avec son budget et ses phases : restructuration du modèle de données, refonte des intégrations |
| Rayon d’impact étroit | Backlog de dette technique, traité régulièrement : nettoyage de champs, automatisations inactives, permission sets orphelins | En attente jusqu’à ce qu’un déclencheur augmente le risque, comme une nouvelle intégration ou un deuxième cloud |
Le quadrant qu’on finance décide si le prochain grand programme part d’une base saine ou traîne d’anciennes décisions que personne ne veut rouvrir. La note sur la dette technique explique comment faire vivre ce backlog. Si l’org est déjà en difficulté, commencez plutôt par le redressement de projet.
À vérifier
- La revue couvre les cinq domaines, discipline de déploiement comprise.
- Elle inclut des entretiens avec ceux qui ont modifié l’org, pas seulement la sortie des outils.
- Les automatisations des objets cœur sont accompagnées d’une carte des dépendances.
- Chaque constat porte un rayon d’impact, un niveau d’effort et un propriétaire nommé.
- Les principaux constats tiennent sur une page, et vous pouvez décider à partir d’elle ce que vous financez.