Anonymat des modèles d'IA : le critère du RGPD n'a pas bougé, sa preuve devient une mesure. Par Laurent Souhy.

Le Règlement général sur la protection des données (RGPD) utilise un critère fixe pour juger de l’anonymat d’un modèle d’intelligence artificielle (IA) : une personne est considérée comme non identifiable si elle ne peut plus être reconnue, même indirectement. Ce critère n’a pas évolué depuis 2016. Cependant, ce qui change aujourd’hui, c’est la manière dont on doit prouver qu’un modèle respecte ce critère. Avant, une simple affirmation de la part d’un fournisseur suffisait souvent. Désormais, il faut démontrer cette absence d’identifiabilité, notamment face à des attaques visant à extraire des données personnelles. Le RGPD ne prescrit pas de méthode spécifique pour cette preuve, mais un avis du Comité européen de la protection des données (CEPD), adopté en décembre 2024, souligne que cette démonstration est souvent nécessaire pour conclure qu’un modèle est anonyme et donc hors du champ d’application du RGPD.

Pour répondre à ce besoin de démonstration, la Commission nationale de l’informatique et des libertés (CNIL), en partenariat avec trois autres organismes publics français, a lancé le projet PANAME (Privacy Auditing of AI Models). Ce projet vise à développer une bibliothèque logicielle en source ouverte (c’est-à-dire dont le code est accessible et modifiable) pour tester la confidentialité des modèles d’IA. Les quatre acteurs impliqués sont le PEReN (développement technique), l’ANSSI (expertise en cybersécurité), l’INRIA (direction scientifique) et la CNIL (pilotage et cadrage juridique). L’objectif est de créer un outil partagé permettant d’évaluer si un modèle d’IA peut être considéré comme anonyme, en simulant des attaques pour vérifier s’il mémorise des données personnelles.

Le considérant 26 du RGPD, depuis 2016, précise que l’anonymat se juge en fonction de l’état de la technique au moment du traitement. Cela signifie que ce qui est considéré comme anonyme aujourd’hui pourrait ne plus l’être demain, si de nouvelles méthodes d’identification apparaissent. Le considérant mentionne explicitement que l’anonymat doit être tel que la personne concernée ne soit pas ou plus identifiable. Cette notion souligne que l’évaluation de l’anonymat est dynamique et doit intégrer l’évolution des technologies. Par exemple, une base de données dont les identifiants directs ont été supprimés peut devenir identifiable si un croisement avec d’autres données devient possible.

Le RGPD repose sur un critère juridique : l’identifiabilité d’une personne. Ce critère n’a pas changé, mais la manière de l’évaluer évolue. Traditionnellement, les juristes se contentaient d’une qualification (affirmer qu’un modèle est anonyme). Désormais, ils doivent s’appuyer sur des mesures concrètes, comme des tests d’attaques simulées. Cette transition déplace le débat de la confiance envers un fournisseur vers l’examen d’un protocole partagé. Par exemple, une clause contractuelle affirmant qu’un modèle est anonyme devient vérifiable si elle peut être confrontée à des résultats obtenus via une bibliothèque logicielle ouverte et transparente.

Avant l’annonce du projet PANAME, une clause contractuelle affirmant qu’un modèle est anonyme était difficile à contester, car aucune méthode partagée ne permettait de la vérifier. Désormais, avec une bibliothèque logicielle en source ouverte, cette clause peut être testée et confrontée à des résultats concrets. Cela ne rend pas la clause fausse, mais elle devient datée : elle est vraie au regard des moyens techniques disponibles à un moment donné, mais susceptible d’être réexaminée si ces moyens évoluent. Par exemple, un modèle considéré comme anonyme en 2026 pourrait ne plus l’être en 2030 si de nouvelles méthodes d’attaque apparaissent. Cette évolution s’inscrit dans la logique du considérant 26 du RGPD.

La source ouverte de la bibliothèque logicielle est un élément central du projet PANAME. Un instrument de mesure fermé (dont le code n’est pas accessible) produit des résultats dont la fiabilité repose sur la confiance envers son développeur. À l’inverse, une bibliothèque en source ouverte permet à toutes les parties de vérifier la méthode utilisée pour obtenir un résultat. Pour les professionnels du droit, habitués à discuter la valeur probante d’un élément, cette transparence déplace le débat de la confiance envers un fournisseur vers l’examen critique d’un protocole. Cela renforce la rigueur des évaluations et limite les risques de manipulation ou d’erreur non détectée.

Le projet PANAME associe quatre organismes publics français, chacun avec un rôle spécifique. Le PEReN (Pôle d’expertise de la régulation numérique) est chargé du développement technique de la bibliothèque. L’ANSSI (Agence nationale de la sécurité des systèmes d’information) apporte son expertise en cybersécurité, notamment pour concevoir des scénarios d’attaques réalistes. L’INRIA (Institut national de recherche en informatique et en automatique) pilote la partie scientifique du projet. Enfin, la CNIL assure le pilotage global et le cadrage juridique. Ces rôles reflètent une approche collaborative et transparente, où chaque acteur contribue à un outil partagé et vérifiable.

À la date de l’article (25 août 2026), la bibliothèque logicielle développée dans le cadre du projet PANAME n’a pas encore été publiée. Aucune date officielle de sortie n’est indiquée sur les pages officielles de la CNIL ou de l’ANSSI. Un appel à manifestation d’intérêt pour la phase de test a été lancé du 26 février 2026 au 28 mars 2026, mais il est désormais clos. Les pages officielles ne précisent pas non plus les méthodes exactes qui seront utilisées pour tester les modèles, ni leur sensibilité. Ces informations restent à définir. L’absence de calendrier précis et de détails techniques ne remet pas en cause l’annonce du projet, mais elle limite les conclusions que l’on peut en tirer pour l’instant.

Pour les organisations qui entraînent ou déploient des modèles d’IA, l’article souligne une question technique et juridique clé : sur quoi repose l’affirmation d’anonymat d’un modèle, et à quelle date cette affirmation a-t-elle été établie ? Ces deux éléments sont rarement documentés de manière transparente. Par exemple, un fournisseur peut affirmer qu’un modèle est anonyme sans préciser si cette affirmation a été vérifiée via des tests ou si elle repose sur une simple hypothèse. L’absence de réponse claire à ces questions peut poser un risque juridique, notamment si le modèle est ultérieurement considéré comme non anonyme. L’article invite donc à exiger des preuves tangibles et datées, plutôt que des affirmations non étayées.