Propriété et cycle de vie

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 8 sur 10 du chapitre L’architecture de données Salesforce, chapitre 3 du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Les relations ont des conséquences · Suivant : Garder les données cohérentes

La question à laquelle répond ce module : à qui appartient l’enregistrement, et que lui arrive-t-il tout au long de sa vie ?

Quand je regarde un modèle de données, je ne veux pas seulement savoir quels sont les objets et comment ils sont reliés. Je veux savoir ce qui arrive aux enregistrements dans le temps. Qui les crée ? À qui appartiennent-ils ? Qui peut les réaffecter ? Que se passe-t-il quand la relation métier change, quand ils ne sont plus actifs ? Faut-il jamais les supprimer, et combien de temps les gardons-nous ? Rien de tout cela n’apparaît sur un ERD, le diagramme entité-relation (entity relationship diagram) : les boîtes et les traits du modèle de données du chapitre 2. Tout cela est de l’architecture de données. Et sur Salesforce, la propriété est l’endroit où le modèle de données et le modèle de sécurité se percutent.

La propriété, c’est plus qu’un nom dans un champ

Les administrateurs voient le Propriétaire d’un enregistrement et le lisent comme une étiquette : Bart possède ce compte, Lisa possède cette requête. Cela peut vouloir dire ça. Mais sur Salesforce, la propriété est aussi un mécanisme de la plateforme. Sur les objets qui ont un propriétaire, le propriétaire détermine qui peut voir l’enregistrement à travers la hiérarchie des rôles, les règles de partage, les files d’attente et la réaffectation. Alors quand je demande « à qui appartient cet enregistrement ? », je ne demande pas quel nom figure sur la page. Je demande quel comportement de sécurité et de cycle de vie nous y attachons. Le propriétaire peut être un utilisateur ou, pour certains objets, dont les objets personnalisés, les requêtes et les pistes, une file d’attente, et dans les deux cas le propriétaire obtient un accès complet à l’enregistrement (Understanding Sharing (opens in a new tab), en anglais).

C’est pourquoi je sépare la responsabilité métier de la propriété de l’enregistrement. Parfois, c’est la même personne. Parfois, non. Si le métier dit qu’un répartiteur est responsable d’une livraison, cela ne fait pas automatiquement du répartiteur le propriétaire. La responsabilité peut vivre dans son propre champ tandis que la propriété est définie pour servir la sécurité et le volume. Ne laissez pas les deux se confondre juste parce que les deux utilisent le mot « propriétaire ».

La table de partage : là où la propriété devient l’accès

Certaines personnes ne savent même pas ce qu’est la table de partage. Chaque architecte de données devrait le savoir.

L’essentiel du partage d’un enregistrement est conservé dans un objet de partage associé, la version Salesforce d’une liste de contrôle d’accès (Understanding Sharing (opens in a new tab), en anglais). Compte a AccountShare, Contact a ContactShare, et un objet personnalisé reçoit le sien : Truck__c a Truck__Share (Sharing a Record Using Apex (opens in a new tab), en anglais). Chaque ligne dit quatre choses :

• Quel enregistrement : l’ID du parent.
• Qui : un utilisateur, ou un groupe (un groupe public, le groupe d’un rôle, un territoire).
• Combien : Lecture, Modification ou Tout (accès complet).
• Pourquoi : la cause de la ligne (row cause). Owner pour le propriétaire, Rule pour une règle de partage, Manual pour un partage manuel, Team, les causes implicites que Salesforce ajoute entre un compte et ses enfants, et les raisons qu’un développeur définit pour le partage Apex.

En cours, j’ouvre Workbench et j’interroge la table de partage pendant que je partage un enregistrement, et vous voyez les lignes apparaître et disparaître. Quand quelqu’un demande « pourquoi cette personne peut-elle voir ça ? », la réponse se trouve souvent dans une ligne, avec sa raison.

Mais tout n’y est pas. Le paramètre par défaut de l’organisation n’est pas une ligne. La hiérarchie des rôles n’y est pas stockée non plus : l’accès des personnes au-dessus du propriétaire est calculé au moment où il est nécessaire. Et Afficher tout, Modifier tout, Afficher toutes les données et Modifier toutes les données contournent complètement la table de partage (Sharing a Record Using Apex (opens in a new tab), en anglais). Comme je le dis en cours : cochez Afficher tout et vous avez contourné la table de partage.

