Anonymisation, RGPD, AI Act : la conformité cachée de vos datasets

C'est l'erreur la plus répandue, et la plus lourde de conséquences. Remplacer les noms par des identifiants, hacher un numéro client, masquer un e-mail : beaucoup de data scientists appellent cela « anonymiser ». Le RGPD, lui, appelle cela pseudonymiser — et la nuance change tout.

La pseudonymisation consiste à traiter des données de telle sorte qu'elles ne puissent plus être attribuées à une personne sans information supplémentaire, conservée séparément. La table de correspondance existe encore quelque part. Conséquence juridique : la donnée reste une donnée à caractère personnel, et l'intégralité du RGPD continue de s'appliquer (base légale, durée de conservation, droits des personnes, sécurité, registre des traitements).

L'anonymisation, au sens du RGPD, est un standard bien plus exigeant : elle suppose qu'il soit impossible, par des moyens raisonnables, de ré-identifier la personne. Et seulement dans ce cas, la donnée sort du champ du RGPD. Le considérant 26 du règlement est explicite sur ce point.

L'enjeu pour vous est direct : un dataset que vous croyez hors RGPD parce qu'il est « anonymisé » peut, en réalité, être pseudonymisé et donc pleinement soumis au règlement. Vous exposez alors votre client — et potentiellement vous-même comme sous-traitant — à un manquement.

Comment savoir si un jeu de données est réellement anonyme ? Les autorités européennes de protection des données ont fixé une grille de lecture devenue la référence : une anonymisation n'est robuste que si elle résiste à trois risques de ré-identification.

• L'individualisation (singling out) : est-il possible d'isoler un individu dans le jeu de données ? Si un enregistrement, par sa combinaison d'attributs, ne correspond qu'à une seule personne, l'anonymisation échoue.
• La corrélation (linkability) : peut-on relier deux enregistrements concernant la même personne, au sein du jeu ou avec une source externe ? Le croisement avec des bases tierces est l'un des principaux vecteurs de ré-identification.
• L'inférence : peut-on déduire, avec une probabilité élevée, la valeur d'un attribut à partir des autres ? Un modèle peut « deviner » une donnée sensible même absente du jeu.

Des techniques comme la généralisation, l'agrégation, l'ajout de bruit (confidentialité différentielle) ou la k-anonymité visent à neutraliser ces risques. Mais aucune n'est magique : la ré-identification à partir de données « anonymisées » a été démontrée à de multiples reprises sur des jeux pourtant volumineux. La leçon pratique : traitez l'anonymisation comme une analyse de risque à documenter, jamais comme une case à cocher.

Tant qu'un doute raisonnable subsiste sur la possibilité de ré-identifier une personne, considérez le jeu comme pseudonymisé — et donc soumis au RGPD.

Supposons que votre dataset contienne bien des données personnelles. Première question, trop souvent éludée : avez-vous le droit de l'utiliser pour entraîner un modèle ?

Le RGPD repose sur deux piliers : toute donnée personnelle doit être traitée sur une base légale (consentement, contrat, obligation légale, intérêt légitime…) et pour une finalité déterminée. Or les données qui alimentent vos modèles ont presque toujours été collectées pour autre chose : gérer un compte client, exécuter une commande, assurer un service. Les réutiliser pour entraîner une IA constitue un nouveau traitement, qui doit franchir le test de compatibilité des finalités.

Plusieurs points de vigilance concrets :

• La finalité d'origine permet-elle l'entraînement ? Sinon, une nouvelle base légale, voire une nouvelle information des personnes, peut être nécessaire.
• Le dataset contient-il des données sensibles (santé, opinions, origine, biométrie) ? Leur traitement est par principe interdit, sauf exceptions strictes. Un modèle ne doit jamais ingérer ces catégories sans cadre juridique solide.
• La minimisation est-elle respectée ? Vous ne devez utiliser que les données strictement nécessaires à la finalité. Aspirer « toutes les colonnes par précaution » est un manquement.
• Le sous-traitant que vous êtes a-t-il un contrat conforme (article 28 du RGPD) avec le responsable de traitement ? Vos obligations de sécurité et d'instruction y sont définies.

En cas de manquement, les sanctions ne sont pas théoriques : le RGPD prévoit des amendes administratives pouvant atteindre 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. Et l'autorité de contrôle peut viser le responsable de traitement comme son sous-traitant.

Au RGPD s'ajoute désormais le règlement européen sur l'intelligence artificielle (AI Act), adopté en 2024 et dont l'application s'échelonne dans les années qui suivent. Pour un data scientist, ce texte n'est pas une abstraction : il introduit des obligations directes sur la façon de concevoir et d'entraîner les modèles.

L'AI Act raisonne par niveaux de risque :

• Les pratiques jugées inacceptables (notation sociale, certaines manipulations) sont interdites.
• Les systèmes dits à haut risque — par exemple ceux utilisés dans le recrutement, l'accès au crédit, l'éducation, certains domaines de la santé ou des infrastructures critiques — sont soumis à des exigences strictes.
• Les autres systèmes relèvent d'obligations de transparence allégées.

Pour les systèmes à haut risque, plusieurs exigences touchent directement votre cœur de métier : une gouvernance des données d'entraînement, de validation et de test (qualité, pertinence, représentativité), un examen des biais susceptibles de produire des discriminations, une documentation technique détaillée, une traçabilité (journalisation) et un contrôle humain. Autrement dit, des bonnes pratiques que beaucoup considéraient comme facultatives deviennent des obligations légales, assorties de sanctions propres.

Le biais algorithmique, en particulier, change de statut. Là où il relevait jusqu'ici de l'éthique et de la qualité, il devient pour les systèmes à haut risque une exigence de conformité : un modèle qui reproduit ou amplifie une discrimination mesurable peut engager la responsabilité du client comme la vôtre, sur le terrain réglementaire et sur celui de la non-discrimination.

Face à cet empilement RGPD + AI Act, quelques réflexes structurants protègent votre activité et celle de vos clients :

1. Cartographiez les données de chaque projet : nature, origine, finalité d'origine, présence de données personnelles ou sensibles, base légale. Avant toute ligne de code.
2. Documentez votre anonymisation comme une analyse de risque (individualisation, corrélation, inférence) plutôt que comme une simple suppression de colonnes.
3. Qualifiez le niveau de risque AI Act du système que vous construisez, et appliquez les exigences correspondantes dès la conception (privacy & compliance by design).
4. Tenez un dossier technique : provenance des données, mesures de qualité, tests de biais, choix de modélisation, limites connues.
5. Cadrez le partage des responsabilités avec le client par un contrat de sous-traitance conforme (article 28 RGPD), précisant qui est responsable de quoi.

Ce travail réduit fortement le risque de manquement, mais ne l'annule jamais : une faille, une ré-identification imprévue ou une notification de violation peuvent toujours survenir. La cyber-assurance pour data scientist intervient alors sur les conséquences d'une atteinte aux données — frais de notification, d'expertise, de gestion de crise et de défense, recours de tiers — là où une RC Pro classique s'arrête. Retrouvez l'ensemble des couvertures utiles à votre activité sur la fiche assurance data scientist.