Consentement, limitation des finalités et la muraille entre produits

Votre gestionnaire de prêt immobilier connaît vos revenus, votre historique de paiement et à quel point vous avez frôlé l'incident. L'unité de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit auto de la même banque adorerait disposer de ces données pour tarifer votre prochain crédit voiture. Légalement, dans la plupart des cas, elle ne peut pas y toucher. Non parce que les données ne seraient pas « les siennes », mais parce que elles ont été collectées pour une finalité et une seule : accorder et gérer votre prêt immobilier.

C'est la limitation des finalités, l'un des principes les plus discrets mais les plus exigeants opérationnellement du droit des données personnelles. Il ne demande pas « avez-vous la donnée ? » Il demande « le client a-t-il accepté cet usage précis ? » Pour une banque qui opère des dizaines de produits en retail, gestion de patrimoine, cartes et crédit, faire respecter cette question à grande échelle suppose de l'ingénierie réelle, pas une simple note de conformité.

La muraille juridique, en clair

La limitation des finalités signifie que des données personnelles collectées pour une finalité déterminée et explicite ne peuvent pas être réutilisées pour une finalité substantiellement différente sans nouvelle base légale (en général un consentement renouvelé, ou un autre fondement licite).

Dans l'UE/le Royaume-Uni, c'est directement codifié dans le RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète → (Règlement général sur la protection des données), article 5(1)(b). C'est l'un des principes fondamentaux de la protection des données, aux côtés de la minimisation des données et de la limitation de conservation. La version britannique post-Brexit, le UK GDPR, reprend ce principe.

Aux États-Unis, il n'existe pas de loi fédérale unique aussi large que le RGPD, mais la muraille existe quand même :

• Le Gramm-Leach-Bliley Act (GLBA, 1999) impose aux institutions financières de remettre aux clients un avis de confidentialité et, point clé, un droit d'opt-out avant de partager certaines informations personnelles non publiques avec des tiers non affiliés. Le partage entre les lignes de produits internes d'une banque relève des règles GLBA sur le partage entre affiliés et du Fair Credit Reporting Act (FCRA), qui restreint l'usage de certaines données (surtout celles issues des rapports de crédit) à des fins dépassant ce qui a été divulgué.
• Les lois d'État ajoutent des couches : le California Consumer Privacy Act (CCPA), mis à jour par le California Privacy Rights Act (CPRA), donne aux consommateurs le droit de limiter l'usage des données sensibles et de s'opposer à certains traitements.

Côté bancaire, les régulateurs qui font appliquer tout cela sont notamment le Consumer Financial Protection Bureau (CFPB) aux États-Unis et, dans l'UE, les autorités nationales de protection des données (DPA) coordonnées par le Comité européen de la protection des données (EDPB).

Pourquoi « on a déjà la donnée » n'est pas une défense

Une idée fausse répandue, même chez des banquiers expérimentés : dès lors que la donnée est « dans la banque », elle serait librement exploitable en interne. Les régulateurs rejettent ce raisonnement. L'unité crédit immobilier et l'unité crédit auto ont beau être la même entité juridique, **la *finalité* au titre de laquelle la donnée a été captée continue de la lier**.

Concrètement : si la demande de prêt immobilier d'un client révèle un ratio d'endettement, ce chiffre a été collecté pour instruire un crédit immobilier. L'injecter, sans consentement, dans un modèle de tarification de crédit auto peut violer :

1. L'avis de confidentialité d'origine remis au client (sujet GLBA et CCPA aux États-Unis).
2. Le principe de limitation des finalités du RGPD, dès lors qu'un client européen ou des données domiciliées dans l'UE sont concernés.
3. Les attentes en matière de fair lending, puisque des régulateurs comme le CFPB examinent si l'usage croisé non consenti affecte de façon disproportionnée des groupes protégés.

C'est aussi pourquoi le « consentement » n'est pas une case à cocher unique. Sous le RGPD, il doit être spécifique, éclairé et librement donné, et un consentement pour un prêt immobilier ne couvre pas automatiquement la vente croisée d'un crédit auto. Un opt-in distinct et clair est en général requis pour cette nouvelle finalité.

Comment la muraille s'intègre au pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète →

Les principes juridiques ne tiennent que s'ils survivent au contact des systèmes de production. Les banques opérationnalisent la limitation des finalités par le purpose tagging : des métadonnées attachées à la donnée au moment de la collecte, qui la suivent dans tous les systèmes en aval.

Une version simplifiée ressemble à ceci :

customer_data_record:
  customer_id: 88213
  field: "monthly_income"
  value: 7200
  source_purpose: "mortgage_underwriting"
  consent_id: "CNS-2024-0091"
  allowed_uses: ["mortgage_servicing", "mortgage_risk_reporting"]
  cross_product_use: false
  retention_expiry: "2031-06-01"

Tout système, modèle ou analyste interrogeant ce champ doit vérifier cross_product_use et allowed_uses avant de l'ingérer. Si l'extraction de données du modèle de tarification crédit auto ne filtre pas sur les purpose tags, elle risque d'ingérer silencieusement des données hors périmètre, exactement le mode de défaillance que cherchent les auditeurs.

Cela s'applique via :

