Scorecard Développeur Salesforce
Voici comment évaluer un Développeur Salesforce en entretien : les compétences à noter, les questions à poser et les signaux d'alerte. Une grille de base, à ajuster selon votre contexte et vos priorités.
Un exemple à adapter. Cette scorecard est un modèle, pas une grille à appliquer telle quelle. Gardez les critères qui correspondent à votre poste et à votre équipe, ajustez ou retirez les autres. Le bon profil dépend de votre contexte.
Développeur Salesforce
La mission en une phrase
Livraison de fonctionnalités fiables
Développe en Apex et en Lightning Web Components des fonctionnalités testées, documentées et déployées proprement entre les environnements via un pipeline maîtrisé.
Arbitrage configuration et code
Privilégie la configuration native quand elle suffit et réserve le développement aux cas qui le justifient, afin de limiter la dette technique et faciliter la maintenance.
Intégrations stables avec le système d'information
Conçoit et fiabilise les échanges entre Salesforce et les autres applications par API, avec une gestion robuste des erreurs et des volumes.
Respect des limites de la plateforme
Anticipe les governor limits et optimise les requêtes et les traitements pour éviter les régressions de performance en production.
✗ Faible · Code au cas par cas sans logique de traitement par lot, néglige la couverture de tests ou ne sait pas justifier ses assertions.
✓ Excellent · Écrit des classes et des triggers Apex structurés, gère le bulk processing et couvre son code par des tests unitaires pertinents.
✗ Faible · Reste sur des approches anciennes sans maîtriser LWC, ou produit des composants difficiles à réutiliser et à maintenir.
✓ Excellent · Construit des composants LWC réutilisables, gère l'échange de données avec Apex et respecte les standards de l'expérience Lightning.
✗ Faible · Code systématiquement par réflexe, même quand un outil déclaratif natif aurait répondu au besoin plus simplement.
✓ Excellent · Identifie quand un flow ou une règle de validation suffit et quand le code devient nécessaire, en argumentant sur la maintenabilité.
✗ Faible · Conçoit des intégrations fragiles, sans gestion d'erreur ni reprise, et sous-estime les contraintes de volume.
✓ Excellent · Met en place des appels entrants et sortants en REST ou SOAP, sécurise l'authentification et gère les erreurs et les volumes.
✗ Faible · Ignore les limites jusqu'à l'incident, ou ne sait pas diagnostiquer un dépassement de gouverneur.
✓ Excellent · Connaît les governor limits, optimise ses requêtes SOQL et ses traitements asynchrones pour rester sous les seuils en production.
✗ Faible · Développe sans relier ses choix techniques aux usages métier ni au modèle de partage des données.
✓ Excellent · Comprend le modèle de données standard, le modèle de sécurité et la façon dont les équipes ventes ou service utilisent l'outil.
✗ Faible · N'a aucune certification ni habitude de veille, et reste figé sur des pratiques obsolètes.
✓ Excellent · Détient des certifications développeur à jour et suit l'évolution des releases pour adapter ses pratiques.
Traduction du besoin métier
✗ Faible · Exécute la demande à la lettre sans interroger le besoin réel ni proposer d'alternative.
✓ Excellent · Reformule une demande floue en exigences techniques claires et challenge le besoin quand une solution plus simple existe.
Rigueur et qualité
✗ Faible · Livre vite mais laisse derrière lui un code non documenté et difficile à reprendre.
✓ Excellent · Documente, teste et applique des conventions de code, et soigne la maintenabilité de ses livrables.
Collaboration avec les administrateurs et le métier
✗ Faible · Travaille en silo, court-circuite les administrateurs ou ignore les contraintes du paramétrage existant.
✓ Excellent · Travaille en bonne intelligence avec les administrateurs et les référents métier pour répartir les responsabilités.
Autonomie et résolution de problèmes
✗ Faible · Se bloque rapidement, attend des consignes détaillées ou contourne le problème sans le comprendre.
✓ Excellent · Diagnostique un dysfonctionnement de bout en bout et avance sans être bloqué par l'incertitude.
Compétences techniques
Comment décidez-vous entre une solution déclarative et du développement Apex pour un besoin donné ?
→ Évaluer la capacité d'arbitrage entre configuration et code et le souci de maintenabilité.
Comment concevez-vous un trigger ou un traitement qui doit gérer un volume important d'enregistrements sans dépasser les limites ?
→ Vérifier la maîtrise du bulk processing et des governor limits.
Réalisations & expérience
Décrivez un projet Salesforce que vous avez mené de bout en bout. Quel était votre périmètre et quels choix techniques avez-vous portés ?
→ Mesurer la profondeur réelle de l'expérience et la part de responsabilité technique assumée.
Mise en situation
Racontez une intégration entre Salesforce et un autre système. Comment avez-vous géré les erreurs et la volumétrie ?
→ Apprécier la robustesse de conception sur les échanges par API.
Une fonctionnalité fonctionne en recette mais échoue en production sous la charge. Comment diagnostiquez-vous et corrigez-vous ?
→ Tester la méthode de diagnostic et la connaissance des contraintes de production.
Motivation & fit
Comment maintenez-vous vos compétences à jour face au rythme des releases et aux certifications ?
→ Jauger la curiosité, la rigueur de veille et l'investissement dans l'écosystème.
Savoir-être & collaboration
Un référent métier vous demande une solution complexe à coder. Comment menez-vous l'échange ?
→ Observer la capacité à challenger le besoin et à proposer une alternative pertinente.
Recourt systématiquement au code même quand la configuration native suffit
Génère de la dette technique inutile et alourdit la maintenance future de l'organisation.
Ne maîtrise pas les governor limits ni le traitement par lot
Expose la production à des incidents de performance dès que les volumes augmentent.
Néglige les tests unitaires et la couverture de code
Fragilise les déploiements et complique toute évolution ultérieure de la solution.
Conçoit des intégrations sans gestion d'erreur ni reprise
Provoque des pertes de données silencieuses et des désynchronisations difficiles à rattraper.
Ne relie jamais ses choix techniques au besoin métier
Livre des solutions techniquement correctes mais inadaptées aux usages réels des équipes.
Lecture du score
Notez chaque compétence et savoir-être de 1 à 5. Repère de décision : moyenne supérieure ou égale à 4 sur les must-have et aucun red flag majeur = go ; 3 à 4 avec réserves = à challenger en second tour ; un must-have sous 3 ou un red flag majeur = no-go. Un nice-to-have faible ne doit jamais éliminer un bon profil.
Qu'est-ce qu'une scorecard pour recruter un Développeur Salesforce ?
Une scorecard développeur salesforce est une grille d'évaluation structurée : elle liste les compétences et savoir-être à noter de 1 à 5, les questions d'entretien à poser et les signaux d'alerte. Elle permet de comparer les candidats sur des critères objectifs plutôt que sur une impression. On parle aussi de scorecard développeur salesforce, scorecard dev apex, scorecard consultant technique salesforce.
Comment utiliser cette scorecard Développeur Salesforce ?
Téléchargez-la en PDF, Excel ou Notion, notez chaque critère de 1 à 5 pendant l'entretien, puis additionnez les scores du panel pour décider sur des faits. La version Excel calcule la moyenne et la décision automatiquement.
Quelle est la différence entre un développeur Salesforce, un administrateur et un consultant fonctionnel ?
L'administrateur configure la plateforme avec les outils déclaratifs natifs et gère les utilisateurs, les droits et le paramétrage courant. Le consultant fonctionnel cadre le besoin métier, conçoit la solution cible et fait le lien entre les équipes et l'outil. Le développeur intervient quand le besoin dépasse la configuration : il code en Apex et en Lightning Web Components, construit les intégrations par API et traite les cas que les outils natifs ne couvrent pas. Sur un projet, ces trois profils se complètent plutôt qu'ils ne se substituent.
Faut-il exiger des certifications pour recruter un développeur Salesforce ?
Les certifications développeur confirment un socle de connaissances et rassurent sur la maîtrise des fondamentaux, mais elles ne remplacent jamais la mise à l'épreuve sur des cas concrets. Un profil certifié sans projet livré peut rester théorique, à l'inverse un développeur expérimenté non certifié peut être excellent. Le bon réflexe consiste à traiter la certification comme un nice-to-have et à valider en entretien la qualité réelle du code, l'arbitrage configuration ou développement et la compréhension des limites de la plateforme.