Consentement et chaînes de partage de données entre courtiers, réassureurs et prestataires

Maria souscrit une assurance vie auprès d'un agent indépendant dans l'Ohio. Dix-huit mois plus tard, un data broker dont elle n'a jamais entendu parler vend son score de risque santé à une agence marketing. Personne n'a rien piraté. Ses données ont simplement circulé, de l'agent à l'assureur, puis au réassureur, puis à un prestataire analytics, et à chaque transfert le consentement qui couvrait l'étape 1 a discrètement cessé de couvrir l'étape 4.

C'est la vie normale des données d'assurés dans l'assurance, et c'est là que se cache une part surprenante de l'exposition réglementaire et de la responsabilité.

Pourquoi les chaînes de données en assurance sont anormalement longues

Un seul contrat passe généralement par :

• L'agent, le producteur ou le courtier, qui collecte les données de la demande.
• L'assureur (carrier), qui souscrit et gère le contrat.
• Le réassureur, qui prend en charge une partie du risque et a besoin de données pour le tarifer et l'auditer. La réassurance est l'assurance des assureurs.
• Les prestataires tiers : gestionnaires de sinistres, sociétés de fraud analytics, fournisseurs de télématique, prestataires de dossiers médicaux (comme MIB Group aux États-Unis), et plateformes cloud/IA.

Chaque transfert est une relation juridique distincte, et le consentement donné au départ (le plus souvent une formule large enfouie dans le formulaire de demande) précise rarement ce qui se passe au troisième ou quatrième maillon. C'est le problème central de cette leçon : le périmètre du consentement ne suit pas les données par défaut.

La carte réglementaire à connaître

États-Unis :

• Aucune loi fédérale unique sur la confidentialité des données d'assurance. La régulation est au niveau des États, coordonnée de façon souple par la NAIC (National Association of Insurance Commissioners) via des lois modèles comme l'Insurance Data Security Model Law, adoptée (avec des variantes) dans la plupart des États en 2026.
• Les données de santé relèvent de HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (Health Insurance Portability and Accountability Act) lorsque les assureurs ou prestataires ont la qualité de covered entity ou de business associate.
• Les lois d'États sur la vie privée (le CCPA/CPRA californien, le Colorado, la Virginie et d'autres) s'appliquent de plus en plus aux données clients des assureurs, même si beaucoup excluent les données déjà encadrées par des règles propres à l'assurance.

Europe :

• 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) régit toute la chaîne. Le consentement est l'une des six bases légales de traitement, et l'article 28 impose un contrat écrit dès qu'un « responsable de traitement » (celui qui décide des finalités, par exemple l'assureur) transmet des données à un « sous-traitant » (celui qui traite sur instruction, par exemple un prestataire analytics).
• Les transferts hors UE/EEE vers des réassureurs ou prestataires exigent un mécanisme de garantie : décision d'adéquation, clauses contractuelles types (SCC) ou règles d'entreprise contraignantes.
• DORA (Digital Operational Resilience Act, en vigueur depuis janvier 2025) ajoute des obligations de gestion du risque ICT tiers, directement pertinentes quand des prestataires se trouvent loin dans la chaîne.

Régulateurs à connaître : dans l'UE, les autorités nationales de protection des données appliquent le RGPD (la DPC irlandaise, les autorités régionales allemandes) ; aux États-Unis, les commissaires aux assurances des États, plus la FTC sur le volet protection du consommateur.

Source primaire gratuite à mettre en favori : texte intégral du RGPD avec commentaire article par article (gdpr-info.eu).

Où le consentement casse vraiment : quatre transferts

1. Agent → Assureur

