Développeur Salesforce Apex et LWC, des triggers en masse aux composants

Une contrainte attend les développeurs Java ou JavaScript qui arrivent sur Salesforce, et les questions d'entretien pour un développeur Salesforce Apex / LWC tournent autour d'elle. Chaque transaction a ses limites : 100 requêtes SOQL en synchrone, 150 instructions DML, dix secondes de CPU. Un trigger écrit pour un enregistrement passe la recette et casse au premier import de 10 000 lignes. Demandez comment la personne traite 200 enregistrements à la fois.

L'automatisation déclarative a aussi changé. Les règles de workflow et Process Builder sont abandonnés au profit de Flow, devenu l'outil de référence. Un bon développeur sait quand un Flow suffit et quand le code se justifie, et fait cohabiter les deux sur un même objet sans mises à jour en double.

Côté interface, Aura et Visualforce restent présents dans beaucoup d'organisations, mais les nouveaux composants s'écrivent en LWC. Vérifiez enfin le respect du partage : une classe Apex sans with sharing peut montrer à un utilisateur des comptes qu'il ne devrait pas voir. Le PDF ajoute un cas de 20 minutes sur l'escalade automatique des cas Service Cloud.

Ce que le développeur Salesforce manipule au quotidien

Apex

Le langage de Salesforce, proche de Java, exécuté sur les serveurs de la plateforme. On y écrit des classes, des triggers et des traitements asynchrones. Chaque transaction est plafonnée par les limites gouverneur, et le code ne part en production qu'avec 75 % de couverture par les tests.

SOQL et SOSL

Les langages de requête de Salesforce. SOQL lit les enregistrements d'un objet et de ses relations, SOSL fait une recherche plein texte sur plusieurs objets. Sur de gros volumes, la sélectivité des filtres décide si une requête répond en une seconde ou tombe en timeout.

Triggers et framework de trigger

Le code qui s'exécute à la création, la modification ou la suppression d'un enregistrement. Les équipes sérieuses gardent un seul trigger par objet, qui délègue à une classe, avec un moyen de le désactiver pendant une reprise de données. Demandez quel framework la personne a utilisé.

Apex asynchrone

future, Queueable, Batch et Schedulable, pour les traitements longs, les gros volumes et les appels externes. Les limites y sont plus larges qu'en synchrone. Le bon choix dépend du volume et du besoin d'enchaîner ou de suivre les tâches.

Lightning Web Components (LWC)

Le framework d'interface actuel de Salesforce, basé sur les standards Web Components. Les composants lisent les données par @wire, Lightning Data Service ou des appels Apex. Aura et Visualforce, plus anciens, restent à maintenir dans beaucoup d'organisations.

Flow

L'outil déclaratif d'automatisation : Flows déclenchés à l'enregistrement, Flows d'écran, Flows planifiés. Il a remplacé les règles de workflow et Process Builder. Le développeur l'utilise lui-même et l'appelle depuis Apex ou l'inverse, avec des méthodes invocables.

Modèle de partage et sécurité

Paramètres de partage par défaut, rôles, règles de partage, profils et permission sets. En Apex, with sharing et le mode utilisateur font respecter ces droits. C'est la source la plus fréquente de fuites de données entre équipes commerciales.

Intégrations

Appels REST ou SOAP vers d'autres systèmes avec des Named Credentials, services REST exposés en Apex, Platform Events et Change Data Capture pour prévenir les autres applications. Sur Service Cloud, les intégrations avec la téléphonie et les outils de ticketing sont courantes.

Salesforce CLI, DX et outils de déploiement

La CLI sf, les projets Salesforce DX dans Git, les sandboxes et les scratch orgs, avec DevOps Center, Copado ou Gearset pour livrer. Un développeur qui ne connaît que les change sets n'a pas l'habitude du travail en équipe sur une même organisation.

