RGPD, données sensibles et la porte du §5 — Cours — Académie

L'article 10 vit dans le RGPD. Un dossier signable tient sur une chaîne de bases légales — et sur la seule porte qui autorise à toucher le sensible pour mesurer un biais.

1Base légale, données sensibles

Réutiliser une donnée pour entraîner un modèle est un nouveau traitement : il lui faut une base légale RGPD · art. 6 et une finalité compatible avec la collecte initiale.

Les catégories particulières RGPD · art. 9 — origine, santé, opinions, religion, orientation, biométrie… — sont interdites de traitement, sauf exception. Or, pour vérifier qu'un modèle ne discrimine pas selon l'origine ou le sexe, il faut connaître l'origine ou le sexe.

Le RGPD prévoit lui-même des exceptions à cette interdiction art. 9(2) — dont le consentement explicite de la personne — distinctes de la porte spécifique ouverte par l'AI Act (§5) ci-dessous.

La porte étroite — art. 10 §5. L'AI Act autorise le traitement de données sensibles dans la mesure strictement nécessaire à la détection et correction des biais des systèmes à haut risque, avec des garanties : sécurité, limitation d'accès, pseudonymisation, pas de transmission, suppression une fois l'objectif atteint. C'est ce §5 qui rend un dossier de biais légal.

2Finalités, minimisation, durée, anonymisation

Les six bases légales

Tout traitement s'appuie sur l'une des six bases de l'art. 6 : consentement, exécution d'un contrat, obligation légale, intérêt vital, mission d'intérêt public, intérêt légitime (mis en balance). La « rentabilité » n'en est pas une. En RH, le consentement est fragile : le lien de subordination fait douter de son caractère « librement donné ».

Finalité et réutilisation

Réutiliser une donnée pour un nouvel usage suppose une finalité compatible avec la collecte initiale (test de compatibilité) ou une nouvelle base. Recycler un CRM marketing vers un modèle RH est un changement de finalité à instruire — pas un détail technique.

La licéité en amont. Une collecte sans base légale contamine tout ce qui en découle : la performance du modèle ne régularise pas l'illicéité. Un régulateur peut exiger la suppression des données — voire du modèle qui en est issu.

Minimisation et durée

Minimisation : n'inclure que ce qui est nécessaire et pertinent à la finalité (un numéro de sécurité sociale n'a rien à faire dans un tri de CV). Ne pas « tout garder au cas où ».
Limitation de la durée : on conserve le temps nécessaire, puis on supprime. Le sensible traité au titre du §5 se supprime une fois l'objectif de mesure du biais atteint.

Pseudonymisation ≠ anonymisation

Pseudonymiser (remplacer les identifiants par des codes) laisse la donnée personnelle — la ré-identification reste possible — donc dans le RGPD. Seule une anonymisation irréversible (ré-identification impossible) fait sortir du RGPD… mais elle est difficile à garantir réellement.

3Rôles et droits des personnes

Qui répond de quoi

Responsable de traitement — détermine les finalités et les moyens.
Sous-traitant art. 28 — agit pour le compte du responsable, sur instruction documentée ; il assure la sécurité et n'engage pas de sous-traitance ultérieure sans autorisation. Il ne décide pas des finalités.
Responsables conjoints art. 26 — codéterminent finalités et moyens ; ils répartissent leurs responsabilités.

Les droits des personnes

Accès, rectification, effacement (sous conditions — pas absolu : des exceptions existent), opposition… En revanche, il n'existe pas de « droit de veto absolu » sur tout entraînement d'IA.

L'in-place, du point de vue RGPD. Quand la donnée reste chez le client (seules des métadonnées sortent), l'opérateur agit en sous-traitant, rien de brut n'est transmis à un tiers, l'exposition est réduite : minimisation et sécurité en sortent renforcées.

4AIPD et transferts hors UE

L'analyse d'impact (AIPD)

Quand un traitement présente un risque élevé — nouvelles technologies, profilage à grande échelle, données sensibles — une AIPD art. 35 est obligatoire, en amont. Un système d'IA à haut risque la déclenche presque toujours.

Sortir les données de l'UE

Un transfert hors UE exige une base de transfert chapitre V : décision d'adéquation, clauses contractuelles types, etc. Ce n'est ni libre, ni interdit par principe. Un prestataire qui propose d'envoyer les données vers un cloud hors UE « pour accélérer » soulève cette question — et sort de la logique in-place : à encadrer fortement ou à refuser.