Un plan de formation de lancement se décide avant la recette, pas la semaine de la bascule. Avant le premier test, il doit dire qui est formé et dans quel ordre, à quel moment, sur quels processus, dans quel environnement et avec quelles données. Décidé plus tard, il se réduit à une démonstration générique, donnée à tout le monde la même semaine.
Des utilisateurs clés qui découvrent Salesforce le premier jour de la recette passent leurs sessions à chercher où se trouve un champ. Les anomalies qu’ils remontent sont des questions de navigation. Les vrais écarts de processus (une étape de validation absente, un statut qui ne correspond à rien chez vous) passent sans être vus et ressortent en production. La recette est signée, mais ce qu’elle a testé, c’est la prise en main de l’outil.
Que faut-il avoir décidé avant la recette ?
Le plan tient en peu de décisions, mais chacune dépend d’un autre acteur du projet. Les dates de recette viennent du planning de l’intégrateur. La sandbox de formation doit être demandée, configurée puis alimentée. Le jeu de données passe par l’équipe qui prépare la reprise. Les utilisateurs clés doivent être libérés par leur manager, parfois des journées entières. Aucune de ces décisions ne se règle en dernière minute.
Le responsable du programme, interne ou externe, rédige le plan avec l’intégrateur et les utilisateurs clés. Le sponsor métier le signe, parce que c’est lui qui accorde le temps des équipes. Relisez aussi le contrat de l’intégrateur pour savoir s’il prévoit la formation des administrateurs et celle des formateurs, et qui fournit les supports.
Qui former en premier, et pourquoi cet ordre ?
Une règle suffit : chaque groupe est formé avant ceux qu’il devra aider.
Les administrateurs d’abord. Ils reprendront l’org quand l’intégrateur partira. D’ici là, ils préparent la sandbox de formation et répondent aux questions de la recette. Un administrateur qui découvre la configuration en même temps que les utilisateurs n’aide personne. Selon qu’ils découvrent l’administration ou administrent déjà une org, le cours n’est pas le même : voir ADX201 ou ADX211.
Les utilisateurs clés ensuite. Ce sont des personnes du métier, une par équipe ou par processus, qui mènent la recette puis tiennent le premier niveau de support. Formés avant la recette, ils testent leur processus dès le premier jour. Ce sont aussi eux qui forment le mieux les vagues suivantes : ils parlent la langue de leurs collègues et connaissent les exceptions.
Les managers avant leurs équipes. Cet ordre est souvent inversé, et c’est lui qui décide de l’adoption. Un manager qui réclame encore le tableur le lundi matin annule en une réunion la formation de son équipe. Formé en premier, il apprend à piloter depuis ses rapports et ses tableaux de bord, et il sait quels champs il exigera. Il peut alors libérer le temps de son équipe. Sa session lui est propre : moins de saisie, plus de lecture et de décisions.
Les utilisateurs finaux en dernier, au plus près de la bascule. Ce sont les plus nombreux, et ce qu’ils apprennent doit servir dès le lendemain.
Quand former, et à quoi sert chaque vague ?
Administrateurs et utilisateurs clés sont formés avant la recette, sur l’org configurée, avec un objectif précis : savoir dérouler un processus de bout en bout et dire s’il est juste. La recette sert ensuite à écrire les supports, puisque chaque scénario validé devient un exercice avec ses données de départ et son résultat attendu.
Managers et utilisateurs finaux, eux, attendent une configuration stable et sont formés juste avant la bascule. Former trop tôt a deux coûts : les gens oublient, et les corrections de recette changent les écrans appris. Former le jour même en a un autre : personne n’est disponible, et la première vraie question arrive avant la fin de la session.
Après la bascule, la formation sert à corriger. Des sessions courtes reprennent les questions qui reviennent au support et approfondissent les rapports des managers. Les nouveaux arrivants y sont formés à leur tour. Ce travail continue après la fin du support renforcé, car chaque release qui touche un écran du quotidien appelle une mise à jour des supports. Qui décide de ces changements relève de la gouvernance Salesforce, et le plan de formation doit y avoir sa ligne.
Sur quoi former, dans quel environnement, avec quelles données ?
La matière de la formation, ce sont vos processus. Un exercice générique (« créez un compte, puis une opportunité ») ne dit rien à un commercial qui doit savoir comment se qualifie un prospect chez vous, qui valide une remise et à quel moment part un devis. Les exercices reprennent donc les scénarios de recette, dans le vocabulaire de l’entreprise et avec ses champs obligatoires. Le test est simple : la personne refait seule, le lendemain, ce qu’elle a fait en session.
L’environnement est une sandbox de formation, séparée de la production et de la sandbox de recette. En production, un exercice crée de vrais enregistrements que quelqu’un devra nettoyer. En recette, il mélange des données d’exercice aux cas de test. La sandbox de formation reçoit la configuration validée, et chaque participant s’y connecte avec un utilisateur qui a le profil de son poste. Un formateur connecté en administrateur voit des boutons et des champs que la salle n’aura pas.
Je l’ai vu en formation : mon ancienne org de démonstration avait des fonctions déjà activées et montrait d’autres menus que ceux des stagiaires. Depuis octobre 2026, je répète chaque étape de mes supports avant la session, dans une org neuve créée comme la leur. Au lancement, même règle : chaque exercice se répète avant la session, avec un utilisateur du profil formé.
Les données doivent être réalistes et anonymisées. Une sandbox vide forme mal : un rapport sans données ne montre rien. Une copie brute de la production pose l’autre problème : les coordonnées et l’historique de vrais clients, visibles par toute la salle. Le bon jeu de données garde la forme du réel (des comptes avec leurs contacts, leurs opportunités, leurs requêtes, des statuts plausibles) et remplace tout ce qui identifie une personne. La méthode d’anonymisation se valide avec le DPO avant la première session.
Ce jeu se construit avec l’équipe qui prépare la reprise, sur les mêmes objets et dans le même ordre de chargement. Les données d’une répétition de chargement, une fois anonymisées, peuvent alimenter la sandbox de formation. Pour la méthode de reprise, voir Migration de données Salesforce : prouver avant la bascule.
Reste l’enchaînement des exercices. Dans une session ADX201, en septembre 2026, les exercices s’enchaînaient : au moment des rapports, certains stagiaires n’avaient pas l’objet créé la veille, et l’import a buté sur l’ordre parent-enfant. Mes supports, revus en octobre 2026, donnent à chaque exercice son point de départ, un rattrapage de cinq minutes et un jeu de données fourni.
Comment savoir si le plan a marché ?
La feuille de présence et l’évaluation de fin de session mesurent la session elle-même. Une session bien notée peut produire des utilisateurs qui retournent à leur tableur le lendemain. Les signes utiles se lisent dans le projet et dans l’org.
- Pendant la recette, les anomalies portent sur le processus (une règle ou un droit), pas sur l’endroit où se trouve un bouton.
- Le jour de la bascule, les utilisateurs font leurs tâches courantes sans formateur à côté, et les utilisateurs clés absorbent les premières questions.
- Les semaines suivantes, les questions « comment je fais » diminuent au support, et celles qui restent sont traitées par les utilisateurs clés.
- En réunion, les managers pilotent depuis leurs rapports et leurs tableaux de bord, et le tableur parallèle disparaît.
- Dans les données, les champs obligatoires portent des valeurs qui ont un sens, et les enregistrements naissent directement dans Salesforce.
Ces signes se fixent avant la recette, chacun avec un responsable et une date de lecture après la bascule. Sans cela, le bilan se fait à l’impression. Un signe qui ne bouge pas indique le groupe ou le processus où refaire une session.