Une org ne se dégrade jamais d'un coup
Personne ne décide un matin de laisser son Salesforce se dégrader. La dérive est lente, faite de décisions raisonnables prises isolément. Un champ ajouté en urgence pour une campagne. Une règle de validation désactivée le temps d'une reprise de données, et jamais réactivée. Un profil dupliqué pour dépanner un nouvel arrivant un vendredi soir.
Prises une par une, ces décisions se défendent. Accumulées sur trois ans, elles produisent une org que plus personne n'ose modifier. C'est précisément à ce moment qu'un audit Salesforce devient l'investissement le plus rentable, parce qu'il transforme un malaise diffus en liste de chantiers chiffrés.
Voici les sept signes que je retrouve le plus souvent. Trois suffisent à justifier une remise au propre.
Les sept signes d'une org à remettre au propre
1. Des champs en double, et personne ne sait lequel fait foi
Vous avez un champ « Chiffre d'affaires », un champ « CA annuel » et un champ « Revenu estimé » sur le même objet. Deux sont renseignés au hasard selon les habitudes de chacun, le troisième alimente un rapport que la direction regarde.
Ce cas est le plus banal et le plus coûteux, parce qu'il contamine tout le reste. Un rapport bâti sur le mauvais champ produit un chiffre faux qui a l'air juste. Personne ne le détecte, et une décision se prend dessus.
Le test est simple. Ouvrez le gestionnaire d'objets, triez les champs personnalisés par date de création, et demandez à votre équipe à quoi servent les dix derniers. Si deux personnes donnent deux réponses différentes, vous avez votre réponse.
2. Des automatisations qui se marchent dessus
Une Workflow Rule d'origine, un Process Builder ajouté trois ans plus tard, un Flow construit l'an dernier, et tous les trois touchent le même objet. Chacun a été conçu sans connaître les autres.
Le symptôme visible, c'est un enregistrement qui se modifie tout seul, un champ qui se remplit puis se vide, ou une notification envoyée deux fois. Le symptôme invisible, c'est le temps de traitement qui s'allonge et les erreurs qui remontent aux utilisateurs sous forme de messages incompréhensibles.
Salesforce a cessé de faire évoluer Workflow Rules et Process Builder au profit de Flow. Tant que ces automatisations tournent encore chez vous, elles constituent une dette que vous paierez au moment le moins choisi.
3. Des droits accordés au cas par cas
Un utilisateur a besoin d'accéder à un objet. Plutôt que de créer un permission set, quelqu'un a dupliqué un profil et l'a modifié. L'opération s'est répétée. Vous vous retrouvez avec autant de profils que d'utilisateurs, aucun ne portant de nom explicite.
Personne ne sait plus qui voit quoi. Le jour où un contrôle vous demande de le prouver, l'exercice devient une enquête de plusieurs jours. C'est le chantier qui ne se rentabilise jamais visiblement, jusqu'au jour où il vous évite un incident.
4. Des rapports que plus personne n'ouvre
Regardez le dossier des rapports partagés. Vous y trouverez des dizaines d'éléments, souvent des variantes du même, créés par des personnes parties depuis longtemps. Le tableau de bord officiel, lui, n'a pas été consulté depuis des mois.
Un rapport abandonné n'est pas neutre. Il occupe l'espace visuel, il concurrence le rapport utile, et il finit par être ouvert par erreur avec des filtres périmés. Un reporting de pilotage n'a de valeur que si l'on peut trouver le bon élément en dix secondes.
5. Vos utilisateurs ont reconstitué l'outil ailleurs
Un commercial tient son pipeline dans un tableur parce que la vue Salesforce ne lui convient pas. L'assistante suit les relances dans sa messagerie. Le responsable garde son propre fichier de prévisions.
Ce contournement est le signal le plus honnête que vous puissiez obtenir, et il ne se voit dans aucune statistique de connexion. Les utilisateurs ne sabotent pas l'outil, ils compensent ce qu'il ne leur donne pas. Quand vous constatez ce phénomène, la question n'est pas de les rappeler à l'ordre, c'est de comprendre ce qui manque.
6. Personne ne sait ce qui a changé, ni quand
Vous demandez pourquoi tel comportement a changé la semaine dernière. Personne ne sait. Il n'existe ni documentation, ni journal des modifications tenu par quelqu'un, ni environnement de test à jour où reproduire le problème.
Dans cet état, chaque modification devient un pari. C'est ce qui explique la paralysie que je rencontre le plus souvent : l'org fonctionne mal, tout le monde le sait, et personne n'y touche parce que le risque n'est pas mesurable.
7. Vos données ne se laissent plus exploiter
Des comptes en double, des adresses au format libre, des listes déroulantes contenant des valeurs devenues obsolètes mais jamais retirées, des enregistrements orphelins dont le propriétaire a quitté l'entreprise.
Tant que ce socle n'est pas assaini, toute automatisation construite par dessus reproduira et amplifiera le désordre. C'est pour cette raison qu'un audit regarde toujours les données avant de proposer des automatisations.
Ce que je regarde pendant un audit Salesforce
Un audit d'org Salesforce n'est pas une impression générale, c'est un passage en revue méthodique. Voici ce que j'ouvre systématiquement, dans cet ordre.
- Les utilisateurs et leurs dates de dernière connexion. Comptes actifs jamais utilisés, comptes d'anciens salariés, comptes techniques dont personne ne connaît l'usage.
- Les profils, rôles et permission sets. Qui voit quoi, qui peut modifier quoi, et surtout qui peut exporter des données.
- Le modèle de données. Objets personnalisés, champs jamais renseignés, champs en double, listes déroulantes non maintenues.
- Les automatisations. Workflow Rules, Process Builder, Flows, règles de validation, et surtout leurs recouvrements sur un même objet.
- Le code existant. Classes Apex, déclencheurs, composants sur mesure, couverture de test réelle, et ce qui n'est plus appelé par rien.
- Les rapports et tableaux de bord. Ce qui est réellement consulté, ce qui fait doublon, ce qui repose sur des champs douteux.
- Le cycle de déploiement. Existe-t-il une sandbox à jour, qui déploie, et selon quelle procédure.
Ce travail se fait dans une copie de test, jamais en production. Il ne modifie rien et n'interrompt personne.
Du constat au plan d'actions
Un audit qui produit une liste de problèmes ne sert à rien. Ce qui compte, c'est ce qui vient après, et c'est là que se joue l'utilité réelle de l'exercice.
Le livrable que je remets classe les constats selon deux axes seulement : ce que cela vous coûte de ne rien faire, et ce que cela coûte de le corriger. Le croisement des deux donne l'ordre des chantiers, et cet ordre surprend souvent. Le sujet qui agace le plus au quotidien n'est pas toujours celui qu'il faut traiter en premier.
Chaque chantier est ensuite estimé en jours, avec ses hypothèses et ses exclusions, exactement comme un devis découpé en lots. Vous décidez de ce que vous lancez, dans quel ordre, et vous gardez la possibilité de ne rien faire en connaissance de cause. C'est un résultat acceptable : savoir que votre org tient debout vaut mieux que le supposer.
Ce qu'un audit Salesforce ne fait pas
Il ne corrige rien. C'est un diagnostic, pas une intervention, et confondre les deux mène à des déceptions. La correction se chiffre séparément, et vous êtes libre de la confier à qui vous voulez.
Il ne définit pas non plus votre processus commercial à votre place. Un administrateur Salesforce freelance constate l'écart entre votre façon de travailler et ce que l'outil reflète, il vous signale les endroits où cet écart vous coûte, mais l'arbitrage métier reste le vôtre.
Enfin, il ne conclut presque jamais qu'il faut tout refaire. La refonte complète est la réponse la plus chère et la plus risquée, et elle n'est justifiée que dans une minorité de situations. Dans la grande majorité des cas, quelques jours de remise au propre suffisent à rendre l'org exploitable.
Par où commencer si vous ne lancez rien aujourd'hui
Deux choses se regardent en dix minutes, sans compétence particulière, et vous en apprendrez déjà beaucoup.
La première : triez vos utilisateurs actifs par date de dernière connexion, en partant de la plus ancienne. Chaque compte actif qui ne s'est pas connecté depuis des mois est une licence payée et un accès ouvert.
La seconde : demandez à trois utilisateurs de vous montrer, sans préparation, comment ils créent une opportunité. Regardez les écrans qu'ils ouvrent, les champs qu'ils remplissent au jugé, et ce qu'ils recopient depuis un autre outil. Vous verrez en direct ce qu'un audit Salesforce met des heures à formaliser.
Questions fréquentes
Combien de temps prend un audit d'org Salesforce ?
Un à deux jours dans la grande majorité des cas, exploration comprise. Ce délai couvre la lecture de la configuration dans une sandbox, les entretiens avec deux ou trois utilisateurs, et la rédaction du plan d'actions priorisé.
Faut-il donner un accès à la production pour un audit Salesforce ?
Non. Une sandbox suffit pour lire la configuration, les automatisations et les droits. Seules les statistiques de connexion et le volume réel de données se regardent en production, avec un accès en lecture seule et révocable.