Les équipes commerciales et de service client expriment leurs besoins en processus, en rapports et en écrans. Le business analyst Salesforce les traduit dans le modèle de la plateforme : objets standard ou personnalisés, flows, règles de validation, partage. Les questions d'entretien business analyst Salesforce lui font modéliser un cas, écrire une user story et décrire qui voit quels enregistrements.
Le profil se situe entre l'administrateur et le chef de projet. Certains BA configurent eux-mêmes en sandbox, d'autres rédigent pour un administrateur ou un développeur. Les deux fonctionnent, à condition de connaître les limites de la plateforme. Un candidat qui propose du code Apex pour chaque automatisation, ou qui ignore que Salesforce a arrêté le support des règles de workflow et de Process Builder fin 2025, n'a pas suivi l'évolution de l'outil.
Sa pratique des releases compte aussi. Salesforce livre trois versions par an, et le BA prépare le métier aux changements visibles. La certification Salesforce Business Analyst couvre la découverte, les exigences, la cartographie des processus, les user stories et la recette. Elle complète l'expérience sans la remplacer.
Ce que le business analyst Salesforce configure ou spécifie
Sales Cloud
Le module commercial : leads, comptes, contacts, opportunités, produits et prévisions. La majorité des offres de BA Salesforce le citent. Le candidat doit connaître le cycle de vente standard avant de proposer des objets personnalisés.
Service Cloud
La gestion des demandes clients : requêtes, files d'attente, règles d'affectation, délais de traitement et escalades. Les canaux courriel et formulaire web créent les requêtes automatiquement. La modélisation des délais promis aux clients est un bon sujet d'entretien.
Objets et relations
Le modèle de données de Salesforce. Objets standard et personnalisés, relations de recherche ou principal-détails, objets de jonction, types d'enregistrements. Un mauvais choix ici pèse sur les rapports, le partage et les automatisations pendant des années.
Flow Builder
L'outil d'automatisation déclarative de Salesforce, qui remplace les règles de workflow et Process Builder (support arrêté fin 2025). Flows déclenchés par un enregistrement, flows d'écran, flows planifiés. Le BA doit savoir spécifier les conditions d'entrée et le comportement en cas d'erreur.
Sécurité et partage
Profils, ensembles d'autorisations, rôles, paramètres par défaut de l'organisation et règles de partage. Ce sont eux qui décident de ce que chaque utilisateur peut faire et voir. Les erreurs de partage apparaissent souvent tard, en recette ou après la mise en service.
Rapports et tableaux de bord
Les rapports natifs de Salesforce, construits sur des types de rapports. Le BA part souvent du rapport attendu par la direction pour remonter aux champs et aux objets nécessaires.
Sandboxes et releases
Les environnements de travail (Developer, Developer Pro, Partial Copy, Full) et le rythme de trois releases par an. Le BA y fait ses recettes et teste les nouveautés en préversion avant qu'elles arrivent en production.
Jira ou Azure DevOps
Les outils de suivi du backlog les plus cités dans les offres. Le BA y écrit les user stories, les critères d'acceptation et rattache les anomalies de recette.
Le business analyst Salesforce travaille chez un client qui utilise la plateforme ou chez un intégrateur, souvent dans une équipe agile avec un product owner, un administrateur et des développeurs. Sur un premier déploiement, il mène la découverte et rédige le backlog. Sur une organisation en place, il traite les évolutions, nettoie ce qui a été empilé au fil des années et prépare les releases. Les missions portent le plus souvent sur Sales Cloud et Service Cloud, parfois sur Experience Cloud ou des outils de devis. Selon le poste, il configure lui-même en sandbox ou rédige pour l'administrateur.
Les savoir-faire Salesforce attendus du BA
- Modélisation des objets et des relations
- Spécification d'automatisations Flow
- Sécurité et règles de partage
- Découverte et user stories
- Recette, reprise et releases
- Arbitrage déclaratif ou code
Cinq mises en situation pour un business analyst Salesforce
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Les commerciaux veulent suivre des contrats qui couvrent plusieurs produits et plusieurs sites du client. Comment modélisez-vous cela dans Salesforce ?
Une bonne réponseIl part des objets standard (compte, opportunité, produits d'opportunité, contrat) avant de créer quoi que ce soit. Le site devient un objet personnalisé rattaché au compte, et la relation entre contrats et sites passe par un objet de jonction avec deux relations principal-détails. Il explique la différence entre recherche (lookup) et principal-détails : propriétaire, partage hérité, champs de cumul, suppression en cascade. Il pense aux rapports dont le métier aura besoin.
Signal d'alerteAjouter sur le compte des champs « Site 1 », « Site 2 », « Site 3 », ou créer un objet personnalisé qui recopie l'opportunité.
Question 2 · confirmé
Quand une opportunité passe à « Gagnée », un dossier de mise en service doit être créé et l'équipe concernée prévenue. Comment le spécifiez-vous, et avec quel outil ?
Une bonne réponseUn flow déclenché par l'enregistrement, après sauvegarde, sur l'opportunité, avec une condition qui ne s'exécute que lorsque l'étape devient « Gagnée » (et pas à chaque modification). Le flow crée le dossier, l'affecte à une file d'attente et envoie la notification. Le candidat décrit le chemin d'erreur, le cas d'une mise à jour en masse par import et ce qui se passe si l'opportunité repasse à une autre étape. Il ne propose ni règle de workflow ni Process Builder, dont Salesforce a arrêté le support fin 2025.
Signal d'alerte« On demande un trigger Apex » par réflexe, ou un Process Builder. Une spécification qui oublie la condition d'entrée et crée un dossier à chaque modification.
Question 3 · confirmé
Chaque commercial ne doit voir que les comptes de son secteur géographique, ses managers ceux de leur équipe, le service client tous les comptes sans pouvoir les modifier. Quel modèle de partage décrivez-vous à l'administrateur ?
Une bonne réponseDes paramètres par défaut de l'organisation en privé sur les comptes, la hiérarchie des rôles pour que les managers voient les comptes de leurs équipes, des règles de partage sur critère (la région) pour les commerciaux d'une même zone. Pour le service client, une règle de partage en lecture vers son groupe ou son rôle. Il garde des profils minimaux, donne les droits par ensembles d'autorisations et précise la sécurité au niveau des champs sensibles.
Signal d'alerteUn profil par région, ou un accès public en lecture et écriture « pour simplifier ». Une confusion entre ce qu'un utilisateur peut faire (profil) et les enregistrements qu'il voit (partage).
Question 4 · junior à confirmé
Les commerciaux convertissent des leads qui créent des comptes en double. Quelle user story et quels critères d'acceptation écrivez-vous pour la conversion ?
Une bonne réponseUne story avec le rôle, le besoin et le bénéfice, puis des critères vérifiables : champs obligatoires avant conversion, détection des doublons sur le compte et le contact (règles de doublons), mappage des champs personnalisés du lead vers le compte, le contact et l'opportunité, création d'opportunité facultative, propriétaire attribué. Il écrit les critères sous forme de situations testables (étant donné, quand, alors).
Signal d'alerte« En tant qu'utilisateur, je veux un bouton Convertir », sans critère, ou des critères qui ne peuvent pas se tester.
Question 5 · confirmé
Une release Salesforce arrive dans six semaines. Que faites-vous côté métier pour éviter les mauvaises surprises ?
Une bonne réponseIl lit les notes de version, repère ce qui touche les fonctions utilisées, demande une sandbox en préversion et y rejoue les scénarios de non-régression des processus principaux. Il vérifie les mises à jour de version (release updates) à activer, prépare un message pour les utilisateurs sur ce qui change à l'écran et note ce qui peut remplacer un développement existant. Il sait qu'il y a trois releases par an.
Signal d'alerte« Salesforce gère les mises à jour, il n'y a rien à faire. »
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Business analyst Salesforce : questions fréquentes
Business analyst ou administrateur Salesforce : quel profil pour le poste ?
L'administrateur fait tourner l'organisation au quotidien : utilisateurs, droits, configuration, petites évolutions. Le business analyst part du métier, conduit les ateliers, écrit les user stories et prépare la recette. Sur une petite organisation, une seule personne fait souvent les deux. Dès qu'un projet implique plusieurs équipes ou plusieurs processus, séparer les rôles aide. L'annonce doit dire si le BA configure lui-même ou rédige pour un administrateur.
Que vaut la certification Salesforce Business Analyst ?
Elle atteste la connaissance de la méthode d'analyse appliquée à Salesforce : découverte, exigences, cartographie, user stories, recette. Elle ne prouve pas qu'un candidat a mené un projet réel. Elle se lit avec la certification Platform Administrator si le poste demande de la configuration, et surtout avec des exemples concrets : un flow spécifié, un modèle de partage conçu, une reprise menée.
Comment se déroule le test technique d'un business analyst Salesforce ?
Le test part d'un besoin court, par exemple la gestion des réclamations d'un service client, et attend en quarante-cinq minutes un modèle d'objets, deux user stories avec critères et une description du partage. Si le poste inclut de la configuration, un flow simple se construit dans une sandbox de démonstration. Le candidat commente ses choix à voix haute : le raisonnement compte autant que le résultat.
Quel niveau technique attendre d'un BA Salesforce ?
Il doit connaître les possibilités et les limites de la plateforme : modèle d'objets, automatisations déclaratives, partage, limites de traitement en masse. Il n'a pas besoin d'écrire du code Apex. Il doit savoir dire quand un besoin dépasse le déclaratif et le formuler pour un développeur. Un BA qui ne connaît pas la différence entre un profil et une règle de partage risque de spécifier des solutions impossibles.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
