Guide complet des produits Salesforce et des profils associés

Quand on découvre Salesforce, on tombe très vite sur une difficulté simple : tout le monde parle de Sales Cloud, Service Cloud, Marketing Cloud, Experience Cloud, Data Cloud, MuleSoft, CPQ, Platform, Flows, Profiles, Roles, Permission Sets, Architects, Consultants ou Admins… mais rarement au même endroit, et rarement avec une explication claire des différences.

Cet article a été pensé comme un recueil de référence pour celles et ceux qui veulent enfin comprendre les grands produits Salesforce, le vocabulaire métier de l’écosystème, et surtout les profils types qui travaillent sur chaque brique.

L’objectif n’est pas de lister des intitulés de poste sans contexte. L’objectif est d’expliquer, avec le vocabulaire Salesforce, qui fait quoi, sur quelle couche fonctionnelle ou technique, et comment distinguer les profils entre eux.

Comprendre l’écosystème Salesforce

Salesforce n’est pas un seul outil. C’est un écosystème de produits construits autour de la relation client, de la donnée, de l’automatisation et de l’intégration. Une partie importante de ces produits repose sur la Salesforce Platform, qui sert de socle commun pour la sécurité, le modèle de données, l’automatisation et le développement applicatif. Trailhead présente d’ailleurs des parcours de carrière distincts pour les rôles d’Admin, Developer, Architect, Consultant, Designer et Analyst, ce qui montre bien que l’écosystème se structure autant par familles de produits que par familles de rôles [web:32][web:39][web:42].

Dans la pratique, quand une entreprise dit qu’elle « fait du Salesforce », cela peut vouloir dire des choses très différentes : gérer un pipe commercial dans Sales Cloud, industrialiser un centre de support avec Service Cloud, orchestrer des campagnes omnicanales dans Marketing Cloud, exposer un portail partenaire dans Experience Cloud, connecter un SI avec MuleSoft, ou unifier les données clients dans Data Cloud [web:31][web:35][web:41].

Le vocabulaire de base à maîtriser

Avant de parler des profils, il faut clarifier un point essentiel : dans Salesforce, le mot profil peut désigner deux réalités différentes selon le contexte. D’un côté, un profil métier ou projet comme Administrateur, Consultant, Développeur ou Architecte. De l’autre, l’objet de sécurité Profile dans la plateforme, qui définit une base de permissions pour un utilisateur. C’est l’une des confusions les plus fréquentes chez les débutants [web:19][web:22].

Autre nuance importante : les Roles dans Salesforce ne servent pas à donner des permissions techniques, mais à organiser la visibilité hiérarchique sur les données. Les Profiles et les Permission Sets gèrent l’accès fonctionnel et technique, tandis que les Roles structurent surtout le partage des enregistrements dans la hiérarchie de l’org [web:19][web:22].

Enfin, il faut distinguer les Clouds ou produits des rôles. Sales Cloud ou Service Cloud sont des solutions. Admin, Developer, Consultant ou Architect sont des profils qui interviennent sur ces solutions avec des responsabilités différentes [web:30][web:31][web:33].

Les grandes familles de profils Salesforce

L’Administrateur Salesforce

L’Administrateur Salesforce est souvent le point d’entrée de l’écosystème. Trailhead le décrit comme le socle de l’org : il gère les utilisateurs, les données, la sécurité et l’automatisation pour garder la plateforme efficace, sécurisée et exploitable au quotidien [web:39][web:12].

Dans le vocabulaire Salesforce, l’Admin travaille beaucoup sur la configuration déclarative (clicks not code) : objets, champs, page layouts, record types, validation rules, reports, dashboards, Flow, permissions, sharing et quality of life des utilisateurs. Un bon Admin ne se contente pas de « paramétrer » ; il maintient la cohérence fonctionnelle de l’org et protège sa gouvernance [web:12][web:36].

C’est le profil le plus transversal, parce qu’il intervient aussi bien sur Sales Cloud que sur Service Cloud, Experience Cloud, parfois sur CPQ, et sur le cœur de la plateforme. En revanche, il n’est pas forcément spécialiste des patterns d’intégration complexes, du code Apex avancé ou des architectures multi-cloud à grande échelle [web:31][web:39].

Le Développeur Salesforce

Le Salesforce Developer intervient lorsque le standard et le déclaratif ne suffisent plus. Trailhead distingue clairement ce rôle comme un parcours à part entière dans l’écosystème, avec une spécialisation sur la logique applicative, les composants sur mesure et l’extension de la plateforme [web:32][web:4].