• Des outils de data lineage qui tracent un champ depuis le système source jusqu'à chaque table, dashboard ou feature de modèle en aval (des outils comme Collibra ou Informatica sont courants en banque ; voir l'aperçu des cadres de gouvernance des données de l'OCDE pour le contexte réglementaire).
• Des plateformes de gestion du consentement (CMP) qui stockent quel identifiant de consentement autorise quel usage, et qui expirent ou révoquent l'accès en cas de retrait du consentement.
• Des couches de contrôle d'accès dans le data warehousedata warehouseUn référentiel central qui consolide les données de nombreux systèmes sources dans un stockage structuré et optimisé pour les requêtes, conçu pour l'analytique, le reporting et la business intelligence.Voir la définition complète → qui bloquent les requêtes joignant des tables de « domaines de finalité » différents, sauf enregistrement explicite d'un nouveau consentement.

Les contrôles et audits concrets

Pour une équipe de data governancedata governanceLa data governance est l'ensemble des politiques, rôles et processus qui garantissent que les données sont exactes, sécurisées, bien définies et utilisées de façon responsable dans toute l'organisation.Voir la définition complète →, la limitation des finalités n'est pas une politique ponctuelle, c'est un cycle d'audit récurrent. Contrôles types :

• Audit de couverture des purpose tags : quel pourcentage des champs de données clients dispose d'un purpose tag valide et non nul ? Les données legacy non taguées reviennent souvent dans les constats d'examens réglementaires.
• Monitoring des requêtes cross-domaines : journalisation et revue de toute requête joignant des données issues de deux finalités produit différentes (par ex. schémas crédit immobilier et crédit auto).
• Réconciliation consentement/usage : échantillonnage des features de modèles en production et traçage de chacune jusqu'à un enregistrement de consentement valide.
• Audits de features de modèles : pour tout modèle ML, une liste documentée de features rattachée à sa finalité autorisée, revue avant déploiement (recoupe le model risk management sous des cadres comme la directive SR 11-7 de la Fed aux États-Unis).
• Test de propagation du retrait : quand un client révoque son consentement, le champ est-il réellement exclu du prochain réentraînement batch du modèle, ou traîne-t-il dans un feature storefeature storeRéférentiel centralisé qui gère les features de ML et garantit la cohérence entre les environnements d'entraînement et de production.Voir la définition complète → en cache ?

Ce dernier point est celui sur lequel beaucoup de banques se font prendre. Un retrait de consentement enregistré dans un CRMCRMCustomer Relationship Management : logiciel et stratégie pour gérer et analyser les interactions clients tout au long de leur cycle de vie.Voir la définition complète → ne sert à rien si le feature store de machine learning se rafraîchit chaque semaine à partir d'un snapshot périmé.

Où cela se teste : cross-selling et open bankingopen bankingCadre réglementaire (PSD2 en Europe) obligeant les banques à partager les données clients via des API standardisées, avec consentement, transformant les données bancaires en actif compétitif.

Deux points de tension actifs en 2026 rendent le sujet très concret :

Analytics de cross-selling. Les banques veulent des vues client unifiées pour recommander des produits. C'est légitime, mais cela suppose en général un consentement distinct « marketing et vente croisée », séparé du consentement « gérer ce compte ». Construire une customer data platform (CDP) unique sans segmentation par finalité est un point de défaillance fréquent en audit.

Open banking et partage de données. Sous la DSP2 européenne (Directive sur les services de paiement 2) et son cadre successeur en cours d'évolution, ainsi que sous le régime Open Banking britannique, les clients peuvent autoriser des tiers à accéder à leurs données de compte via des API. Cela ajoute une couche : le consentement devient aussi directionnel (quel tiers) et limité dans le temps (les consentements expirent généralement et doivent être renouvelés, souvent tous les 90 jours selon les règles du UK Open Banking). Les États-Unis rattrapent leur retard avec la règle Section 1033 du CFPB, finalisée en 2024, qui exige elle aussi une autorisation spécifique à la finalité et révocable pour le partage de données.

🎬 [VIDEO: "GDPR Explained: Purpose Limitation and Data Minimization" - youtube.com/results?search_query=gdpr+purpose+limitation+explained - cherchez une courte vidéo explicative qui parcourt les principes de l'article 5 avec des exemples concrets, utile comme introduction avant de les appliquer aux flux de données bancaires]

Points clés

• La limitation des finalités signifie que des données collectées pour une finalité (instruction d'un crédit immobilier) ne peuvent pas être réutilisées pour une autre (tarification d'un crédit auto) sans nouvelle base légale, en général un consentement renouvelé et spécifique.
• Le socle juridique diffère selon les régions : article 5 du RGPD dans l'UE/le Royaume-Uni, GLBA et FCRA plus des lois d'État comme le CCPA/CPRA aux États-Unis, appliqués respectivement par les DPA/l'EDPB et le CFPB.
• L'application passe techniquement par le purpose tagging : des métadonnées sur chaque champ de données précisant ses usages autorisés, rattachées à un enregistrement de consentement, vérifiées avant tout usage cross-produit ou modèle.
• Les équipes de gouvernance doivent mener des audits récurrents : couverture des tags, monitoring des requêtes cross-domaines, réconciliation consentement/feature de modèle, et tests de propagation du retrait de consentement.
• De nouveaux points de tension, les CDP de cross-sell, l'open banking sous DSP2/UK Open Banking, et la règle américaine CFPB Section 1033, élargissent le périmètre où le consentement spécifique à la finalité doit être prouvé, pas présumé.