Questions d'entretien architecte technique Salesforce, de type board CTA

L'architecte technique Salesforce répond des parties de l'org qui cèdent en premier quand l'usage grandit : les tables de plusieurs dizaines de millions de lignes, les quotas d'API, les flux d'événements, les droits des intégrations et la chaîne de livraison. Les meilleurs candidats savent dire à partir de quel volume leur solution ne tient plus.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus6 min de lecture

La fiche Architecte technique Salesforce (parcours CTA) : technologies, chaîne du poste, une question et la grille d'évaluation

Sur une org de quelques milliers d'utilisateurs, raccordée à un ERP, un site e-commerce et un entrepôt de données, les incidents sérieux viennent rarement d'un écran mal configuré. Ce sont des rapports qui tombent en timeout sur 30 millions de cas, un quota d'API vide à midi, un abonné qui a perdu trois jours d'événements, un déploiement bloqué par cinq équipes sur les mêmes objets. L'architecte technique est celui qu'on appelle pour ces sujets, et celui qui doit les prévoir.

Le parcours de Certified Technical Architect (CTA) sert de repère. Il exige les designations System Architect et Application Architect, puis une évaluation et un passage devant un jury de CTA, sur un scénario à résoudre et à défendre. Peu de candidats en France le détiennent. Beaucoup le préparent. Un entretien utile reprend les domaines évalués par le jury : données volumineuses, intégration, identité et sécurité, cycle de développement.

Un tech lead Apex solide n'est pas encore architecte technique. Les réponses attendues portent des chiffres : volumes réels, nombre d'appels d'API par jour, durée des déploiements, nombre d'équipes sur l'org. Le PDF comporte 30 questions, un cas de 20 minutes et une grille de 1 à 4.

Le périmètre technique d'un architecte Salesforce

Large data volumes

Au-delà de plusieurs millions d'enregistrements par objet, les requêtes non sélectives, les rapports et les recalculs de partage ralentissent. Les réponses passent par les index personnalisés, les skinny tables demandées au support, l'archivage et la conception du modèle. Le candidat doit pouvoir citer le plus gros objet qu'il a traité, et comment.

Limites de la plateforme

Salesforce est mutualisé : chaque transaction a des limites (requêtes, temps CPU), et l'org a des quotas sur 24 heures (appels d'API, événements livrés, traitements asynchrones). L'architecte technique sait lesquelles son architecture consomme, où les lire et ce qui se passe quand l'une d'elles est atteinte.

API REST, SOAP, Bulk et Composite

L'API REST pour les échanges unitaires, Composite et sObject Collections pour regrouper plusieurs opérations en un appel, Bulk API 2.0 pour charger ou extraire des millions de lignes en asynchrone. Le choix change la consommation de quota et le comportement en cas d'erreur partielle.

Platform Events, Change Data Capture et Pub/Sub API

Les événements de plateforme portent des messages métier, la capture des changements publie les modifications d'enregistrements. Les abonnés externes les lisent par la Pub/Sub API (gRPC) et reprennent après une coupure grâce à l'identifiant de rejeu (replay ID), dans la limite de la durée de conservation des événements, de l'ordre de trois jours.

MuleSoft

Le middleware de Salesforce, avec un connecteur Salesforce qui gère les API REST, Bulk et l'abonnement aux événements. L'architecte technique Salesforce ne conçoit pas toute la plateforme MuleSoft, mais il fixe ce que le middleware doit garantir côté Salesforce : quotas, rejeu, unicité, utilisateur d'intégration.

Identité et OAuth

SSO SAML ou OpenID Connect pour les utilisateurs, flux OAuth pour les intégrations (JWT bearer, client credentials, web server avec PKCE). Les applications connectées et les External Client Apps portent ces accès. Named Credentials et External Credentials gèrent les secrets des appels sortants.

Shield et surveillance

Platform Encryption chiffre des champs et des fichiers au repos, avec des effets sur la recherche et les filtres selon le schéma choisi. Event Monitoring trace connexions, exports, consultations et appels d'API. Les politiques de sécurité des transactions (Transaction Security) bloquent ou signalent un comportement en temps réel.