Dans les projets, le développeur travaille typiquement sur Apex, SOQL, Lightning Web Components (LWC), intégrations, tests, logique transactionnelle, custom UI, traitements asynchrones et optimisation technique. Là où l’Admin configure, le Developer industrialise ou construit ce que le standard ne couvre pas proprement [web:4][web:31].

La différence entre un bon Admin avancé et un Developer ne tient donc pas seulement au code. Elle tient à la responsabilité sur la qualité technique, la maintenabilité, la performance et la capacité à concevoir des solutions custom robustes [web:4][web:24].

Le Consultant Salesforce

Le Consultant est le profil de traduction entre besoin métier et solution Salesforce. Trailhead le présente comme un rôle spécialisé par domaine, notamment sur Service Cloud, Sales Cloud ou Experience Cloud, avec une forte responsabilité de cadrage, design fonctionnel et conduite de la solution [web:30][web:17].

Un Consultant ne se limite pas à faire des ateliers. Il modélise les processus cibles, challenge le besoin, arbitre entre standard et custom, prépare les backlog items, rédige parfois les user stories, et s’assure que la solution reste soutenable dans le temps. Il raisonne en termes de business requirements, solution design, adoption, process alignment et scalability [web:30][web:37].

La grande différence entre Consultant et Admin, c’est que le Consultant est plus orienté design fonctionnel et transformation métier, alors que l’Admin est plus orienté opérations de plateforme et exécution dans l’org. Dans les petites structures, une même personne peut faire les deux. Dans les organisations plus matures, les rôles se séparent clairement [web:30][web:39].

L’Architecte Salesforce

L’Architecte Salesforce intervient sur les sujets de structure, de gouvernance et de passage à l’échelle. Trailhead distingue les architectes autour de dimensions comme la donnée, l’intégration ou l’architecture solution globale, avec une attente forte sur le design de solutions robustes, scalables et performantes [web:24][web:33][web:42].

Dans le quotidien projet, l’Architecte arbitre le modèle de données, les patterns d’intégration, la stratégie de sécurité, la répartition entre clouds, les limites de plateforme, la dette technique et les choix de design qui auront des conséquences à moyen terme. Il ne fait pas seulement « de la technique » ; il protège la cohérence d’ensemble [web:24][web:31].

La différence entre un Architecte et un Developer senior est importante : le Developer construit des composants, l’Architecte conçoit des fondations. Le premier est responsable de l’implémentation de qualité ; le second est responsable de la qualité des choix structurants [web:24][web:42].

L’Analyste, le Designer et les profils hybrides

Salesforce formalise aussi des parcours pour les Analysts et les Designers, preuve que l’écosystème ne se limite pas au trio Admin / Dev / Consultant. L’Analyste aide à structurer le besoin, la donnée et les usages ; le Designer se concentre davantage sur l’expérience utilisateur et la qualité des parcours [web:32].

Dans la réalité des projets, on rencontre aussi beaucoup de profils hybrides : Admin/Consultant, Consultant/Architect, Technical Architect/Developer Lead, Marketing Cloud Consultant/Developer, ou encore Revenue Ops Admin spécialisé sur Sales Cloud. Salesforce est un écosystème où les frontières existent, mais où les combinaisons sont fréquentes [web:32][web:36].

Salesforce Platform : le socle commun

La Salesforce Platform est la couche fondamentale sur laquelle reposent une grande partie des solutions de l’écosystème. Elle fournit le modèle d’objets, les mécanismes de sécurité, l’automatisation, la logique applicative, l’interface Lightning et les briques de personnalisation qui permettent de transformer le CRM en véritable plateforme métier [web:31][web:36].

Profils types sur la Platform

Sur la Platform, on retrouve surtout quatre profils majeurs :

Administrateur Salesforce : gère users, security model, automation déclarative, data quality, reports, dashboards, objets et configuration.
Développeur Salesforce : construit Apex, LWC, intégrations custom, logique métier spécifique et composants réutilisables.
Consultant fonctionnel : traduit les processus métier en modèle cible exploitable dans l’org.
Architecte Platform / Solution Architect : définit les fondations du modèle de données, de la sécurité et de l’extensibilité [web:31][web:33][web:39].

Différences clés entre profils sur la Platform

