Protéger, conserver et prouver

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · 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) · Deutsch (Schweiz)

Image générée par IA

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

Module 6 sur 6 du chapitre Qualité et gouvernance des données, chapitre 5 du cours Data Architect. Chaque module est autonome. Précédent : Le consentement et le droit à l’oubli · Suivant : le chapitre suivant, Données maîtres et identité

La question à laquelle répond ce module : comment protéger les données, les conserver aussi longtemps que nécessaire, et le prouver ?

Nous avons fixé les propriétaires et les politiques, tenu les mauvaises données à l’écart, écrit le dictionnaire, tracé le lignage, classé ce qui compte, appris les lois et modélisé le consentement. Maintenant, il faut faire tourner tout cela. Les données arrivent, sont utilisées, copiées et modifiées, vieillissent, et un jour une partie doit partir. Et un jour, quelqu’un demandera : prouvez ce qui s’est passé.

La gouvernance suit les données

Je ne pense pas la gouvernance comme une fonctionnalité. Je pense à ce qui arrive aux données depuis le moment où elles entrent jusqu’à ce que nous en ayons fini avec elles :

Capturer → Classer → Protéger → Utiliser → Conserver → Supprimer → Auditer

Pas sept processus techniques : sept questions auxquelles l’architecture doit répondre. Capturer et classer, nous l’avons couvert : tenir les erreurs coûteuses à l’écart (module 2), et savoir quelles données sont sensibles (module 3). La classification décide de ce qui se passe à chaque étape suivante, alors ce module reprend à partir de là.

Click to enlarge

Sept questions tout au long de la vie des données. Les outils soutiennent la politique ; ils ne la définissent pas.

Protéger : adaptez le contrôle aux données

Qui peut les voir, les modifier, les recevoir ? Doivent-elles être chiffrées, masquées hors production, exportables, accessibles à un agent ? C’est là que la sécurité Salesforce devient une partie de la gouvernance des données : partage, autorisations sur les objets et les champs, chiffrement, masquage, accès des intégrations. Ces sujets remplissent des cours entiers, je ne vais donc pas les réenseigner. Le point de gouvernance : la protection suit la classification et la politique. Tous les champs n’ont pas besoin de la même protection, tous les utilisateurs du même accès, tous les systèmes en aval de tous les champs.

Le chiffrement est un contrôle, pas la conformité

Pour les données réglementées, le chiffrement au repos peut être exigé, et ma position est que Shield est la réponse aux exigences réglementaires clés comme celle-ci. Shield Platform Encryption chiffre les champs et les fichiers au repos. Mais « nous l’avons chiffré, donc nous sommes conformes » est doublement faux. Le chiffrement est un contrôle parmi d’autres : accès, conservation, audit, consentement, surveillance, minimisation et suppression. Et il a des compromis fonctionnels à prendre en compte dès le départ. Avec le schéma probabiliste par défaut, un champ chiffré ne peut pas être utilisé dans les clauses SOQL WHERE, GROUP BY ou ORDER BY ni dans les filtres de gestion des données ; le chiffrement déterministe sacrifie un peu de robustesse pour que vous puissiez filtrer sur le champ. Les champs chiffrés ne peuvent pas piloter des règles de partage basées sur des critères, et vous ne pouvez pas trier les vues de liste sur eux (General Shield Platform Encryption Considerations (opens in a new tab) ; Filter Encrypted Data with Deterministic Encryption (opens in a new tab), en anglais). Le chiffrement n’est donc pas une case à cocher à la fin. C’est une décision d’architecture. Le chapitre sur la sécurité des données va plus loin.

Ne copiez pas le risque de la production dans la sandbox

La production est verrouillée. Puis quelqu’un actualise une sandbox complète, et les développeurs, les testeurs, les prestataires et les intégrations de test détiennent maintenant des copies de vraies données personnelles dont ils n’ont jamais eu besoin. L’environnement a changé ; la sensibilité des données, non. Les outils de masquage de Salesforce existent exactement pour cela. Notez un changement : le package géré Data Mask arrive en fin de service le 31 décembre 2026, et son successeur est Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), en anglais). Mais l’outil soutient la politique, et la question vient en premier : cet environnement a-t-il seulement besoin de vraies données sensibles ? Si des données réalistes et non sensibles suffisent pour les tests, c’est la meilleure réponse.

Utiliser : l’autorisation ne concerne pas que les personnes

Les utilisateurs, les intégrations, l’analytique, les partenaires, l’automatisation et les agents utilisent tous les données. Le consentement (module 5), la propriété (module 1) et la classification (module 3) se rejoignent ici, à l’exécution. Cet utilisateur doit-il voir le numéro de téléphone du destinataire ? Cette intégration doit-elle le recevoir, ou Snowflake, ou cet agent comme ancrage ? La réponse ne peut pas être « eh bien, techniquement, il peut ». C’est la différence entre capacité et gouvernance : l’architecture décide s’il doit.