Le développeur Salesforce Apex / LWC travaille sur une organisation Sales Cloud ou Service Cloud, souvent avec des administrateurs et des consultants fonctionnels qui configurent le reste. Une bonne part des offres est en freelance ou en ESN, sur de la TMA ou des évolutions d'une organisation déjà riche en code et en automatisations. Les offres citent Apex, LWC, SOQL, Flow, parfois Aura et Visualforce, des outils de déploiement comme Copado ou SFDX, et parfois Data Cloud ou Agentforce en complément. Les certifications Platform Developer (ex-Platform Developer I) et Platform Developer II attestent les bases. Précisez dans l'offre le cloud concerné, l'état de l'organisation (récente ou chargée d'historique) et l'outil de déploiement utilisé.

Les compétences Apex et LWC à contrôler

• Apex et limites gouverneur
• Triggers, Flow et ordre d'exécution
• SOQL et gros volumes
• Lightning Web Components
• Sécurité et modèle de partage
• Tests, intégrations et déploiement

Cinq questions sur Apex, LWC et le partage des données

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.

1. Question 1 · junior à confirmé

   Un trigger sur Opportunity met à jour le compte associé. Il marche quand on saisit une opportunité à la main, mais l'import de 5 000 opportunités échoue sur « Too many SOQL queries: 101 ». Qu'est-ce qui ne va pas, et comment le réécrivez-vous ?

   Une bonne réponseUne requête SOQL, et sans doute un update, placés dans la boucle sur Trigger.new. Le trigger reçoit jusqu'à 200 enregistrements à la fois. Il collecte les AccountId dans un Set, fait une seule requête avec IN, range le résultat dans une Map, modifie les comptes en mémoire et fait un seul update à la fin. Il vérifie aussi ce que les autres triggers et Flows de la même transaction consomment.

   Signal d'alerte« On passe en batch » sans corriger la boucle, « on demande à Salesforce d'augmenter la limite », ou un try/catch autour de l'erreur.

2. Question 2 · confirmé

   Sur l'objet Case, il y a déjà deux Flows déclenchés à l'enregistrement et un trigger. Le métier demande une nouvelle règle. Comment choisissez-vous entre Flow et Apex, et comment évitez-vous les conflits ?

   Une bonne réponseUn Flow avant enregistrement pour mettre à jour des champs du même enregistrement, simple et rapide. De l'Apex quand la logique demande des collections, de gros volumes, des appels externes ou des tests précis. Il connaît l'ordre d'exécution : Flows avant enregistrement, triggers before, règles de validation, triggers after, puis Flows après enregistrement. Il garde un seul trigger par objet et fixe l'ordre des Flows entre eux.

   Signal d'alerte« Toujours du code » ou « toujours du Flow », sans critère. Aucune idée de l'ordre dans lequel les automatisations s'exécutent.

3. Question 3 · confirmé

   Une classe Apex appelée par un LWC renvoie une liste de comptes. Un commercial y voit des comptes d'une autre région. D'où peut venir le problème ?

   Une bonne réponseApex tourne par défaut en mode système. Il cherche une classe déclarée without sharing, ou une classe appelée par une autre qui l'est, et passe la classe en with sharing. Il précise que with sharing ne filtre que les enregistrements : les droits sur les objets et les champs se contrôlent avec WITH USER_MODE dans la requête ou Security.stripInaccessible. Il vérifie aussi les paramètres de partage par défaut et les règles de partage du compte.

   Signal d'alerteFiltrer la liste dans le composant JavaScript, ou ajouter une condition sur la région en dur dans la requête.

4. Question 4 · confirmé

   Un LWC affiche les contacts d'un compte avec @wire. Après la création d'un contact depuis ce même composant, la liste ne se met pas à jour. Pourquoi, et que faites-vous ?

   Une bonne réponseLa méthode Apex appelée par @wire est cacheable=true, son résultat est mis en cache côté client et rien ne lui dit de se relire. Il garde la valeur fournie par le wire et appelle refreshApex dessus après la création. Si la création passe par Lightning Data Service (createRecord), il peut aussi notifier les changements avec notifyRecordUpdateAvailable ou utiliser un adaptateur de liste associée qui se met à jour seul.

   Signal d'alerteRecharger la page, ou retirer cacheable partout « pour ne plus avoir de cache ».

5. Question 5 · senior

   Une requête SOQL sur 3 millions de cas met plus de deux minutes ou tombe en timeout. Que vérifiez-vous ?

   Une bonne réponseLa sélectivité des filtres : champs indexés (Id, Name, OwnerId, CreatedDate, SystemModstamp, relations, identifiants externes), pas de LIKE commençant par %, pas de != ni de recherche sur null, pas de champ formule dans le WHERE. Il passe la requête dans le Query Plan de la Developer Console, envisage un index personnalisé demandé au support, l'archivage des vieux cas et repère un éventuel data skew.

   Signal d'alerteAjouter un LIMIT sans toucher au filtre, ou « augmenter le timeout ».

Ce que les recruteurs demandent sur le développeur Salesforce

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.