Salesforce partage aussi certains enregistrements pour vous, en raison de la façon dont ils sont liés. C’est le partage implicite, et il fonctionne entre un compte et ses enfants. Si vous pouvez voir un contact, une requête ou une opportunité, vous pouvez aussi lire le compte auquel il appartient. Et le propriétaire du compte obtient l’accès aux contacts, requêtes et opportunités du compte, à un niveau défini par le rôle du propriétaire (Implicit Sharing (opens in a new tab), en anglais). Dans les versions récentes, Salesforce calcule une partie de cet accès aux enfants au moment où il est nécessaire au lieu de le stocker sous forme de lignes, alors ne soyez pas surpris quand une requête sur la table de partage ne le montre pas. Je ne vous donne ici qu’un aperçu ; les détails sont dans Les relations et le partage intégré.

Encore une exception, pour quand vous avez beaucoup d’utilisateurs externes. Les utilisateurs de communauté à haut volume, les licences Customer Community conçues pour des milliers à des millions de clients, n’ont pas de rôle, ne peuvent pas être dans des groupes publics, et ne peuvent pas recevoir d’enregistrements par des règles de partage ou des partages manuels (About High-Volume Community or Site Users (opens in a new tab) ; Sharing Rule Considerations (opens in a new tab), en anglais). Pour eux, la table de partage n’est pas la réponse : ils accèdent aux enregistrements par des ensembles de partage (sharing sets), qui font correspondre le compte ou le contact d’un enregistrement à celui de l’utilisateur. C’est l’une des raisons pour lesquelles ces licences passent à l’échelle. Le cours Sharing and Visibility le traite dans Le partage avec les utilisateurs externes.

Et souvenez-vous du module 7 : un objet détail n’a pas du tout d’objet de partage. Son accès vient de l’objet de partage du principal et du Paramètre de partage du champ principal-détails.

Pourquoi un architecte de données s’en soucie-t-il ? Parce que la propriété est écrite dans cette table. Chaque changement de propriétaire, chaque nouvelle règle de partage, chaque utilisateur qui change de rôle ou de groupe veut dire que Salesforce ajoute et retire des lignes. À quelques milliers d’enregistrements, personne ne le remarque. À dix millions, avec un seul utilisateur qui en possède la plupart, c’est le recalcul que nous allons rencontrer dans un instant.

À savoir pour l’examen. L’objet de partage d’un objet personnalisé s’appelle Object__Share, comme Truck__Share. Un objet détail n’a pas d’objet de partage : son accès vient du principal. Et quand le propriétaire d’un enregistrement change, ses partages manuels sont supprimés, tandis que le partage Apex avec une raison propre au développeur reste.

C’est ici que le modèle de données passe le relais au modèle de sécurité, et j’enseigne la suite dans le cours Sharing and Visibility Architect : Les 22 façons de partager un enregistrement de Steve, Paramètres par défaut de l’organisation, propriété, files d’attente et hiérarchie des rôles, Les relations et le partage intégré pour les partages implicites, et Le partage programmatique et le code sécurisé pour les raisons de partage Apex. Dans ce cours, le chapitre 12 rassemble le tout pour les humains, les applications et les agents.

Parfois, la propriété est héritée

Dans le module précédent, nous avons vu qu’un enfant principal-détails n’a pas de propriétaire propre ; il suit son parent. C’est souvent exactement juste. Le métier a-t-il besoin d’un propriétaire différent pour chaque article d’une livraison ? Non. La livraison porte le cycle de vie et l’article lui appartient. C’est pourquoi la conception des relations et celle de la propriété vont ensemble : en choisissant principal-détails, vous aviez déjà pris une partie de la décision de propriété.

À qui appartiennent les enregistrements créés par des systèmes ?

C’est là que ça devient intéressant. Une personne crée un compte, et elle en devient peut-être le propriétaire. Mais un ERP envoie 100 000 transactions pendant la nuit. À qui appartiennent-elles ? À l’utilisateur d’intégration ? À une file d’attente ? À un propriétaire régional déduit des données ? À un compte système auquel personne n’a pensé depuis cinq ans ? Et maintenant, les agents créent aussi des enregistrements.

