La plupart des missions d'architecte Salesforce couvrent plusieurs clouds à la fois. Les annonces citent Sales Cloud, Service Cloud, Experience Cloud, Marketing Cloud et Data Cloud, avec une intégration vers l'ERP et souvent MuleSoft. L'architecte définit la cible, anime le comité d'architecture, fixe les standards de développement et tranche entre configuration, code et application de l'AppExchange. En prestation, il intervient aussi en avant-vente et en audit d'orgs existantes.
Beaucoup de candidats sont d'anciens développeurs ou tech leads. Ils connaissent bien la plateforme et parlent volontiers d'Apex et de limites. L'architecte solution doit montrer autre chose : savoir dire pourquoi deux filiales partagent une org ou non, ce que coûte l'activation des comptes personnels, quel pattern d'intégration convient à une commande et lequel convient au catalogue produits. Un bon profil parle de licences, de propriété des données et d'exploitation, et pas seulement de la solution technique.
Le récit d'une décision d'architecture défendue devant une direction, et le regard que le candidat porte sur elle aujourd'hui, en disent beaucoup. Les certifications Application Architect et System Architect structurent le parcours, sans dire si la personne a tenu une cible sur plusieurs années. Le PDF ajoute 30 questions sur six axes et une étude de cas.
Les briques Salesforce que l'architecte assemble
Sales Cloud et Service Cloud
Le cœur CRM, sur la même plateforme et la même base : comptes, contacts, opportunités, cas. Quand les deux sont dans une seule org, commerciaux et service client partagent la vue client. L'architecte décide ce qui est commun (comptes, produits) et ce qui reste propre à chaque équipe.
Experience Cloud
Les portails clients et partenaires, sur la même org. Le choix de licence change le modèle de partage : les licences Customer Community passent par des sharing sets, les licences Customer Community Plus et Partner acceptent les rôles et les règles de partage. Une erreur de licence se paie au moment où le volume d'utilisateurs externes monte.
Marketing Cloud
Marketing Cloud Engagement est une plateforme séparée du CRM, avec ses propres données (data extensions), reliée par Marketing Cloud Connect. Salesforce propose aussi des éditions marketing construites sur la plateforme principale et Data 360. L'architecte doit savoir laquelle le client possède avant de dessiner les flux.
Data 360 (ex-Data Cloud)
La plateforme de données clients de Salesforce, rebaptisée Data 360. Elle rassemble des données venues de plusieurs orgs et systèmes, rapproche les profils et les rend utilisables dans le CRM, le marketing ou Agentforce. Elle se facture à la consommation de crédits, ce qui pèse sur les choix d'architecture.
Plateforme : objets, Flow, Apex
La même base technique pour tous les clouds du CRM. L'architecte fixe la frontière entre configuration et code, les conventions de nommage, le nombre de Flows par objet et les règles d'écriture de l'Apex. Ces standards évitent qu'une org partagée par plusieurs équipes devienne impossible à faire évoluer.
Salesforce Connect et objets externes
Affiche dans Salesforce des données qui restent dans un autre système (via OData ou un adaptateur entre orgs Salesforce) sans les copier. Utile pour consulter des factures ou des commandes de l'ERP. Le candidat doit connaître les limites : pas de toutes les fonctions d'un objet standard, et une dépendance au temps de réponse du système source.
MuleSoft et middleware
Salesforce possède MuleSoft, souvent cité dans les offres. D'autres clients passent par Boomi, SAP Integration Suite ou un ETL. L'architecte Salesforce n'a pas à concevoir le middleware, mais il choisit quels flux y passent, avec quel pattern, et qui porte les données de référence.
Identité et SSO
SAML ou OpenID Connect avec le fournisseur d'identité de l'entreprise (Entra ID, Okta, Ping) pour les salariés, une identité client pour les portails. Les intégrations utilisent OAuth avec des applications connectées ou externes. L'architecte décide où vivent les identités et qui crée les comptes.
Hyperforce et localisation
L'infrastructure Salesforce sur des clouds publics, qui permet de choisir la région d'hébergement de l'org. Pour un client européen, la question de la localisation des données et du Hyperforce EU Operating Zone revient souvent dans les appels d'offres. Le candidat doit savoir ce qu'elle couvre, et ce qu'elle ne couvre pas.
Les postes d'architecte Salesforce se partagent entre deux situations. Chez un client final, l'architecte tient la cible de l'org, préside le comité d'architecture et dit non aux demandes qui dégradent la plateforme. En prestation, il conçoit des solutions pour plusieurs clients, répond aux appels d'offres, audite des orgs existantes et encadre les tech leads. Les offres lisent souvent architecte solution, architecte technique ou tech lead pour des rôles voisins. L'architecte solution porte le choix des produits, le modèle de données et les flux, l'architecte technique descend dans les volumes, les limites et le DevOps. Les certifications d'architecte Salesforce (designations Application Architect et System Architect, obtenues en cumulant plusieurs certifications de la plateforme et d'architecte) et le Certified Technical Architect sont souvent cités comme un plus.
Les décisions qu'un architecte Salesforce doit savoir prendre
- Conception multi-clouds et choix des produits
- Stratégie d'org
- Modèle de données et données de référence
- Patterns d'intégration
- Partage, sécurité et identité
- Gouvernance et standards de l'org
Cinq questions d'entretien et les choix attendus
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 · senior
Un groupe veut Sales Cloud pour ses commerciaux, Service Cloud pour son support, un portail pour ses distributeurs et des campagnes e-mail. Comment répartissez-vous ces besoins entre les produits Salesforce ?
Une bonne réponseSales Cloud et Service Cloud dans la même org, avec un modèle de compte commun. Le portail distributeurs sur Experience Cloud, avec des licences Partner si les distributeurs gèrent des opportunités, ce qui donne accès aux rôles et aux règles de partage. Pour l'e-mail, il demande ce que le client possède déjà : Marketing Cloud Engagement est une plateforme séparée, reliée par Marketing Cloud Connect, avec ses propres données et sa synchronisation à concevoir. Il évoque Data 360 seulement si plusieurs sources de données clients doivent être rapprochées. Il chiffre l'impact licences de chaque choix et dit ce qu'il ne mettrait pas dans Salesforce.
Signal d'alerteTout activer parce que « c'est la même plateforme », sans parler de licences, de modèle de partage du portail ni de la séparation de Marketing Cloud.
Question 2 · senior
Trois filiales vendent dans des pays différents, avec des processus commerciaux proches mais pas identiques. Une seule org ou une org par filiale ?
Une bonne réponseIl part des critères : besoin d'une vue client commune, ventes croisées, degré de différence entre les processus, contraintes réglementaires ou de localisation des données, autonomie souhaitée des filiales et rythme de leurs évolutions, limites et volumes d'une org unique. Une seule org donne la vue client commune et une seule base à maintenir, au prix d'une gouvernance plus lourde (types d'enregistrements, standards, comité commun). Plusieurs orgs donnent de l'autonomie, mais imposent des intégrations entre orgs, des données de référence dupliquées et plus de coûts d'exploitation. Il dit comment il trancherait ici et ce qui le ferait changer d'avis.
Signal d'alerteUne réponse de principe (« toujours une seule org ») sans critère, ou une org par filiale sans parler du coût des échanges entre orgs.
Question 3 · confirmé à senior
Le client vend à des entreprises et à des particuliers. Activez-vous les comptes personnels (person accounts) ?
Une bonne réponseIl sait que l'activation est définitive et touche tout le modèle (un compte personnel est un compte et un contact à la fois), les rapports, les intégrations, les applications de l'AppExchange et Marketing Cloud. Il compare avec l'alternative : un compte générique ou un compte foyer avec des contacts, et ses défauts. Il demande la part de clients particuliers, le besoin de relations entre un particulier et une entreprise (relations de contacts à plusieurs comptes), et les applications tierces prévues. Il teste dans un sandbox avant de demander l'activation en production.
Signal d'alerteLes activer « parce qu'il y a des particuliers », sans savoir que la décision ne se défait pas.
Question 4 · senior
Chaque commande gagnée dans Salesforce doit créer une commande dans l'ERP, et l'ERP renvoie le statut de livraison. Quels patterns d'intégration choisissez-vous ?
Une bonne réponseIl s'appuie sur les patterns documentés par Salesforce. Pour l'envoi de la commande, un fire and forget asynchrone (événement de plateforme ou capture des changements consommés par le middleware), car le commercial n'a pas à attendre l'ERP. Une demande-réponse synchrone seulement si le numéro de commande ERP doit s'afficher tout de suite. Pour le retour du statut, un appel entrant (remote call-in) de l'ERP ou du middleware vers les API Salesforce, en masse si les volumes sont forts. Il traite l'unicité (identifiant externe, rejeu sans doublon), les erreurs et la reprise, et dit quel système fait foi pour chaque donnée.
Signal d'alerteUn appel synchrone depuis un trigger pour tout, ou « MuleSoft s'en occupe » sans pattern ni gestion d'erreur.
Question 5 · senior
Vous prenez la direction du comité d'architecture d'une org où quatre intégrateurs livrent en parallèle. Que décidez-vous dans les premières semaines ?
Une bonne réponseDes standards écrits et courts : conventions de nommage, frontière configuration et code, un cadre pour les Flows et les triggers par objet, règles de sécurité de l'Apex, revue de code. Un passage obligé au comité pour ce qui touche le modèle de données partagé, le partage, les intégrations et les nouvelles applications de l'AppExchange, avec un dossier de décision court et tracé. Un état des lieux de la dette (automatisations en double, champs inutilisés, code sans test). Il s'appuie sur des références publiques comme Salesforce Well-Architected et mesure l'effet (incidents, délais de livraison, consommation des limites).
Signal d'alerteUn comité qui valide tout en fin de sprint, ou un document de 80 pages que personne ne lit.
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 Salesforce, les questions fréquentes
Architecte solution ou architecte technique Salesforce : quelle différence ?
L'architecte solution part du besoin : produits et licences, modèle de données, flux entre systèmes, gouvernance. L'architecte technique descend plus bas : volumes de données, limites de la plateforme, performances, sécurité des intégrations, chaîne de déploiement. Dans beaucoup d'entreprises, une seule personne tient les deux rôles. L'offre gagne à dire lequel pèse le plus, car un ancien tech lead brillant sur l'Apex n'a pas forcément l'expérience du choix des produits face à une direction.
Quelles certifications attendre d'un architecte Salesforce ?
Les designations Salesforce Certified Application Architect et System Architect s'obtiennent en cumulant plusieurs certifications : App Builder et Developer de la plateforme, puis des certifications d'architecte par domaine (données, partage et visibilité, intégration, identité et accès, cycle de développement). Elles montrent une connaissance large de la plateforme. Le Certified Technical Architect, validé devant un jury, est rare. Les offres le citent comme un plus. Aucune certification ne remplace le récit d'une architecture tenue en production, avec ses erreurs et ses corrections.
Comment se déroule le test technique d'un architecte Salesforce ?
Un scénario d'une page est envoyé la veille, ou préparé en une heure sur place, puis présenté en 20 minutes avant les questions. Le scénario mélange plusieurs clouds, une intégration avec l'ERP et une contrainte de partage. La notation retient la clarté du schéma, la justification des choix et la réaction quand une hypothèse change. Un architecte de l'équipe, s'il y en a un, participe utilement.
Un architecte Dynamics 365 ou SAP peut-il passer sur Salesforce ?
Les réflexes d'intégration, de données de référence et de gouvernance se transposent. Le modèle de partage, les limites d'une plateforme mutualisée, les licences et l'écosystème de l'AppExchange demandent de la pratique. Pour un poste de cible et de comité d'architecture, un tel profil peut convenir s'il a déjà conduit un projet Salesforce, même comme architecte d'entreprise. Pour un rôle de référent technique, mieux vaut une expérience Salesforce directe.
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.