Conserver : tout garder pour toujours n’est pas neutre

Beaucoup d’organisations ont une politique de conservation accidentelle : pour toujours. Personne ne l’a décidée ; le stockage était disponible, alors les données sont restées. Mais garder des données coûte du stockage et des performances, élargit l’exposition en matière de protection des données et de sécurité, ajoute des obligations de recherche, et vous donne plus d’endroits à fouiller quand quelqu’un demande à être oublié. Pour chaque catégorie importante : pourquoi la garder, combien de temps, qu’est-ce qui déclenche le compte à rebours, y a-t-il un minimum légal ou un maximum lié à la protection des données, et que se passe-t-il à la fin : archiver, supprimer, désidentifier ?

Et archiver n’est pas la même chose que régler la conservation. « Nous l’avons archivé. » L’exigence de conservation a-t-elle disparu ? L’exigence de protection des données ? La sécurité ? Vous avez changé l’endroit où vivent les données, pas ce qu’elles sont. Une archive a besoin de contrôles d’accès, de règles de conservation et de suppression, de recherche et d’audit. Déplacez des données personnelles dans une archive que tout le monde oublie, et la gouvernance vient de se dégrader.

Supprimer : le cycle de vie a besoin d’une sortie

La suppression ne concerne pas que les demandes individuelles de protection des données. Les données arrivent au bout de leur durée de conservation ; des enregistrements temporaires survivent à leur utilité ; des archives expirent ; un processus désidentifie au bout d’un délai fixé. Quoi que dise la politique, l’architecture a besoin d’une sortie, pas de capturer → stocker → stocker davantage → stocker pour toujours. Et comme l’a montré le module 5, supprimer l’enregistrement Salesforce ne suffit pas quand des copies vivent ailleurs.

L’historique est aussi une donnée

Parfois, la valeur actuelle ne suffit pas. La raison sociale d’un partenaire, la classification d’un client, un statut de consentement, un attribut financier : le métier ou un régulateur peut avoir besoin de savoir ce qu’elle était avant, quand elle a changé et qui l’a modifiée. Cet historique est une donnée, et il a besoin de sa propre décision de conservation.

Le suivi de l’historique des champs standard suit jusqu’à 20 champs par objet et garde les modifications jusqu’à 18 mois, et jusqu’à 24 mois uniquement par l’API, avec Data Loader ou queryAll() (Field History Tracking Overview (opens in a new tab), en anglais). Et pour les champs de texte long, il consigne seulement que le champ a été modifié, pas ce qu’il contenait : une lacune si ce sont vos preuves. Field Audit Trail, inclus dans Shield ou acheté seul, suit jusqu’à 200 champs par objet et garde l’historique jusqu’à ce que vous le supprimiez, dans une archive accessible par l’API (Field Audit Trail (opens in a new tab), en anglais). Ma position : l’historique standard des champs est la valeur par défaut ; utilisez Field Audit Trail quand une réglementation ou une obligation de conformité exige un historique plus long et prouvable. Pas parce que « l’audit, ça sonne bien ».

Auditer et surveiller, ce n’est pas la même chose

L’historique des champs répond aux questions sur les modifications de champs choisis. Les questions plus larges (qui s’est connecté, qui a exporté des données, quelles API ont été appelées, qui a consulté quoi) relèvent de la surveillance, et c’est Event Monitoring. D’après mon expérience, il est généralement nécessaire chez les clients les plus réglementés, et voici ma position la plus forte de ce chapitre : mettez-le en place avant d’en avoir besoin, et envoyez les événements à l’avance vers un référentiel, comme Splunk ou un autre SIEM.

Voici pourquoi. Les fichiers journaux d’événements sont conservés 1 jour sans le module complémentaire, et seulement pour certains types d’événements ; 30 jours par défaut avec Shield ou le module complémentaire Event Monitoring, et jusqu’à 365 jours si vous étendez la conservation (Event Monitoring FAQ (opens in a new tab), en anglais). Tout ce qui est plus ancien a disparu, sauf si vous l’avez exporté. Et les journaux payants ne peuvent être récupérés pour aucune période antérieure au début de votre contrat (même FAQ) : acheter le module complémentaire après l’incident ne fait pas revenir le passé. Alors l’une des pires conversations qu’un architecte puisse avoir est celle-ci : « Pouvons-nous voir ce qui s’est passé il y a six mois ? » « Non. » « Pourquoi ? » « Nous ne le capturions pas. » On ne veut pas tomber sur un problème et découvrir alors qu’on ne capturait ni ne stockait ces événements. À ce moment-là, la réponse a tout simplement disparu.

Click to enlarge

Mettez-le en place avant d’en avoir besoin.