Ma position : cela dépend de l’importance de la propriété pour le partage. L’utilisateur d’intégration, ou l’utilisateur de l’agent, est un utilisateur valide, et il peut posséder les enregistrements. Si la propriété détermine l’accès sur cet objet (via la hiérarchie des rôles ou les règles de partage), affectez les enregistrements au bon propriétaire : un vrai utilisateur, une file d’attente, ou un utilisateur propriétaire dédié. Sinon, garder l’utilisateur système comme propriétaire peut être le meilleur choix, car la piste d’audit ramène alors directement à ce qui a créé l’enregistrement.

Dans tous les cas, décidez-le délibérément. Un compte d’intégration qui possède tout est discrètement devenu une partie de votre architecture de sécurité, et quelqu’un doit savoir ce qui se passe s’il est un jour désactivé.

La propriété peut devenir un problème de volume

La répartition compte aussi. Dix millions d’enregistrements répartis entre des milliers de propriétaires, c’est une forme. Dix millions d’enregistrements possédés par un seul utilisateur, c’en est une très différente. Salesforce appelle déséquilibre de propriété (ownership data skew) le cas où un seul utilisateur possède plus de 10 000 enregistrements d’un objet (Ownership Data Skew (opens in a new tab), en anglais). Cela arrive généralement quand quelqu’un gare tout sur un seul utilisateur ou une seule file : toutes les pistes non affectées sur un utilisateur bouche-trou, chaque enregistrement d’intégration sur l’utilisateur d’intégration. C’est sans danger jusqu’à ce que cet utilisateur bouge dans la hiérarchie des rôles, ou entre dans un groupe dont dépend une règle de partage ou en sorte. Salesforce doit alors ajuster un nombre énorme d’entrées de partage, et vous obtenez des recalculs interminables.

Les recommandations sont pratiques. Répartissez la propriété sur davantage d’utilisateurs quand vous le pouvez. Si un utilisateur doit posséder beaucoup, gardez-le hors de la hiérarchie des rôles ; s’il a besoin d’un rôle, mettez-le seul dans un rôle au sommet et ne le déplacez pas, et gardez-le hors des groupes publics utilisés par les règles de partage (Ownership Data Skew (opens in a new tab), en anglais). Le même raisonnement s’applique au parent qui a trop d’enfants vu au module précédent, le déséquilibre parent-enfant.

La répartition fait donc partie du modèle physique. Ne demandez pas seulement combien d’enregistrements ; demandez comment ils sont répartis. C’est une autre version du Nombre de Zéros : pas seulement combien de zéros, mais où les zéros se concentrent. La partie 2 approfondit le déséquilibre ; ici, je veux que vous le voyiez venir. Le cours Sharing and Visibility y revient dans Le partage à grande échelle.

Le « propriétaire par défaut » devient de l’architecture

Voici un schéma que je vois tout le temps. Personne ne sait à qui devrait appartenir quelque chose, alors quelqu’un dit : « Affectez-les tous à l’utilisateur d’intégration », ou « créez un utilisateur générique appelé System ». C’est peut-être juste. Mais ne le faites pas par accident. Un défaut temporaire a la fâcheuse tendance de devenir permanent : deux ans plus tard, chaque enregistrement appartient à integration@company.com, personne ne se souvient pourquoi, et le changer est un projet. C’est le test de réversibilité du chapitre 1 : avant de donner un million d’enregistrements à un seul propriétaire, demandez ce qu’il faudra pour changer cela plus tard.

La réaffectation est un événement du cycle de vie

Les propriétaires changent. Les commerciaux partent, les territoires bougent, les équipes se réorganisent, les régions sont rééquilibrées. Qu’est-ce qui dépend du propriétaire : partage, automatisation, rapports, files d’attente, escalades, intégrations ? Si changer de propriétaire change qui peut voir l’enregistrement, la réaffectation n’est pas du ménage administratif. C’est un événement de sécurité, et à un million d’enregistrements, c’est aussi un événement opérationnel. Surveillez la table de partage quand cela se produit : les partages manuels sont supprimés quand le propriétaire change, tandis que le partage Apex avec une raison propre au développeur survit au changement (Understanding Sharing (opens in a new tab), en anglais). En cours, je partage un enregistrement avec quelqu’un, je change le propriétaire, et la personne perd l’accès. La salle est toujours surprise.

