La Réponse Courte
Un bon modèle de données sur Salesforce n'est pas le plus beau en théorie, mais celui qui concilie simultanément trois éléments : le processus métier, le modèle de permissions et les rapports requis. La plupart des modèles échouent car ils sont construits uniquement autour du premier.
La distinction entre une décision de modélisation et d'autres décisions de projet réside dans le coût du changement. Modifier un enregistrement Flow prend une journée ; changer le type de relation entre les objets après deux ans de données, d'automatisations et d'intégrations est un projet en soi. C'est pourquoi l'investissement dans la phase de conception est plus rentable ici que partout ailleurs.
Règle Première : Utiliser les Objets Standard
Account, Contact, Lead, Opportunity, Case et Product apportent des fonctionnalités qui ne sont pas incluses gratuitement avec un objet personnalisé : processus de vente, prévisions, droits d'accès, Omni-Channel, application mobile et intégration native avec d'autres produits de la plateforme.
Une organisation qui crée un Customer__c au lieu d'un Account obtient initialement un modèle d'apparence plus propre, mais découvre plus tard que chaque fonctionnalité standard nécessite une construction personnalisée. La règle est la suivante : ne vous écartez du standard que s'il existe une raison que l'on peut exprimer en une phrase.
Quand un Objet Personnalisé est-il Requis ?
| Situation | Objet Personnalisé ? | Justification |
|---|---|---|
| Contrat/Abonnement avec son propre cycle de vie | Oui | Statuts, renouvellement, propriété et rapports distincts |
| Actif installé chez un client | Oui (ou Asset standard) | Entité indépendante avec historique de service |
| "Client potentiel" supplémentaire | Non | C'est un Lead ou un Account avec un Record Type |
| Département d'une organisation | Non | Donnée sur un utilisateur, pas une entité |
| Lignes de tarification complexes | Dépend | Vérifier Quote Line ou CPQ avant de construire |
Normalisation vs. Aplatissement : Le Compromis qui Influence les Rapports
Dans les bases de données classiques, la normalisation est une vertu. Sur Salesforce, elle est échangée contre la facilité de reporting : chaque niveau de relation supplémentaire complique la création de rapports sans outil externe, car le reporting standard est limité en profondeur de relations.
Le compromis habituel est la normalisation là où la donnée change et est dupliquée, et un aplatissement contrôlé des champs de requête courants vers l'objet à partir duquel les rapports sont générés – à condition que la duplication soit gérée automatiquement et non manuellement. Un champ dupliqué mis à jour par saisie manuelle devient obsolète en quelques mois.
Les Permissions Font Partie du Modèle, Pas une Étape Ultérieure
La question "qui voit quoi" doit être posée lors de l'esquisse des objets. Un modèle où une donnée sensible réside sur le même objet qu'une donnée opérationnelle contraint par la suite à des solutions de contournement – objet miroir, champs chiffrés ou visibilité excessivement large.
La vérification pratique : pour chaque nouvel objet, écrivez une ligne – qui est le propriétaire, qui lit, qui modifie et ce qui se passe dans la hiérarchie. Si la réponse nécessite plus de quatre lignes, la structure mélange probablement deux entités.
Une extension sur les sources de données et l'autorité de mise à jour se trouve dans Source de Référence dans l'Organisation, et sur la gestion des entités clés dans Master Data Management.
Cas d'Étude : Une Entreprise Logicielle Ayant Construit un Modèle Autour des Départements
Une entreprise SaaS de taille moyenne a construit un modèle avec quatre objets personnalisés – un pour chaque équipe de vente – car chaque équipe avait un processus différent. Un an et demi plus tard, les équipes ont été fusionnées, ce qui a nécessité : la fusion des rapports, des automatisations parallèles à quatre endroits et une migration interne de 60 000 enregistrements entre les objets.
La reconstruction s'est basée sur un seul objet Opportunity avec des Record Types pour les différents processus. La même distinction métier a été conservée – différents parcours de vente, différents champs, différentes Page Layouts – mais au niveau de la configuration et non de la structure. Le prochain changement organisationnel nécessitera une modification de Record Type, pas une migration.
La règle qui en découle est la suivante : la structure représente les entités ; la configuration représente l'organisation. Ce qui est susceptible de changer tous les deux ans ne devrait pas faire partie de la structure.
Performance et Volume – Ce qui Compte Vraiment
Les problèmes de performance dans un modèle de données proviennent principalement de trois sources : la distorsion des données (Data Skew – par exemple, un parent unique avec des dizaines de milliers d'enfants, comme un compte "Clients Particuliers"), des formules imbriquées qui calculent en temps réel à travers les relations, et le partage basé sur Apex Sharing créé à grande échelle. Les trois peuvent être identifiés dès la phase de conception si l'on anticipe le nombre d'enregistrements attendus sous chaque parent.
Risques Courants et Actions Préventives
| Risque | Comment il se manifeste | Action Préventive |
|---|---|---|
| Objet Personnalisé inutile | Fonctionnalités standard recréées manuellement | Vérifier l'Objet Standard avant tout nouvel objet |
| Master-Detail trop précoce | Suppressions en chaîne et structure immuable | Commencer par un Lookup si un Roll-Up n'est pas nécessaire |
| Modèle reflétant l'organisation | Chaque changement organisationnel devient une migration | Record Types au lieu d'objets |
| Distorsion des données (Data Skew) | Blocages et lenteurs lors des mises à jour massives | Répartir les parents, vérifier le volume lors de la conception |
| Permissions en afterthought | Solutions de contournement et visibilité trop large | Matrice d'accès pour chaque objet lors de la conception |
Comment Mesurer le Succès
| Domaine | Quoi Mesurer | Fréquence de Vérification |
|---|---|---|
| Utilisation des champs | Taux de remplissage pour chaque champ | Trimestriel |
| Rapports | Pourcentage de rapports nécessitant une consolidation manuelle | Trimestriel |
| Stabilité de la structure | Nombre de modifications structurelles par semestre | Semestriel |
| Performance | Temps de mise à jour massives et blocages | Mensuel |
La conception d'un modèle de données dans le cadre d'une architecture globale est réalisée via le service d'intégration et de données.
Liste de Vérification Avant de Geler le Modèle
- Pour chaque objet personnalisé, une justification en une phrase existe.
- Un objet standard alternatif a été vérifié pour chaque entité.
- Le type de relation a été explicitement choisi avec une justification pour Master-Detail.
- Le volume prévu pour chaque parent a été estimé (vérification du Skew).
- Matrice d'accès : propriétaire, lecture, modification, hiérarchie.
- Il a été vérifié que chaque rapport clé peut être construit dans le modèle.
- Les champs dupliqués sont mis à jour uniquement automatiquement.
- Les changements organisationnels attendus sont traités dans la configuration.
- Un diagramme ERD à jour et documenté existe.
- Il a été déterminé qui approuvera les futures modifications de structure.
Sources Professionnelles
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data