Le release manager DevOps Salesforce organise le passage des modifications des sandboxes vers la production : stratégie de sandboxes, branches Git, construction des paquets de métadonnées, validation avec les tests Apex, déploiement, puis redescente des changements vers les environnements amont. Les offres françaises citent surtout Copado, parfois ClickDeploy, Gearset ou la Salesforce CLI, avec Git, Jenkins et Jira.
Le poste attire des profils variés. Un administrateur qui a beaucoup utilisé les change sets connaît l'org mais pas toujours Git. Un développeur Apex connaît les tests mais rarement la gestion de plusieurs sandboxes. Un DevOps venu d'autres plateformes maîtrise la CI sans savoir pourquoi un profil déployé modifie des droits. Les bons candidats parlent de format source, de couverture par classe, de quick deploy et de back-promotion.
Le contexte compte : outil en place, nombre de sandboxes, rythme de release visé. Le candidat décrit la dernière release saisonnière qu'il a préparée et un déploiement qu'il a dû défaire. Le PDF contient 30 questions, un cas de 20 minutes et une grille de 1 à 4.
L'outillage de release Salesforce et son rôle dans un déploiement
Salesforce CLI et format source
L'outil en ligne de commande de Salesforce (commande sf, qui remplace les anciennes commandes sfdx). Il récupère et déploie les métadonnées en format source, un fichier par champ ou par règle, plus lisible dans Git. C'est la base de toute chaîne de release, même quand un outil commercial s'ajoute par-dessus.
Metadata API et manifestes
L'API qui déploie objets, champs, classes Apex, flows ou mises en page d'une org à l'autre. Le contenu est décrit dans un package.xml, les suppressions dans un destructiveChanges.xml. Les données, elles, n'y passent pas et demandent un autre circuit.
Sandboxes
Les copies de la production : Developer et Developer Pro pour développer, Partial Copy avec un échantillon de données, Full avec toutes les données. Un Full se rafraîchit au plus tous les 29 jours, un Partial Copy tous les 5 jours. Leur nombre dépend de l'édition et des licences, et leur organisation fait une bonne part du poste.
Copado
La plateforme de release la plus citée dans les offres françaises. Elle s'installe dans Salesforce, gère les user stories, les promotions entre environnements et la back-promotion, et s'appuie sur Git. Depuis avril 2026, l'éditeur met en avant Agentia, son offre d'agents IA pour le DevOps Salesforce, mais les CV et les offres parlent de Copado.
Gearset
Un service externe qui compare deux orgs ou une org et une branche Git, aide à construire le déploiement et signale les dépendances manquantes. Il propose aussi des pipelines, des sauvegardes, le déploiement de données et des retours arrière à partir d'instantanés.
DevOps Center et ClickDeploy
DevOps Center est l'outil gratuit de Salesforce, branché sur GitHub, plus simple que Copado ou Gearset. ClickDeploy apparaît dans certaines offres pour des déploiements plus légers. Un candidat qui connaît l'un d'eux s'adapte vite aux autres s'il comprend Git et la Metadata API.
Tests Apex et niveaux de test
Un déploiement en production qui contient de l'Apex exige 75 % de couverture et des tests qui passent. Le niveau de test choisi (tous les tests locaux, une liste précise, ou les tests pertinents, en bêta depuis 2026) change la règle de couverture et la durée de la validation. C'est souvent ce qui fait échouer une mise en production.
Unlocked packages
Une façon de découper l'org en paquets versionnés, créés depuis une Dev Hub et installés par numéro de version. Utile pour les grosses orgs bien découpées, difficile à mettre en place sur une org ancienne pleine de dépendances.
Releases saisonnières
Salesforce met à jour toutes les orgs trois fois par an (Spring, Summer, Winter). Les sandboxes en preview reçoivent la version quelques semaines avant la production, ce qui donne une fenêtre pour tester et crée un décalage de version à gérer pendant les déploiements.
Le release manager Salesforce arrive souvent dans une org où les livraisons passent encore par des change sets et où des corrections se font directement en production. Sa première mission est alors de mettre Git au centre et de réaligner les sandboxes. Dans une équipe déjà outillée, il administre Copado ou Gearset, tient le calendrier, arbitre les conflits entre équipes et prépare les releases saisonnières. Certaines offres le combinent avec un rôle de tech lead et demandent alors Apex et LWC. Copado et Gearset proposent leurs propres formations et certifications. Elles attestent l'usage de l'outil. La capacité à remettre de l'ordre dans une org se vérifie en entretien.
Compétences à vérifier chez un release manager Salesforce
- Métadonnées, Metadata API et Salesforce CLI
- Stratégie de sandboxes et d'environnements
- Branches Git et conflits de métadonnées
- Copado, Gearset ou chaîne CLI maison
- Tests Apex, couverture et validation
- Releases saisonnières et retour arrière
Release manager Salesforce : cinq questions avec réponse attendue
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é
Quel niveau de test choisissez-vous pour un déploiement en production, et quelles règles de couverture s'appliquent ?
Une bonne réponseRunLocalTests est le défaut en production dès qu'il y a de l'Apex : tous les tests de l'org sauf ceux des packages installés, avec 75 % de couverture globale et chaque trigger couvert. RunSpecifiedTests lance une liste choisie, mais chaque classe et chaque trigger du déploiement doit alors être couvert à 75 %, un par un. RunAllTestsInOrg inclut les packages gérés. RunRelevantTests, en bêta depuis l'API 66.0, laisse Salesforce choisir les tests liés au contenu, avec la même règle classe par classe. NoTestRun ne s'utilise pas en production quand il y a de l'Apex.
Signal d'alerte« NoTestRun pour aller plus vite », ou ignorer que RunSpecifiedTests calcule la couverture classe par classe.
Question 2 · confirmé
Un sandbox Full vient d'être rafraîchi et les développeurs ont perdu le travail de la semaine. Qu'est-ce qui manquait ?
Une bonne réponseUn refresh remplace tout le sandbox par une copie de la production, donc Git doit être la référence et tout travail commité avant. Le calendrier des refresh est annoncé (un Full se rafraîchit au plus tous les 29 jours, un Partial Copy tous les 5 jours, un Developer chaque jour). Après le refresh, il redéploie les travaux en cours depuis Git, réapplique le masquage des données, reconfigure les intégrations (Named Credentials, endpoints) et vérifie que l'envoi d'e-mails est limité. Une classe SandboxPostCopy automatise une partie de ce travail.
Signal d'alerteLe sandbox considéré comme la source de vérité.
Question 3 · confirmé
Deux équipes modifient l'objet Account dans des branches différentes. Où naissent les conflits, et comment les réduisez-vous ?
Une bonne réponseEn format source, chaque champ a son fichier et ne pose pas de souci. Les conflits viennent des fichiers qui regroupent beaucoup d'éléments : mises en page, profils, pages Lightning, labels personnalisés, traductions, ou le fichier de l'objet lui-même. Il réduit les branches longues, fusionne souvent et utilise un outil qui résout les conflits en comprenant le XML Salesforce plutôt qu'un merge ligne à ligne.
Signal d'alerte« Git gère les conflits », sans savoir lesquels arrivent en pratique.
Question 4 · confirmé
Pourquoi les profils posent-ils autant de problèmes dans les déploiements Salesforce, et que faites-vous à la place ?
Une bonne réponseUn profil récupéré par la Metadata API ne contient que les droits liés aux composants demandés dans le même retrieve. Le fichier change donc selon ce qu'on récupère, les diffs trompent, les conflits sont fréquents et un déploiement peut modifier des droits sans que la revue le montre. Il déplace les droits vers des permission sets et des permission set groups, garde des profils minimaux, et s'appuie sur un outil qui compare les profils élément par élément.
Signal d'alerteDéployer les profils complets à chaque release sans les relire.
Question 5 · confirmé
Copado, Gearset ou DevOps Center : sur quels critères choisissez-vous l'outil de release d'une org Salesforce ?
Une bonne réponseCopado s'installe dans l'org comme un package, organise le travail en user stories, promotions et pipelines, et convient aux équipes nombreuses avec un processus encadré, au prix d'une administration lourde. Gearset est un service externe, fort sur la comparaison entre orgs et Git, avec pipelines, sauvegardes et déploiement de données. DevOps Center, fourni par Salesforce, s'appuie sur GitHub et reste plus simple. La Salesforce CLI avec GitHub Actions, GitLab CI ou Jenkins convient aux équipes à l'aise avec le code. Il décide sur la taille de l'équipe, la part d'administrateurs, le Git existant et le budget.
Signal d'alerte« Copado, c'est le standard » sans autre critère.
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
Release manager Salesforce : les questions fréquentes
Release manager Salesforce et développeur Salesforce : quelle différence de profil ?
Le développeur écrit l'Apex, les LWC et les flows d'une fonctionnalité. Le release manager fait passer le travail de toutes les équipes d'org en org : il construit les paquets de métadonnées, choisit les niveaux de test, gère les conflits et les sandboxes, et décide du déploiement. Il lit l'Apex pour comprendre un test qui échoue, sans forcément en écrire tous les jours. Certaines offres combinent les deux rôles.
Les certifications Copado ou Salesforce sont-elles utiles pour juger un candidat ?
Elles montrent que la personne connaît l'outil ou la plateforme. Certaines offres demandent une certification Copado de premier niveau. Elles ne disent rien de la gestion d'une org où des corrections arrivent en production sans passer par Git, ni d'une release saisonnière ratée. Une situation réelle compte davantage : un déploiement défait, un refresh qui a mal tourné, des sandboxes réalignés.
Quel test technique est donné à un release manager Salesforce ?
L'exercice part d'un package.xml, de la liste des user stories et d'un message d'échec de validation (couverture à 68 % sur une classe, champ référencé par un flow). Le candidat explique la cause, corrige le paquet et choisit le niveau de test. Une heure, en direct, suffit pour voir s'il connaît la Metadata API et les règles de couverture.
Un candidat formé sur Copado peut-il travailler sur Gearset ?
Oui, s'il comprend ce que l'outil fait dans Git et avec la Metadata API. Les deux reposent sur les mêmes notions : branches par environnement, promotion, redescente des changements, validation avec tests. L'interface et le vocabulaire changent. Un profil qui ne connaît que les boutons de Copado aura plus de mal. Le candidat doit pouvoir expliquer ce qui se passe dans Git lors d'une promotion.
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.
