Blog

Offboarding d'un utilisateur Salesforce, la checklist complète

Le jour d'un départ, tout le monde pense à couper la messagerie. Presque personne ne pense au CRM, et c'est pourtant là que sont vos affaires en cours.

Offboarding d un utilisateur Salesforce, la checklist complete du departDÉPART · CHECKLISTUn départ,sans casseCe qu'il faut faire, et dans quel ordreCE QUE VOUS Y TROUVEZGeler d'abord, désactiver ensuiteTransférer avant de couperLes dépendances invisibles à vérifierNicolas Devaux · Administrateur Salesforce freelancedevaux-consulting.com

Pourquoi ce moment est plus délicat qu'il n'en a l'air

Un départ met en jeu deux exigences contradictoires. Il faut couper l'accès vite, parce qu'un compte actif est une porte ouverte sur votre base commerciale. Et il faut couper proprement, parce que la personne qui part est attachée à des dizaines d'enregistrements, de processus et d'automatisations.

Faire les deux dans le désordre produit soit une fuite, soit des affaires orphelines que personne ne suit, soit des rapports qui cessent de fonctionner sans que quiconque comprenne pourquoi. Un offboarding Salesforce réussi, c'est simplement le bon ordre des opérations.

Précision utile avant de commencer : dans Salesforce, un utilisateur ne se supprime pas. Il se désactive. Son nom reste attaché à l'historique des enregistrements qu'il a créés, ce qui préserve la traçabilité, et la désactivation libère la licence.

Étape 1, geler immédiatement

Le jour même, souvent dans l'heure, la bonne action n'est pas la désactivation mais le gel. Geler bloque instantanément la connexion, sans rien modifier d'autre.

C'est le geste qui concilie les deux exigences. L'accès est coupé tout de suite, et vous gardez le temps nécessaire pour traiter proprement ce qui suit, sans précipitation et sans casser quoi que ce soit.

Attention, le gel ne libère pas la licence. Ce n'est pas l'étape finale, c'est la mesure conservatoire.

Étape 2, sauvegarder ce qui va disparaître de vue

Avant de transférer quoi que ce soit, exportez la liste de ce que cette personne possède. Comptes, opportunités ouvertes, pistes, tâches et événements à venir, rapports et tableaux de bord personnels.

Cet export prend dix minutes et vous sauvera le jour où quelqu'un demandera « qui suivait ce client avant ». Sans lui, l'information reste théoriquement dans l'org, mais personne ne saura la reconstituer.

Étape 3, transférer la propriété

C'est l'étape la plus importante, et celle qui prend le plus de temps si elle a été négligée.

Un utilisateur désactivé reste propriétaire de ses enregistrements. Ses opportunités continuent d'apparaître à son nom dans les prévisions, ses comptes n'ont plus d'interlocuteur réel, et ses tâches ouvertes n'apparaissent dans la liste de personne. Le pipeline affiche alors des affaires que plus personne ne travaille.

Transférez donc avant de désactiver, dans cet ordre : les comptes, puis les opportunités ouvertes, puis les pistes, puis les tâches et rendez-vous à venir. Le transfert des comptes emporte souvent les enregistrements liés, mais vérifiez systématiquement plutôt que de le supposer.

Une décision d'organisation se pose ici, et elle n'est pas technique : transférer à un seul repreneur, ou répartir entre plusieurs. Répartir est presque toujours meilleur pour le suivi commercial, mais demande un arbitrage que l'administrateur ne peut pas prendre seul.

Étape 4, les dépendances invisibles

C'est ici que se cachent les mauvaises surprises, des semaines après le départ. Sept points à vérifier.

  • Les tableaux de bord. Un tableau de bord s'exécute avec les droits d'un utilisateur désigné. Si c'est la personne partie, les chiffres cessent de se rafraîchir correctement. C'est l'oubli le plus fréquent.
  • Les processus d'approbation. Si elle était approbateur, les demandes en cours restent bloquées et les nouvelles ne partiront nulle part.
  • Les alertes par email. Les automatisations qui lui envoyaient des notifications continuent de tourner et d'écrire dans le vide.
  • Les files d'attente. Retirez-la des files, sinon les attributions automatiques continuent de lui adresser du travail.
  • Les rapports partagés. Un rapport dont elle était propriétaire peut devenir inaccessible aux autres.
  • La hiérarchie des rôles. Si elle avait des subordonnés, leur visibilité remontait vers elle. Repositionnez avant de désactiver.
  • Les intégrations. Si son compte servait à connecter un outil tiers, la désactivation coupe le flux. Ce cas doit être traité séparément, avec un compte technique dédié.

