Pendant trois décennies, protéger les données personnelles revenait à maîtriser leur lieu de stockage et à contrôler qui pouvait accéder à la base. Les outils d'IA ont démantelé ce modèle en dix-huit mois environ.
Ce n'est pas une critique de l'IA. C'est le constat d'un basculement structurel — et le comprendre, c'est faire la différence entre une protection des données qui fonctionne vraiment et une protection qui fait bonne figure lors d'un audit de conformité mais qui s'effondre dès qu'un collaborateur ouvre une fenêtre de discussion.
L'ancien modèle — et les raisons de son efficacité
La protection classique des données personnelles a été pensée pour des données structurées : fiches CRM, dossiers patients, bases RH, grands livres comptables. La menace, c'était l'accès non autorisé — un attaquant ou un salarié non habilité atteignant des données qu'il n'était pas censé voir.
La parade était tout aussi structurée :
- Tokenisation et chiffrement au niveau du champ dans les bases : on remplace les numéros de sécurité sociale et les comptes par des jetons opaques au repos. Seuls les services habilités peuvent retrouver la valeur d'origine derrière le jeton.
- Contrôles d'accès par rôle : on limite quels salariés peuvent interroger quelles tables. Chaque lecture est journalisée.
- DLP réseau (prévention des fuites de données) : on analyse le trafic sortant à la recherche de motifs de données personnelles structurées — format de numéro de sécurité sociale, numéros de carte bancaire, motifs d'IBAN — et on bloque l'exfiltration avant qu'elle ne franchisse le périmètre de l'entreprise.
- Masquage des données dans les environnements hors production : on teste avec des données d'apparence réaliste mais générées synthétiquement, qui ne contiennent aucune identité réelle.
Cela fonctionnait parce que les données vivaient dans des emplacements connus et délimités. On pouvait recenser les systèmes contenant des données personnelles, ceinturer les couches de stockage et de réseau de contrôles, et ces contrôles tenaient face à la menace pour laquelle ils avaient été conçus.
Ce que les outils d'IA ont changé
La surface d'exposition s'est déplacée — non pas parce que les outils d'IA seraient peu sûrs, mais parce qu'ils ont ouvert un chemin nouveau et sans friction entre le stockage maîtrisé et le traitement externe.
Prenez le déroulé : un collaborateur ouvre SharePoint, télécharge un contrat au format PDF, ouvre ChatGPT et en colle le contenu. Il était habilité à consulter le document — aucun contrôle d'accès n'a été enfreint. Il n'a pas exfiltré de données au sens technique — il a utilisé un appareil approuvé sur le réseau de l'entreprise. Mais le document, avec chaque nom, chaque adresse et chaque montant qu'il contient, vient de transiter vers une infrastructure cloud commerciale dont l'organisation ne voit rien, qu'aucun contrat n'encadre, et dont il n'existe aucune trace journalisée.
L'outillage d'autrefois n'a aucune prise là-dessus :
- Le DLP réseau détecte les motifs structurés dans les téléversements de fichiers et les flux sortants, mais la plupart des interactions avec une IA se font sous forme de requêtes HTTPS POST vers une interface web — le proxy voit le domaine de destination, pas le contenu du corps du message.
- La tokenisation en base protège les données personnelles au repos. Au moment où l'utilisateur a téléchargé un PDF et le lit, les données ont déjà été extraites du coffre de jetons, reconstituées et affichées. Le système de jetons a fait exactement ce qu'on attendait de lui — il n'avait simplement pas été conçu pour l'étape suivante.
- Les contrôles d'accès ont été satisfaits à l'instant même où l'utilisateur habilité a ouvert le fichier. Ce qui se passe en aval de cet accès échappe à leur périmètre, par construction.
L'ancien modèle partait du principe que contrôler l'accès aux données revenait à contrôler ce qu'on en faisait. Les outils d'IA ont rompu cette hypothèse net. Accès autorisé plus fenêtre de discussion : voilà des données qui quittent l'organisation — discrètement, légalement (du point de vue du contrôle d'accès), et en volume.
Pourquoi le filtrage côté cloud ne suffit pas
Une réponse à cette faille consiste à faire transiter tout le trafic IA par un proxy d'entreprise qui intercepte les requêtes, recherche les données personnelles, les caviarde et transmet la version assainie. Cette approche existe et vaut mieux que rien. Mais elle se heurte à des limites structurelles :
- Elle suppose l'inspection SSL du trafic HTTPS — techniquement intrusive, coûteuse à exploiter, et de plus en plus contestée par les modèles de sécurité des navigateurs comme par les salariés au nom du respect de leur vie privée.
- Elle exige une configuration par outil d'IA. À mesure que la prolifération des outils d'IA s'accélère, la surface à configurer grandit plus vite qu'aucune équipe sécurité ne peut suivre. Un nouvel outil d'IA devient une faille à l'instant même où un utilisateur le découvre.
- Elle repère les motifs de données personnelles structurées (format de numéro de sécurité sociale, IBAN) mais peine sur les noms en clair, les adresses et les identifiants dépendant du contexte — qui constituent l'essentiel des données personnelles dans les documents professionnels.
- Elle ne peut rien contre le copier-coller depuis des applications hors du périmètre du proxy — appareils mobiles, machines personnelles, flux « hors ligne puis collé ».
Le filtrage côté cloud traite l'IA comme un canal à surveiller plutôt que comme un comportement à repenser. L'action de fond — un utilisateur qui extrait un contenu sensible d'un système maîtrisé pour le confier à un service externe — a toujours lieu. Le filtrage ajoute un ralentisseur au milieu du chemin. Il ne s'attaque pas à la racine.
La comparaison, en clair
Critère DLP classique Anonymisation côté clientLa bonne frontière : avant l'IA, sur la machine
L'intervention doit avoir lieu avant que les données ne quittent l'appareil de l'utilisateur — ni au périmètre du réseau, ni dans l'infrastructure du fournisseur d'IA une fois le mal fait.
Cela suppose un autre cadre de pensée. Au lieu de se demander « comment surveiller ce que les utilisateurs envoient aux outils d'IA ? », la question devient : « comment donner aux utilisateurs une version de leurs documents qu'il soit, par construction, sûr d'envoyer à n'importe quel outil d'IA ? »
L'idée clé, c'est que l'IA n'a pas besoin des identités pour faire son travail. Elle a besoin de la structure, de la langue et du contexte. « Alice Martin, née le 14 mars 1987, domiciliée 14 rue des Acacias à Lyon, référence client A-2091 » n'apprend rien de plus à un grand modèle de langage sur la clause contractuelle qu'on lui demande d'analyser. Retirez l'identité, gardez la clause. Le résultat de l'IA est tout aussi utile — et les données d'origine n'ont jamais quitté la machine.
Comment promptShield met cela en œuvre
promptShield s'exécute entièrement hors ligne sur l'appareil de l'utilisateur — aucune inférence dans le cloud, aucun appel réseau pendant l'anonymisation. Le pipeline de détection applique trois couches à chaque document :
- Expressions régulières — motifs structurés de haute précision : IBAN, numéro de sécurité sociale, courriel, téléphone, numéro de passeport et autres formats d'identifiants, dans 7 langues européennes. Elles s'activent en premier, avec une grande précision, sans nécessiter le chargement d'un modèle.
- Reconnaissance d'entités nommées — des modèles spaCy et transformer exécutés en local, qui détectent noms, adresses, organisations et dates en contexte. Une même entité revenant au fil des pages est reliée : anonymiser en page 1 la supprime automatiquement en page 4.
- Passe LLM optionnelle — pour les cas ambigus, un modèle GGUF exécuté localement tranche les détections limites sans envoyer la moindre donnée où que ce soit.
Chaque entité détectée est remplacée par un jeton typé et stable : [PERSON_1], [ADDRESS_2], [IBAN_1]. La correspondance entre le jeton et la valeur d'origine est conservée dans une base SQLite locale — le registre de jetons — qui ne quitte jamais la machine.
L'utilisateur colle le document anonymisé dans l'outil d'IA de son choix. L'IA produit son analyse à partir des jetons. Lorsque l'utilisateur veut reporter le résultat de l'IA sur le document d'origine, promptShield rétablit les valeurs réelles. Le déroulé analytique est inchangé. L'exposition, elle, est éliminée par construction.
Ce qui change, et ce qui ne change pas
L'anonymisation côté client comble une faille précise : le chemin sans friction d'un document maîtrisé vers un service d'IA externe. Elle ne remplace pas les contrôles d'accès, ne remplace pas la journalisation des audits, et ne dispense pas de former les salariés à un usage approprié de l'IA.
Ce qu'elle change, en revanche, c'est le modèle de risque pour ce cas d'usage précis. Dès lors que vous anonymisez avant de coller, la question « que se passe-t-il si un salarié utilise ChatGPT sur un document client ? » appelle une autre réponse. L'IA reçoit un contenu structuré — logique des clauses, ratios financiers, architecture du contrat — sans le moindre identifiant. Il n'y a plus rien à exposer.
L'ancien périmètre, c'était l'entrepôt de documents. Le nouveau périmètre, ce doit être le document lui-même — précisément à l'instant où il passe d'un système délimité à du texte libre entre les mains d'un utilisateur.
Cette frontière-là, le DLP classique n'a jamais été conçu pour la tenir. C'est pourtant celle qui compte désormais.
