Peut-on envoyer les données de vos clients à une IA sans risquer une sanction RGPD ?

Une confusion revient sans cesse dans les projets IA que je croise : on me parle d'« anonymiser » des données avant de les envoyer à une IA, en pensant que ça suffit à sortir du RGPD. Dans l'immense majorité des cas, c'est faux — et cette confusion peut coûter cher.

La différence qui change tout

Anonymisation = des données rendues définitivement impossibles à relier à une personne. Une fois vraiment anonymisées, elles sortent du champ du RGPD.

Pseudonymisation = des données où l'identité est masquée, mais reste retrouvable via une clé séparée. Elles restent sous RGPD, avec toutes les obligations que ça implique.

Le problème : ce qu'on vous vend comme « anonymisation » est presque toujours, en réalité, de la pseudonymisation.

Pourquoi la vraie anonymisation est un mythe en pratique

Des chercheurs de l'UCLouvain et d'Imperial College London ont démontré qu'il est possible de ré-identifier précisément des individus au sein de bases de données présentées comme « anonymisées », grâce au machine learning. Ce n'est pas une hypothèse théorique : c'est un résultat de recherche publié.

Conséquence concrète : si un prestataire vous garantit une anonymisation totale et irréversible de vos données, exigez de comprendre comment — la réponse honnête, dans la plupart des cas, est qu'il s'agit en fait de pseudonymisation.

Ce qu'il faut exiger, concrètement

Plutôt que de chercher une anonymisation qui n'existe quasiment jamais, la bonne pratique est une pseudonymisation rigoureuse :

1. Remplacer les identifiants (noms, emails) par des identifiants aléatoires avant tout envoi à une IA
2. Stocker la table de correspondance ailleurs, chiffrée, avec un accès strictement limité
3. Ne jamais transmettre cette clé au fournisseur d'IA
4. Avoir un contrat de sous-traitance (DPA) signé avec ce fournisseur

Exemple concret : au lieu d'envoyer « Client n°5293, Alice Dupont, [données sensibles] », on envoie « ID uuid-a7f9-4e2b, [données sensibles] » — la clé qui permet de retrouver Alice reste chez vous, chiffrée, séparée du reste.

Le point qui piège le plus d'entreprises : le contrat avec le fournisseur IA

Un DPA (Data Processing Agreement) est obligatoire dès que des données personnelles sont traitées. Or la plupart des offres IA grand public n'en proposent pas.

Les plans gratuits ou individuels (ChatGPT Plus, Claude Pro, etc.) n'incluent aucun DPA — les utiliser avec des données de vos clients ou de vos salariés constitue un risque de non-conformité, quel que soit le soin apporté à la pseudonymisation en amont.

Et un DPA seul ne suffit pas non plus : il faut aussi documenter le traitement (registre article 30), réaliser une analyse d'impact quand le traitement le justifie, et former les équipes qui manipulent ces outils au quotidien.

Pourquoi prévoir un plan B compte autant que le choix initial

Dépendre d'un seul fournisseur IA pour un processus métier sensible (RH, santé, finance) est un risque en soi : un changement de conditions d'utilisation ou une suspension de compte peut bloquer votre activité du jour au lendemain, avec un coût de reprise en urgence bien supérieur à celui d'avoir prévu une alternative dès la conception.

C'est un principe que j'applique à chaque architecture que je construis : votre système doit rester réversible — capable de changer de fournisseur sans tout reconstruire — plutôt que de vous enfermer chez un seul prestataire dont vous dépendriez entièrement.

Mise à jour : un expert m'a corrigé publiquement, et il avait raison

Cet article a suscité la réponse détaillée d'un professionnel de la conformité IA au quotidien. Je choisis de la partager et de me corriger publiquement plutôt que de laisser passer une approximation, parce que c'est exactement le niveau d'exigence que j'applique avant de proposer quoi que ce soit à un client.

Trois corrections importantes :

1. Les données de santé demandent un hébergement spécifique. Mon exemple initial sous-estimait le sujet : traiter des données de santé exige un hébergement certifié spécifiquement pour ça (HDS), pas un hébergement cloud standard même conforme RGPD par ailleurs. Sans cette certification, pas de données de santé — quel qu'en soit le prix.
2. Un DPA ne garantit pas toujours un traitement 100 % européen. Certains fournisseurs présentés comme « européens » ne garantissent pas contractuellement que 100 % du traitement reste en Europe. Pour des données sensibles, il faut vérifier explicitement ce point plutôt que de se fier à la nationalité affichée du fournisseur.
3. L'analyse d'impact (AIPD) est trop souvent oubliée. Avoir un registre des traitements ne suffit pas : dès qu'un traitement présente un risque significatif (typiquement en RH), une analyse d'impact formelle est requise en plus.

Ce que cet expert m'a aussi rappelé, à juste titre : trop d'outils IA dans des secteurs sensibles (santé, RH) opèrent aujourd'hui dans une zone grise, en exposant les responsables finaux à des risques qu'ils ne mesurent pas toujours eux-mêmes. C'est précisément ce que je cherche à éviter : qu'un client découvre après coup qu'il portait un risque dont personne ne l'avait informé.

Ce que ça signifie pour votre projet

Si vous envisagez d'intégrer de l'IA dans vos processus métier avec des données de clients, de prospects ou de salariés, trois questions suffisent pour évaluer votre exposition : votre fournisseur a-t-il un DPA signé, vos données sont-elles réellement pseudonymisées avec une clé séparée, et avez-vous un plan si ce fournisseur change ses conditions demain ? Si une seule réponse est non, c'est le point de départ d'une mise en conformité — contactez-moi si vous voulez qu'on regarde ça ensemble.