Sur la Platform, l’Admin cherche la meilleure solution en standard et en déclaratif. Le Developer intervient quand il faut sortir du standard sans compromettre la qualité technique. Le Consultant s’assure que la solution répond réellement au process métier. L’Architecte garantit que l’ensemble reste viable à long terme [web:31][web:39][web:42].

Autrement dit : Admin = exploitation et configuration, Developer = extension technique, Consultant = design fonctionnel, Architect = cohérence structurelle [web:30][web:31][web:33].

Sales Cloud : le CRM commercial

Sales Cloud est le produit historique de Salesforce pour les équipes commerciales. Il est centré sur l’acquisition de comptes, la gestion des leads, le suivi des opportunités, le pipeline et le forecasting. Des sources spécialisées rappellent que Sales Cloud est avant tout pensé pour les commerciaux et les managers commerciaux, avec un focus sur la conversion et la performance de vente [web:35].

Les principales features Sales Cloud

Dans le vocabulaire Salesforce, Sales Cloud couvre notamment : Leads, Accounts, Contacts, Opportunities, Activities, Forecasting, Quotes de base, Reports, Dashboards, parfois Territory Management et différents mécanismes de productivité commerciale [web:35].

Profils types sur Sales Cloud

Salesforce Admin orienté Sales : gère la configuration du pipe, les page layouts, les validation rules, les flows, la qualité de donnée et les dashboards de pilotage.
Sales Cloud Consultant : modélise le cycle de vente, la qualification, les étapes d’opportunité, le forecast et l’adoption par les équipes business.
Salesforce Developer : intervient pour des logiques de scoring custom, UX spécifiques, intégrations ERP ou devis, ou règles métier complexes.
Solution Architect : arbitre les choix structurants quand Sales Cloud s’intègre avec CPQ, Service, Experience ou un SI plus large [web:30][web:35][web:36].

Différences entre profils sur Sales Cloud

Le Consultant Sales Cloud parle d’abord process de vente, pipeline hygiene, forecast accuracy et adoption des sales. L’Admin s’occupe ensuite d’implémenter proprement le design dans l’org. Le Developer intervient surtout quand le besoin commercial suppose des extensions non couvertes par le standard. L’Architecte arrive dès que l’on touche aux dépendances transverses, à la gouvernance des données ou à la complexité inter-systèmes [web:30][web:35].

Service Cloud : la relation client et le support

Service Cloud est orienté support, relation client et efficacité des agents. Il se distingue de Sales Cloud par un focus très net sur le Case Management, les canaux de service, les SLA, l’expérience client et la productivité des équipes support [web:35].

Les principales features Service Cloud

Le cœur fonctionnel de Service Cloud comprend généralement Cases, Queues, Omni-Channel, Knowledge, Entitlements, Milestones, outils de service console, self-service et mécanismes de routage ou de traitement des interactions [web:35].

Profils types sur Service Cloud

Service Cloud Consultant : définit les process de support, la structure des cases, les files de traitement, les SLA, la base de connaissance et les parcours agents.
Salesforce Admin orienté Service : configure les objets, files, flows, permissions, console et reporting opérationnel.
Developer Salesforce : construit les automatisations avancées, composants spécifiques agent, intégrations CTI ou logique complexe autour des interactions.
Architecte Solution / Integration : intervient pour les architectures de service omnicanal, les dépendances avec d’autres systèmes et la gouvernance de bout en bout [web:30][web:35].

Différences entre Sales Cloud et Service Cloud

Les deux produits partagent le socle Salesforce Platform et des objets communs comme Accounts et Contacts, mais leur finalité diverge. Sales Cloud est centré sur la conquête et la gestion commerciale ; Service Cloud est centré sur la résolution des demandes, l’efficacité agent et le respect des engagements de service [web:35].

Cette différence fonctionnelle explique pourquoi les profils spécialisés ne travaillent pas exactement avec la même logique. Un Consultant Sales Cloud raisonne en pipeline et conversion ; un Consultant Service Cloud raisonne en cases, SLA, routing, knowledge et customer experience [web:30][web:35].

Marketing Cloud : l’orchestration marketing omnicanale

Marketing Cloud Engagement est la brique Salesforce dédiée à l’exécution marketing omnicanale. Trailhead décrit le Consultant Marketing Cloud Engagement comme un profil capable de concevoir des solutions de campagne multi-canal, en lien avec les parties prenantes et avec une compréhension large des applications Salesforce [web:37].

Les principales features Marketing Cloud