Ce dernier point mérite une règle générale : un compte nominatif ne doit jamais servir d'intégration. C'est une confusion courante, et elle transforme chaque départ en incident technique.

Étape 5, désactiver et récupérer la licence

Une fois les quatre étapes précédentes faites, la désactivation ne casse plus rien. Elle libère la licence, qui redevient attribuable à la prochaine arrivée.

Profitez-en pour vérifier ce que cette personne avait comme droits. Si elle disposait de permission sets sensibles, l'occasion est bonne de vérifier qui d'autre les possède. Un départ est souvent le seul moment où quelqu'un regarde vraiment les licences et les droits.

La checklist, en une page

Voici la version courte, celle qu'il faut garder sous la main et donner aux ressources humaines.

  • Geler le compte le jour du départ
  • Exporter la liste des enregistrements possédés
  • Transférer comptes, opportunités, pistes, tâches et rendez-vous
  • Vérifier tableaux de bord, approbations, alertes, files d'attente, rapports, hiérarchie
  • Traiter séparément les éventuelles intégrations
  • Désactiver le compte et libérer la licence
  • Noter la date et le nom du repreneur quelque part de durable

Comptez une trentaine de minutes pour un utilisateur ordinaire, davantage pour un commercial chargé ou un responsable placé haut dans la hiérarchie.

Trois situations qui sortent du cadre

La checklist couvre le départ ordinaire. Trois cas demandent un traitement différent.

Le départ conflictuel. Ici, le gel se fait avant l'annonce, pas après. Exportez d'abord la liste de ce que la personne possède, puis gelez, puis annoncez. L'ordre inverse laisse une fenêtre pendant laquelle une base commerciale peut être exportée en quelques clics. Le reste de l'offboarding se déroule ensuite normalement, sans urgence.

Le changement de poste interne. Ce n'est pas un offboarding Salesforce complet, et le traiter comme tel serait une erreur : la personne reste dans l'entreprise, garde son historique et souvent une partie de ses accès. On retire les permission sets devenus inutiles, on transfère le portefeuille commercial, et on repositionne le rôle si la hiérarchie change. Le compte, lui, reste actif.

Le prestataire externe. Le meilleur traitement se décide à la création du compte, pas à sa fermeture. Fixez dès le départ une date de fin d'intervention, notez-la quelque part de durable, et n'accordez que les permission sets strictement nécessaires à la mission. Un accès prestataire oublié pendant deux ans est l'un des cas les plus fréquents que je trouve en auditant les utilisateurs actifs.

Dans les trois cas, la même règle vaut : ce qui n'est pas écrit sera oublié. Une ligne dans un tableau partagé avec les ressources humaines suffit à éviter la plupart de ces situations.

Le meilleur moment pour préparer un départ

C'est avant qu'il n'arrive. Une org où les droits sont accordés par permission sets, où les intégrations passent par des comptes techniques et où les tableaux de bord ne dépendent pas d'une personne en particulier rend chaque départ presque anodin.

À l'inverse, une org où chaque utilisateur a son propre profil et où les automatisations pointent vers des personnes nommées transforme chaque départ en enquête. Le coût d'un offboarding Salesforce se décide donc bien avant le jour du départ, au moment où l'on structure les accès.

Si vous avez eu des départs non traités par le passé, le rattrapage est simple : triez vos utilisateurs actifs par dernière connexion et reprenez la checklist pour chacun. C'est un chantier d'une demi-journée qui règle souvent plusieurs années de négligence.

Questions fréquentes

Peut-on supprimer un utilisateur dans Salesforce ?

Non, et c'est volontaire. Un utilisateur se désactive, il ne se supprime pas, car son nom reste attaché à l'historique des enregistrements qu'il a créés ou modifiés. La désactivation libère la licence tout en préservant cette traçabilité.

Que devient un tableau de bord dont le propriétaire est parti ?

Il peut cesser d'afficher les bons chiffres. Un tableau de bord s'exécute avec les droits d'un utilisateur désigné : si cette personne est désactivée, les composants concernés ne se rafraîchissent plus correctement. C'est le point le plus souvent oublié d'un départ.

À lire aussi

Un doute sur votre propre org ? Décrivez-moi ce qui vous fait perdre du temps. L'analyse de votre besoin et le chiffrage ne sont pas facturés, et vous n'engagez rien avant signature.
Demander un devis

Retour au blog