+150 XP

Les règles de confidentialité qui encadrent l'usage des données clients par les assureurs

L'équipe de souscription d'un assureur vie veut utiliser le nombre de pas enregistré par le Fitbit d'un candidat pour tarifer un contrat. Un assureur santé veut acheter des scores de crédit pour prédire le risque de sinistre. Ces deux démarches sont légales dans certaines juridictions, encadrées dans d'autres, et purement interdites dans quelques-unes. La différence ne vient pas de la donnée elle-même. Elle vient du cadre réglementaire qui l'entoure, et se tromper sur ce cadre peut coûter des amendes, l'annulation de contrats, ou l'interdiction réglementaire d'un modèle de souscription entier.

Cette leçon parcourt les trois couches réglementaires qui gouvernent l'usage des données en assurance (RGPD, HIPAA et codes des assurances des États américains), puis présente les vérifications concrètes qu'une équipe data ou compliance effectue avant qu'une nouvelle source de données passe en production.

Pourquoi l'assurance est un cas particulier en matière de régulation des données

L'assurance fonctionne sur la discrimination, au sens statistique : faire payer des prix différents à des personnes différentes selon le risque. C'est le modèle économique. Mais les lois de la plupart des marchés développés interdisent aux assureurs de discriminer sur certains axes (l'origine ethnique, dans la plupart des cas la génétique, parfois l'état de santé) même si ces données amélioreraient la précision de la tarification.

Donc chaque nouvelle source de données qu'un assureur veut exploiter (wearables, données de crédit, réseaux sociaux, géolocalisation) doit passer deux tests :

  1. Est-il légal de collecter et d'utiliser cette donnée, tout simplement ? (droit de la protection des données)
  2. Est-il légal de l'utiliser pour cet usage précis, la tarification ou la souscription ? (droit des assurances)

Une donnée peut passer le test 1 et échouer au test 2, ou l'inverse. C'est pourquoi les assureurs conduisent des revues séparées : confidentialité d'un côté, équité de souscription de l'autre.

RGPD : le socle européen

Le RGPD (Règlement général sur la protection des données, texte européen applicable depuis 2018) fixe les règles de base pour toute entreprise traitant des données personnelles de résidents de l'UE, assureurs inclus. Les mécanismes clés en matière de souscription :

  • Exigence de base légale. Les assureurs ont besoin d'une justification juridique (consentement, nécessité contractuelle ou intérêt légitime) pour traiter toute donnée personnelle. Les données de santé sont classées en « catégorie particulière », ce qui exige un consentement explicite ou une exemption légale spécifique, pas un simple clic sur des conditions générales.
  • Article 22 : décision automatisée. Si une décision de tarification ou d'indemnisation est prise « exclusivement par des moyens automatisés » avec un effet juridique ou significatif comparable, le client a droit à une intervention humaine et à une explication. Cela contraint directement les algorithmes de souscription entièrement automatisés en Europe.
  • Minimisation des données. Les assureurs ne peuvent collecter que les données nécessaires à la finalité déclarée. Aspirer tout l'historique des réseaux sociaux d'un client pour tarifer un contrat santé échouerait probablement à ce test.

Les régulateurs chargés de l'application sont les autorités nationales de protection des données (DPA), comme la CNIL en France ou le BfDI en Allemagne. Les amendes peuvent atteindre 4 % du chiffre d'affaires annuel mondial pour les manquements les plus graves.

Effet pratique : un assureur européen qui veut utiliser les données de comptage de pas d'une application santé doit obtenir un consentement explicite et spécifique, expliquer comment la donnée influe sur la tarification, et permettre au client de refuser sans perdre le produit de base.

HIPAA : les données de santé aux États-Unis, plus étroit qu'on ne le croit

HIPAA (Health Insurance Portability and Accountability Act, 1996, loi fédérale américaine) est souvent mal comprise. Elle ne régule pas largement « les données de santé ». Elle régule les Protected Health Information (PHI) détenues par des « covered entities » précises : régimes de santé, professionnels de santé et leurs sous-traitants.