Dans le vocabulaire de Marketing Cloud Engagement, on retrouve notamment Business Units, Email Studio, Journey Builder, Automation Studio, Contact Builder, segmentation, orchestration de campagnes, activation multi-canal et gouvernance des environnements marketing [web:37][web:16].

Profils types sur Marketing Cloud

Marketing Cloud Administrator : gère l’instance, les accès, l’organisation des Business Units, certains paramétrages d’environnement et la stabilité opérationnelle.
Marketing Cloud Engagement Consultant : conçoit les parcours marketing, structure les cas d’usage, le modèle de campagne et la gouvernance marketing.
Marketing Cloud Developer : travaille sur les développements spécifiques, les intégrations, parfois AMPscript, SSJS, API et composants techniques propres à l’environnement.
Email Specialist / Campaign Specialist : profil plus orienté production de campagnes, qualité d’exécution et performance opérationnelle [web:8][web:37].

Différences de profils dans Marketing Cloud

Marketing Cloud a une particularité forte : les frontières entre fonctionnel, opérationnel et technique y sont souvent plus marquées que sur le core Salesforce. Le Consultant y porte la vision de l’orchestration, l’Administrator garantit le cadre d’exploitation, le Developer gère les customisations et l’intégration, tandis que l’Email Specialist ou Campaign Operator exécute une partie importante du run marketing [web:8][web:37].

Il faut aussi distinguer Marketing Cloud Engagement de Marketing Cloud Account Engagement. Le premier est historiquement orienté orchestration marketing multi-canal ; le second, anciennement Pardot, est plus centré sur le marketing B2B, le lead nurturing et l’alignement marketing/vente [web:34][web:40].

Account Engagement : le marketing B2B

Marketing Cloud Account Engagement est l’ancien Pardot. Trailhead présente le Consultant Account Engagement comme un profil expérimenté dans le design et l’implémentation de solutions adaptées aux exigences métier, et le Specialist comme un profil capable de concevoir, construire et mettre en œuvre des workflows marketing dans la plateforme [web:34].

Profils types sur Account Engagement

Account Engagement Specialist : configure les parcours de nurturing, scoring, formulaires, listes, automatisations B2B.
Account Engagement Consultant : structure le modèle de lead management, le cycle MQL/SQL, l’alignement sales/marketing et l’intégration métier.
Admin / Marketing Ops : exploite la plateforme au quotidien et contrôle les opérations.
Developer / Integration profile : intervient surtout sur les connexions, synchronisations et extensions spécifiques [web:34][web:40].

Différence avec Marketing Cloud Engagement

La différence n’est pas seulement technique ; elle est aussi organisationnelle. Account Engagement s’insère plus naturellement dans des équipes B2B marketing ops proches du CRM, alors que Marketing Cloud Engagement est souvent opéré dans une logique plus large d’orchestration de campagnes multi-canal et de marketing relationnel à plus grande échelle [web:34][web:37].

Experience Cloud : portails, extranets et expériences digitales

Experience Cloud sert à construire des portails clients, partenaires, fournisseurs ou communautés, en s’appuyant sur les données et la sécurité Salesforce. Trailhead identifie un rôle de Consultant Experience Cloud, ce qui reflète bien la part importante de design fonctionnel, d’expérience utilisateur et de gouvernance dans ces projets [web:17].

Les principales features Experience Cloud

On y retrouve la gestion de sites, d’expériences connectées au CRM, de parcours utilisateurs externes, de visibilité sécurisée sur les données et de collaboration élargie autour des enregistrements [web:17].

Profils types sur Experience Cloud

Experience Cloud Consultant : structure le portail, les cas d’usage, les audiences, les parcours et les règles de visibilité.
Salesforce Admin : configure objets, permissions, sharing, profils externes et exploitation courante.
Developer Salesforce : intervient sur des composants UI, interactions spécifiques et besoins de personnalisation avancée.
Architecte sécurité / solution : arbitre les modèles d’accès, les volumes, la gouvernance et les impacts sur le core org [web:17][web:24].

Ce qui rend Experience Cloud particulier

Sur Experience Cloud, la difficulté principale n’est pas seulement de « faire un portail ». La vraie complexité porte souvent sur la sécurité des données, le sharing model, la lisibilité des parcours et la maîtrise des profils externes. C’est pourquoi les Admins et Architectes y ont souvent un rôle plus critique que sur des périmètres plus simples [web:17][web:24].

Commerce Cloud : le commerce digital B2B et B2C