Mais ne basculez pas dans « tout journaliser ». Qu’essayez-vous de prouver ? Quels événements comptent, qui en a besoin, pendant combien de temps, qui peut lire les journaux, et les journaux eux-mêmes pourraient-ils contenir des données sensibles ? Journaliser crée des données, et ces données ont aussi besoin de gouvernance. Et les preuves ont besoin d’un propriétaire : qui possède le référentiel, examine les alertes, vérifie que la conservation fonctionne, remarque que le flux a silencieusement échoué il y a trois mois ? Une technologie sans propriétaire n’est pas de la gouvernance ; nous revoilà au propriétaire, au data steward et au dépositaire du module 1.

Prouvez le contrôle, pas seulement la configuration

« Les données des destinataires ne sont accessibles qu’aux équipes affectées à l’arrêt. » Comment le savons-nous ? La configuration de sécurité montre ce qui devrait se passer. Les preuves opérationnelles (qui y a réellement accédé, des exports inhabituels, une intégration qui les extrait, des contrôles d’accès modifiés) montrent ce qui s’est passé. Une bonne gouvernance a souvent besoin des deux.

Au-delà de l’examen : ce que l’IA change. À mesure que les agents passent de la réponse à l’action, la gouvernance a besoin de preuves de ce que l’agent a vu, de ce qu’il a décidé ou généré et de ce qu’il a fait, ainsi que de qui ou quoi l’a lancé, sous quelle politique. Les mécanismes de journalisation changeront ; l’exigence, non : si une action autonome compte, concevez dès maintenant comment vous la reconstituerez plus tard.

Steve Trucking : le cycle de vie sur un seul champ

Prenez le numéro de téléphone du destinataire. Capturer : il arrive sur le manifeste du partenaire ; vérifiez qu’il est exploitable là où le processus en a besoin. Classer : donnée personnelle. Protéger : seuls les personnes et les systèmes qui en ont un besoin opérationnel le reçoivent, et les équipes ne le voient que pour leurs propres arrêts, le jour même. Utiliser : l’équipe coordonne la livraison ; la messagerie l’utilise pour une finalité approuvée ; un agent ne l’utilise que si la politique le permet. Conserver : aussi longtemps que le dit la politique métier et de protection des données approuvée. Supprimer ou désidentifier : quand cette durée se termine ou qu’une demande valide arrive, dans chaque copie du paysage. Auditer : garder la preuve que les contrôles et les actions ont eu lieu.

Prenez maintenant un code de centre de distribution. Capturez-le avec exactitude, classez-le comme donnée de référence non sensible, protégez-le avec un accès opérationnel ordinaire, utilisez-le largement, conservez-le selon les besoins du métier, et auditez les modifications si elles comptent. Même cycle de vie, contrôles différents. C’est à cela que sert la classification.

La gouvernance n’est jamais terminée

Une nouvelle réglementation apparaît. Un nouveau système ou une nouvelle intégration crée une copie de plus. Une équipe invente un champ de plus. Une nouvelle plateforme est mise en service. Un agent obtient un accès. Une règle de conservation change. Un nouveau partenaire distributeur arrive. L’architecture bouge, et la gouvernance bouge avec elle. Le but n’est pas des données parfaites, des contrôles infinis ou un document de gouvernance que personne ne lit. Ce sont des décisions délibérées sur les données, intégrées à l’architecture.

Ce qu’un architecte décide ici

• Quels contrôles de protection reçoit chaque catégorie de données, selon la classification, la politique et l’usage réel, y compris les compromis du chiffrement.
• Combien de temps les données et leur historique sont conservés, ce qui déclenche le compte à rebours, et ce qui se passe à la fin.
• Quand l’historique standard des champs suffit et quand une réglementation demande Field Audit Trail.
• Quels événements sont capturés, où les preuves sont stockées au-delà de la durée de conservation de la plateforme, et qui les possède.
• Comment l’architecture prouve après coup les actions importantes des personnes, des intégrations et des agents.

Ce chapitre a commencé par une idée : la gouvernance se conçoit dans l’organisation, elle ne s’écrit pas à côté. Les propriétaires fixent la politique et les architectes l’appliquent. Tenez les mauvaises données à l’écart là où cela compte. Sachez ce que signifient vos données, d’où elles viennent et à quel point elles sont sensibles. Respectez les lois, modélisez le consentement, contrôlez où vont les données personnelles. Protégez, conservez et supprimez selon la politique. Et capturez les preuves avant que quiconque ne les demande, car six mois après un incident, c’est un moment terrible pour découvrir que les preuves n’existaient que trente jours.

Pour aller plus loin

• Aide Salesforce, General Shield Platform Encryption Considerations (opens in a new tab) et Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Field History Tracking Overview (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Field Audit Trail (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (en anglais), consulté le 2026-10-14.
• Aide Salesforce, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (en anglais), consulté le 2026-10-14.