PSEUDONOMIA est la référence de la pseudonymisation locale — et être la référence, c'est appliquer les règles de l'art, pas les réinventer.
La promesse est partout la même : « masquez vos documents avant de les confier à l'IA ». Mais la plupart de ces services commencent par vous faire faire l'inverse exact de ce que le RGPD exige : téléverser vos documents, en clair, sur le serveur d'un tiers. Voici la grille — article par article — qui distingue une pseudonymisation dans les règles de l'art d'un simple masquage en ligne.
Pour « protéger » vos données, on commence par vous demander de les envoyer.
Suivez le trajet d'un document dans un service de pseudonymisation en ligne : vous téléversez le fichier en clair — noms, adresses, NIR, IBAN, tout — sur le serveur de l'éditeur. Le masquage a lieu là-bas. Puis le document « protégé » vous revient.
Juridiquement, il s'est passé trois choses avant la moindre protection :
Pour un professionnel soumis au secret — avocat, expert judiciaire, médecin, commissaire de justice — ce n'est pas une nuance : c'est souvent rédhibitoire avant même d'ouvrir le RGPD (secret professionnel, secret de l'instruction, secret médical).
La pseudonymisation n'est pas un concept marketing. C'est un terme défini par la loi, précisé par le régulateur européen, outillé par l'ENISA.
L'article 4(5) du RGPD la définit : un traitement tel que les données ne puissent plus être attribuées à une personne « sans avoir recours à des informations supplémentaires, pour autant que ces informations supplémentaires soient conservées séparément et soumises à des mesures techniques et organisationnelles ». Les lignes directrices EDPB 01/2025 et les travaux de l'ENISA sur les techniques de pseudonymisation en tirent des exigences concrètes. Cinq sont structurantes :
Les « informations supplémentaires » (la table de correspondance pseudonyme ↔ identité) doivent être conservées séparément des données pseudonymisées, sous mesures techniques et organisationnelles dédiées.
RGPD art. 4(5) · EDPB 01/2025Chiffrement, contrôle d'accès, maîtrise exclusive : si la table est lisible par un tiers — ou si elle circule dans un simple fichier — toute la construction s'effondre.
RGPD art. 32(1)(a)Retirer les noms ne suffit pas : âge + commune + profession peuvent réidentifier. Les règles de l'art exigent d'évaluer la réidentification par les moyens raisonnables, dans le contexte réel.
Considérant 26 · EDPB 01/2025Un procédé réversible est une pseudonymisation — les données restent personnelles (considérant 26). L'appeler « anonymisation » est juridiquement inexact et prive le client d'un consentement éclairé sur le risque réel.
RGPD cons. 26 · EDPB 01/2025Le responsable de traitement doit pouvoir démontrer sa conformité : qui a pseudonymisé quoi, quand, avec quel réglage, qui a réidentifié, sur quelle justification.
RGPD art. 5(2) · art. 24 · art. 30L'article 25 impose la protection dès la conception et par défaut — et cite nommément la pseudonymisation. Une protection qui dépend de la bonne conduite d'un serveur tiers n'est pas « par conception » : elle est par procuration.
RGPD art. 25(1)Même promesse en vitrine, deux architectures irréconciliables derrière.
| Exigence des règles de l'art | Outil de pseudonymisation en ligne | PSEUDONOMIA |
|---|---|---|
| Où vont vos documents ? | Téléversés en clair sur les serveurs de l'éditeur | Ne quittent jamais votre machine — l'application n'exige aucune connexion réseau |
| La table de correspondance (art. 4(5), 32) |
Générée côté serveur, restituée dans un fichier — à vous de la protéger | Coffre chiffré local, mot de passe de l'opérateur, aucune copie chez l'éditeur — pas de porte dérobée, par choix assumé |
| Sous-traitance (art. 28, 30) |
Un sous-traitant de plus : DPA à signer, chaîne à auditer, registre à tenir | Aucun sous-traitant introduit : le traitement reste intégralement chez le responsable de traitement |
| Violation de données (art. 33-34) |
Une fuite serveur de l'éditeur devient votre notification CNIL | Pas de serveur, pas de copie tierce : la surface de violation liée à l'outil est nulle |
| Transferts hors UE (chap. V, art. 44 s.) |
À vérifier à chaque étage (hébergeur, sous-traitants ultérieurs, support) | Sans objet : rien ne transite, il n'y a pas de transfert |
| Mesure du risque résiduel (cons. 26, EDPB 01/2025) |
Aucune métrique : des entités masquées, sans évaluation du contexte | Paliers de k-anonymat calculés sur les populations nationales réelles (INSEE, US Census, ONS, Destatis, ISTAT, INE), affichés avant export |
| Réidentification (art. 5(2)) |
Quiconque détient le fichier de clés restaure tout, sans trace | Dé-pseudonymisation supervisée par l'opérateur, journalisée action par action |
| Preuve dans le temps (art. 5(2), 24) |
Au mieux un log applicatif, chez l'éditeur | Journal scellé sur votre machine : chaque action horodatée, infalsifiable, exportable pour DPO, auditeur ou contentieux |
| Cohérence sur un dossier (qualité du résultat) |
Document par document : la même personne change de masque d'une pièce à l'autre | Mode projet persistant breveté (INPI FR2607944) : pseudonymes cohérents sur toutes les pièces, dans la durée |
| Vocabulaire (cons. 26) |
« Anonymisation » — pour un procédé réversible | Pseudonymisation, dite comme telle — jusque dans nos audits |
La jurisprudence européenne récente rend la rigueur d'exécution encore plus payante — et le bricolage encore plus coûteux.
Dans l'affaire EDPS / SRB (CJUE, 4 septembre 2025, C-413/23 P), la Cour de justice a consacré une approche relative de l'identifiabilité : pour savoir si des données pseudonymisées sont des données personnelles entre les mains d'un destinataire, on regarde les moyens dont ce destinataire dispose raisonnablement pour réidentifier — pas ceux de l'émetteur.
Traduit pour votre pratique : si votre IA ne reçoit que des documents rigoureusement pseudonymisés, et que la table de correspondance n'a jamais quitté votre machine, vous êtes en position de soutenir que le destinataire ne traite pas de données identifiables. C'est un argument de poids — devant un DPO, un client, une juridiction.
Depuis le règlement (UE) 2024/1689, utiliser une IA sur des dossiers n'est plus seulement une question RGPD.
L'article 4 impose aux organisations un niveau suffisant de maîtrise de l'IA par leur personnel. Savoir ce que l'IA reçoit — et pouvoir le montrer — en est le premier étage : la douane amont matérialise cette maîtrise.
AI Act art. 4Pour les usages à haut risque, l'article 10 exige une gouvernance des données — et cite la pseudonymisation parmi les garanties appropriées lorsque des catégories particulières sont en jeu (art. 10(5)).
AI Act art. 10Le professionnel qui utilise l'IA est un déployeur : obligations d'utilisation conforme, de contrôle et de conservation des journaux (art. 26). Le journal scellé de PSEUDONOMIA documente précisément ce qui a été transmis, quand, sous quelle forme.
AI Act art. 26Le point de bascule est le même que pour le RGPD : ces obligations pèsent sur vous, pas sur le fournisseur d'IA. Un outil qui pseudonymise en ligne ne vous aide pas à les tenir : il ajoute un maillon de plus à documenter. Un poste de travail local qui journalise chaque franchissement de frontière est votre dossier de preuve.
RGPD et AI Act passés au crible, article par article, avec la réponse technique de PSEUDONOMIA en face de chaque exigence.
Y compris au nôtre. Un éditeur sérieux répond aux sept sans détour — c'est le test le plus rapide du marché.
Si oui, tout le reste est secondaire : vous venez d'ajouter un sous-traitant (art. 28), un transit à sécuriser (art. 32) et une surface de violation (art. 33) — avant la première protection.
C'est le cœur de l'article 4(5). « Dans un fichier que vous téléchargez » n'est pas une mesure technique et organisationnelle : c'est un transfert de problème.
Un éditeur qui se trompe sur le mot central de son propre produit vous renseigne sur la rigueur du reste. Des données réversibles restent des données personnelles (considérant 26).
Masquer les noms ne protège pas contre le croisement âge + commune + profession. Exigez une métrique — et demandez sur quelle population de référence elle est calculée.
Si la réponse implique vos documents ou vos clés, la notification CNIL sera pour vous. La seule bonne réponse : « nous ne détenons rien de vous ».
Face à un DPO, un auditeur ou un juge, il vous faudra démontrer qui a transmis quoi, quand, sous quelle forme, et qui a réidentifié. Un journal scellé et exportable — ou rien.
Un dossier vit des mois et s'enrichit de pièces. Si la même personne change de masque d'un document à l'autre, le travail de l'IA — et le vôtre — devient incohérent. C'est le problème que résout notre mode projet breveté.
Deux façons de satisfaire une exigence : promettre de bien se conduire, ou rendre la mauvaise conduite matériellement impossible.
Les outils en ligne relèvent de la première : hébergement souverain, certifications, engagement de non-conservation — autant de promesses contractuelles qu'il faut croire, auditer, renouveler. PSEUDONOMIA relève de la seconde :
C'est en ce sens — architectural, vérifiable, démontrable — que nous soutenons qu'une pseudonymisation dans les règles de l'art, pour un professionnel soumis au secret, ne peut être que locale. Ce n'est pas un choix marketing contre le cloud : c'est la conclusion qu'imposent les textes dès qu'on les lit jusqu'au bout.
Pourquoi le cloud échoue structurellement (RGPD art. 5, 28, 32, 44 ; AI Act art. 9, 12, 14, 50) et les 4 mécanismes techniques du local.
Références citées : règlement (UE) 2016/679 (RGPD), art. 4(5), 5, 24, 25, 28, 30, 32, 33-34, 44 s. et considérant 26 · lignes directrices 01/2025 de l'EDPB sur la pseudonymisation · ENISA, Pseudonymisation techniques and best practices · CJUE, 4 septembre 2025, C-413/23 P (EDPS c/ SRB) · règlement (UE) 2024/1689 (AI Act), art. 4, 10, 26. Cette page est une analyse d'architecture au regard des textes ; elle ne constitue pas un conseil juridique individualisé.