Les ID persistants ne sont pas anonymes : amende RGPD de 7 M€

Le 9 octobre 2026, le Comité européen de la protection des données (EDPB) a mis en avant une décision majeure de l'autorité italienne de protection des données (Garante per la protezione dei dati personali) : une amende administrative de 7 000 000 d'euros infligée à IQVIA Solutions Italy S.r.l. (Décision n° 710, Docweb 10302141). Pour les développeurs, directeurs techniques et fondateurs de startups IA en Europe, cette décision brise un mythe persistant : hasher un identifiant ou remplacer un nom par un jeton persistant ne crée pas de données anonymes au sens du RGPD.

En droit européen, tout identifiant persistant associé à des données de télémétrie, de diagnostic ou d'usage longitudinal constitue une donnée à caractère personnel pseudonymisée, et non une donnée anonyme. Traiter ces données comme anonymes prive les personnes de leurs droits, contourne les obligations de consentement, omet l'AIPD obligatoire et expose votre entreprise aux sanctions maximales de l'article 83(5) du RGPD pouvant atteindre 20 millions d'euros ou 4 % du chiffre d'affaires mondial.

---

Qu'a reproché l'autorité italienne à IQVIA ?

IQVIA exploitait une base de données de santé longitudinale (Longitudinal Patient Data, LPD) regroupant les dossiers médicaux d'environ un million de patients italiens via 800 médecins généralistes. IQVIA commercialisait ce jeu de données auprès de laboratoires pharmaceutiques en affirmant qu'il s'agissait de données anonymes de recherche.

Pour supprimer les identités directes, le logiciel des médecins attribuait à chaque patient un code persistant unique (Pat ID). Les informations directes (noms, numéros de sécurité sociale) étaient masquées lors de l'exportation.

Le Garante a rejeté cette argumentation sur plusieurs points déterminants :

1. Le suivi persistant empêche l'anonymisation : Un identifiant unique conservé sur plusieurs années permet d'agréger l'historique complet d'un individu. Croisé avec l'année de naissance, le sexe, la localisation et les dates d'ordonnances, cet identifiant permet d'isoler (singling out) une personne spécifique.
2. Moyens raisonnables de ré-identification : Le considérant 26 du RGPD impose de prendre en compte tous les moyens raisonnablement susceptibles d'être utilisés par un tiers. Un employeur, un assureur ou un tiers disposant d'informations externes peut croiser ces fichiers et ré-identifier les individus.
3. Fuite de données personnelles dans les champs de texte libre : Les médecins notaient des observations cliniques dans des zones de texte libre. Des noms complets, numéros de téléphone et codes fiscaux de 3 370 patients (dont 3 080 avec données médicales) ont été intégrés sans filtre ni masquage dans la base de données d'IQVIA.
4. Conservation illicite depuis 2001 : IQVIA conservait des dossiers de santé depuis plus de vingt ans sans politique de purge ni justification au titre de l'article 5(1)(e).

En plus de l'amende de 7 millions d'euros, le Garante a imposé une mise en conformité sous 120 jours sous peine d'interdiction totale de traitement.

---

Pourquoi les ID hashés et la télémétrie sont-ils légalement pseudonymes et non anonymes ?

Cette décision touche directement les architectures logicielles des éditeurs SaaS et des startups d'IA. Nombreux sont les ingénieurs qui affirment :

"Nous appliquons un hash SHA-256 sur l'user_id et supprimons l'adresse email avant d'envoyer nos logs d'événements vers notre base vectorielle ou notre data warehouse. Nos logs sont donc anonymes et échappent au RGPD."

Cette affirmation est juridiquement infondée.

Selon l'article 4(5) du RGPD, la pseudonymisation désigne le traitement de données personnelles de telle façon qu'elles ne puissent plus être attribuées à une personne concernée sans avoir recours à des informations supplémentaires. La donnée pseudonymisée demeure une donnée à caractère personnel.

L'anonymisation véritable, définie au considérant 26, requiert une irréversibilité totale. Ce n'est pas un masque appliqué sur une colonne, mais la destruction définitive de tout risque d'individualisation, de corrélation (linkability) et d'inférence. Si vous conservez une clé de corrélation persistante (hash utilisateur, identifiant machine ou cookie persistant), la corrélation subsiste. Le jeu de données reste donc intégralement soumis au RGPD et, le cas échéant, au Règlement sur l'IA.