Implication clé pour les assureurs :

  • Les données de sinistres d'un assureur santé (diagnostics, traitements, facturation) sont des PHI et strictement encadrées : les partager à des fins marketing ou de souscription en dehors du régime de santé lui-même exige généralement une autorisation.
  • Mais les données issues d'une application santé grand public (Fitbit, Apple Health, MyFitnessPal) ne sont généralement pas couvertes par HIPAA si l'application n'est pas elle-même une covered entity. Ces données se trouvent dans une zone grise réglementaire, régie plutôt par la Federal Trade Commission (FTC) au titre du droit général de la consommation, et par les lois des États sur la vie privée.

C'est exactement ce qui rend l'exemple du comptage de pas intéressant : la même donnée (pas par jour) peut être protégée par HIPAA si elle circule via le programme de bien-être d'un régime de santé, ou pour l'essentiel non régulée au niveau fédéral si elle vient d'une application de wearable dont l'assureur a acheté l'accès auprès d'un courtier en données tiers.

Pour une explication en langage clair, la page de guidance HIPAA du HHS est la source de référence.

Codes des assurances des États américains : la couche propre à la souscription

Comme les États-Unis n'ont pas de régulateur fédéral unique de l'assurance (l'assurance est régulée État par État en vertu du McCarran-Ferguson Act de 1945), chaque département des assurances fixe ses propres règles sur les facteurs que les assureurs peuvent utiliser en souscription et en tarification.

Deux mécanismes comptent le plus :

  • Textes sur la discrimination abusive. La plupart des États interdisent la tarification fondée sur l'origine ethnique, et restreignent de plus en plus les scores d'assurance basés sur le crédit, les informations génétiques (renforcé au niveau fédéral par GINA, le Genetic Information Nondiscrimination Act de 2008) et, dans certains États, le genre.
  • Lois modèles de la NAIC. La National Association of Insurance Commissioners (NAIC) rédige des textes modèles que les États adoptent en tout ou partie. Le Model Bulletin 2023 de la NAIC sur l'usage de l'IA exige spécifiquement des assureurs recourant à des algorithmes ou à des données tierces (y compris des données alternatives comme les wearables ou les réseaux sociaux) qu'ils soient en mesure d'expliquer et de justifier leurs modèles auprès des régulateurs, et de tester l'impact disparate sur les classes protégées.
  • Interdictions propres à certains États. Le SB21-169 du Colorado (en vigueur depuis 2023) en est l'exemple le plus concret : il oblige les assureurs à tester toute source de données externe ou tout algorithme utilisé en souscription pour détecter une discrimination abusive fondée sur l'origine ethnique, et donne à la division des assurances de l'État le pouvoir d'exiger des mesures correctives. La Californie encadre le scoring de crédit en assurance auto et habitation bien plus strictement que la plupart des autres États.

Effet pratique : un score de crédit peut être un facteur de tarification parfaitement légal en assurance auto au Texas, restreint en Californie, et totalement interdit au Massachusetts pour certaines branches. Un assureur national a besoin d'un moteur de règles État par État, pas d'une politique nationale unique.

Vérification des acquis

1. Pourquoi l'assurance exige-t-elle à la fois une revue au titre du droit de la protection des données et une revue distincte au titre du droit des assurances avant d'utiliser une nouvelle source de données ?

2. Un assureur veut utiliser l'activité sur les réseaux sociaux pour tarifer des contrats auto. Quelle est la formulation la plus juste de la tension réglementaire de fond décrite dans la leçon ?

3. Au titre du RGPD, que doit établir un assureur avant de traiter les données personnelles d'un candidat de l'UE à des fins de souscription ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les bonnes réponses : pourquoi l'assurance est-elle traitée comme un cas particulier au regard de la protection des données et de la non-discrimination, comparée à beaucoup d'autres secteurs ?

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les bonnes réponses : quels scénarios illustrent l'idée de la leçon selon laquelle une même source de données peut être traitée différemment selon la juridiction et la finalité ?

Sélectionnez toutes les réponses correctes.

Les vérifications concrètes menées par une équipe data

Avant qu'une nouvelle source de données entre en production dans un modèle de souscription, une fonction mature de gouvernance des données en assurance déroule une checklist de ce type :

1. Audit de lineage et de consentement

D'où vient cette donnée ? Le consentement a-t-il été recueilli, et couvre-t-il ce cas d'usage précis (la tarification, et pas seulement la fourniture du service) ?

2. Test de limitation des finalités

La donnée a-t-elle été collectée pour cette finalité, ou pour une autre ? Utiliser les données d'une application santé collectées pour un programme de récompenses bien-être afin d'ajuster silencieusement la tarification d'une assurance vie échoue généralement au principe de limitation des finalités du RGPD et à de nombreuses règles de transparence des États américains.

3. Tests d'impact disparate

Même une variable « neutre » (code postal, score de crédit, schémas d'usage d'une application) peut agir comme proxy de l'origine ethnique ou du revenu. Les régulateurs exigent de plus en plus des assureurs qu'ils testent statistiquement leurs facteurs de tarification sur ce point. Une version simplifiée de ce contrôle :

python
# Vérification simplifiée du ratio d'impact disparate
# Règle empirique issue de la "four-fifths rule" de l'EEOC, adaptée au test des tarifs d'assurance

approval_rate_group_a = approved_a / applicants_a   # ex. groupe majoritaire
approval_rate_group_b = approved_b / applicants_b   # ex. classe protégée

impact_ratio = approval_rate_group_b / approval_rate_group_a

if impact_ratio < 0.80:
    print("Potential disparate impact: flag for fairness review")

C'est un premier filtre, pas une conclusion juridique. Les audits réels s'appuient sur des modèles statistiques plus rigoureux et sur une revue juridique.

4. Contrôle d'explicabilité

La décision de souscription peut-elle être expliquée à un régulateur et au client en langage clair ? Au titre de l'article 22 du RGPD et du bulletin IA de la NAIC, « le modèle l'a dit » n'est pas une réponse acceptable.

5. Audit des fournisseurs et des données tierces

Quand des courtiers en données fournissent des scores de crédit, des données de wearables ou des données sociales, les assureurs doivent auditer les pratiques de consentement et de collecte du fournisseur. L'assureur reste généralement responsable même si le manquement provient de l'amont.

Points clés

  • Test à deux couches : toute nouvelle source de données en souscription doit passer à la fois le droit de la protection des données (RGPD, HIPAA, lois des États) et le droit spécifique de l'assurance sur la discrimination abusive. Passer l'un ne veut pas dire passer l'autre.
  • HIPAA est plus étroit qu'on ne le suppose : elle couvre les régimes de santé et les professionnels de santé, pas la plupart des données issues des wearables ou applications de fitness grand public, qui relèvent de la supervision de la FTC et du droit des États.
  • Le RGPD donne aux clients européens un droit à explication sur les décisions de souscription automatisées (article 22), ce qui pousse les assureurs vers des modèles explicables plutôt que vers une IA purement boîte noire.
  • La régulation américaine de l'assurance est État par État : la même variable (score de crédit, code postal) peut être un facteur de tarification légal dans un État et interdit dans un autre, selon les lois modèles de la NAIC et les textes des États comme le SB21-169 du Colorado.
  • La gouvernance est un processus, pas une validation unique : contrôles de lineage, revue de limitation des finalités, tests d'impact disparate, revue d'explicabilité et audits fournisseurs doivent être menés chaque fois qu'une nouvelle source de données ou une mise à jour de modèle touche la tarification ou la souscription.