Et souvenez-vous que la propriété n’est pas la même chose que l’accès. Le propriétaire n’est pas la seule personne qui a besoin de voir un enregistrement, et Salesforce a de nombreuses façons d’accorder l’accès : hiérarchie des rôles, règles de partage, équipes, territoires, partage manuel et programmatique. Le cours Sharing and Visibility les approfondit, en commençant par Les 22 façons de partager un enregistrement de Steve. Le point de l’architecte est plus simple : n’utilisez pas la propriété pour résoudre chaque problème d’accès. Si vous déplacez des propriétaires juste pour que quelqu’un voie un enregistrement, vous résolvez probablement le mauvais problème.

La création n’est que le début

Beaucoup de modélisation s’arrête à la création : les champs, l’objet, la relation, terminé. Mais l’enregistrement peut vivre dix ans. Il est mis à jour, change de propriétaire, change de statut et de relations, devient inactif, devient de l’historique, a peut-être besoin d’être archivé, et un jour peut-être supprimé. L’architecture, ce n’est pas seulement la naissance de l’enregistrement. C’est ce qui se passe de la naissance à la mort.

Click to enlarge

Ne supprimez pas juste parce que c’est vieux

Un partenaire distributeur cesse d’envoyer du travail. Supprimer le compte ? Pas automatiquement : ses livraisons, ses réclamations et son historique de facturation comptent toujours. Un camion est retiré du service. Le supprimer, avec son historique de livraisons et ses réclamations pour dommages ? La chose n’est peut-être plus active, mais ses données le sont toujours. Je sépare donc inactif de disparu. Un camion retiré peut rester dans le modèle ; un ancien employé peut toujours apparaître dans l’historique d’audit. L’architecture doit garder les faits qui comptent après la fin de la relation opérationnelle.

La conservation est une exigence métier

L’autre côté : tout garder pour toujours n’est pas non plus de l’architecture. Le stockage grandit, les rapports ralentissent, la recherche devient plus bruyante, et le droit de la vie privée peut exiger que certaines données disparaissent. Je veux donc une réponse explicite à combien de temps gardons-nous ceci ? « Salesforce le garde » n’est pas une politique de conservation.

Et surtout, c’est une question de données transactionnelles. Les données de référence, les produits, les types de service, les centres de distribution, ne deviennent pas énormes, et d’autres enregistrements pointent vers elles, donc elles restent généralement. Les données client sont entre les deux : il peut venir un jour où vous mettez fin à la vie d’un client, surtout quand vous détenez des données personnelles et que la raison de les conserver prend fin. Mais le volume est dans les transactions : les livraisons, les commandes, les requêtes, les rendez-vous, créés chaque jour, pour toujours. C’est ce qui grandit jusqu’à des centaines de millions de lignes, et c’est là que la conservation doit être explicite : peut-être deux ans de données opérationnelles dans l’organisation, sept ans de documents financiers ailleurs, quatre-vingt-dix jours pour certaines photos. Ce sont des règles métier, et si personne ne les a demandées, l’architecte devrait le faire.

Je le dis en cours depuis des années : si vous n’archivez pas aujourd’hui, allez-vous un jour archiver ? « On s’en occupera plus tard » a tendance à devenir un projet d’urgence à trois cents millions d’enregistrements. La partie 2 consacre un module entier à l’archivage et à la purge, construit sur la même question.

Steve Trucking : à qui appartient une livraison ?

Une livraison est créée à partir du manifeste du partenaire distributeur, par une intégration, environ 3 300 fois par jour. À qui appartient-elle ? Pas au partenaire distributeur ; c’est une relation métier. Pas au destinataire. L’équipe l’exécute, mais l’enregistrement doit-il changer de propriétaire à chaque fois que les équipes changent de camion ? Au répartiteur ? Au centre de distribution ? À une file d’attente ? À l’utilisateur d’intégration qui l’a créée ?

Appliquez maintenant ce module, en commençant par la question qui tranche : la propriété détermine-t-elle l’accès de quiconque aux livraisons ? Chez Steve Trucking, non. Les répartiteurs voient les livraisons de leur centre de distribution, les équipes voient celles de leurs tournées, et chaque distributeur voit les siennes dans le portail partenaire. Rien de tout cela ne dépend de qui possède l’enregistrement ; cela vient du centre de distribution, de la tournée et du partenaire.

Alors ma réponse : l’utilisateur d’intégration possède les livraisons. C’est un bon exemple d’utilisateur système qui possède des enregistrements délibérément :

