Philosophie

Pourquoi anonymiser ?

Un exposé factuel sur la manière dont les modèles cloud traitent vos données, sur les protections juridiques et techniques en place (et celles qui manquent), et sur la raison pour laquelle anonymiser avant d'envoyer est le seul contrôle qui reste entièrement entre vos mains.

Comment fonctionne un modèle cloud

Un modèle comme ChatGPT, Claude ou Mistral Le Chat n'est pas un logiciel qui tourne sur votre ordinateur. C'est un service distant. Votre question quitte votre machine, traverse Internet, atteint les serveurs du fournisseur, y est traitée, et une réponse vous revient.

L'interface peut être locale, le modèle ne l'est pas. Même si vous utilisez une application de bureau, une extension de navigateur ou un plugin d'IDE, le modèle ne s'exécute pas sur votre machine. Seule l'interface s'y exécute. Le calcul a lieu dans le cloud du fournisseur. Le terme « LLM local » désigne uniquement l'inférence sur votre propre matériel, via des outils comme Ollama ou llama.cpp.

Ce chemin a plusieurs conséquences souvent sous-estimées :

  • Le message est reçu en clair par l'infrastructure du fournisseur. Le chiffrement TLS protège le transit, pas la lecture côté serveur.
  • Il est en général journalisé à des fins de facturation, de détection d'abus, de débogage et d'amélioration du modèle.
  • Il peut être conservé pendant des semaines, des mois ou des années, selon la politique du fournisseur et les obligations légales qui le lient.

Les limites d'une promesse contractuelle

Partons de l'hypothèse la plus favorable : les grands fournisseurs (OpenAI, Anthropic, Google, Mistral et d'autres) veulent sincèrement protéger les données de leurs utilisateurs. Leurs politiques de confidentialité formalisent des engagements (« nous n'entraînons pas sur vos données API », « nous supprimons après 30 jours », « nous rejetons les requêtes abusives »), et ces engagements sont en général tenus.

Ce n'est pas suffisant, car un engagement contractuel peut tomber pour trois raisons distinctes, dont aucune ne relève de la mauvaise foi du fournisseur.

Un incident technique, un bug, une attaque

Aucune politique ne protège d'une erreur d'ingénierie ou d'une intrusion réussie. Deux cas suffisent à illustrer le propos.

Le 20 mars 2023, un bug dans la bibliothèque Redis utilisée par OpenAI a exposé les titres de conversations ChatGPT à d'autres utilisateurs pendant environ neuf heures. Pour environ 1,2 % des abonnés ChatGPT Plus actifs pendant cette fenêtre, des informations de paiement partielles (nom, e-mail, quatre derniers chiffres de la carte, date d'expiration) étaient également visibles depuis des comptes tiers. OpenAI a publié un post-mortem public reconnaissant l'incident.

En janvier 2025, des chercheurs de Wiz Research ont découvert qu'une base de données ClickHouse de DeepSeek était joignable sur Internet sans authentification. Plus d'un million de lignes de journaux étaient exposées, incluant des historiques de conversations, des clés API et des métadonnées d'infrastructure interne.

Dans les deux cas, les données ont fuité sans procès, sans injonction et sans intention malveillante de la part de l'entreprise. Un bug, une configuration oubliée, et le périmètre contractuel perd son sens.

Vos données utilisées pour l'entraînement

« Si c'est gratuit, c'est vous le produit. » Le vieil adage du web commercial s'applique aussi aux LLM. Faire tourner l'inférence sur un grand modèle coûte cher : chaque réponse mobilise des GPU en temps réel et le fournisseur paie cette facture à chaque requête. Pourtant, OpenAI, Google et d'autres proposent des paliers gratuits très généreux. Les raisons commerciales classiques (acquisition d'utilisateurs, effet de standard de fait) n'expliquent qu'une partie de ce modèle économique. Ces paliers gratuits alimentent aussi la collecte de données d'entraînement.

Sur les paliers gratuits grand public, vos conversations peuvent servir à améliorer le modèle de plusieurs façons : les retours explicites (pouce levé ou baissé, reformulation, régénération) servent de signal d'apprentissage par renforcement, les échanges peuvent être relus par des annotateurs humains pour identifier les modes d'échec, et le corpus complet des conversations peut servir de matière première pour construire les jeux de données des itérations suivantes.

Les offres payantes (API, ChatGPT Enterprise, Claude Team, etc.) excluent en général vos données de l'entraînement par défaut. Sur les paliers gratuits, en revanche, l'option de désinscription est souvent enfouie dans les paramètres, parfois désactivée par défaut, et la politique peut évoluer au fil du temps.

Une injonction judiciaire

Même quand le fournisseur veut supprimer vos données, un tribunal peut l'en empêcher.