---

Quelle documentation est obligatoire pour traiter des jeux de données longitudinaux ?

Si votre application exploite des métriques d'usage ou des logs utilisateurs sous pseudonyme, les autorités de contrôle exigent un dossier de conformité rigoureux :

1. Base légale explicite (Articles 6 et 9 du RGPD)

L'intérêt légitime de l'article 6(1)(f) ne s'applique pas aux données sensibles (santé, biométrie, opinions politiques). Le traitement de ces données exige un consentement explicite sous l'article 9(2)(a) ou une exception légale formelle.

2. Analyse d'impact relative à la protection des données (Article 35)

Le suivi de personnes à grande échelle, le traitement longitudinal de données sensibles et le profilage algorithmique rendent obligatoire la réalisation préalable d'une AIPD. L'absence d'AIPD a constitué l'un des manquements majeurs sanctionnés chez IQVIA.

3. Registre des activités de traitement (Article 30)

Tout flux de données pseudonymisées doit être consigné dans votre RAT, avec indication des finalités, des durées de rétention et des mesures de sécurité.

4. Contrats de sous-traitance (Article 28)

Si des partenaires ou des clients vous transmettent des données brutes, des contrats de sous-traitance conformes à l'article 28 ou des accords de responsabilité conjointe (article 26) doivent impérativement encadrer les flux.

---

Quelles sont les sanctions encourues pour fausse anonymisation ?

Traiter des données personnelles en feignant l'anonymat prive les personnes de leurs droits fondamentaux. Les CNIL européennes qualifient cette faute d'infraction substantielle :

| Type d'infraction | Article du RGPD | Amende maximale encourue | | :--- | :--- | :--- | | Principes fondamentaux du traitement | Article 5(1)(a), (e) | Jusqu'à 20 000 000 € ou 4 % du CA mondial | | Traitement illicite de données sensibles | Article 9(1) | Jusqu'à 20 000 000 € ou 4 % du CA mondial | | Défaut d'Analyse d'impact (AIPD) | Article 35(1) | Jusqu'à 10 000 000 € ou 2 % du CA mondial | | Manquement au Privacy by Design | Article 25(1) | Jusqu'à 10 000 000 € ou 2 % du CA mondial | | Sécurité insuffisante et fuites de données | Article 32(1) | Jusqu'à 10 000 000 € ou 2 % du CA mondial |

Si ces données alimentent un système d'IA à haut risque, les sanctions cumulées du Règlement sur l'IA peuvent s'élever jusqu'à 35 000 000 € ou 7 % du chiffre d'affaires (article 99).

---

Quelles mesures concrètes les équipes techniques doivent-elles prendre ?

N'attendez pas un audit client ou une mise en demeure. Appliquez sans délai ces quatre recommandations techniques :

1. Auditer les identifiants de télémétrie : Inspectez vos tables SQL, vos bases vectorielles et vos pipelines d'analytique. Requalifiez tout jeu de données articulé autour d'un hash persistant (user_id, device_token) en « données pseudonymisées » dans votre RAT.
2. Assainir les champs libres : Déployez des filtres automatiques d'expressions régulières et des modèles NER pour supprimer les noms, numéros de téléphone et coordonnées bancaires avant toute insertion en base.
3. Mener une AIPD sur vos pipelines de données : Documentez les risques de ré-identification, l'étanchéité des clés de chiffrement et les mesures de compartimentage via une AIPD formelle.
4. Purger les logs obsolètes : Mettez en place des cycles de purge automatique pour effacer irréversiblement les logs d'événements dépassant vos délais de rétention opérationnelle.

Évaluez vos obligations réglementaires avec notre Vérificateur de réglementation ou auditez vos systèmes d'IA grâce à notre Évaluateur de risque IA.

---

Avertissement : EuroComply fournit des outils de préparation à la conformité et des projets de documentation probante. Ce guide est publié à des fins purement informatives et ne constitue pas un conseil juridique, réglementaire ou de conformité. Les documentations techniques et évaluations doivent être validées par des conseils juridiques qualifiés.