Le chef de projet Salesforce pilote la mise en place ou l'extension d'une org : Sales Cloud, Service Cloud, souvent Experience Cloud ou Marketing Cloud à côté, avec un ou plusieurs partenaires intégrateurs. Il n'a pas à configurer lui-même, même si beaucoup d'offres demandent de savoir le faire sur des cas simples. Il répond du périmètre, du budget, de la recette et de la mise en service.
Côté CV, deux profils reviennent. L'ancien consultant ou administrateur Salesforce connaît la plateforme et ses limites, mais n'a pas toujours tenu un contrat ou un comité. Le chef de projet généraliste sait piloter, sans savoir ce qu'une licence plateforme autorise ou ce que change une release au planning. Une mise en service vécue sert de fil : la date, ce qui a été repris, ce qui a coincé le premier jour.
Trois sujets récents servent de test rapide : la fin du support des règles de workflow et de Process Builder au 31/12/2025, l'arrêt de la vente de CPQ aux nouveaux clients et la dépréciation de l'intégration Open CTI de Genesys. Un candidat actif sur Salesforce en a entendu parler. Le PDF contient un cas de 20 minutes sur un déploiement en deux clouds.
Ce que recouvrent clouds, licences et outils d'un projet Salesforce
Les clouds Salesforce
Sales Cloud pour les ventes, Service Cloud pour le service client, Experience Cloud pour les portails clients ou partenaires, Marketing Cloud pour les campagnes. Ils partagent souvent la même org et les mêmes comptes clients. Ajouter un cloud, c'est ajouter un métier, des licences et des règles de visibilité dans une base commune.
Licences et éditions
Chaque utilisateur a un type de licence qui fixe les objets qu'il peut utiliser, et l'édition (Enterprise, Unlimited) fixe les sandboxes, les limites et le support. Le contrat est un abonnement pluriannuel avec des clauses de renouvellement. Le statut commercial des produits change : CPQ n'est plus vendu aux nouveaux clients, Revenue Cloud Advanced est présenté comme son successeur.
Releases saisonnières
Salesforce met à jour toutes les orgs trois fois par an (printemps, été, hiver), à des dates publiées par instance. Les sandboxes placées sur une instance de preview reçoivent la nouvelle version quatre à six semaines avant la production. Un projet de dix-huit mois en traverse cinq ou six, chacune avec ses tests.
Sandboxes et pipeline de livraison
Les sandboxes sont des copies de la production pour développer, tester et recetter. Les livraisons passent par Git et un outil de déploiement : DevOps Center de Salesforce, Copado, Gearset ou la Salesforce CLI. Le chef de projet décide qui possède ce pipeline, ce qui pèse le jour où l'intégrateur change.
Flow et automatisations historiques
Flow est l'outil d'automatisation sans code de Salesforce. Les règles de workflow et Process Builder, plus anciens, ne sont plus supportés depuis le 31/12/2025 : ils tournent encore, mais leurs défauts ne seront plus corrigés. Une org ancienne en contient souvent des dizaines, à migrer et à chiffrer.
Reprise et intégrations
La reprise depuis un ancien CRM passe par Data Loader ou Bulk API 2.0. Les intégrations avec l'ERP, l'outil d'e-mailing ou la téléphonie passent par les API de Salesforce ou un middleware comme MuleSoft, dans les limites d'appels fixées par l'édition.
Agentforce et produits à la consommation
Agentforce ajoute des agents d'IA dans les clouds Salesforce. Salesforce le vend à la consommation (Flex Credits ou conversations) ou en licences par utilisateur. La consommation se suit autrement qu'un nombre de licences fixe. Un pilote demande des données propres, des droits bien définis et un budget de consommation suivi.
Le chef de projet Salesforce travaille chez le client final, rattaché à la DSI ou à une direction commerciale ou relation client, ou chez un partenaire intégrateur qui conduit le projet pour le client. Côté client, il pilote un ou plusieurs partenaires, porte le contrat de licences avec les achats et prépare le run de l'org. Côté intégrateur, il tient le forfait, l'équipe et la relation avec le client. Les offres associent souvent le poste à un rôle de product owner, demandent Sales Cloud et Service Cloud, parfois Experience Cloud, Marketing Cloud ou un cloud métier, et une bonne compréhension des intégrations (MuleSoft, ERP, téléphonie). L'anglais est fréquent dans les programmes internationaux.
Ce qu'un chef de projet Salesforce doit savoir arbitrer
- Choix des clouds et des licences
- Pilotage d'un partenaire intégrateur Salesforce
- Planning calé sur les releases
- Gouvernance des environnements et des livraisons
- Reprise des données et intégrations
- Mise en service, adoption et budget de l'org
Des questions de projet Salesforce, de la licence à la mise en service
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é à senior
Le projet compte 300 commerciaux, 80 agents du service client et 400 personnes qui consultent seulement les comptes. Comment construisez-vous la demande de licences ?
Une bonne réponsePar usage réel : Sales Cloud pour les commerciaux, Service Cloud pour les agents, et une licence plateforme moins chère pour les consultations, après avoir vérifié quels objets standard elle donne le droit d'utiliser (les opportunités et les requêtes n'y sont pas toujours accessibles). Il compare les éditions sur ce qui compte pour le projet (sandboxes incluses, limites d'API, support), prévoit une montée en charge des licences au rythme du déploiement et vérifie le statut commercial de chaque produit : CPQ, par exemple, n'est plus vendu aux nouveaux clients. Il fait relire les clauses de renouvellement.
Signal d'alerteUne seule licence Sales Cloud pour tout le monde, ou la licence la moins chère choisie sans vérifier les objets accessibles.
Question 2 · confirmé
L'intégrateur Salesforce livre chaque sprint à l'heure, mais la recette métier rejette un tiers des user stories. Que faites-vous ?
Une bonne réponseIl fait classer les rejets : story mal écrite, critères d'acceptation absents, besoin qui a changé, défaut de réalisation, données de test inadaptées dans la sandbox de recette. Selon la cause, il renforce la définition de prêt (story validée par le métier avant le sprint), fait démontrer la configuration au métier pendant le sprint et non après, ou exige une correction sans coût si le défaut vient de l'intégrateur. Il suit le taux de rejet sprint par sprint.
Signal d'alerteAccuse le métier ou l'intégrateur sans analyse, ou accepte les stories pour tenir le planning.
Question 3 · senior
La sandbox de recette vient de passer sur la prochaine release, la production non. Qu'est-ce que cela change pour la recette en cours ?
Une bonne réponseLa recette valide une version que la production n'a pas encore : une anomalie peut venir de la release et non du projet, et un comportement accepté peut changer à la mise à jour de la production. Il fait qualifier chaque anomalie selon son origine, garde si possible une sandbox sur la version actuelle pour comparer, vérifie qu'un déploiement depuis la sandbox mise à jour passe vers la production restée sur l'ancienne version, et recale les dates de mise en service sur le calendrier publié.
Signal d'alerteNe voit pas la différence, ou découvre au déploiement que des métadonnées de la nouvelle version ne passent pas en production.
Question 4 · senior
Trois équipes livrent dans la même org : l'intégrateur, une agence pour Experience Cloud et l'équipe interne. Comment organisez-vous les livraisons ?
Une bonne réponseUn seul dépôt Git qui fait référence, un pipeline commun (DevOps Center, Copado, Gearset ou la Salesforce CLI) que le client possède, un chemin d'environnements partagé, un calendrier de livraison unique et des revues croisées sur les objets que plusieurs équipes touchent. Des conventions de nommage et une instance de conception commune arbitrent les conflits. Personne ne modifie la production en direct.
Signal d'alerteChaque équipe déploie avec ses change sets depuis sa sandbox, et on découvre les écrasements en production.
Question 5 · senior
La reprise depuis l'ancien CRM doit tenir sur un week-end, mais les essais montrent 30 heures de chargement. Que faites-vous ?
Une bonne réponseIl fait charger l'historique ancien plusieurs jours avant, et ne garde pour le week-end que les données modifiées depuis. Il demande l'usage de Bulk API 2.0 en parallèle quand c'est possible, la désactivation contrôlée des flows, triggers et règles de validation pendant la reprise, et le report du recalcul des partages. Il refait un essai complet avec les nouvelles durées et fixe un point de décision si la fenêtre ne tient pas.
Signal d'alerteProlonge la fenêtre de bascule sans chercher où passe le temps, ou laisse toutes les automatisations actives pendant le chargement.
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
Questions fréquentes sur le chef de projet Salesforce
Chef de projet Salesforce ou product owner Salesforce : quelle différence ?
Le product owner gère un backlog et des priorités sur une org qui existe, souvent dans la durée. Le chef de projet porte un périmètre, un budget, un contrat avec un intégrateur et une date de mise en service. Beaucoup d'offres mélangent les deux. Quand un contrat d'intégration ou de licences se signe dans l'année, mieux vaut un chef de projet qui l'a déjà fait. Si l'org est stable et que le métier pousse des évolutions, un product owner suffit.
Quelles certifications Salesforce pour un chef de projet ?
Aucune n'est indispensable. Une certification de consultant sur un cloud du projet, comme Salesforce Certified Agentforce Sales Consultant pour Sales Cloud, ou la certification Salesforce Certified Platform Administrator montre que la personne connaît la plateforme. Elle ne dit rien du pilotage d'un contrat ou d'une mise en service. Comptent davantage les projets menés jusqu'au démarrage, leur taille, et ce que la personne a décidé elle-même.
Quel test technique pour un chef de projet Salesforce ?
Un cas écrit plutôt qu'une configuration à l'écran. Le cas décrit une org existante, un nouveau cloud à déployer, un intégrateur retenu et une release qui tombe près de la mise en service. Le candidat propose un découpage, la liste des licences, un plan de reprise et la réponse à une recette qui rejette un tiers des user stories. Vingt minutes de préparation suffisent, puis les chiffres avancés se discutent avec la grille du PDF.
Un chef de projet venu de Dynamics 365 ou de SAP peut-il réussir sur Salesforce ?
Oui pour le pilotage, si la personne apprend vite la logique de la plateforme : licences par type d'utilisateur, trois releases par an imposées, livraisons par métadonnées et pipeline Git. Les premiers mois, elle dépendra plus de l'architecte et de l'intégrateur. L'entretien vérifie qu'elle a déjà travaillé sur un SaaS mis à jour par l'éditeur, et qu'elle pose les bonnes questions sur les licences et les releases.
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.
