PSEUDONOMIA est la référence de la pseudonymisation locale — et être la référence, c'est une conformité démontrée, article par article.
PSEUDONOMIA n'est pas un outil RGPD avec un sticker IA collé dessus. L'architecture — locale, signée, journalisée — répond article par article aux obligations du Règlement Général sur la Protection des Données ET du Règlement européen sur l'Intelligence Artificielle.
Depuis 2018, le RGPD encadre le traitement de données personnelles. Depuis 2024, l'AI Act ajoute un deuxième niveau d'obligations dès qu'un système d'intelligence artificielle intervient dans ce traitement.
PSEUDONOMIA utilise des modèles d'IA (reconnaissance d'entités nommées multi-recognizers spécialisés FR/UE) pour détecter automatiquement les informations identifiantes. C'est donc à la fois un traitement de données personnelles (RGPD) ET un système d'IA (AI Act).
Ce document liste, article par article, comment l'architecture de PSEUDONOMIA répond aux exigences. Le tout est opposable : chaque action est tracée par une chaîne cryptographique vérifiable hors-ligne.
La conformité de PSEUDONOMIA ne repose pas sur une déclaration. Elle repose sur quatre choix techniques structurels — vérifiables.
Aucune donnée ne quitte le poste de l'opérateur. Pas d'API externe, pas de télémétrie, pas d'auto-update. Pendant l'usage. Au repos. Jamais.
Chaque action sensible est signée cryptographiquement par l'identité opérateur (paire Ed25519 personnelle). Vérifiable hors-ligne. Toute modification est détectable.
Toute action sensible est enregistrée dans un journal append-only chaîné par hash, signé par opérateur, avec horodatage UTC. Démarrage de session, exports, décisions k-anonymité, supervision humaine, rotation de clés.
L'opérateur garde toujours la main sur les décisions de l'IA. Les détections sont proposées, jamais imposées : ajout, suppression, requalification. Chaque override est tracé.
Les principes du RGPD (Règlement UE 2016/679) ne sont pas de simples slogans. Chacun se traduit en obligation technique. Voici comment PSEUDONOMIA y répond directement.
« Les données à caractère personnel doivent être traitées de manière licite, loyale et transparente au regard de la personne concernée. »
La finalité (pseudonymisation à des fins de transmission externe) est documentée. L'opérateur déclare une identité personnelle obligatoire à l'onboarding — pas de traitement anonyme.
« Les données doivent être adéquates, pertinentes et limitées à ce qui est nécessaire. »
La pseudonymisation EST l'application littérale de ce principe : remplacer ce qui identifie par ce qui suffit à la finalité (un pseudonyme cohérent). Couplé à la k-anonymité, garantit que le doc décrit sans désigner.
« Le responsable du traitement est responsable du respect du paragraphe 1 et est en mesure de démontrer ce respect. »
Le journal scellé chaîné fournit la preuve technique opposable : chaque export documente la finalité, l'opérateur, la date, les paramètres utilisés, et est signé cryptographiquement.
« Le responsable met en œuvre les mesures techniques et organisationnelles appropriées (…) tant au moment de la détermination des moyens que lors du traitement. »
L'architecture locale + chiffrement de la table de correspondance (Argon2id + XChaCha20) + signature Ed25519 sont des mesures by-design, pas des add-ons. Aucun paramétrage "non-conforme" n'est techniquement possible.
« Chaque responsable tient un registre des activités de traitement effectuées sous sa responsabilité. »
Le Mode 3 « Pack RGPD » génère automatiquement le registre à partir des informations opérateur + DPO + journal scellé. Le Journal IA enrichit ce registre avec un volet « utilisation IA » détaillé.
« Le responsable met en œuvre des mesures techniques et organisationnelles appropriées (…) telles que la pseudonymisation et le chiffrement. »
Pseudonymisation cohérente (cœur produit) + chiffrement de la table par mot de passe dédié + chiffrement du vault opérateur (preferences.lpx) + signatures de toutes les preuves. Le RGPD nomme explicitement la pseudonymisation comme mesure technique recommandée.
« Lorsqu'un type de traitement (…) est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques, le responsable effectue une analyse de l'impact. »
Le Mode 3 RGPD inclut un template AIPD pré-rempli pour 7 personas sectoriels. Génération en .docx + .pdf signés en quelques clics, depuis l'app.
« La personne concernée a le droit d'obtenir du responsable du traitement la confirmation que des données la concernant sont ou ne sont pas traitées… »
Mode 2 (dé-pseudonymisation supervisée) permet de répondre à un droit d'accès en retrouvant l'identité originale liée à un pseudonyme. La table chiffrée conserve ce lien — réversibilité contrôlée par l'opérateur, opposable, signée.
Le Règlement européen sur l'IA (2024/1689) impose des obligations spécifiques aux systèmes d'IA, en particulier ceux utilisés sur des données personnelles. PSEUDONOMIA est conçu en conformité native — journal d'activité IA compris, livré et exportable en PDF signé.
« Les systèmes d'IA visés à l'annexe III sont considérés comme à haut risque. » L'annexe III pt. 1 vise notamment les systèmes utilisés pour identifier des personnes.
PSEUDONOMIA assume la qualification haut risque pour les modèles NER appliqués à des données personnelles, et respecte par conséquent les obligations art. 9 à 15. Aucun usage en boîte noire — toute capacité IA est documentée, paramétrable, supervisable.
« Un système de gestion des risques est établi, mis en œuvre, documenté et tenu à jour. »
Les recognizers sont versionnés, signés Ed25519, et leurs performances sont mesurées par banc public (corpus adversarial publié, F1 = 93,6 % au banc v1.0.0-rc.2). Politique de rollback documentée par tag git.
« Les jeux de données d'entraînement, de validation et de test (…) sont pertinents, suffisamment représentatifs, exempts d'erreurs autant que possible. »
Le corpus benchmark de 30 documents synthétiques FR (1025 entités annotées) est entièrement reproductible et public. Aucun document client n'entre dans l'entraînement. Les recognizers spécialisés FR/UE sont déterministes (regex + validation cryptographique type NIR Insee, IBAN mod-97, BIC ISO 9362, Luhn).
« Les systèmes d'IA à haut risque permettent l'enregistrement automatique des événements ("journaux") sur toute la durée du cycle de vie. »
Journal scellé déjà en place pour les actions sensibles (export, k-anon, projet, supervision). Le Journal IA ajoute une trace automatique par inférence : version des modèles, hash du document, métriques attendues, durée, opérateur. Chaîné, signé, vérifiable hors-ligne.
« Les systèmes d'IA à haut risque sont conçus de manière à ce que les déployeurs puissent interpréter les sorties du système. »
Chaque entité détectée affiche son type, sa confidence, le recognizer responsable. La documentation publique (cf. landings k-anonymité + pseudonymisation) explicite les capacités, limites et métriques. Aucune sortie n'est une boîte noire.
« Les systèmes d'IA à haut risque sont conçus de manière à pouvoir être contrôlés efficacement par des personnes physiques durant la période d'utilisation du système. »
UI dédiée à la revue avant export : Vue Liste + Vue Texte avec entités surlignées, popover d'action (supprimer / ajouter / requalifier). Le forçage k-anon en-dessous du seuil exige une confirmation explicite et est tracé. Le Journal IA enregistre chaque override comme événement distinct.
« Les systèmes d'IA à haut risque sont conçus pour atteindre, eu égard à leur destination, un niveau approprié d'exactitude, de robustesse et de cybersécurité, et fonctionner de manière constante. »
Métriques publiques : précision 95,4 %, rappel 95,5 %, F1 93,6 % (banc v1.0.0-rc.2, corpus publié). Tests de régression automatisés : plus de 4 800 backend + 1 900 frontend. Signature Ed25519 anti-tampering sur tous les artefacts. Aucune dépendance réseau réduit la surface d'attaque.
« Les déployeurs (…) tiennent les journaux générés automatiquement par leur système d'IA à haut risque pendant au moins six mois. »
Conservation locale par défaut configurable, minimum prévu à 24 mois (au-delà du seuil légal). Politique d'archivage chiffré en local au-delà de cette période. Le déployeur conserve la maîtrise complète — aucune dépendance LexLabs.
« Les fournisseurs de systèmes d'IA générant ou manipulant des contenus audio, image, vidéo ou texte veillent à ce que les sorties (…) soient marquées comme générées ou manipulées artificiellement. »
Chaque document expurgé contient en tête un bloc signé « PSEUDONOMIA · vX.Y · opérateur · date · signature Ed25519 » indiquant explicitement la manipulation IA. Les exports .docx / .pdf incluent cette mention dans le pied de page.
À quoi ressemble concrètement le journal scellé qu'un DPO peut vous demander ? Voici un extrait typique — chaque ligne est signée Ed25519 et chaînée à la précédente par hash.
● Actions déjà en place dans la version courante (export, kanon, sessions projet, supervision). ● Actions du journal IA (trace détaillée — inférence + sessions + overrides individuels), livrées.
L'extension du journal scellé pour répondre exactement aux obligations AI Act art. 12-14-26. Livré, journalisé dans la même chaîne scellée, exportable en PDF signé.
Modèle hybride à 2 niveaux : une entrée de synthèse par document traité + une entrée détaillée par décision humaine (override). Concentration de l'attention d'audit sur les décisions intéressantes.
ai.session.start / ai.session.end — bornes d'utilisation du systèmeai.inference.summary — un événement par document : versions de modèles utilisés, langue, taille, total d'entités par type, durée, OCR si applicableai.override.add / delete / relabel — chaque correction humaine de l'IA tracéeai.kanon.override — forçage en-dessous du seuil k, tracéCette extension ne remplace pas le journal existant — elle l'enrichit. Le format JSONL append-only chaîné reste identique, garantissant que la chaîne de tous les exports antérieurs reste valable et que la mise à jour est non rétro-incompatible.
Toutes les briques techniques qui rendent la conformité opposable. Toutes livrées.
Aucune connexion réseau pendant l'usage. Aucun pixel de télémétrie. Aucun appel API tiers. Aucun auto-update.
Paire de clés personnelle générée à l'onboarding. Signature de toutes les actions sensibles. Vérifiable hors-ligne sans serveur LexLabs.
Mot de passe dédié à l'export. Indépendant du mot de passe maître. Argon2id pour la dérivation, XChaCha20 pour le chiffrement.
JSONL append-only, hash SHA-256 chaîné, signature Ed25519 par opérateur. Verifier autonome standalone. Toute modification est détectable.
7 personas × 4 documents = 28 templates (AIPD, registre, mentions d'information, exercice des droits). Génération .docx + .pdf signés en 3 clics.
Chaque jeu de données de référence (countries, professions, BPE, INSEE…) est signé par la clé production LexLabs. Une signature invalide bloque le chargement.
Trace par inférence (modèle, doc, métriques) + par décision humaine (override). Réponse directe à AI Act art. 12 et art. 14.
Ajout automatique d'un volet « utilisation IA » au registre généré par Mode 3 RGPD. Couvre RGPD art. 30 + AI Act art. 26 simultanément.
Quand votre DPO interne, votre client, l'auditeur CNIL ou un avocat en contentieux demande la preuve — voici ce que PSEUDONOMIA produit, signé.
Les SaaS de pseudonymisation hébergés US/Cloud peuvent être techniquement performants — mais leur architecture leur impose une dette de conformité structurelle.
| Exigence | SaaS cloud | PSEUDONOMIA local |
|---|---|---|
| RGPD chap. V — transferts internationaux | DPA + SCC + Schrems II Transfer Impact Assessment | Aucun transfert — données restent sur le poste |
| RGPD art. 28 — encadrement sous-traitant | Contrat sous-traitant + audit annuel | Pas de sous-traitant cloud |
| RGPD art. 30 — registre | À rédiger soi-même | Auto-généré + signé + .pdf |
| RGPD art. 32 — pseudonymisation/chiffrement | Côté serveur — données en clair pendant traitement | Données jamais en clair hors poste — chiffrement local |
| RGPD art. 33 — notification de fuite | Si le fournisseur fuite, vous notifiez | Pas de fournisseur à fuiter |
| AI Act art. 12 — logging automatique | Selon les logs proposés par le fournisseur | Chaîné + signé localement par votre opérateur |
| AI Act art. 14 — supervision humaine | UI fournisseur — pas toujours documenté | UI dédiée + override tracé + signé |
| AI Act art. 26 — conservation logs ≥ 6 mois | Selon politique fournisseur (souvent payant) | Local, paramétrable, défaut 24 mois |
| Cloud Act US — saisie extra-territoriale | Applicable même si serveurs en Europe | Hors champ — pas de serveur US |
L'architecture technique répond aux obligations. Elle ne se substitue pas à la responsabilité humaine. Trois précisions importantes.
PSEUDONOMIA produit les preuves techniques. Le déployeur reste responsable au sens du RGPD (art. 24) et au sens de l'AI Act (art. 26). Désigner un DPO, tenir le registre à jour, former les utilisateurs : c'est votre rôle. PSEUDONOMIA vous outille — pas plus, pas moins.
Si l'opérateur efface intentionnellement le fichier sealed.log, un nouveau genesis démarre à zéro. Ce reset reste détectable par toute partie qui aurait conservé une entrée antérieure (la nouvelle chaîne ne pourra plus la produire). Pour un anti-reset fort (immutable storage côté OS), c'est en feuille de route v3.
Au sens RGPD, des données pseudonymisées restent des données à caractère personnel (Considérant 26). La k-anonymité (voir landing dédiée) renforce la protection mais ne transforme pas non plus en anonyme au sens strict. Pour aller plus loin, voir la doc utilisateur k-anonymité.
Pour le détail technique de la pseudonymisation et de la k-anonymité — fonctionnement, garanties, scénarios.