Comment une org se retrouve à l'abandon
La situation est plus fréquente qu'on ne l'imagine, et elle n'a rien d'un cas pathologique. Salesforce a été déployé par un intégrateur qui est reparti une fois le projet livré. La personne qui suivait l'outil en interne a changé de poste ou quitté l'entreprise. Le projet qui devait suivre a été reporté, puis oublié.
Pendant ce temps, l'org continue de fonctionner. C'est d'ailleurs ce qui rend la situation durable : rien ne s'arrête, donc rien n'alerte. Les utilisateurs s'adaptent, contournent, remplissent moins de champs, et la dégradation se fait sans bruit.
Le réveil arrive presque toujours par un événement extérieur. Un changement de direction commerciale, une intégration à monter, un contrôle sur les accès, ou simplement le renouvellement de l'abonnement qui fait ouvrir la facture. À ce moment, quelqu'un doit reprendre une org Salesforce dont personne ne connaît plus le contenu.
La première décision, et elle est contre-intuitive
Le premier réflexe, quand on découvre une org dans cet état, c'est de vouloir tout refaire proprement. Je comprends ce réflexe, et je le déconseille dans la quasi-totalité des cas.
Une org abandonnée contient votre historique commercial, souvent plusieurs années d'opportunités, d'échanges et de pièces jointes. Elle contient aussi des intégrations avec vos autres outils, dont certaines sont invisibles jusqu'au jour où elles cessent de fonctionner. Elle contient enfin des habitudes de travail, qui ont plus d'inertie que n'importe quel paramétrage.
Repartir de zéro veut dire remigrer tout cela, reconstruire les intégrations, reformer tous les utilisateurs, et accepter une période où les deux systèmes coexistent. Le coût et le risque sont sans commune mesure avec une remise au propre. La refonte se justifie dans des cas précis, quand le modèle de données lui-même ne correspond plus du tout à l'activité, mais c'est une minorité de situations.
La bonne approche pour reprendre une org Salesforce consiste donc à comprendre avant de modifier, puis à corriger par couches, en commençant par ce qui protège.
Étape 1, l'inventaire, sans rien changer
La règle absolue de cette phase : on regarde, on ne touche à rien. Toute modification faite avant d'avoir compris l'ensemble risque de casser une chaîne dont vous ignorez l'existence.
Ce que je relève, dans l'ordre : la liste des utilisateurs actifs avec leur dernière connexion, les profils et permission sets en place, les objets personnalisés et leurs champs, les automatisations de toutes générations, le code existant, les applications connectées, et les tâches planifiées.
Ce dernier point mérite une attention particulière. Les traitements programmés sont ce qu'on oublie le plus souvent, parce qu'ils ne se voient nulle part dans l'interface quotidienne. Un travail nocturne qui met à jour des enregistrements depuis trois ans peut expliquer des comportements que personne ne s'explique.
L'inventaire se fait dans une sandbox rafraîchie, avec un accès en lecture seule à la production pour les seules statistiques qui n'existent que là, comme l'historique de connexion.
Étape 2, la sécurité et les accès
C'est le premier chantier de correction, avant les données et avant les automatisations, parce que c'est celui dont l'exposition est immédiate.
Les comptes actifs de personnes qui ont quitté l'entreprise sont la première cible. Chacun coûte une licence et constitue un accès ouvert à vos données commerciales. Attention au geste : dans Salesforce, un utilisateur ne se supprime pas, il se désactive, et cette désactivation libère la licence tout en conservant l'historique. Vérifiez avant de désactiver que la personne n'est pas propriétaire d'enregistrements actifs ou destinataire d'automatisations, sinon vous déplacez le problème.
Vient ensuite la question des droits d'export. Dans beaucoup d'orgs reprises, je trouve des profils autorisant l'export de la totalité des données à des personnes qui n'en ont aucun besoin. C'est le point que je corrige en priorité lors d'une remise au propre de la sécurité.
Enfin, les comptes techniques. Chaque application connectée utilise en général un utilisateur dédié. Identifiez à quoi chacun sert avant d'y toucher : désactiver un compte d'intégration coupe un flux entier, et le symptôme apparaîtra plusieurs jours plus tard.
Étape 3, les données
Assainir les données avant de retoucher les automatisations est un ordre volontaire. Une automatisation construite sur des données douteuses propage le désordre plus vite qu'elle ne le corrige.
Quatre chantiers reviennent systématiquement. Les doublons de comptes et de contacts, accumulés faute de règle de rapprochement. Les listes déroulantes contenant des valeurs mortes, qui faussent tous les rapports par regroupement. Les enregistrements orphelins, dont le propriétaire est un utilisateur désactivé. Et les champs obligatoires qui ne le sont pas, ce qui explique les trous dans le reporting.
À ce stade, je ne cherche pas la perfection. Je cherche un socle assez fiable pour que les décisions suivantes reposent sur du solide. Le nettoyage exhaustif d'un historique de dix ans est rarement rentable, et il n'est presque jamais nécessaire.
Étape 4, les automatisations
C'est la couche la plus délicate, parce que c'est celle où l'on casse quelque chose sans s'en apercevoir.
La méthode consiste à cartographier objet par objet. Pour chaque objet qui compte, je liste tout ce qui se déclenche à la création et à la modification, toutes générations confondues : règles de validation, Workflow Rules, Process Builder, Flows, déclencheurs Apex. Cette liste révèle immédiatement les recouvrements et les contradictions.
Ce que je désactive en premier, ce sont les automatisations qui ne servent plus, celles qui pointent vers des champs abandonnés ou des utilisateurs partis. Elles consomment du temps de traitement et produisent des erreurs silencieuses.
Ce que je ne fais pas dans la foulée, c'est migrer l'ensemble vers Flow d'un seul mouvement. Salesforce a engagé le retrait de Workflow Rules et de Process Builder, donc la migration devra se faire, mais elle se planifie comme un chantier à part entière, avec ses tests. La mélanger à une reprise d'org, c'est additionner deux risques.
Étape 5, remettre en place un cycle de travail
Les quatre étapes précédentes remettent l'org en état. La cinquième évite qu'elle ne s'y retrouve à nouveau dans deux ans, et c'est celle qu'on saute le plus souvent.
Trois choses suffisent. Une sandbox à jour, où tout se conçoit et se teste avant la production. Une procédure de recette écrite, même courte, qui dit qui valide quoi et sur quels cas. Et une documentation vivante, tenue au fil des modifications plutôt qu'en fin de projet.
Ajoutez un point de revue périodique, deux fois par an suffit : dernières connexions, nouveaux champs créés, automatisations ajoutées, rapports devenus inutiles. Une demi-journée qui évite la reprise complète.
Combien de temps prend une reprise
L'inventaire se compte en un à deux jours, exactement comme un audit d'org. C'est la partie la plus prévisible, parce qu'elle ne dépend que du volume de configuration.
Les chantiers de correction dépendent de ce que l'inventaire révèle, et c'est bien pour cela qu'ils ne se chiffrent qu'après. La sécurité et les accès se comptent en jours, les données selon le volume et le degré de désordre, les automatisations selon leur enchevêtrement.
D'expérience, une org laissée deux ans sans administrateur se remet au propre en quelques jours. La même org laissée cinq ans devient un chantier d'un autre ordre. Le facteur qui pèse le plus n'est pas la taille de l'entreprise, c'est le temps écoulé et le nombre de personnes qui sont passées dessus sans se coordonner.
Ce que je remets à la fin
Une reprise n'a de valeur que si elle vous rend autonome. Ce que je laisse systématiquement : la cartographie des objets et des automatisations, la liste des accès avec ce qui a été modifié et pourquoi, la procédure de déploiement, et les points restés en suspens avec leur estimation.
Ce dernier document est le plus utile. Il vous permet de reprendre la main quand vous le décidez, avec un devis en face de chaque ligne, plutôt que de découvrir dans deux ans que la liste a recommencé à s'allonger.
Questions fréquentes
Vaut-il mieux reprendre une org Salesforce existante ou repartir de zéro ?
Reprendre l'existant dans la grande majorité des cas. Une org abandonnée contient votre historique commercial, vos intégrations et vos habitudes de travail. Repartir de zéro signifie tout remigrer, tout reparamétrer et reformer tout le monde, pour un résultat rarement supérieur.
Que faire quand la personne qui administrait Salesforce est partie sans documentation ?
On reconstitue la documentation à partir de l'org elle-même, en lisant la configuration, les automatisations et les journaux de modification. C'est plus long qu'une reprise documentée, mais rien n'est perdu : tout ce qui tourne est lisible dans le paramétrage.