Commerce Cloud est la solution de commerce digital de Salesforce. Salesforce la présente comme une plateforme de bout en bout pour le commerce B2C et B2B, connectée aux autres départements orientés client, notamment sales, service et marketing, afin de décloisonner la donnée et personnaliser les expériences d’achat [web:41].

Profils types sur Commerce Cloud

Commerce Consultant : définit le parcours d’achat, les exigences métier, l’expérience cible et les interactions avec les autres canaux.
Commerce Developer : développe les composants, templates, intégrations, logiques de catalogue ou de checkout selon le périmètre.
Architecte e-commerce / Solution Architect : garantit la cohérence entre commerce, CRM, service, marketing et systèmes back-office.
Admin ou Ops e-commerce : intervient davantage sur l’exploitation et certaines configurations selon la stack choisie [web:38][web:41].

Différences avec Sales Cloud

Sales Cloud pilote la relation commerciale, les opportunités et la performance des équipes de vente. Commerce Cloud pilote l’expérience d’achat digitale et le parcours transactionnel. Les deux peuvent se compléter, mais ils ne répondent pas au même besoin métier [web:38][web:41].

MuleSoft : l’intégration et l’API-led connectivity

MuleSoft occupe une place particulière dans l’écosystème Salesforce, car il s’agit d’une brique d’intégration et d’automatisation orientée API. Trailhead rappelle que les certifications MuleSoft sont conçues pour des profils connaissant les fondations de l’intégration et de l’API-led connectivity, ce qui place clairement cette famille en dehors du simple paramétrage CRM [web:23].

Ce que couvre MuleSoft

MuleSoft sert à connecter Salesforce à d’autres systèmes, exposer ou consommer des API, orchestrer des flux de données, fiabiliser les échanges inter-applicatifs et structurer des patterns d’intégration plus durables qu’une simple synchronisation point à point [web:1][web:23].

Profils types sur MuleSoft

MuleSoft Developer : construit les flows d’intégration, les APIs, les mappings, les transformations et les traitements techniques.
Integration Architect / MuleSoft Architect : définit les patterns d’intégration, les couches API, la gouvernance et l’urbanisation des échanges.
Salesforce Architect / Technical Architect : intervient lorsque l’intégration impacte fortement le core Salesforce.
Consultant fonctionnel : peut contribuer au cadrage, mais n’est généralement pas le profil central sur la construction des intégrations [web:23][web:24].

Différence entre Developer Salesforce et MuleSoft Developer

Le Salesforce Developer construit à l’intérieur de la plateforme Salesforce. Le MuleSoft Developer construit les ponts entre Salesforce et le reste du SI. Les deux travaillent parfois ensemble, mais ils n’opèrent pas sur la même couche technique ni avec les mêmes contraintes de design [web:23][web:31].

Data Cloud : l’unification et l’activation de la donnée

Data Cloud répond au besoin d’unification, d’harmonisation et d’activation des données clients à grande échelle. Même si les contours projets varient fortement selon les entreprises, cette brique se situe à l’intersection du CRM, de la donnée, du marketing, de l’analytics et parfois de l’IA [web:41][web:24].

Profils types sur Data Cloud

Data Cloud Consultant : structure les cas d’usage, les sources, les règles d’unification et l’activation métier.
Data Architect / Solution Architect : conçoit les flux, la gouvernance, les identifiants, les modèles de rapprochement et l’architecture cible.
Marketing Ops / CRM Ops : exploite les segments, audiences et activations.
Developer / Integration Engineer : prend en charge certaines connexions ou automatisations nécessaires [web:24][web:37].

Ce qui distingue Data Cloud

Data Cloud attire des profils plus data que les clouds historiques. Les sujets y sont souvent moins centrés sur les écrans utilisateurs et davantage sur l’identité, la qualité de donnée, l’unification et l’activation cross-channel [web:24][web:41].

CPQ et Revenue : devis, pricing et complexité commerciale

Dans l’univers Salesforce, CPQ est associé à la gestion des devis, de la tarification, de la configuration produit et des logiques commerciales avancées. Même quand la brique évolue avec les offres Revenue, les problématiques restent proches : maîtriser les règles de configuration, les dépendances produit, le pricing et la cohérence entre vente et exécution [web:13][web:36].

Profils types sur CPQ

CPQ Consultant : structure les règles métier, les scénarios de configuration et les processus quote-to-cash.
CPQ Admin : maintient les règles, objets, produits et paramétrages opérationnels.
Developer Salesforce : intervient si des extensions ou intégrations spécifiques sont nécessaires.
Architecte Solution : arbitre les impacts de CPQ sur ERP, facturation, Sales Cloud et modèle de données [web:13][web:36].