DevOps Center et suivi des sources

DevOps Center, l'outil gratuit de Salesforce, relie des éléments de travail, un dépôt Git et un pipeline d'environnements. Il s'appuie sur le suivi des sources (source tracking), à activer pour les sandboxes Developer et Developer Pro, qui détecte les modifications faites dans l'org. La Salesforce CLI, les unlocked packages et les outils tiers complètent la chaîne.

Parcours CTA

Le Certified Technical Architect se prépare après les designations System Architect et Application Architect. La dernière étape est un jury : un scénario à résoudre, une présentation de la solution, puis des questions qui testent chaque choix. Un candidat en préparation a souvent travaillé sur des scénarios d'entraînement et peut en parler.

Le titre recouvre deux réalités. Chez un client final, l'architecte technique tient une org importante dans la durée, avec plusieurs équipes et intégrateurs, et arbitre tout ce qui touche aux performances, aux intégrations et au déploiement. En prestation, il intervient sur les gros projets, les audits techniques et les reprises d'orgs en difficulté, souvent avec un rôle de référent auprès des tech leads. Les annonces demandent dix ans d'expérience Salesforce ou plus, une pratique de MuleSoft ou d'un autre middleware, de Git et d'un outil de livraison (DevOps Center, Copado, Gearset). Le CTA y figure rarement comme condition et souvent comme un plus. Un candidat qui le prépare et a passé une partie des certifications de domaine se reconnaît à la précision de ses arbitrages.

Ce qu'un architecte technique Salesforce doit avoir déjà traité

  • Gros volumes de données
  • Limites de la plateforme et performance
  • Intégration : API, événements, MuleSoft
  • Identité et sécurité
  • DevOps et cycle de développement
  • Présentation et défense d'une architecture

Questions de type board pour un architecte technique 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.

  1. Question 1 · senior

    L'objet Task compte 80 millions d'activités. Les rapports des managers, filtrés sur le type d'activité et un champ « Canal », tombent en timeout. Que faites-vous ?

    Une bonne réponseIl mesure d'abord : Query Plan de la Developer Console sur les filtres du rapport, part des lignes renvoyées par chaque filtre. Un type d'activité très répandu n'est pas sélectif, un filtre négatif ou un joker en tête non plus. Il ajoute un filtre de date et de propriétaire par défaut, demande un index personnalisé sur le champ « Canal » si sa distribution s'y prête, et une skinny table au support pour les rapports fréquents. Il connaît l'archivage automatique des anciennes activités par Salesforce et son effet sur les rapports. Sur le fond, il fixe une durée de conservation et sort l'historique (big objects ou stockage externe). Il compare les temps avant et après.

    Signal d'alerte« On augmente les ressources » comme sur une base dédiée, ou demander aux managers d'exporter vers Excel.

  2. Question 2 · confirmé à senior

    À midi, les intégrations ont consommé 80 % du quota quotidien d'appels d'API de l'org. Comment trouvez-vous le responsable, et que changez-vous ?

    Une bonne réponseLa ressource REST /limits ou l'écran de la configuration pour l'état du quota, puis Event Monitoring (API Total Usage) ou les journaux du middleware pour répartir les appels par application connectée et par utilisateur. Les corrections typiques : remplacer une interrogation toutes les minutes par la capture des changements, regrouper les écritures avec Composite ou sObject Collections, passer les chargements massifs sur Bulk API 2.0, mettre en cache les données de référence côté middleware. Il pose une alerte de seuil et un quota par intégration.

    Signal d'alerteAcheter du quota supplémentaire sans chercher, ou couper l'intégration la plus récente au hasard.

  3. Question 3 · senior

    Un système abonné aux événements de capture des changements des commandes est resté hors ligne quatre jours. Que récupère-t-il au redémarrage, et comment l'aviez-vous prévu ?

    Une bonne réponseIl sait que les événements ne sont conservés que trois jours environ (72 heures) dans le bus d'événements : au-delà, le rejeu depuis le dernier replay ID ne retrouve pas tout. L'abonné doit stocker son dernier replay ID, détecter qu'il est trop ancien et lancer une resynchronisation complète (extraction par Bulk API des commandes modifiées depuis la coupure) avant de reprendre le flux. La conception prévoit cette reprise dès le départ, avec une supervision de l'abonné qui alerte bien avant trois jours.

    Signal d'alerte« Les événements sont gardés tant qu'ils ne sont pas lus », ou aucune stratégie de reprise.

  4. Question 4 · senior

    Un commercial sur le départ exporte 50 000 contacts. Comment l'auriez-vous détecté ou empêché ?

    Une bonne réponseDes droits d'export limités par permission (rapports, Data Loader, API), puis Event Monitoring pour tracer les exports de rapports et les requêtes d'API. En temps réel, une politique Transaction Security qui bloque ou demande une vérification au-delà d'un nombre de lignes exportées, ou alerte la sécurité. Il distingue ce que donne la licence standard et ce qui demande Shield ou l'add-on Event Monitoring, et pense aux exports par des applications connectées.

    Signal d'alerte« On regarde l'historique de connexion », qui ne montre pas l'export, ou interdire tous les rapports.

  5. Question 5 · senior

    Une org de douze ans, cinq équipes, tout le code et la configuration dans un seul bloc de métadonnées. Comment la découpez-vous pour que chaque équipe livre sans bloquer les autres ?

    Une bonne réponseUn découpage par domaine en unlocked packages, avec un socle commun (objets partagés, utilitaires, cadre de triggers) dont dépendent les packages métier, sans dépendance circulaire. Il commence par un domaine peu couplé, extrait le code mort, et accepte qu'une partie (profils, réglages de l'org, partage) reste gérée hors packages. Chaque équipe a son dépôt ou son répertoire, ses tests et son rythme, et un environnement d'intégration commun vérifie l'assemblage. Il compare avec l'option plus simple d'un seul dépôt et de DevOps Center si les équipes sont surtout déclaratives.

    Signal d'alerteTout mettre dans un seul package, ou découper en vingt packages sans gérer les dépendances.

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