• La piste d’audit est honnête. Le propriétaire de chaque livraison dit d’où elle vient : l’intégration du manifeste.
• L’accès vient du partage, pas de la propriété. Des règles de partage basées sur des critères, sur le centre de distribution, donnent à l’équipe de chaque centre ses livraisons ; les partenaires accèdent aux leurs par le portail.
• Le déséquilibre est évité dès la conception. À 3 300 par jour, l’utilisateur d’intégration dépasse 10 000 livraisons en trois jours, donc c’est un déséquilibre de propriété dès le premier jour, et ce n’est pas grave si nous le prévoyons. L’utilisateur d’intégration n’a pas de rôle, donc rien au-dessus de lui dans une hiérarchie n’a à être recalculé, et il reste hors des groupes publics qu’utilisent nos règles de partage.
• Personne ne réaffecte les livraisons. Les équipes changent de camion et les répartiteurs changent de poste, et le propriétaire ne bouge jamais, donc pas de tempête de réaffectations ni de partages manuels à perdre.

Et écrivez ce qui se passe si cet utilisateur est un jour désactivé ou remplacé, parce qu’il possède maintenant des millions d’enregistrements. C’est la décision que la prochaine équipe aura besoin de trouver.

Au-delà de l’examen : ce que l’IA change. Les agents créent et modifient des enregistrements à la vitesse de la machine. Si un agent crée 100 000 enregistrements sous son propre utilisateur, « on corrigera le propriétaire plus tard » devient un déséquilibre, un recalcul du partage et un projet de nettoyage. Décidez de la règle de propriété de l’agent avant sa mise en service, avec la même question : la propriété compte-t-elle ici pour le partage ?

Ce que l’architecte décide ici

• Si la propriété représente une responsabilité métier, un mécanisme de sécurité, ou les deux, et où vit la responsabilité si ce n’est pas dans Propriétaire.
• Si les enregistrements ont besoin de leur propre propriétaire ou doivent l’hériter d’un parent.
• À qui appartiennent les enregistrements créés par les intégrations et les agents, selon que la propriété détermine ou non le partage.
• Comment la propriété est répartie, et comment éviter le déséquilibre de propriété quand un utilisateur doit posséder beaucoup.
• Quand les enregistrements deviennent inactifs, quand ils sont archivés, combien de temps ils sont gardés, et quand la suppression est la bonne réponse.

Quand vous regardez un modèle physique, ne demandez pas seulement où les données sont stockées. Demandez à qui elles appartiennent aujourd’hui, à qui elles pourraient appartenir demain, et ce qui se passe quand nous n’en avons plus besoin. Ensuite : même avec le bon objet, les bons champs, les bonnes relations et le bon propriétaire, les données doivent encore rester dignes de confiance.

Pour aller plus loin

• Apex Developer Guide, Understanding Sharing (opens in a new tab) (en anglais), consulté le 2026-10-13 : les propriétaires (un utilisateur, ou une file d’attente pour les objets personnalisés, les requêtes et les pistes) obtiennent un accès complet ; l’essentiel du partage vit dans un objet de partage associé ; la hiérarchie des rôles est calculée à l’exécution ; les partages manuels sont supprimés quand le propriétaire change, le partage géré par Apex est conservé ; les valeurs de cause de ligne.
• Apex Developer Guide, Sharing a Record Using Apex (opens in a new tab) (en anglais), consulté le 2026-10-13 : AccountShare, MyCustomObject__Share ; les objets détail n’ont pas d’objet de partage ; ce que l’objet de partage ne suit pas (paramètres par défaut de l’organisation, hiérarchie des rôles, Afficher tout et Modifier tout).
• Aide Salesforce, Implicit Sharing (opens in a new tab) (en anglais), consulté le 2026-10-13 : l’accès entre un compte et ses contacts, requêtes et opportunités.
• Aide Salesforce, About High-Volume Community or Site Users (opens in a new tab) et Sharing Rule Considerations (opens in a new tab) (en anglais), consulté le 2026-10-13 : pas de rôles, pas de règles de partage ni de partages manuels ; des ensembles de partage à la place.
• Cours Sharing and Visibility Architect : Les 22 façons de partager un enregistrement de Steve, Paramètres par défaut de l’organisation, propriété, files d’attente et hiérarchie des rôles, Les relations et le partage intégré, Le partage programmatique et le code sécurisé, Le partage avec les utilisateurs externes, Le partage à grande échelle.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Ownership Data Skew (opens in a new tab) et Parent-Child Data Skew (opens in a new tab) (en anglais), consulté le 2026-10-02.