Vitalis Bien-être : données de santé, remise tarifaire et hébergement non certifié HDS

1. Qualification : ce sont des données de santé, même sans diagnostic. L'art. 4-15 vise les données relatives à l'état de santé physique ou mental, y compris celles dont la combinaison permet d'inférer cet état (considérant 35). La CJUE retient une conception large : des données en apparence anodines peuvent révéler un état de santé (arrêt du 4 octobre 2024, C-21/23, Lindenapotheke). Ici, les pas, le sommeil et la fréquence cardiaque croisés avec un questionnaire sur l'anxiété, l'alcool et les maladies chroniques ne laissent aucun doute : données de santé, donc art. 9.

2. Base légale : l'interdiction de principe s'applique. Art. 9-1 : interdiction, sauf exception. Sont exclues ici : 9-2-b (aucune obligation légale en matière de droit du travail ou de sécurité sociale ne fonde ce dispositif), 9-2-g (pas de motif d'intérêt public substantiel prévu par le droit), 9-2-j (ce n'est pas de la recherche). Reste le consentement 9-2-a, dont la validité est examinée à la question suivante.

3. Hébergement : l'HDS n'est pas une option commerciale. L'art. L.1111-8 du Code de la santé publique impose que l'hébergement de données de santé recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social soit assuré par un organisme certifié HDS, sur le périmètre certifié correspondant. Un cloud européen non certifié ne convient pas, même hébergé en France, même avec des garanties contractuelles. Il faut soit migrer vers un hébergeur certifié, soit démontrer que les données ne sont pas des données de santé - démonstration ici intenable.

4. SDK américain : double problème. Il emporte communication de données de santé à un tiers (sous-traitant ultérieur non autorisé, art. 28-2 et 28-3) et transfert hors UE (chapitre V). Un SDK intégré « sans paramétrage » collecte généralement plus que nécessaire : minimisation (art. 5-1-c) et privacy by design (art. 25) sont en défaut.

5. AIPD obligatoire. Traitement de données de santé à grande échelle (250 000 adhérents) : art. 35-3-b, et la liste CNIL. Si le risque résiduel reste élevé après mesures, consultation préalable de la CNIL (art. 36).

Le consentement est vicié dans sa liberté et dans sa spécificité.

• Liberté (art. 7-4, considérant 43) : le consentement n'est pas libre si le refus a des conséquences négatives. Une remise de 120 € par an sur un contrat d'assurance n'est pas un avantage accessoire : elle crée une pression économique réelle, surtout lorsqu'elle est conditionnée à un « bon score ». Le considérant 43 vise expressément le cas où le consentement est recueilli pour un contrat dont l'exécution dépend d'acceptations non nécessaires.
• Spécificité : une case unique agrège prévention, collecte de données de la montre, scoring et, à terme, tarification. Chaque finalité exige un consentement distinct.
• Preuve : l'absence de traçabilité par finalité affaiblit toute démonstration.

La tarification fondée sur la santé est le point le plus fragile. Utiliser un score de prévention pour moduler une prime revient à traiter des données de santé à des fins de tarification individualisée : cela heurte le principe de non-discrimination en raison de l'état de santé et l'esprit de mutualisation de l'assurance complémentaire. Le risque juridique (art. 9, art. 83-5) et le risque réputationnel sont supérieurs au bénéfice actuariel espéré. Recommandation : y renoncer et l'écrire dans la note à la direction.

Architecture alternative.

1. Programme de prévention sans contrepartie financière individuelle : accès libre, information, objectifs personnels, contenus.
2. Données restituées à l'adhérent, indicateurs agrégés et anonymisés pour la pilotage santé publique de la mutuelle (k-anonymat, seuils de restitution, pas de réidentification).
3. Consentements séparés : participation au programme / données de la montre / recherche interne / communication. Retrait aussi simple que l'acceptation, sans perte d'accès au contrat.
4. Refus explicite et documenté du partenariat agroalimentaire sur données de santé : la réutilisation à des fins commerciales est incompatible avec la finalité initiale (art. 6-4, test de compatibilité) et avec l'art. 9.

Bloquant (le lancement ne peut pas avoir lieu sans).

1. Hébergeur certifié HDS sur le bon périmètre, ou requalification démontrée des données - la seconde option n'est pas crédible ici.
2. AIPD complétée (art. 35), couvrant les données de santé, la montre connectée, le scoring et les tiers ; consultation de la CNIL si le risque résiduel reste élevé (art. 36).
3. Suppression ou encadrement du SDK américain : liste des finalités, minimisation, contrat de sous-traitance, analyse de transfert, ou remplacement par une brique maîtrisée.
4. Refonte du parcours de consentement : cases distinctes, aucune contrepartie financière individuelle conditionnée, preuve horodatée, retrait simple.
5. Abandon du scoring individuel et de la tarification santé dans le modèle.

Important mais non bloquant, à traiter avant ou juste après.

• Contrat de sous-traitance art. 28 avec le prestataire polonais, avec encadrement des accès et des sous-traitants ultérieurs.
• Registre des activités de traitement, politique de conservation (durée de vie des données de la montre, purge des questionnaires).
• Information en couches, lisible, sur les risques et les droits.
• Désignation d'un DPO si ce n'est pas déjà fait (traitement de données de santé à grande échelle).
• Cadre éthique : comité, avis sur le programme de prévention, transparence sur les indicateurs agrégés.

Réponse à la direction juridique. Le lancement au printemps est tenable si le périmètre est réduit (programme de prévention sans remise ni scoring). Il ne l'est pas si le modèle tarifaire est maintenu : dans ce cas, mieux vaut un report assumé qu'un lancement dont l'AIPD conclut à un risque élevé non maîtrisé, avec une base légale art. 9 contestable et un hébergement non conforme au Code de la santé publique.