Le 13 mai 2025, dans le cadre de son procès contre OpenAI, le New York Times a obtenu de la Magistrate Judge Ona T. Wang une ordonnance de conservation : OpenAI a été tenu de conserver chaque conversation ChatGPT et chaque appel API de ses clients, y compris ceux que l'entreprise aurait normalement supprimés selon sa propre politique. OpenAI s'est opposé publiquement à l'ordonnance en déposant une demande de reconsidération, rejetée en première instance, puis en interjetant appel devant le District Judge Sidney Stein, qui a rejeté l'appel en juin 2025. L'ordonnance a finalement été levée le 26 septembre 2025 (clôture formelle le 9 octobre), les utilisateurs de l'EEE, de Suisse et du Royaume-Uni ayant été exemptés de la mesure.

L'affaire ne s'est pas arrêtée là. Le 7 novembre 2025, la même Magistrate Judge a ordonné à OpenAI de remettre 20 millions de journaux ChatGPT pseudonymisés au New York Times à titre d'élément de preuve. OpenAI a déposé une demande de reconsidération, qui a été rejetée, puis a fait appel. Le 5 janvier 2026, le District Judge Stein a confirmé la décision, entérinant l'obligation de remise.

Cet épisode a deux conséquences pratiques. D'abord, la politique de confidentialité d'un fournisseur n'est jamais définitive : une décision judiciaire à laquelle vous n'êtes pas partie peut la réécrire, forcer la rétention, ou contraindre la remise massive de conversations à un tiers. Ensuite, la fenêtre d'exposition de vos données à une fuite ou à une attaque future s'élargit mécaniquement, et avec elle la probabilité qu'une autorité publique (américaine ou, par commission rogatoire internationale, étrangère) y accède.

Usages secondaires : ce que les données collectées rendent possible

Les sections précédentes expliquent comment les données quittent votre périmètre. Il reste à préciser ce qu'elles permettent une fois collectées. Trois usages, inégalement documentés, méritent d'être distingués pour ne pas mélanger un risque structurel et une pratique avérée.

Surveillance de masse

Une conversation avec un LLM ressemble techniquement à un e-mail ou à une discussion : du texte horodaté, attaché à un compte identifiable. Elle relève du même périmètre de collecte que les autres communications électroniques couvertes par FISA 702, renouvelé pour deux ans en avril 2024 par RISAA, et dont le renouvellement est de nouveau en débat au Congrès en avril 2026. Des rapports déclassifiés du PCLOB documentent plusieurs centaines de milliers de sélecteurs (identifiants de cible) actifs chaque année, et la collecte « about » (suspendue en 2017, puis ré-autorisée) élargit mécaniquement le périmètre à des communications qui ne sont ni adressées à la cible, ni envoyées par elle, mais qui la mentionnent.

Profilage et ciblage politique

L'inquiétude n'est pas spéculative ; elle repose sur des cas documentés de surveillance ciblée dans d'autres couches d'Internet.

  • Angela Merkel, octobre 2013 : les révélations Snowden documentent la surveillance par la NSA du téléphone portable de la chancelière allemande, listée comme cible depuis 2002.
  • Associated Press, 2012-2013 : le Department of Justice a saisi en secret, en avril-mai 2012, les relevés de plus de vingt lignes téléphoniques d'AP, dans le cadre d'une enquête sur des fuites.
  • Pegasus / NSO, 2021 : la coalition Forbidden Stories documente l'usage du logiciel espion Pegasus contre environ 180 journalistes ciblés, ainsi que des militants, avocats, diplomates et chefs d'État dans plus de 20 pays.

Ciblage commercial et courtiers en données

Le risque diffère des deux précédents : il ne demande ni juge, ni mandat. Il repose sur l'écosystème commercial qui entoure les fournisseurs, et se déploie en trois temps.

