Quand la DSI a annoncé « on passe sur Salesforce », la salle a applaudi. Six mois plus tard, le même comité regardait un org rempli de champs orphelins, trois apps AppExchange à moitié utilisées, et une facture de licences qui n’avait plus grand-chose à voir avec le business case initial.
Salesforce n’avait pas « mal marché ». Le projet avait commencé par le build, alors qu’il aurait fallu commencer par les arbitrages.
Migrer vers Salesforce, ce n’est pas brancher un outil plus puissant. C’est accepter une plateforme — avec sa logique d’objets, ses licences, son écosystème — et décider tôt ce que vous refusez de complexifier.
Ce que Salesforce change vraiment
Salesforce brille quand vous avez besoin d’un modèle riche, d’automatisations robustes, d’un reporting exigeant, et souvent d’un déploiement multi-équipes ou multi-pays. L’écosystème (AppExchange, partenaires, talents) est un atout réel.
Mais la puissance attire la sur-conception. Chaque demande métier trouve une réponse technique. Sans garde-fous, vous construisez une usine avant d’avoir un processus commercial stable.
À retenirLe bon projet Salesforce tranche d’abord quoi automatiser et quoi laisser simple. Le reste du build suit.
Licences : le sujet qu’on regarde trop tard
Avant le mapping, regardez qui a vraiment besoin de quoi. Sales Cloud, Service Cloud, licences platform, add-ons marketing ou analytics : chaque profil a un coût et un périmètre.
Le piège classique : acheter large « pour grandir », puis découvrir que la moitié des sièges dorment pendant que trois power users demandent des modules supplémentaires. L’autre piège : sous-estimer les licences pour les profils transverses (ops, finance, managers) qui finissent en lecture seule frustrante… ou en comptes partagés, pire encore.
Construisez une matrice rôles × besoins × licence. Ensuite seulement, parlez architecture.
Modèle de données : la décision structurante
Accounts, Contacts, Opportunities, Cases, custom objects : Salesforce vous laisse presque tout inventer. C’est exactement le danger.
Commencez par vos objets métier incontournables. Une opportunité, c’est quoi chez vous — un deal produit, un projet, un renouvellement, les trois ? Un compte groupe avec filiales, comment le représentez-vous ? Les produits et price books sont-ils nécessaires dès le jour 1, ou un simple montant suffit-il les six premiers mois ?
Chaque objet custom supplémentaire est une dette. Parfois utile. Souvent prématurée.
| Choix | Utile si… | Risqué si… |
|---|---|---|
| Objets standard maximisés | Processus classiques B2B | Vous forcez le métier dans un moule absurde |
| Custom objects tôt | Différenciation métier réelle | Vous modélisez des exceptions rares |
| Champs à foison | Reporting exigé et tenu | Personne ne les remplit |
| Flows partout | Processus stables | Vous automatisez le chaos |
Partenaire, interne, ou hybride
Beaucoup d’entreprises sous-traitent le build puis découvrent qu’elles ne savent pas faire évoluer l’org. D’autres essaient de tout faire en interne avec un admin à mi-temps et s’épuisent.
Le montage réaliste pour une ETI : un partenaire pour l’architecture et les briques complexes, un admin/owner interne pour la gouvernance au quotidien, et des référents métier qui valident les process — pas seulement les écrans.
Sur crmly, le bon expert Salesforce n’est pas celui qui promet le plus d’objets custom. C’est celui qui vous force à prioriser un MVP crédible.
ConseilExigez un backlog priorisé en « must / should / later » avant le kickoff technique. Si tout est prioritaire, rien ne l’est.
Données : migration ≠ import
Migrer vers Salesforce, c’est souvent migrer depuis un CRM plus simple, un ERP, ou un patchwork. Les doublons, les comptes sans contacts, les opportunités sans montant : tout cela arrive dans le nouvel org si vous ne nettoyez pas.
Définissez des règles de qualité avant l’ETL : clé de dédoublonnage, champs obligatoires minimaux, statut des enregistrements inactifs, stratégie pour l’historique d’activités. Un import « big bang » non nettoyé transforme Salesforce en musée de vos erreurs passées — avec une UI plus chère.
Et prévoyez le gel : à partir d’une date, plus de création dans l’ancien outil sauf exception écrite. Sans gel, vous migrez une cible mouvante.
Automatisations, Apex et dette future
Flows, validation rules, Apex, triggers : Salesforce permet d’aller très loin. Le critère n’est pas « peut-on le faire ? » mais « saura-t-on le maintenir ? ».
Documentez chaque automation avec un propriétaire. Évitez les empilements de flows qui se marchent dessus. Réservez Apex aux cas où le déclaratif ne suffit vraiment pas. Et testez en sandbox avec des scénarios métier, pas seulement des tests techniques verts.
AttentionUne org Salesforce sans documentation des automations devient illisible en dix-huit mois — même avec de bons développeurs.
Sécurité, rôles et partage
Le modèle de sharing Salesforce (org-wide defaults, roles, sharing rules, permission sets) est puissant et facilement sous-estimé. Trop ouvert, vous exposez des infos sensibles. Trop fermé, les commerciaux se sentent dans un silo et contournent.
Concevez la matrice de droits avec le métier : qui voit les comptes des autres ? Les managers voient-ils tout le pipe ? Le support accède-t-il aux opportunités ? Ces questions politiques se déguisent en paramétrage technique ; tranchez-les tôt.
Mini-cas : l’ETI qui a sauvé son budget en coupant le scope
Une ETI industrielle voulait « tout Salesforce » en neuf mois : CPQ, service, communauté partenaires, reporting avancé. Après deux ateliers, le comité a réduit au Sales Cloud + intégration ERP minimale + reporting pipeline. Le reste a été planifié en vagues.
Six mois plus tard, l’adoption commerciale dépassait 80 % sur les deals. Le CPQ est arrivé ensuite — sur un socle déjà vivant. Inversé, le projet aurait probablement livré un monstre peu utilisé.
Une feuille de route en quatre décisions
D’abord, le périmètre MVP : quels équipes, quels objets, quels rapports indispensables. Ensuite, le modèle de licences et le TCO à 36 mois. Puis le partenaire et le modèle de gouvernance interne. Enfin, le plan data : nettoyage, mapping, dry-runs, cutover, hypercare.
Si l’une de ces décisions reste floue, ralentissez le build. Salesforce pardonne mal l’improvisation structurelle.
ChecklistAvant de coder : licences validées, modèle de données V1 signé, règles de partage esquissées, backlog MVP figé, jeu de données de recette prêt.
FAQ rapide
Salesforce est-il trop lourd pour une PME ? Parfois oui. Si vos processus sont simples et vos effectifs limités, d’autres CRM coûtent moins cher à faire vivre. Salesforce devient pertinent quand la complexité métier ou la trajectoire de croissance le justifient — voir aussi notre comparatif CRM.
Combien de temps pour migrer ? Pour un périmètre Sales Cloud raisonnable, comptez souvent 3 à 9 mois selon dette data et intégrations.
Faut-il tout customiser ? Non. Standard d’abord. Custom ensuite, avec ROI clair.
Qui possède l’org après le projet ? Un owner interne nommé, avec budget de run. Sans ça, le partenaire devient une béquille permanente.
Anticiper pour ne pas subir
Migrer vers Salesforce, c’est moins une question de connecteurs qu’une question de décisions : licences, modèle, partenaires, droits, et ce que vous acceptez de ne pas construire tout de suite.
Si vous êtes au stade du cadrage, faites-vous challenger sur le scope avant le premier sprint. Les experts Salesforce vérifiés sur crmly existent précisément pour ça : éviter de payer une plateforme premium pour reproduire, en plus complexe, les défauts de l’ancien monde.