Pourquoi CPQ demande des profils spécifiques

CPQ n’est pas seulement un add-on commercial. C’est souvent un domaine où la complexité métier est très forte, parce qu’il faut traduire des règles tarifaires, contractuelles et produits en logique exploitable. Les meilleurs profils CPQ sont généralement très bons à la fois sur le métier et sur la rigueur de configuration [web:13][web:36].

Les différences réelles entre les profils

Pour éviter les confusions, on peut résumer les différences de la façon suivante.

Admin vs Consultant

L’Admin met en œuvre, maintient, sécurise et améliore l’org au quotidien. Le Consultant cadre, conçoit et aligne la solution avec les besoins métier. L’un est davantage dans l’exploitation et la configuration ; l’autre dans le design fonctionnel et la transformation [web:30][web:39].

Admin vs Developer

L’Admin privilégie le standard, le déclaratif et la maintenabilité sans code. Le Developer intervient quand la solution nécessite du code, une logique applicative fine, des intégrations avancées ou une UI spécifique [web:4][web:39].

Developer vs Architect

Le Developer construit des composants robustes. L’Architect prend les décisions structurantes sur le modèle global, les patterns, la sécurité, la donnée et l’intégration. Le premier exécute une solution technique ; le second conçoit l’ossature de la solution [web:24][web:42].

Consultant vs Architect

Le Consultant raisonne d’abord en processus métier, adoption, ateliers, backlog et solution fonctionnelle. L’Architect raisonne en cohérence transverse, scalabilité, limites de plateforme, dépendances systèmes et gouvernance [web:30][web:24].

Les certifications comme repères, pas comme vérité absolue

Salesforce structure officiellement ses certifications par familles, notamment Administrator, Architect et MuleSoft, avec des spécialisations qui reflètent assez fidèlement les zones de compétence de l’écosystème [web:12][web:23][web:24].

Ces certifications sont utiles pour se repérer, pour recruter et pour structurer un parcours, mais elles ne suffisent pas à qualifier la valeur réelle d’un profil. Un Admin certifié sans compréhension métier aura du mal à tenir une org complexe ; un Consultant certifié sans rigueur de delivery créera beaucoup de dette ; un Developer très fort sans vision de gouvernance peut produire un système difficile à maintenir [web:24][web:36][web:39].

Quel profil pour quel besoin

Si votre besoin principal est de tenir proprement une org, de gérer les utilisateurs, la sécurité, les dashboards et l’automatisation standard, vous avez surtout besoin d’un Administrateur Salesforce [web:39][web:12].

Si votre besoin est de repenser un processus commercial ou de service, vous avez besoin d’un Consultant spécialisé sur le cloud concerné, souvent épaulé par un Admin pour l’implémentation [web:30][web:35].

Si votre besoin est de développer du spécifique, d’intégrer des interfaces, d’écrire du code robuste ou de dépasser les capacités natives, il vous faut un Développeur Salesforce ou un MuleSoft Developer selon la couche concernée [web:4][web:23].

Si votre besoin touche à la structure de l’org, au design multi-cloud, à la sécurité, aux limites de plateforme ou à l’intégration à l’échelle, il vous faut un Architecte [web:24][web:42].

Ce qu’il faut retenir quand on débute

Le plus important, quand on découvre Salesforce, est de ne pas confondre produit, rôle projet, objet de sécurité, certification et intitulé RH. Ce sont cinq niveaux différents, et c’est précisément leur mélange qui rend l’écosystème difficile à lire pour les nouveaux arrivants [web:19][web:22][web:32].

Une bonne façon de se repérer est de partir de cette logique simple :

Quel produit ou cloud ? Sales, Service, Marketing, Experience, Commerce, Data, MuleSoft…
Quel type de responsabilité ? exploitation, design fonctionnel, développement, architecture…
Quel niveau d’intervention ? standard, custom, intégration, gouvernance, transformation… [web:31][web:32][web:42]

C’est seulement une fois ces trois dimensions clarifiées qu’un intitulé comme Salesforce Admin, Sales Cloud Consultant, Marketing Cloud Developer ou Integration Architect devient vraiment lisible.

Si vous cherchez à recruter, à vous reconvertir, à staffer une mission ou simplement à comprendre les intitulés que vous voyez passer, cette grille de lecture est souvent la plus fiable.