D'abord, une structure d'incitation. Plusieurs grands acteurs du LLM ont des intérêts adjacents dans la publicité ciblée : Google en fait son cœur de métier, Microsoft (gros actionnaire d'OpenAI) opère Bing Ads, Meta pousse son propre écosystème d'IA générative au sein d'un groupe dont la quasi-totalité du chiffre d'affaires vient du ciblage publicitaire.

Ensuite, l'état actuel des preuves. Aucune preuve aujourd'hui qu'un fournisseur ait revendu des conversations LLM à des courtiers en données. L'argument ne repose donc pas sur une pratique avérée mais sur un risque structurel : des données qui entrent dans un système, détenues par un acteur qui a un intérêt économique à les exploiter, peuvent en ressortir plus tard par des canaux qui n'étaient pas ceux annoncés au départ.

Enfin, la porosité documentée entre l'écosystème publicitaire et la surveillance. Un rapport du directeur du renseignement national daté de janvier 2022 et déclassifié en juin 2023 reconnaît que les agences de renseignement américaines achètent régulièrement des données commerciales auprès de courtiers en données, notamment des données de localisation et de navigation. Ce qui est collecté pour vendre de la publicité peut donc être racheté pour surveiller, sans mandat ni notification.

Pourquoi l'anonymisation casse ce graphe

Une donnée personnelle envoyée en clair devient un nœud dans un graphe potentiel : on peut la croiser avec des réseaux sociaux, des fuites antérieures, des registres publics ou des bases commerciales, pour ré-identifier, enrichir ou cibler. Un jeton de remplacement n'a aucune valeur d'agrégation. Anonymiser avant d'envoyer coupe la racine commune de chaque chaîne d'usage secondaire décrite plus haut.

Où vous placer sur le spectre des fournisseurs ?

Le choix n'est pas binaire entre « cloud américain » et « rien ». Il existe un continuum, du plus exposé au plus isolé, et chaque palier modifie à la fois le risque juridique et la part de responsabilité qui retombe sur vous.

OptionCLOUD Act / FISA 702RGPDAccès technique du fournisseurEntraînement sur vos données
Fournisseur US, serveurs USOui, directementIndirect, via DPF, fragileOuiVariable
Fournisseur US, serveurs UEOui (cf. Microsoft Irlande)S'applique, mais préemptéOuiExclu par défaut sur les offres entreprise
Fournisseur UENon (sauf filiale sous contrôle US)S'applique pleinementOuiExclu par défaut sur les offres payantes
Modèle local (auto-hébergé)NonVous en êtes responsableNon : vous êtes le fournisseurNon : vous le contrôlez

À une extrémité du spectre, un fournisseur américain hébergé aux États-Unis cumule les trois risques ci-dessus : le CLOUD Act, FISA 702 et le décret 12333 s'appliquent sans filtre, les transferts depuis l'UE reposent sur le Data Privacy Framework contesté, et une décision judiciaire américaine peut imposer la conservation indéfinie des conversations.

Déplacer physiquement les serveurs en Europe ne change presque rien sur le plan juridique. Dès lors que l'entité exploitante est sous juridiction américaine, le CLOUD Act s'applique, peu importe où sont les disques durs.

Changer de juridiction en passant à un fournisseur européen (Mistral, OVHcloud AI, Scaleway, Aleph Alpha) fait tomber par défaut le risque CLOUD Act, sauf si le fournisseur possède une filiale américaine sous contrôle. Le RGPD s'applique pleinement et les autorités européennes peuvent sanctionner. Cela ne rend pas le fournisseur aveugle au contenu : il garde un accès technique complet, la protection reste contractuelle et étatique.

Enfin, faire tourner le modèle en local sur votre propre infrastructure (Ollama, vLLM, llama.cpp ou équivalent) supprime le tiers de l'équation : aucun fournisseur n'a accès technique au contenu, par construction. C'est la protection maximale côté confidentialité. La contrepartie, c'est que toute la responsabilité bascule sur vous : sécurité physique et logique, chiffrement au repos, gestion des accès, mises à jour, journalisation.

Le choix du fournisseur reste important pour beaucoup de choses : latence, coût, qualité du modèle, conformité RGPD globale, écosystème d'intégration. Mais pour le risque spécifique de fuite de données personnelles, l'anonymisation neutralise ce choix. Si seuls des jetons quittent votre infrastructure, un fournisseur américain ne reçoit rien d'exploitable sur vos données sensibles.

Obligations sectorielles et choix déjà faits

Quand c'est une obligation légale

Dans plusieurs métiers, envoyer des données personnelles à un LLM non souverain n'est pas une question de confort, c'est une impossibilité réglementaire.

  • Finance : MiFID II, secret bancaire, obligations de confidentialité client.
  • Avocats : secret professionnel absolu (article 66-5 de la loi française du 31 décembre 1971). Une consultation client envoyée brute et identifiable à un LLM américain peut constituer une faute déontologique.
  • Médecine : secret médical (article L.1110-4 du Code de la santé publique), HIPAA aux États-Unis. Un dossier patient ne peut pas transiter par un service tiers sans garanties techniques lourdes.
  • Défense et secteurs stratégiques : régimes spécifiques (classification, CUI aux États-Unis, Diffusion Restreinte en France).

Ce que les grandes entreprises ont déjà tranché

Faute de protection technique disponible en 2023, plusieurs grands groupes ont simplement interdit à leurs employés d'utiliser les LLM cloud.

  • Samsung, avril 2023 : plusieurs incidents internes au cours desquels des ingénieurs avaient collé du code source et des notes de réunion dans ChatGPT. En mai 2023, l'entreprise a interdit l'usage des LLM génératifs sur les appareils professionnels.
  • Secteur bancaire américain, printemps 2023 : JPMorgan Chase, Bank of America, Citigroup, Goldman Sachs, Deutsche Bank et Wells Fargo ont bloqué ou restreint l'usage de ChatGPT pour leurs employés.

Ce que l'anonymisation ne résout pas

L'anonymisation est une couche dans une posture de défense en profondeur, pas une solution miracle.

  • Elle ne rend pas un LLM conforme à tous les régimes réglementaires. Certaines données (données de santé re-liables, matériel classifié défense) ne doivent pas quitter l'infrastructure, même sous forme anonymisée.
  • Elle dépend de la qualité du détecteur. Une donnée personnelle non détectée passe en clair. C'est un sujet d'ingénierie, pas un défaut conceptuel.
  • Elle ne remplace pas les autres bonnes pratiques : chiffrement au repos, journalisation auditée, gestion des accès, formation des équipes.