Le formulaire de demande comporte généralement une clause d'autorisation large (« J'autorise [l'assureur] à obtenir et partager des informations aux fins de souscription »). Problème : elle ne nomme presque jamais les réassureurs ou prestataires en aval, et les clients ne la lisent pas.

Vérification à mener : la clause d'autorisation nomme-t-elle des catégories de destinataires en aval (réassureurs, MIB, laboratoires), et pas seulement l'assureur ?

2. Assureur → Réassureur

Les traités de réassurance transfèrent de gros lots de données d'assurés (historique de sinistres, parfois détail médical) pour la tarification et l'audit. Sous le RGPD, il s'agit souvent d'une relation responsable-à-responsable (le réassureur décide de ses propres finalités), ce qui exige sa propre base légale, et non une base emprentée au consentement initial.

Vérification à mener : existe-t-il un accord de partage de données précisant la limitation des finalités et la durée de conservation, distinct des conditions commerciales du traité de réassurance ?

3. assureur/réassureur → prestataire analytics ou IA

C'est le maillon le plus risqué. Les prestataires qui font du scoring de fraude, du triage de sinistres ou des modèles de souscription reçoivent souvent des données granulaires, parfois ré-identifiables. Si le contrat du prestataire l'autorise à réutiliser les données pour améliorer ses propres modèles pour l'ensemble de ses clients, il peut devenir de fait responsable de traitement, ce que le consentement initial n'a jamais couvert.

Vérification à mener : audit des clauses contractuelles. L'accord limite-t-il l'usage à la mission précise, ou accorde-t-il des droits plus larges d'« amélioration produit » ?

4. Prestataire → Sous-prestataire (le cinquième maillon caché)

Hébergement cloud, équipes de labellisation offshore, ou une société d'analytics sous-traitante que le prestataire principal utilise discrètement. C'est là que se produisent la plupart des ruptures de la chaîne de consentement initiale, parce que personne au contrat d'origine ne l'a validé.

Vérification à mener : cartographie des quatrièmes parties : le prestataire déclare-t-il ses propres sous-traitants ? (L'article 28(2) du RGPD l'exige.)

Une vérification technique simple : le tagging de lineage des données

Un contrôle de gouvernance concret consiste à taguer chaque champ de données avec son périmètre de consentement et à propager ce tag dans tous les systèmes qu'il traverse. Pseudocode simplifié qu'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 → peut utiliser pour signaler les violations avant l'envoi d'un extract à un prestataire :

# simplified consent-lineage check before a data extract to a vendor
def check_consent(field, destination, consent_registry):
    allowed = consent_registry.get(field, {}).get("permitted_destinations", [])
    if destination not in allowed:
        raise ConsentViolation(
            f"{field} not authorized for transfer to {destination}"
        )

for field in extract_fields:
    check_consent(field, vendor_name, consent_registry)

Ce n'est pas de l'IA exotique, c'est de la gouvernance de métadonnées de base, et son absence est le constat le plus fréquent des audits de données en assurance.

La checklist d'audit (à quoi ressemble le « bon » niveau)

1. Inventaire des consentements : un registre reliant chaque élément de données à sa base de consentement et aux destinataires autorisés (exigé dans l'esprit par le registre des traitements de l'article 30 du RGPD).
2. Accords de traitement de données (DPA) avec chaque prestataire et réassureur, précisant finalité, conservation, déclaration des sous-traitants et obligations de suppression.
3. Contrôles de minimisation : le réassureur ou le prestataire a-t-il réellement besoin du nom et de la date de naissance, ou un score de risque désidentifié suffirait-il ?
4. Audits de conservation : les données d'assurance sont conservées des années (un sinistre peut ressurgir dix ans plus tard), mais « conservé parce qu'on pourrait en avoir besoin » n'est pas une base légale au sens du RGPD.
5. Préparation à la notification de violation : le RGPD laisse 72 heures pour notifier l'autorité compétente ; la loi modèle de la NAIC exige en général une notification « dès que possible », avec un plafond courant de 3 jours ouvrés dans les États l'ayant adoptée, les délais exacts variant d'un État à l'autre.

Qui porte la responsabilité quand ça dérape

Une idée fausse répandue veut que la responsabilité reste chez celui qui a causé la défaillance. En pratique :

• Sous le RGPD, le responsable de traitement (généralement l'assureur) est responsable de la défaillance d'un sous-traitant si le DPA était insuffisant, même si c'est le prestataire qui a causé la fuite.
• Sous la plupart des lois d'États américains sur la sécurité des données d'assurance (calquées sur le cadre NAIC), l'entité agréée (assureur ou courtier) porte l'obligation de déclaration réglementaire, et doit en principe démontrer qu'elle a exercé une due diligence sur ses prestataires tiers.
• Les réassureurs sont moins directement régulés sur la protection des données clients dans la plupart des juridictions, mais sont de plus en plus tenus par des clauses de traité exigeant un traitement équivalent au RGPD, en particulier sur les activités de réassurance liées à l'UE.

Implication pratique : externaliser le traitement des données n'externalise pas la responsabilité. C'est pourquoi les questionnaires de due diligence et les clauses de droit d'audit dans les contrats prestataires sont traités comme un contrôle de gouvernance, pas comme de la paperasse.

Points clés

• Le consentement ne suit pas automatiquement les données le long de la chaîne agent → assureur → réassureur → prestataire ; chaque transfert exige sa propre base légale ou sa couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.Voir la définition complète → contractuelle.
• Dans l'UE, la distinction responsable/sous-traitant du RGPD (article 28) détermine qui est responsable ; aux États-Unis, l'Insurance Data Security Model Law de la NAIC fait peser la charge de conformité sur l'assureur ou le courtier agréé, même quand la défaillance vient d'un prestataire.
• Le maillon le plus risqué est généralement les sous-traitants du prestataire lui-même (la « quatrième partie »), que les clauses de consentement initiales n'anticipent presque jamais.
• Contrôles pratiques : un registre de correspondance consentement-champ, des DPA obligatoires avec tous les réassureurs et prestataires, des revues de minimisation et des audits de conservation.
• Traitez la revue des contrats prestataires comme un exercice de data governance, pas comme une simple tâche achats : droits d'audit, déclaration des sous-traitants et clauses de limitation des finalités font la différence entre un incident gérable et une violation multi-juridictionnelle.