Architecte technique Salesforce et parcours CTA, questions fréquentes

Le CTA est-il indispensable pour un poste d'architecte technique Salesforce ?

Rarement. Le Certified Technical Architect est détenu par peu de personnes, et en faire une condition vide le vivier. Les designations System Architect et Application Architect, ou une partie des certifications de domaine, montrent déjà une base large. Un candidat qui prépare le jury est souvent un bon signe, car il s'entraîne à justifier ses choix. L'entretien vérifie quand même les volumes et les intégrations réellement tenus.

Tech lead Salesforce et architecte technique : où passe la frontière ?

Le tech lead encadre une équipe de développement, relit le code, tranche les choix d'implémentation d'un projet. L'architecte technique porte les choix qui dépassent un projet : stratégie de données volumineuses, consommation des quotas de l'org, sécurité des intégrations, découpage en packages, règles de livraison communes à plusieurs équipes. Les offres mélangent souvent les deux intitulés. La différence se voit au nombre de projets ou d'équipes sur lesquels ses décisions s'appliquaient.

Quel test technique pour un architecte technique Salesforce ?

Un scénario court dans l'esprit du jury CTA : une org avec des volumes chiffrés, deux intégrations, une contrainte de sécurité et plusieurs équipes. Le candidat prépare 30 à 45 minutes, présente un schéma, puis répond aux objections du jury. Un incident à diagnostiquer complète le cas, comme un quota d'API épuisé ou un rapport en timeout. Les relances comptent plus que la présentation.

Un architecte technique Salesforce doit-il connaître MuleSoft ?

Il doit savoir ce qu'un middleware doit garantir face à Salesforce : quotas, rejeu des événements, unicité des écritures, utilisateur d'intégration et droits. Une pratique de MuleSoft est un atout, souvent demandé dans les offres, mais l'expérience d'un autre middleware se transpose. Pour concevoir la plateforme MuleSoft elle-même (topologie, gouvernance des API), c'est un autre poste, celui d'architecte MuleSoft.

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.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint