Dossier de conformité RGPD de TokenVeil

Document destiné au DPO / RSSI du client. Version 1.0, à adapter au contexte de chaque déploiement.

TokenVeil est un proxy d’anonymisation auto-hébergé placé entre les collaborateurs d’une organisation et les modèles d’IA générative (Claude, Gemini, ChatGPT, Mistral…). Il pseudonymise les données personnelles et sensibles avant qu’un message n’atteigne le fournisseur d’IA, et restaure les valeurs réelles uniquement à l’affichage local. Ce dossier décrit comment TokenVeil s’inscrit dans les obligations RGPD de l’organisation qui le déploie.

1. Rôles au sens du RGPD

Acteur	Rôle	Justification
Organisation cliente	Responsable de traitement	Elle décide des finalités et des moyens (quels employés, quels usages de l’IA).
Éditeur de TokenVeil (Joopin’s Lab)	Fournisseur de logiciel, pas sous-traitant des données	Le logiciel est livré et exécuté sur l’infrastructure du client. L’éditeur n’a aucun accès aux données traitées, ni en exploitation, ni en télémétrie (voir §7).
Fournisseur d’IA (Anthropic, Google, OpenAI, Mistral…)	Sous-traitant ultérieur du client	Il reçoit uniquement des données pseudonymisées (voir §3). Le client garde son contrat/DPA existant avec ce fournisseur.

Point clé : TokenVeil n’introduit aucun nouveau sous-traitant dans la chaîne de traitement des données personnelles. L’éditeur ne voit jamais les données. Le seul flux sortant de l’instance est la vérification de licence (§7), qui ne transporte aucune donnée personnelle.

2. Nature du traitement réalisé par TokenVeil

TokenVeil réalise une pseudonymisation au sens de l’article 4(5) du RGPD : chaque donnée identifiante détectée est remplacée par un jeton neutre (<PERSON_1>, <IBAN_CODE_2>…). La correspondance jeton → valeur réelle (le « mapping ») :

est chiffrée au repos (chiffrement symétrique Fernet / AES-128-CBC + HMAC) ;
ne quitte jamais le périmètre réseau du client ;
n’est jamais transmise au fournisseur d’IA.

Terminologie rigoureuse : du point de vue de l’organisation cliente, il s’agit de pseudonymisation (la donnée reste réversible côté client, donc reste une donnée personnelle). Du point de vue du fournisseur d’IA, les données reçues ne sont pas ré-identifiables (il n’a aucun accès au mapping) : le risque de traitement de données personnelles par ce tiers est ainsi fortement réduit, voire supprimé pour les catégories correctement détectées.

3. Catégories de données détectées et pseudonymisées

TokenVeil détecte et remplace, par moteur NER (Presidio + spaCy) et motifs déterministes :

Identité : noms/prénoms, civilités, identifiants composites (user_jean_dupont).
Coordonnées : e-mails, téléphones (FR + international).
Identifiants nationaux : NIR (n° de sécurité sociale FR), IBAN, cartes bancaires, plaques d’immatriculation.
Données techniques identifiantes : adresses IP (publiques et internes), adresses MAC, hostnames, identifiants de session.
Secrets : clés API (AWS, GitHub, Stripe, Anthropic, OpenAI…), jetons JWT, mots de passe en clair, chaînes de connexion, blocs de clés privées PEM.
Données financières : montants de transaction contextualisés.
Termes métier personnalisés : noms de produits internes, codenames, définis par l’administrateur du déploiement.

Couverture mesurée : 0 % de fuite sur le jeu de test annoté et sur 5 500+ données générées aléatoirement (voir tools/benchmark_anon.py et la page de benchmark publique). Les catégories activées sont configurables par déploiement (interface admin).

Limite à documenter dans le registre : aucun système de détection n’est parfait. Un nom propre non reconnu par le NER dans un contexte ambigu peut échapper à la pseudonymisation. TokenVeil réduit le risque, il ne l’annule pas contractuellement : l’analyse d’impact (AIPD) doit en tenir compte.

4. Principes RGPD servis par TokenVeil

Principe	Article	Apport de TokenVeil
Minimisation des données	5(1)(c)	Seules des données pseudonymisées atteignent le fournisseur d’IA.
Protection dès la conception	25	La pseudonymisation est appliquée par défaut, avant tout envoi externe.
Sécurité du traitement	32	Chiffrement au repos du mapping, pseudonymisation en transit vers le tiers, contrôle d’accès (voir §5).
Limitation des transferts	44-49	La donnée réelle ne sort jamais du réseau client ; le transfert hors UE éventuel vers le fournisseur d’IA ne porte que sur des jetons non ré-identifiables.

TokenVeil est un outil au service de la conformité du responsable de traitement, pas une garantie de conformité en soi : la conformité globale dépend aussi des finalités, de l’information des personnes et des durées de conservation décidées par le client.

5. Mesures techniques et organisationnelles (art. 32)

Voir le détail dans security-measures.md. En résumé :

Chiffrement au repos : mapping de pseudonymisation, identifiants de comptes IA liés, mot de passe du compte de service LDAP, tous chiffrés (Fernet).
Authentification : comptes locaux (PBKDF2-HMAC-SHA256, 600 000 itérations) ou LDAP/Active Directory ; sessions stockées sous forme de hachage SHA-256 (le jeton en clair n’est jamais persisté).
Anti-force brute : verrouillage par compte et par adresse IP (anti-password-spraying).
Limitation de débit : garde-fou applicatif par utilisateur / clé API / IP.
En-têtes de sécurité HTTP : CSP stricte sans origine tierce, anti-clickjacking, HSTS derrière TLS.
Zéro dépendance CDN externe : toutes les ressources front (scripts, polices) sont servies localement : fonctionne en environnement isolé (air-gapped) et supprime le risque supply-chain.
Journal d’audit : trace qu’une pseudonymisation a eu lieu (catégorie + nombre d’occurrences), jamais la valeur réelle, le journal lui-même ne recrée aucun risque de fuite.
Exécution en moindre privilège : conteneur Docker non-root.

6. Conservation et localisation des données

Localisation : intégralement sur l’infrastructure choisie par le client (serveur on-premise ou cloud souverain FR/UE au choix). Aucune donnée n’est hébergée par l’éditeur.
Base de données : SQLite chiffrée applicativement pour les éléments sensibles, sur le disque du client.
Durée de conservation : entièrement maîtrisée par le client. Les conversations et leurs mappings peuvent être supprimés à tout moment depuis l’interface ; la suppression est définitive (mapping chiffré détruit → pseudonymisation irréversible).
Droit à l’effacement (art. 17) : la suppression d’une conversation efface le mapping ; les jetons résiduels éventuels deviennent alors non réversibles.

7. Flux sortants et absence de télémétrie

Le seul flux réseau initié par une instance TokenVeil vers l’extérieur est la vérification de licence (phone-home), qui transmet exclusivement :

l’identifiant de licence,
un identifiant d’instance anonyme (UUID généré localement),
le numéro de version du logiciel.

Aucune donnée personnelle, aucun contenu de message, aucune métrique d’usage n’est transmis. Ce flux peut être audité (trafic sortant unique vers l’URL du serveur de licences configurée). En cas de déploiement totalement isolé, la licence peut être fournie sous forme de fichier signé (Ed25519) sans phone-home.

8. Éléments pour le registre des traitements du client

À reporter dans le registre (art. 30) de l’organisation cliente :

Finalité : permettre l’usage d’outils d’IA générative par les collaborateurs sans exposer de données personnelles ou sensibles à des tiers.
Catégories de personnes : collaborateurs utilisateurs + toute personne mentionnée dans les contenus soumis (clients, prospects, patients selon le secteur).
Catégories de données : voir §3.
Destinataires : fournisseur(s) d’IA retenu(s), en données pseudonymisées uniquement.
Transferts hors UE : selon le fournisseur d’IA ; ne portent que sur des jetons non ré-identifiables.
Durée de conservation : définie par le client (voir §6).
Mesures de sécurité : voir §5 et security-measures.md.

9. Documents associés

security-measures.md : Mesures techniques et organisationnelles détaillées (art. 32).
DPA-template.md : Modèle d’accord de traitement, à adapter si l’éditeur fournit des prestations d’accompagnement.

Ce dossier est un support technique fourni de bonne foi. Il ne constitue pas un avis juridique. La conformité RGPD relève de l’appréciation du responsable de traitement et, le cas échéant, de son DPO.