Le modèle de données est la fondation d'un projet Salesforce. Une fois les objets, les relations et les règles de partage en production avec plusieurs milliers d'enregistrements, revenir en arrière devient long et risqué. Pourtant, en phase de design, certaines décisions sont validées en quelques minutes de réunion, sans anticiper leurs effets sur les rapports, les performances ou la sécurité. Cet article passe en revue six décisions structurantes souvent prises trop vite, et les questions à poser avant de figer le schéma.
Pourquoi le modèle de données mérite plus de temps qu'on ne lui accorde
Dans beaucoup de projets, la phase de design du modèle de données est comprimée entre le cadrage fonctionnel et le début de la configuration. L'équipe veut « avancer », et les objets standards de Salesforce (Compte, Contact, Piste, Opportunité) donnent l'illusion que la structure va de soi. Le problème apparaît plus tard : rapports impossibles à construire, doublons ingérables, droits d'accès trop larges, ou migration bloquée.
Une décision de modèle de données n'est pas seulement technique. Elle engage la façon dont l'entreprise lira ses données, protégera l'information sensible et fera évoluer son outil. Chaque choix ci-dessous gagne à être documenté et challengé avant validation.
Décision 1 — Objet standard ou objet personnalisé
La tentation est forte de créer un objet personnalisé « propre » plutôt que d'adapter un objet standard. Mais les objets standards embarquent des fonctionnalités difficiles à répliquer : gestion des équipes, historique, intégrations natives, processus de conversion de piste.
À l'inverse, forcer un objet standard pour un besoin qu'il ne couvre pas produit des champs détournés de leur usage et des rapports illisibles. La bonne question : ce besoin est-il vraiment une variation d'un concept standard, ou un objet métier distinct ? Une décision prise « par défaut » sans ce débat se paie en configuration détournée.
Décision 2 — Relation lookup ou principale-détails
Le choix entre une relation lookup (référence simple) et une relation principale-détails (master-detail) est souvent tranché sans mesurer ses conséquences. La relation principale-détails impose que l'enregistrement enfant hérite de la sécurité du parent, se supprime en cascade, et permet les champs de récapitulatif (roll-up summary). C'est puissant, mais rigide.
La relation lookup est plus souple mais ne fournit pas nativement de champs de synthèse ni d'héritage de sécurité. Beaucoup d'équipes choisissent la principale-détails pour obtenir un roll-up, sans anticiper que l'enfant devient inaccessible indépendamment et que la relation est difficile à convertir ensuite.
Convertir une relation principale-détails en lookup (ou l'inverse) après la mise en production est possible mais soumis à des conditions strictes sur les données existantes. Traiter ce choix comme réversible en début de projet mène régulièrement à des impasses de migration.
Décision 3 — Le grain du modèle : un objet ou plusieurs
Faut-il un seul objet « Contrat » avec un champ Type, ou plusieurs objets distincts ? Cette question de granularité est décisive. Regrouper simplifie les rapports transverses mais mélange des cycles de vie différents, avec des champs vides selon les cas. Séparer clarifie chaque processus mais complique les vues consolidées.
Le réflexe rapide consiste à tout regrouper « pour faire simple ». Or un objet fourre-tout, avec des dizaines de champs conditionnellement pertinents, devient vite illisible pour les utilisateurs et coûteux à maintenir. La règle utile : distinguer selon les processus métier réels et selon les besoins de reporting, pas selon la commodité de configuration initiale.
Décision 4 — Le modèle de partage et de visibilité
La sécurité des données (organisation-wide defaults, rôles, règles de partage) est parfois traitée en fin de projet, comme un réglage. C'est une erreur de séquencement. Le modèle de partage dépend directement de la structure des objets et des relations. Décider tard que « tout le monde voit tout » parce que le paramétrage fin est trop complexe crée une dette de conformité.
Les organisations soumises au RGPD doivent pouvoir justifier qui accède à quelles données personnelles. La CNIL rappelle le principe de minimisation et de contrôle des accès. Un modèle de données qui ne prévoit pas dès le design la ségrégation des données sensibles rend ces obligations difficiles à respecter.
Décision 5 — Champs de picklist : valeurs libres ou contrôlées
Les listes de choix (picklists) semblent anodines. Pourtant, autoriser la saisie libre là où une valeur contrôlée s'imposait, ou multiplier les picklists sans gouvernance, dégrade la qualité de données de façon irréversible à grande échelle.
- Une picklist non structurée devient impossible à segmenter dans les rapports.
- Des valeurs mal définies obligent à des nettoyages manuels coûteux plus tard.
- Les picklists globales (partagées entre objets) offrent une cohérence que des picklists locales dupliquées ne garantissent pas.
La question à poser en design : cette information sera-t-elle un jour un critère de filtre, de segmentation ou de reporting ? Si oui, elle doit être contrôlée dès le départ.
Décision 6 — Les identifiants uniques et la stratégie anti-doublons
La gestion des doublons se décide au niveau du modèle, pas seulement des règles de matching. Quel champ sert de clé unique ? SIREN pour un compte professionnel, e-mail pour un contact, référence externe pour une intégration ? Sans champ d'identification externe (external ID) prévu dès le design, les imports et les synchronisations avec d'autres systèmes deviennent fragiles.
Le répertoire SIRENE publié par l'INSEE via data.gouv.fr fournit une base d'identifiants fiables pour les entités françaises. Prévoir un champ dédié au SIREN et une contrainte d'unicité en amont évite des chantiers de dédoublonnage lourds une fois les données massivement chargées.
Comment sécuriser ces six décisions
Aucune de ces décisions n'exige un outil coûteux, mais toutes exigent du temps de cadrage et un dialogue entre le métier et l'équipe technique. Quelques pratiques réduisent le risque :
- Documenter chaque choix avec sa justification et ses alternatives écartées.
- Modéliser sur données réelles (volumes, cas limites) plutôt que sur exemples théoriques.
- Impliquer les futurs utilisateurs des rapports dès le design des objets.
- Tester la migration d'un échantillon avant de figer les relations et les clés.
Ces vérifications distinguent souvent un intégrateur qui questionne le besoin d'un prestataire qui applique une configuration standard. Lors du choix d'un partenaire, demander comment il aborde ces six décisions donne un bon indicateur de sa méthode.