PSEUDONOMIA est la référence de la pseudonymisation locale — et être la référence, c'est que rien ne quitte votre poste. Jamais.
Le SaaS cloud est le modèle dominant. Il a pourtant un défaut structurel : il ne peut pas être conforme au RGPD et à l'AI Act sur les traitements identifiants — peu importent les efforts du fournisseur. Démonstration en 8 minutes, articles à l'appui.
Comprendre la dominance du SaaS, et pourquoi les raisons sont commerciales — pas techniques, pas réglementaires.
Le modèle SaaS est l'écosystème logiciel dominant depuis 2010. Il offre quatre avantages réels au fournisseur : revenus récurrents prévisibles (abonnement mensuel), économies d'échelle d'infrastructure (un seul cluster pour tous les clients), contrôle total du code et des données (mises à jour silencieuses, lock-in contractuel), et collecte de télémétrie qui sert ensuite à améliorer le produit — et parfois à entraîner d'autres modèles.
Du côté de l'utilisateur, les bénéfices apparents sont : pas d'installation, mises à jour automatiques, accès depuis n'importe quel poste. Ces bénéfices existent. Mais pour les traitements de données personnelles — précisément ce que fait PSEUDONOMIA — ils sont annulés par un problème de conformité que la loi rend structurellement insoluble.
Quatre articles du RGPD condamnent structurellement l'externalisation cloud d'un traitement identifiant.
Le RGPD impose la minimisation : limiter strictement les acteurs qui accèdent aux données identifiantes. En SaaS, vous ajoutez le fournisseur, ses sous-traitants d'hébergement, leurs sous-traitants d'infrastructure, leurs prestataires de support — souvent une chaîne de 4 à 6 acteurs à inventorier dans votre registre.
Risque accru par constructionChaque sous-traitant exige un contrat de sous-traitance (DPA) conforme à l'art. 28 — durée, mesures techniques, clauses d'audit. Vous devez auditer régulièrement vos sous-traitants. Vous devez documenter. Vous devez justifier en cas de contrôle CNIL. Tout ça pour un service qui pourrait simplement tourner sur le poste de l'employé.
Charge administrative récurrenteLe paradoxe central du SaaS de pseudonymisation : le traitement se passe sur les données non encore pseudonymisées. C'est précisément à ce moment-là que vous les transmettez à un tiers. Vous prenez le risque maximum pour économiser un déploiement local. La proportionnalité de l'art. 32 est difficilement défendable.
Risque inversé par rapport au besoin90 % de l'infrastructure cloud mondiale est hébergée chez AWS, Azure, GCP — soumis au Cloud Act US (24 USC §2713) qui permet la saisie de données même si les serveurs sont en Europe. Les arrêts Schrems I et II de la CJUE ont explicitement déclaré insuffisantes les garanties contractuelles habituelles (SCC seules). Vos « garanties appropriées » deviennent un acte de foi.
Conformité formellement impossibleL'AI Act (applicable progressivement à partir d'août 2026) ajoute quatre obligations supplémentaires que le cloud rend difficiles à honorer.
L'AI Act exige un système de gestion des risques documenté tout au long du cycle de vie. Quand vous dépendez d'un fournisseur tiers, vous héritez de tous ses risques sans les contrôler : panne fournisseur, changement d'API, incident de sécurité, décision unilatérale d'arrêter le service ou de changer ses conditions.
Risques non contrôlablesL'art. 12 impose un journal des événements pertinents pour la traçabilité. En SaaS, ce journal est généré par le fournisseur, sur ses systèmes, à sa discrétion. Sa structure, sa rétention, son intégrité dépendent de ses choix. En cas de litige, il devient à la fois la pièce et l'évaluateur. Le local renverse cette logique : le journal est chez vous, scellé cryptographiquement.
Contrôle du journal déléguéL'art. 14 exige une supervision humaine effective. Effective signifie que l'humain doit pouvoir inspecter, comprendre, modifier ou interrompre chaque décision IA. Quand le modèle tourne dans un cloud distant, l'employé ne voit qu'une réponse — pas le traitement intermédiaire. Le local rend chaque étape visible et interruptible.
Supervision dégradéeL'art. 50 impose d'informer les personnes concernées quand un système IA est utilisé. Honnêtement, ça implique de leur dire : « vos données sont traitées par un modèle américain hébergé chez AWS US ». Très peu d'entreprises le font, et la jurisprudence à venir ne sera pas tendre. Le local évite ce dilemme : « vos données restent sur le poste de l'opérateur, point. »
Information délicate à formulerLa sécurité n'est pas qu'une question de cryptographie. C'est d'abord une question de surface d'attaque — combien de points d'entrée doivent rester sûrs en permanence.
Aucun serveur. Aucune API. Aucun backup centralisé. Aucun fournisseur d'identité externe. Aucun sous-traitant. Une seule chose à protéger : le poste, que vos équipes sécurité protègent déjà depuis 20 ans.
Pas par astuce, pas par excellence opérationnelle. Par architecture. Là où le SaaS doit compenser ses risques par des mesures, le local les évite.
| Obligation | Réponse SaaS cloud | Réponse PSEUDONOMIA local |
|---|---|---|
| RGPD art. 5 — Minimisation | 4 à 6 sous-traitants en chaîne | Aucun sous-traitant — 1 binaire signé |
| RGPD art. 28 — Sous-traitance | DPA par sous-traitant + audit récurrent | Aucun DPA nécessaire |
| RGPD art. 32 — Sécurité | Transfert au moment le plus sensible | Données ne quittent pas le poste |
| RGPD art. 44 — Transferts | Cloud Act US, garanties contestées | Aucun transfert international |
| AI Act art. 9 — Risques | Risques fournisseur hérités | Périmètre maîtrisé chez vous |
| AI Act art. 12 — Logs | Journal côté fournisseur | Journal scellé chez vous, signé Ed25519 |
| AI Act art. 14 — Supervision | Boîte noire distante | Chaque étape visible, interruptible |
| AI Act art. 50 — Transparence | « Vos données vont chez AWS US » | « Vos données restent sur le poste » |
| Sécurité — Surface d'attaque | 8+ vecteurs à surveiller | 1 — le poste, déjà sous votre IT |
Comment PSEUDONOMIA met cette architecture en œuvre concrètement. Quatre briques techniques qui composent la conformité.
Détection NER (Presidio + spaCy fr_core_news_lg)
et substitution exécutées intégralement sur votre poste.
Des dizaines de recognizers spécialisés par pays (NIR avec
clé Insee, SIRET/SIREN Luhn, IBAN mod-97, BIC, TVA, plaques
SIV, codes postaux, ~400 villes — et leurs équivalents dans
les 6 packs pays). Aucun appel modèle distant.
Aucun envoi à un service de tokenisation tiers.
Aucun fichier ne quitte le poste, jamais.
À chaque export, une table .lpx est
produite et chiffrée par Argon2id
(dérivation de clé) + XChaCha20-Poly1305 IETF
(chiffrement authentifié) avec un mot de passe
dédié que vous choisissez. Le format
binaire v2 supporte une double-clé (utilisateur OU
séquestre admin via X25519 SealedBox), permettant la
récupération par notaire ou HSM sans dépendre du
fournisseur.
Chaque action sensible (création identité, déverrouillage, export, lecture de table, acceptation CGU, cycle aller-retour IA) est consignée dans un journal JSONL append-only chaîné par SHA-256 et signé Ed25519 entrée par entrée. Toute modification rompt la chaîne et devient détectable par tout vérificateur. Le journal est chez vous, pas chez nous. Vous le fournissez en cas de contrôle.
La signature Ed25519 prouve qui et quoi. Pour une date opposable attestée par un tiers, l'option probante ajoute un horodatage qualifié de votre chaîne de preuve (TSA RFC 3161, conforme règlement UE n° 910/2014) par un prestataire de confiance européen — voir Sauvegarde & Reprise.
Le local a un prix. Pas un prix juridique — un prix opérationnel. Les voici clairement.
Chaque nouvelle version passe par un DMG ou EXE téléchargé manuellement. C'est volontaire : pas d'auto-update = pas de surface d'attaque réseau, pas de cheval de Troie possible via une fausse mise à jour. Vous savez quand votre poste change.
Si vous travaillez sur plusieurs ordinateurs, votre identité et vos préférences ne se synchronisent pas automatiquement. La synchronisation E2E chiffrée par CRDT libsodium (sans serveur centralisé) est dans la roadmap LexLabs 2027. En attendant, sauvegarde manuelle du dossier ~/.lexmind/.
PSEUDONOMIA ne vous fournit pas un modèle IA — c'est intentionnel. L'outil prépare vos documents pour que vous puissiez utiliser n'importe quelle IA externe (ChatGPT, Claude, Mistral, Gemini, ou votre instance interne) sans risque de fuite. Vous gardez le choix du modèle, et le coût IA reste où il doit être : chez le fournisseur de modèle, pas dans notre licence.
Chaque poste génère son propre journal scellé. En version Enterprise (à venir), une console DPO permettra d'agréger les journaux pour audit transverse — toujours en cryptographie zero-knowledge côté serveur (le DPO ne voit que les métadonnées signées, pas le contenu).
Ces « limites » sont précisément ce qui rend l'architecture opposable. Une architecture sans contrainte serait une architecture sans propriété de sécurité.
Si vous êtes dans l'une de ces situations, l'architecture locale n'est pas un confort — c'est une exigence.
Trois lectures complémentaires.
6 packs pays, 6 templates, 3 modes, garanties techniques par couche. La mise en œuvre concrète de l'architecture locale.
Découvrir →Pourquoi PSEUDONOMIA existe, où nous allons sur 12 mois, les 3 lignes de défense techniques (NER, crypto, journal scellé).
Lire →L'angle Shadow AI montre concrètement ce que l'architecture cloud coûte aux entreprises tous les jours.
Lire →