Dans toute chaîne de traitement RAG (Retrieval-Augmented Generation) d’entreprise, la fuite d’Informations Identifiables Personnellement (PII) constitue le risque de sécurité numéro un. Noms de personnes, adresses e-mail, identifiants bancaires (IBAN), numéros de Sécurité Sociale (NIR) ou numéros de téléphone ne doivent jamais être exposés en clair à un modèle d’inférence.
C’est une ligne rouge absolue.
Cependant, le masquage basique par suppression de texte prive le modèle de contexte sémantique crucial. Les autorités de protection des données, que ce soit la CNIL en France, la CDP au Sénégal ou la NDPC au Nigeria (NDPA 2023), exigent une étanchéité technique démontrable.
Dans cet article d’ingénierie, nous présentons l’architecture du module Privacy Vault d’Yevi Core v1.0 : un système d’anonymisation réversible en temps réel opérant exclusivement en mémoire RAM volatile chiffrée en AES-256-GCM.
1. Pourquoi le masquage classique par suppression échoue dans le RAG
Section intitulée « 1. Pourquoi le masquage classique par suppression échoue dans le RAG »Une approche naïve de l’anonymisation consiste à remplacer les noms par des chaînes génériques comme [MASQUÉ]. Cette méthode présente deux faiblesses critiques en production :
- Perte de résolution des coréférences : Si un contrat mentionne “Monsieur Martin a transmis le document à Madame Dubois”, remplacer les deux identités par
[MASQUÉ]empêche le LLM de déterminer qui a transmis quoi. Le RAG perd tout son sens juridique. - Irréversibilité de la réponse : L’utilisateur final recevra une réponse contenant des étiquettes masquées et devra reconstituer lui-même l’information.
La solution Yevi Core v1.0 : la substitution par jetons typés réversibles
Section intitulée « La solution Yevi Core v1.0 : la substitution par jetons typés réversibles »Au lieu de supprimer le texte, Yevi remplace chaque donnée personnelle par un jeton typé unique (ex. [[PER_1]], [[PER_2]], [[EMAIL_1]]).
Texte original : "Me Jean Martin (jean.martin@etude.fr) a rédigé l'acte."Texte anonymisé : "[[PER_1]] ([[EMAIL_1]]) a rédigé l'acte."2. Architecture du pipeline d’anonymisation
Section intitulée « 2. Architecture du pipeline d’anonymisation »Le module d’anonymisation de Yevi Core v1.0 combine deux moteurs complémentaires, conçus pour s’exécuter en quelques millisecondes et garantir une souveraineté matérielle totale, que l’appliance soit déployée à Paris, Abidjan ou Lagos :
graph TD Input["Texte Brut (.pdf / .docx)"] --> RegexEngine["1. Moteur Regex Réversible (NIR, IBAN, E-mail, Tél)"] RegexEngine --> SpacyNER["2. Moteur NER spaCy (Noms PER, Lieux LOC, Orgs ORG)"] SpacyNER --> RAMVault["3. Stockage Chiffré AES-256-GCM en RAM Volatile"] RAMVault --> AnonymizedOutput["Texte Anonymisé transmis au RAG / LLM"]A. Le moteur par expressions régulières (Regex)
Section intitulée « A. Le moteur par expressions régulières (Regex) »Utilisé pour la détection déterministe à 100 % des identifiants normés :
- Numéro de Sécurité Sociale (NIR) : Motif à 13 + 2 chiffres.
- Identifiant Bancaire (IBAN) : Format ISO 13616.
- Adresses e-mail & numéros de téléphone : Motifs RFC 5322.
B. Le moteur NER (Named Entity Recognition) spaCy
Section intitulée « B. Le moteur NER (Named Entity Recognition) spaCy »Utilisé pour la détection contextuelle sémantique des entités nommées. Il est optimisé pour capter les subtilités linguistiques biculturelles (noms ouest-africains, formats d’adresses européens, etc.) :
PER: Prénoms et noms de personnes.ORG: Sociétés, associations et institutions (ex: CEDEAO, UEMOA).LOC: Villes, adresses et pays.
3. Le coffre-fort RAM Vault (AES-256-GCM Volatile)
Section intitulée « 3. Le coffre-fort RAM Vault (AES-256-GCM Volatile) »La clé de correspondance entre les valeurs réelles et leurs jetons (ex: [[PER_1]] = Jean Martin) est la pièce la plus critique du système. La compromettre revient à violer le RGPD (Art. 28) et les législations équivalentes (CDP, ARTCI).
Dans Yevi Core v1.0 :
- Zéro écriture sur disque : La table de correspondance réside exclusivement en mémoire RAM volatile. Rien n’est écrit sur le SSD.
- Chiffrement AES-256-GCM : Chaque session d’anonymisation génère une clé de chiffrement éphémère en mémoire RAM.
- Purge automatique : Dès que la réponse sourcée est restituée à l’utilisateur autorisé, la table de correspondance est immédiatement effacée de la mémoire vive. Le serveur redevient vierge.
[!NOTE] Cette approche “Zero Trust” par conception permet aux banques et Fintechs d’utiliser des LLMs sans exposer les PII de leurs clients, évitant au passage les factures d’API Cloud en USD instables, particulièrement pertinentes pour les zones Franc CFA (XOF) ou Naira.
4. Exemple d’exécution en Python avec la CLI Yevi
Section intitulée « 4. Exemple d’exécution en Python avec la CLI Yevi »Voici comment tester la brique d’anonymisation de Yevi directement en ligne de commande :
# Ingestion et anonymisation d'un document confidentielyevi anonymize ./dossier_client.pdf --output ./dossier_anonyme.txtExtrait de log d’audit JSONL généré, opposable en cas de contrôle d’une autorité régulatrice :
{ "timestamp": "2026-08-08T17:30:00Z", "event": "ANONYMIZATION_SUCCESS", "tokens_replaced": { "PER": 4, "EMAIL": 2, "IBAN": 1 }, "vault_status": "ENCRYPTED_RAM_ONLY"}5. Applications métier & conformité réglementaire
Section intitulée « 5. Applications métier & conformité réglementaire »Le module Privacy Vault d’Yevi Core v1.0 est la brique de référence pour satisfaire aux exigences légales les plus strictes :
- Conformité RGPD & Régulateurs africains : Respect des principes de minimisation imposés par la CNIL, la CDP (Sénégal) ou l’ARTCI (Côte d’Ivoire) (Article complet RGPD & IA).
- Secret Notarial & Avocats : Protection déontologique absolue des identités de parties et montants de transactions (IA & Secret Notarial).
- Données Bancaires & DORA : Anonymisation volatile des numéros IBAN et cartes avant traitement (IA & Réglementation DORA).
- Optimisation des Window Context : Préservation du nombre de tokens grâce à notre découpage sémantique du tokenizer.