Anonymiser puis envoyer à une IA : pourquoi ça ne répond pas à la question

Le réflexe : masquer les noms, puis envoyer

L'approche est répandue et elle a de vraies qualités. Un filtre détecte les données identifiantes dans un texte, les remplace par des jetons, envoie le reste à un modèle en ligne, puis réinjecte les vraies valeurs dans la réponse. On garde l'accès aux meilleurs modèles du marché, on ne déploie aucune infrastructure, on paie à l'usage.

Pour beaucoup de cas d'usage, c'est un progrès net par rapport à l'envoi de données brutes. Le problème apparaît quand l'organisation a posé une exigence stricte : les données ne doivent pas quitter son réseau. Là, trois écueils se présentent.

Premier écueil : pseudonymiser n'est pas anonymiser

La distinction n'est pas cosmétique, elle est juridique. La CNIL définit la pseudonymisation comme un traitement qui empêche d'attribuer les données à une personne sans information supplémentaire, et précise qu'il reste bien souvent possible de retrouver l'identité des personnes grâce à des données tierces. Conséquence : les données pseudonymisées conservent un caractère personnel. Elles restent dans le champ du RGPD, avec toutes les obligations associées.

L'anonymisation véritable est un standard bien plus exigeant. Elle suppose que trois conditions soient réunies simultanément : il ne doit pas être possible d'isoler un individu, ni de relier entre eux des ensembles de données le concernant, ni de déduire de façon quasi certaine de nouvelles informations à son sujet.

Sur du texte libre, ces conditions sont presque impossibles à remplir. Un compte rendu de réunion contient des identifiants implicites qu'aucun filtre ne masque complètement : un âge, une pathologie rare, un service, une date, une chronologie d'événements, un contexte familial. La combinaison « personne de 47 ans, telle pathologie, tel service, telle date » suffit souvent à réidentifier. Ce que les outils appellent anonymisation du texte libre est, juridiquement, presque toujours une simple pseudonymisation.

Deuxième écueil : le chiffrement ne couvre pas le moment du traitement

Le chiffrement en transit et au repos est réel et utile. Mais il protège le trajet et le disque, pas le calcul. Pour transcrire ou résumer un texte, le modèle doit le lire en clair. À cet instant précis, la donnée est déchiffrée dans l'infrastructure du fournisseur.

L'autorité européenne de protection des données l'écrit explicitement dans ses recommandations sur les mesures supplémentaires : le chiffrement n'est pas suffisant lorsque le prestataire a besoin d'accéder aux données en clair pour les traiter. C'est exactement le cas d'un service d'IA en ligne.

Troisième écueil : la loi suit le fournisseur, pas le serveur

Une idée tenace veut qu'un hébergement « en région Europe » règle la question des lois extraterritoriales. Ce n'est pas le cas. Le rattachement se fait sur le fournisseur, pas sur la localisation physique des machines : un prestataire soumis au droit américain peut être contraint de communiquer les données qu'il détient, y compris stockées en Europe.

Les autorités européennes ont par ailleurs conclu qu'une injonction de ce type ne constitue pas une base juridique valable de transfert au sens du RGPD. Cela ne rend pas le fournisseur immunisé : cela crée un conflit de lois. Et le risque de conformité est porté par le responsable de traitement, c'est à dire par l'établissement client, pas par l'éditeur.

La vraie question n'est pas juridique, elle est architecturale

C'est le point décisif, et celui qu'on oublie le plus souvent. Quand une direction pose comme règle que ses données ne doivent en aucun cas transiter sur Internet, elle ne pose pas une question de qualification juridique. Elle pose une question de flux réseau.

Or envoyer un texte, même soigneusement expurgé, à une interface en ligne, c'est par définition faire transiter de la donnée sur Internet. L'exigence est franchie dès le premier octet émis, indépendamment de la question de savoir si cet octet est ou non une donnée personnelle.

Autrement dit, « anonymiser puis envoyer » répond à une question que l'organisation n'a pas posée, et échoue sur celle qu'elle a posée. Une exigence de ce type est une exigence d'architecture. La seule réponse qui y satisfait littéralement, c'est que le traitement s'exécute intégralement dans le réseau de l'organisation, et que rien ne soit émis.

Ce que l'anonymisation garde d'utile

Rien de ce qui précède ne disqualifie le masquage des données identifiantes. C'est une excellente pratique, à condition de la mettre à sa vraie place : une défense en profondeur à l'intérieur du périmètre, et non un laissez passer pour en sortir.

Masquer les identifiants dans un traitement qui tourne déjà sur votre infrastructure réduit l'impact d'une erreur de configuration ou d'un accès indu. Sur des données structurées ou des agrégats, une anonymisation véritable est parfois atteignable, et elle a alors toute sa valeur. La différence tient à l'ordre des opérations : on anonymise parce qu'on est prudent, pas pour se donner le droit d'exporter.

Amener le modèle à la donnée

Le renversement est simple à formuler : au lieu d'envoyer la donnée au modèle, on installe le modèle là où la donnée se trouve déjà. Le traitement s'exécute sur l'infrastructure de l'organisation. Il n'y a alors ni transfert, ni prestataire étranger, ni risque de réidentification hors du périmètre, ni conflit de lois.

Ce choix a un coût : il faut une machine et une solution conçue pour fonctionner hors ligne. En échange, la question de la conformité ne se gère plus, elle disparaît par construction. Pour une direction qui a posé « rien ne sort » comme une règle et non comme un souhait, c'est la seule réponse qui tienne.