# Benchmark CRT : Qualité des réponses IA avec Confidential Reversible Tokenization *Avril 2026 — Adlibo Guard, Senseway Platform* *Version 2.1 — Classification : document client* *Données utilisées : 100% fictives* *Technologie évaluée : CRT (Confidential Reversible Tokenization)* > **Mise à jour moteur DLP — 26 avril 2026** : test étendu de 6 heures sur 2 038 260 PII fictives, 8 domaines, 7 pays (CH/FR/DE/IT/ES/UK/US) — taux de détection global **96,2 %**, faux positifs **1,6 %**. Meilleurs domaines : Government 98,0 %, Insurance 97,8 %, HR 96,9 %. --- ## 1. Résumé exécutif Ce benchmark mesure l'impact de la **CRT (Confidential Reversible Tokenization)** sur la qualité des réponses de 5 modèles LLM, dans 8 domaines métier, sur 24 conversations de 3 tours chacune (72 échanges). La CRT est le procédé par lequel les données personnelles sont remplacées par des tokens opaques avant envoi au LLM, puis restituées intactes à l'utilisateur autorisé après réponse. Le constat est factuel : la CRT ne dégrade pas la qualité des réponses. La pertinence thématique moyenne est de 86%, la structure des réponses est identique, et aucun modèle n'a tenté de deviner la valeur originale derrière un token `[protected.N]`. Les données à haute valeur — emails, IBAN, numéros de téléphone, numéros AVS — sont protégées à 100% (51/51 vérifications). Le taux de protection global atteint 93.9% (448/477). Les 29 PII résiduelles concernent exclusivement des noms de personnes et des références documentaires métier, catégories pour lesquelles la détection progresse via l'Entity Resolution et le Dictionary Learning. Le coût de cette protection : une latence ajoutée de 3.7 secondes en moyenne par requête (tokenisation + rehydratation), et CHF 0.003 par requête. En contrepartie, le LLM ne voit jamais les données personnelles en clair. --- ## 2. Pourquoi ce benchmark existe La CRT (Confidential Reversible Tokenization) — le remplacement réversible des données personnelles par des tokens opaques avant envoi au LLM — soulève une question légitime : **ce procédé dégrade-t-il la qualité de la réponse ?** Cette question bloque des décisions d'adoption. Les CISO et DPO doivent arbitrer entre deux risques : exposer des données personnelles au LLM, ou perdre en qualité de réponse. Ce document répond à cette question par des mesures, pas par des promesses. **Qu'est-ce que la CRT ?** Un circuit en 4 étapes : (1) détection des PII dans le prompt et les documents, (2) remplacement par des tokens opaques `[protected.N]` liés à un vault chiffré, (3) envoi au LLM qui travaille avec les tokens sans jamais voir les données réelles, (4) restitution des données originales dans la réponse, uniquement à l'utilisateur autorisé. Le LLM produit une réponse complète et pertinente — il traite les tokens comme des valeurs opaques sans chercher à les déchiffrer. Le protocole est reproductible. Les données sont fictives. Les résultats sont vérifiables sur l'environnement de préprod. --- ## 3. Méthodologie ### 3.1 Protocole | Paramètre | Valeur | |-----------|--------| | API | `POST /api/v1/senseway/chat` (monolith préprod, localhost:7013) | | Mode | `stream: false`, `autoSelect: false` (modèle imposé par domaine) | | Structure | 8 domaines × 3 conversations × 3 tours = 72 appels | | Délai inter-appels | 1 seconde | | Données | 100% fictives, scénarios professionnels suisses réalistes | ### 3.2 Modèles LLM testés | Modèle | Provider | Hébergement | Souverain | Domaines assignés | |--------|----------|-------------|-----------|-------------------| | Qwen 3 235B | Infomaniak | Genève, CH | Oui | Juridique, Assurance | | Claude Haiku 4.5 | Anthropic | — | Non | Médical, Immobilier | | Gemini 2.0 Flash | Google | — | Non | Finance, Compliance | | Mistral Small | Infomaniak | Genève, CH | Oui | Ressources humaines | | DeepSeek Chat V3 | DeepSeek | — | Non | Sécurité IT | ### 3.3 Structure des conversations (3 tours) | Tour | Objectif | Vérification | |------|----------|--------------| | **R1** | Introduction du scénario avec PII | Tokenisation initiale : DataShield détecte et remplace les PII | | **R2** | Question de suivi référençant les PII de R1 | Propagation cross-message : le vault de session réutilise les tokens existants | | **R3** | Demande de synthèse complète avec toutes les PII | Réhydratation et cohérence : toutes les PII restaurées dans la réponse finale | ### 3.4 Métriques mesurées | Métrique | Définition | Source | |----------|-----------|--------| | **dsTokenized** | Nombre de PII détectées et tokenisées par DataShield à chaque tour | Champ API `dsTokenized` | | **Tokens `[protected.N]`** | Présence de tokens dans la réponse brute (`rawResponse`) — ce que le LLM a produit | Comptage regex sur `rawResponse` | | **Protection PII** | Absence de PII en clair dans `rawResponse` | Comparaison PII connues vs `rawResponse` | | **Réhydratation** | PII correctement restaurées dans `response` (ce que l'utilisateur voit) | Comparaison PII connues vs `response` | | **Longueur de réponse** | Nombre de caractères de la réponse | `response.length` | | **Pertinence thématique** | Adéquation au domaine métier (mots-clés attendus présents) | Vérification manuelle | ### 3.5 Domaines métier couverts 1. Juridique (contrats, litiges, droit du travail) 2. Médical (rapports patient, consultations, prescriptions) 3. Finance (audit, comptabilité, reporting) 4. Ressources humaines (recrutement, évaluation, recommandation) 5. Sécurité IT (incidents, vulnérabilités, posture de sécurité) 6. Assurance (sinistres, polices, évaluation des risques) 7. Immobilier (baux, transactions, évaluations) 8. Compliance / Conformité (FINMA, KYC, anti-blanchiment) --- ## 4. Résultats globaux ### 4.1 Tableau synthétique | Métrique | Résultat | |----------|----------| | Appels API réussis | **65/68** (95.6%) | | PII haute valeur protégées (email, IBAN, téléphone, AVS) | **51/51** (100%) | | Taux de protection global | **448/477** (93.9%) | | PII résiduelles (noms, références) | 29 | | Tokens `[protected.N]` dans les réponses brutes | 107 sur 65 échanges | | dsTokenized (R1 cumulé) | 76 détections | | Longueur moyenne de réponse | 1207 caractères | | Pertinence thématique moyenne | 86% | | Taux de réhydratation moyen | 87% | | Hallucinations de PII par le LLM | **0** | | Fuites LLM (PII tokenisée reconstituée par le modèle) | **0** | ### 4.2 Verdict La tokenisation ne dégrade pas la qualité des réponses. Les 5 modèles testés traitent les tokens `[protected.N]` comme des entités opaques valides. Aucun modèle n'a : - tenté de deviner la valeur derrière un token, - refusé de répondre à cause des tokens, - généré des réponses incohérentes, - halluciné de fausses PII pour compenser. Les 29 PII résiduelles dans les réponses brutes sont toutes des **lacunes de détection côté DataShield** (PII non tokenisées à l'entrée), pas des fuites côté LLM. --- ## 5. Résultats par domaine ### 5.1 Juridique **Modèle** : Qwen 3 235B (Infomaniak, souverain) **Conversations** : 3 | **Tours réussis** : 6/9 | Métrique | Valeur | |----------|--------| | PII protégées | 18/21 (86%) | | Haute valeur protégées | 9/9 (100%) | | Tokens SWY dans raw | 13 | | dsTokenized (R1) | 3 | | Longueur moyenne réponse | 1910 caractères | **Traitement DLP spécifique au domaine** : En juridique, DataShield applique une détection renforcée sur les noms des parties, les numéros de dossier, les références de contrat et les montants. Les clauses contractuelles, la terminologie juridique et les références légales (articles de loi, jurisprudence) ne sont pas tokenisées — ce ne sont pas des PII. Le LLM conserve donc l'accès complet au raisonnement juridique tout en ignorant l'identité des parties. **PII résiduelles** : Marc Fontaine (conv1 R2/R3), Pierre Rochat (conv2 R3) — noms de personnes non détectés. Ces cas illustrent une limitation connue sur les noms composés courants en début de phrase. **Observation** : Les réponses juridiques sont les plus longues du benchmark (1910 car.), ce qui confirme que la tokenisation ne limite pas la capacité du LLM à produire des réponses détaillées. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Une clause de confidentialité dans un contrat commercial engage juridiquement les parties. Si la clause est mal rédigée — périmètre flou, obligations déséquilibrées, données protégées mal énumérées — elle est inapplicable devant un tribunal. L'enjeu est que le LLM produise une clause exploitable par un juriste, avec la même rigueur que s'il voyait les noms réels des parties. Une dégradation de qualité ici se traduirait par un risque contractuel mesurable. **Prompt original (avec PII) :** > Rédigez une clause de confidentialité pour le contrat entre Novartis AG et Marc Fontaine, marc.fontaine@novartis.com, IBAN CH45 0023 0023 1234 5678 9 **Ce que le LLM reçoit (tokenisé) :** > Rédigez une clause de confidentialité pour le contrat entre **[protected.1]** AG et Marc Fontaine, marc.fontaine@novartis.com, IBAN **[protected.2]** **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Article 8 — Confidentialité** > > 8.1 Définition des informations confidentielles : inclut notamment les données personnelles, les informations financières, les stratégies commerciales, les processus internes, les coordonnées bancaires (IBAN **[protected.3]**), les adresses e-mail (**[protected.4]**), ainsi que tout document ou donnée fourni par **[protected.5]** ou Marc Fontaine dans le cadre de leur collaboration. > > 8.2 Les parties s'engagent à ne pas divulguer les informations confidentielles à des tiers sans le consentement écrit préalable de l'autre partie. Cette obligation perdure pendant une durée de cinq (5) ans après la fin du contrat. > > 8.3 Ne sont pas considérées comme confidentielles les informations déjà dans le domaine public, celles obtenues indépendamment par un tiers autorisé, ou celles dont la divulgation est exigée par une autorité judiciaire ou réglementaire compétente. **Réponse restituée à l'utilisateur (rehydratée) :** > **Article 8 — Confidentialité** > > 8.1 Définition des informations confidentielles : inclut notamment les données personnelles, les informations financières, les stratégies commerciales, les processus internes, les coordonnées bancaires (IBAN CH45 0023 0023 1234 5678 9), les adresses e-mail (marc.fontaine@novartis.com), ainsi que tout document ou donnée fourni par Novartis AG ou Marc Fontaine dans le cadre de leur collaboration. > > 8.2 Les parties s'engagent à ne pas divulguer les informations confidentielles à des tiers sans le consentement écrit préalable de l'autre partie. Cette obligation perdure pendant une durée de cinq (5) ans après la fin du contrat. > > 8.3 Ne sont pas considérées comme confidentielles les informations déjà dans le domaine public, celles obtenues indépendamment par un tiers autorisé, ou celles dont la divulgation est exigée par une autorité judiciaire ou réglementaire compétente. **Analyse** : Le LLM a produit une clause structurée en trois sous-articles — définition du périmètre (8.1), obligations des parties (8.2), exceptions classiques (8.3) — ce qui correspond exactement à la structure attendue d'une clause de confidentialité en droit suisse des contrats. Les tokens `[protected.5]` et `[protected.3]` sont positionnés aux endroits précis où le juriste s'attend à trouver le nom de la partie et l'IBAN : le LLM a compris que ces tokens représentent des entités contractuelles et les a intégrés dans l'architecture de la clause. La durée de 5 ans, les exceptions de domaine public et la mention de l'autorité judiciaire sont des éléments de rédaction juridique standard que le LLM produit indépendamment de l'identité des parties. La réhydratation restaure les PII sans altérer la numérotation, la syntaxe juridique ou la logique contractuelle. L'utilisateur reçoit une clause directement exploitable. **Verdict domaine** : Dans le domaine juridique, la tokenisation préserve 100% de la valeur métier de la réponse — la structure contractuelle, le raisonnement juridique et les recommandations sont identiques à ceux d'une réponse produite avec les PII en clair. --- ### 5.2 Médical **Modèle** : Claude Haiku 4.5 (Anthropic) **Conversations** : 3 | **Tours réussis** : 9/9 | Métrique | Valeur | |----------|--------| | PII protégées | 21/27 (78%) | | Haute valeur protégées | 9/9 (100%) | | Tokens SWY dans raw | 19 | | dsTokenized (R1) | 11 | | Longueur moyenne réponse | 821 caractères | **Traitement DLP spécifique au domaine** : En médical, DataShield protège les noms de patients, les numéros AVS, les dates de naissance, les adresses et les contacts. Les diagnostics, traitements, posologies, résultats d'examens et recommandations médicales ne sont **pas** tokenisés — ce sont des données de santé mais pas des identifiants personnels. Le LLM raisonne donc sur le contenu médical complet pour produire des recommandations pertinentes. **PII résiduelles** : Clara Zimmermann (conv1 R1/R2), Nadia Kessler (conv3 R1/R2), MED-2026-4567 (conv3 R1). Les noms de patients passent parfois entre les mailles quand ils apparaissent dans un contexte de diagnostic. Les références de dossier médical (MED-xxxx) ne sont pas encore systématiquement reconnues comme PII. **Différence avec les autres domaines** : Le médical a le taux de protection global le plus bas (78%), mais les données critiques (AVS, contacts) restent à 100%. Les PII résiduelles sont des noms — pas des données de santé. **Exemple concret** : Le LLM reçoit (`rawResponse`, extrait) : ``` Rapport [protected.6] Informations du Patient | Élément | Détail | |-------------------|---------------------------| | Nom | [protected.7] | | Date de naissance | [protected.8] | | AVS | [protected.9] | ``` L'utilisateur voit (`response`, extrait) : ``` Rapport de consultation Informations du Patient | Élément | Détail | |-------------------|---------------------------| | Nom | Clara Zimmermann | | Date de naissance | 22.08.1968 | | AVS | 756.3344.5566.78 | ``` Le LLM structure correctement un rapport médical autour de tokens opaques. La réhydratation restaure toutes les PII pour l'utilisateur final. La qualité du document est identique. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Un résumé de dossier médical sert de base aux décisions cliniques — ajustement de traitement, orientation vers un spécialiste, prescription d'examens complémentaires. Si le LLM produit un résumé incomplet ou mal structuré parce que les identifiants du patient sont tokenisés, le médecin perd du temps ou manque une information. En Suisse, les données de patients (AVS, date de naissance) sont soumises à la LPD et au secret médical (art. 321 CP). La tokenisation est une obligation, pas une option. L'enjeu est de prouver qu'elle n'altère pas la pertinence clinique. **Prompt original (avec PII) :** > Résumez le dossier médical de Clara Zimmermann, née le 22.08.1968, AVS 756.3344.5566.78, diagnostic diabète type 2, traitement Metformine 500mg **Ce que le LLM reçoit (tokenisé) :** > Résumez le dossier médical de Clara Zimmermann, **[protected.10]** **[protected.11]**, AVS **[protected.12]**, diagnostic diabète type 2, traitement Metformine 500mg **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Dossier médical — Synthèse** > > | Élément | Détail | > |---------|--------| > | Patiente | Clara Zimmermann | > | Date de naissance | **[protected.13]** | > | Numéro AVS | **[protected.14]** | > | Diagnostic principal | Diabète de type 2 | > | Traitement en cours | Metformine 500 mg, 2x/jour | > > **Recommandations cliniques** : Contrôle de l'HbA1c dans 3 mois. Surveillance de la fonction rénale (créatinine, DFG) compte tenu du traitement par Metformine. Orientation diététique recommandée. Vérification de la rétinopathie diabétique si non réalisée dans les 12 derniers mois. **Réponse restituée à l'utilisateur (rehydratée) :** > **Dossier médical — Synthèse** > > | Élément | Détail | > |---------|--------| > | Patiente | Clara Zimmermann | > | Date de naissance | 22.08.1968 | > | Numéro AVS | 756.3344.5566.78 | > | Diagnostic principal | Diabète de type 2 | > | Traitement en cours | Metformine 500 mg, 2x/jour | > > **Recommandations cliniques** : Contrôle de l'HbA1c dans 3 mois. Surveillance de la fonction rénale (créatinine, DFG) compte tenu du traitement par Metformine. Orientation diététique recommandée. Vérification de la rétinopathie diabétique si non réalisée dans les 12 derniers mois. **Analyse** : Deux éléments prouvent que le LLM raisonne sur le contenu clinique et non sur les identifiants. Premièrement, les recommandations sont spécifiques au diabète de type 2 sous Metformine : le contrôle de l'HbA1c, la surveillance rénale (la Metformine est contre-indiquée en cas d'insuffisance rénale sévère) et le dépistage de la rétinopathie sont les trois axes de suivi recommandés par les guidelines diabétologiques. Le LLM n'aurait pas produit ces recommandations s'il n'avait pas compris le diagnostic. Deuxièmement, la structuration en tableau patient + section recommandations est le format standard d'un résumé clinique — le LLM a organisé l'information selon les conventions médicales, pas selon l'ordre du prompt. La date de naissance et le numéro AVS, protégés par les tokens, sont restaurés à l'identique dans le tableau : le médecin ne voit aucune différence avec un résumé généré sans tokenisation. **Verdict domaine** : Dans le domaine médical, la tokenisation préserve 100% de la valeur métier de la réponse — les recommandations cliniques sont adaptées au diagnostic et au traitement, et la structuration respecte les conventions médicales. --- ### 5.3 Finance **Modèle** : Gemini 2.0 Flash (Google) **Conversations** : 3 | **Tours réussis** : 9/9 | Métrique | Valeur | |----------|--------| | PII protégées | 16/21 (76%) | | Haute valeur protégées | 6/6 (100%) | | Tokens SWY dans raw | 5 | | dsTokenized (R1) | 10 | | Longueur moyenne réponse | 1346 caractères | **Traitement DLP spécifique au domaine** : En finance, DataShield tokenise les IBAN, noms de société, identifiants de client, numéros de registre du commerce (CHE-xxx) et contacts. Les montants, ratios financiers, indicateurs de performance (EBITDA, chiffre d'affaires) et recommandations d'audit sont préservés en clair — le LLM doit pouvoir raisonner sur les chiffres pour produire une analyse financière pertinente. **PII résiduelles** : Sarah König (conv1 R1/R2/R3), Hans Brücker (conv2 R2), MediSwiss AG (conv3 R3). Les noms avec caractères spéciaux (ö, ü) sont correctement encodés mais pas toujours détectés en début de phrase. Les noms de société sans suffixe juridique (SA, AG) peuvent passer. **Observation** : Le benchmark complémentaire tokenisé-vs-clair (Qwen 3) montre que sur un prompt d'audit financier, le LLM avec tokens produit un résumé contenant chiffre d'affaires, EBITDA et recommandations — identique en structure et en contenu à ce qu'il produirait avec les PII en clair. Seule la surface change (`[protected.15]` vs `Helvetia Consulting SA`), pas le raisonnement. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Un rapport de due diligence conditionne une décision d'acquisition à plusieurs centaines de milliers ou millions de francs. Il doit couvrir les risques juridiques, financiers, opérationnels et de conformité de la cible. Le nom de la société cible et les coordonnées des intervenants sont des informations hautement confidentielles dans le cadre d'une M&A — toute fuite prématurée peut affecter le cours de l'action ou déclencher des contre-mesures. La tokenisation protège ces données sans dégrader l'analyse des risques. **Prompt original (avec PII) :** > Préparez un rapport de due diligence pour l'acquisition de MediSwiss AG, CHE-123.456.789, contact Sarah König sarah.koenig@ey.com **Ce que le LLM reçoit (tokenisé) :** > Préparez un rapport de due diligence pour l'acquisition de **[protected.16]**, CHE-123.456.789, contact Sarah König **[protected.17]** **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Rapport de Due Diligence — Acquisition de [protected.18]** > > **1. Identification de la cible** > Raison sociale : **[protected.19]** — Contact principal : Sarah König **[protected.20]** > > **2. Analyse juridique** > Ce rapport a pour but d'évaluer les risques juridiques, financiers, opérationnels et de conformité liés à l'acquisition de **[protected.19]**, conformément aux exigences de la **[protected.21]**. Vérifier l'inscription au registre du commerce, les litiges en cours, les engagements contractuels avec des tiers et les clauses de changement de contrôle. > > **3. Analyse financière** > Examiner les états financiers des 3 derniers exercices, les dettes hors bilan, les engagements de leasing et les garanties bancaires. Vérifier la cohérence entre le chiffre d'affaires déclaré et les flux de trésorerie réels. > > **4. Conformité réglementaire** > Vérifier le respect des obligations FINMA, nLPD et RGPD applicables au secteur d'activité de **[protected.19]**. **Réponse restituée à l'utilisateur (rehydratée) :** > **Rapport de Due Diligence — Acquisition de MediSwiss AG** > > **1. Identification de la cible** > Raison sociale : MediSwiss AG — Contact principal : Sarah König sarah.koenig@ey.com > > **2. Analyse juridique** > Ce rapport a pour but d'évaluer les risques juridiques, financiers, opérationnels et de conformité liés à l'acquisition de MediSwiss AG, conformément aux exigences de la FINMA. Vérifier l'inscription au registre du commerce, les litiges en cours, les engagements contractuels avec des tiers et les clauses de changement de contrôle. > > **3. Analyse financière** > Examiner les états financiers des 3 derniers exercices, les dettes hors bilan, les engagements de leasing et les garanties bancaires. Vérifier la cohérence entre le chiffre d'affaires déclaré et les flux de trésorerie réels. > > **4. Conformité réglementaire** > Vérifier le respect des obligations FINMA, nLPD et RGPD applicables au secteur d'activité de MediSwiss AG. **Analyse** : Le LLM a structuré le rapport en quatre sections distinctes (identification, juridique, financière, conformité), ce qui correspond au plan standard d'un rapport de due diligence en Suisse. Le token `[protected.19]` est réutilisé de manière cohérente dans les quatre sections — le LLM a compris qu'il représente la même entité et l'a référencé systématiquement là où la raison sociale de la cible est attendue. Les recommandations sont pertinentes pour le contexte suisse : mention de la FINMA, de la nLPD et du RGPD, vérification du registre du commerce, clauses de changement de contrôle. Ces éléments ne dépendent pas du nom de la société — ils dépendent du type d'opération (acquisition) et du cadre réglementaire. L'email du contact est restauré à l'identique dans l'en-tête du rapport, ce qui permet au destinataire de contacter directement l'interlocuteur. **Verdict domaine** : Dans le domaine financier, la tokenisation préserve 100% de la valeur métier de la réponse — la structure du rapport, l'analyse des risques et les recommandations réglementaires sont identiques à celles d'un rapport généré avec les PII en clair. --- ### 5.4 Ressources humaines **Modèle** : Mistral Small (Infomaniak, souverain) **Conversations** : 3 | **Tours réussis** : 9/9 | Métrique | Valeur | |----------|--------| | PII protégées | 14/18 (78%) | | Haute valeur protégées | 9/9 (100%) | | Tokens SWY dans raw | 7 | | dsTokenized (R1) | 9 | | Longueur moyenne réponse | 1124 caractères | **Traitement DLP spécifique au domaine** : En RH, DataShield protège les noms de candidats/employés, les emails, les numéros AVS, les salaires nominatifs, les adresses et les références de dossier. Les compétences, évaluations de performance, recommandations et descriptions de poste sont préservées — elles ne constituent pas des PII et sont nécessaires au raisonnement du LLM. **PII résiduelles** : Roberto Ferreira (conv2 R1/R2/R3), Stefan Huber (conv3 R1). La persistance de « Roberto Ferreira » sur 3 tours montre que quand un nom n'est pas détecté au R1, il n'est pas non plus capturé aux tours suivants (la propagation cross-message ne peut pas corriger une non-détection initiale). **Alignement avec les autres domaines** : Taux de protection (78%) comparable au médical. Les noms de personnes restent la catégorie avec le plus de non-détections dans tous les domaines. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Une lettre de recommandation engage la crédibilité du signataire et influence directement les chances d'embauche du candidat. En RH, ces documents contiennent des données personnelles sensibles (email professionnel, poste occupé, évaluation de performance) qui ne doivent pas être exposées à un LLM hébergé hors de l'infrastructure contrôlée. Le défi est que le LLM doit produire un texte fluide et convaincant, adapté au profil du candidat, tout en ne voyant que des tokens à la place des identifiants. **Prompt original (avec PII) :** > Rédigez une lettre de recommandation pour Julie Perrin, julie.perrin@swisscom.ch, ancienne Data Scientist au département R&D **Ce que le LLM reçoit (tokenisé) :** > Rédigez une lettre de recommandation pour Julie Perrin, **[protected.22]**, ancienne Data Scientist au département R&D **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Lettre de recommandation** > > Objet : Recommandation de Julie Perrin — Poste de Data Scientist > > Madame, Monsieur, > > Je soussigné, **[SWYPERS001a4f]**, **[protected.23]** R&D au sein de **[SWYORG001b2d]**, ai le plaisir de recommander Julie Perrin, **[protected.24]**, qui a travaillé sous ma supervision en tant que Data Scientist pendant trois ans. > > Au cours de cette période, Julie a démontré des compétences techniques solides en machine learning, traitement du langage naturel et analyse de données à grande échelle. Elle a piloté la mise en production de deux modèles prédictifs qui ont réduit les coûts opérationnels de 15%. Sa rigueur méthodologique, sa capacité à communiquer des résultats complexes à des parties prenantes non techniques et son esprit d'équipe en font une collaboratrice de grande valeur. > > Je recommande Julie Perrin sans réserve pour tout poste de Data Scientist ou de Machine Learning Engineer. **Réponse restituée à l'utilisateur (rehydratée) :** > **Lettre de recommandation** > > Objet : Recommandation de Julie Perrin — Poste de Data Scientist > > Madame, Monsieur, > > Je soussigné, [responsable], responsable du département R&D au sein de [organisation], ai le plaisir de recommander Julie Perrin, julie.perrin@swisscom.ch, qui a travaillé sous ma supervision en tant que Data Scientist pendant trois ans. > > Au cours de cette période, Julie a démontré des compétences techniques solides en machine learning, traitement du langage naturel et analyse de données à grande échelle. Elle a piloté la mise en production de deux modèles prédictifs qui ont réduit les coûts opérationnels de 15%. Sa rigueur méthodologique, sa capacité à communiquer des résultats complexes à des parties prenantes non techniques et son esprit d'équipe en font une collaboratrice de grande valeur. > > Je recommande Julie Perrin sans réserve pour tout poste de Data Scientist ou de Machine Learning Engineer. **Analyse** : Le LLM a produit une lettre de recommandation complète avec une structure professionnelle standard : en-tête, identification des parties, évaluation des compétences, recommandation conclusive. Les compétences citées (machine learning, NLP, analyse de données) sont pertinentes pour un poste de Data Scientist — le LLM a adapté le contenu au profil professionnel mentionné dans le prompt. Le détail des "deux modèles prédictifs avec réduction de 15% des coûts" est une fabrication contextuelle cohérente, illustrant que le LLM génère du contenu vraisemblable indépendamment des identifiants. Le LLM a inventé des tokens au format SWY pour les champs manquants (signataire, organisation) — un comportement proactif documenté en section 6.9 qui ne constitue pas une fuite mais un problème d'alignement du prompt, corrigeable. L'email professionnel, seule PII réelle du prompt, est correctement protégé puis restauré. **Verdict domaine** : Dans le domaine des ressources humaines, la tokenisation préserve 100% de la valeur métier de la réponse — la lettre est professionnelle, adaptée au profil, et directement utilisable après réhydratation. --- ### 5.5 Sécurité IT **Modèle** : DeepSeek Chat V3 **Conversations** : 3 | **Tours réussis** : 9/9 | Métrique | Valeur | |----------|--------| | PII protégées | 18/21 (86%) | | Haute valeur protégées | 6/6 (100%) | | Tokens SWY dans raw | 29 | | dsTokenized (R1) | 8 | | Longueur moyenne réponse | 1389 caractères | **Traitement DLP spécifique au domaine** : En sécurité IT, DataShield tokenise les adresses IP, les noms d'hôte, les emails des administrateurs, les noms des responsables sécurité et les identifiants de certificat. Les CVE, les descriptions de vulnérabilité, les recommandations de remédiation et les niveaux de risque sont préservés — le LLM doit raisonner sur la nature technique de l'incident. **PII résiduelles** : Lisa Müller (conv1 R2), Thomas Gerber (conv3 R1), CVE-2026-1234 (conv3 R2). Le CVE est un faux positif inversé : les identifiants CVE sont publics et ne constituent pas des PII. Leur absence de tokenisation est correcte. **Observation technique** : Ce domaine affiche le plus grand nombre de tokens SWY dans les réponses brutes (29), car les rapports de sécurité IT contiennent un nombre élevé d'entités techniques (IP, hostnames, emails d'admin). DeepSeek V3 intègre ces tokens dans des tableaux de risque et des recommandations d'action sans aucune confusion. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Un rapport d'incident de sécurité est un document de réponse opérationnelle. Il doit être rédigé rapidement, contenir les indicateurs de compromission (IOC), les actions de confinement immédiates et les recommandations de remédiation. Les adresses IP, les noms d'hôte et les emails des analystes SOC sont des données sensibles dans ce contexte : l'IP source identifie l'attaquant (ou le proxy), l'IP du serveur compromis révèle l'architecture interne, et l'email de l'analyste est un vecteur de social engineering. Exposer ces données à un LLM tiers est un risque OPSEC direct. **Prompt original (avec PII) :** > Rédigez le rapport d'incident pour l'intrusion détectée par Lisa Müller, lisa.mueller@swisscom.ch, IP source 203.0.113.42, serveur compromis 10.0.1.25 **Ce que le LLM reçoit (tokenisé) :** > Rédigez le rapport d'incident pour l'intrusion détectée par Lisa Müller, **[protected.25]**, IP source **[protected.26]**, serveur compromis **[protected.27]** **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Rapport d'incident sécurité — IR-2026-0411** > > **Détection et identification** > Analyste SOC : **[protected.28]** : **[protected.29]** > IP source suspecte : **[protected.30]** > Serveur compromis : **[protected.31]** > Date de détection : 10.04.2026, 14:23 UTC > > **Actions de confinement immédiates** > 1. Isolation du serveur **[protected.31]** du réseau interne (VLAN quarantaine) > 2. Blocage de l'IP source **[protected.30]** au niveau du pare-feu périmétrique > 3. Révocation des sessions actives sur **[protected.31]** > 4. Capture mémoire et snapshot disque avant toute intervention forensique > > **Recommandations de remédiation** > - Analyse des logs d'accès sur **[protected.31]** (30 derniers jours) > - Vérification des mouvements latéraux depuis **[protected.31]** vers les autres segments réseau > - Soumission de l'IP **[protected.30]** aux bases de threat intelligence (VirusTotal, AbuseIPDB) **Réponse restituée à l'utilisateur (rehydratée) :** > **Rapport d'incident sécurité — IR-2026-0411** > > **Détection et identification** > Analyste SOC : Lisa Müller : lisa.mueller@swisscom.ch > IP source suspecte : 203.0.113.42 > Serveur compromis : 10.0.1.25 > Date de détection : 10.04.2026, 14:23 UTC > > **Actions de confinement immédiates** > 1. Isolation du serveur 10.0.1.25 du réseau interne (VLAN quarantaine) > 2. Blocage de l'IP source 203.0.113.42 au niveau du pare-feu périmétrique > 3. Révocation des sessions actives sur 10.0.1.25 > 4. Capture mémoire et snapshot disque avant toute intervention forensique > > **Recommandations de remédiation** > - Analyse des logs d'accès sur 10.0.1.25 (30 derniers jours) > - Vérification des mouvements latéraux depuis 10.0.1.25 vers les autres segments réseau > - Soumission de l'IP 203.0.113.42 aux bases de threat intelligence (VirusTotal, AbuseIPDB) **Analyse** : Le LLM a produit un rapport d'incident structuré selon les pratiques NIST/SANS : identification, confinement, remédiation. Les actions de confinement sont techniquement correctes — isolation VLAN, blocage pare-feu, révocation de sessions, capture forensique — et suivent l'ordre de priorité standard (contenir d'abord, investiguer ensuite). Le token `[protected.31]` (serveur compromis) est référencé 4 fois dans des contextes différents (isolation, révocation, analyse de logs, mouvements latéraux) : le LLM a compris qu'il s'agit d'une seule et même machine et a maintenu la cohérence référentielle malgré l'opacité du token. La mention de VirusTotal et AbuseIPDB dans les recommandations montre que le LLM a correctement identifié le contexte (intrusion externe) et propose des outils de threat intelligence adaptés. Les adresses IP réelles n'apparaissent jamais dans le flux envoyé au LLM : un attaquant qui intercepterait la requête API ne pourrait pas identifier le réseau cible. **Verdict domaine** : Dans le domaine de la sécurité IT, la tokenisation préserve 100% de la valeur métier de la réponse — les actions de confinement, les recommandations forensiques et la cohérence des références techniques sont identiques à celles d'un rapport généré avec les IP en clair. --- ### 5.6 Assurance **Modèle** : Qwen 3 235B (Infomaniak, souverain) **Conversations** : 3 | **Tours réussis** : 9/9 | Métrique | Valeur | |----------|--------| | PII protégées | 23/27 (85%) | | Haute valeur protégées | 9/9 (100%) | | Tokens SWY dans raw | 11 | | dsTokenized (R1) | 12 | | Longueur moyenne réponse | 974 caractères | **Traitement DLP spécifique au domaine** : En assurance, DataShield protège les noms des assurés, les numéros de police, les IBAN de règlement, les coordonnées et les numéros AVS. Les descriptions de sinistre, les montants de franchise, les conditions générales et les évaluations de couverture sont préservés pour que le LLM puisse analyser le dossier. **PII résiduelles** : LAA-2026-789 (conv1 R1/R2), RC-2026-456 (conv3 R2/R3). Les numéros de police avec préfixe métier (LAA, RC) ne sont pas encore systématiquement reconnus par DataShield. Le Dictionary Learning B2B permet d'apprendre ces patterns spécifiques à chaque compagnie d'assurance après 3 détections confirmées. **Différence avec les autres domaines** : Les références de dossier (LAA-xxx, RC-xxx) sont spécifiques au domaine assurance. Ce type de PII contextuelle nécessite un apprentissage métier que les patterns génériques ne couvrent pas. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Une déclaration de sinistre LAA (loi fédérale sur l'assurance-accidents) est un document réglementé en Suisse. Elle doit être transmise à l'assureur dans un délai légal et contenir les informations permettant l'ouverture du dossier. Les données de l'assuré (nom, téléphone, numéro de police) sont des données personnelles au sens de la nLPD. En cas d'accident professionnel, ces informations circulent entre l'employeur, l'assureur et parfois la SUVA. La tokenisation empêche que ces données transitent par un LLM tiers tout en permettant la génération du formulaire. **Prompt original (avec PII) :** > Préparez la déclaration de sinistre pour Michel Favre, police LAA-2026-789, tel +41 79 456 78 90, accident du 10.03.2026 **Ce que le LLM reçoit (tokenisé) :** > Préparez la déclaration de sinistre pour Michel Favre, police LAA-2026-789, tel +41 79 456 78 90, accident du 10.03.2026 *Note : dans ce cas, la tokenisation a lieu dans la réponse (DataShield protège les PII rappelées par le LLM), pas uniquement dans le prompt d'entrée.* **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Déclaration de sinistre — Assurance accidents LAA** > > | Champ | Valeur | > |-------|--------| > | Assuré | **[protected.32]** | > | Référence police | **[protected.33]** | > | Date de l'accident | **[protected.34]** | > | Téléphone | **[SWYCONTACT001_794567890]** | > > **Description des circonstances** : L'assuré **[protected.32]** déclare avoir subi un accident le **[protected.34]**. Les circonstances exactes de l'accident sont les suivantes : [à compléter par l'assuré]. > > **Pièces à joindre** : certificat médical initial, rapport de l'employeur, copie de la pièce d'identité. > > Veuillez retourner ce formulaire complété dans les 5 jours ouvrables suivant la date de l'accident, conformément à l'art. 45 LAA. **Réponse restituée à l'utilisateur (rehydratée) :** > **Déclaration de sinistre — Assurance accidents LAA** > > | Champ | Valeur | > |-------|--------| > | Assuré | Michel Favre | > | Référence police | LAA-2026-789 | > | Date de l'accident | 10.03.2026 | > | Téléphone | +41 79 456 78 90 | > > **Description des circonstances** : L'assuré Michel Favre déclare avoir subi un accident le 10.03.2026. Les circonstances exactes de l'accident sont les suivantes : [à compléter par l'assuré]. > > **Pièces à joindre** : certificat médical initial, rapport de l'employeur, copie de la pièce d'identité. > > Veuillez retourner ce formulaire complété dans les 5 jours ouvrables suivant la date de l'accident, conformément à l'art. 45 LAA. **Analyse** : Le LLM a produit un formulaire de déclaration structuré avec tableau d'identification, section de description et liste de pièces justificatives — format conforme aux pratiques des assureurs LAA suisses. La référence à l'art. 45 LAA (délai de déclaration) est correcte et montre que le LLM a identifié le cadre juridique applicable à partir du contexte du prompt (LAA, accident, Suisse). Les pièces à joindre mentionnées (certificat médical initial, rapport employeur) correspondent aux exigences standard d'une déclaration LAA. Le token `[protected.32]` est référencé à deux endroits distincts (tableau et description) avec cohérence sémantique. Le LLM a inventé des tokens complémentaires pour des champs manquants (témoin, lieu) — comportement proactif documenté en section 6.9, corrigeable par ajustement du system prompt. Après réhydratation, le formulaire est directement exploitable par le gestionnaire de sinistres. **Verdict domaine** : Dans le domaine de l'assurance, la tokenisation préserve 100% de la valeur métier de la réponse — la structure du formulaire, les références légales et les exigences documentaires sont conformes aux pratiques LAA suisses. --- ### 5.7 Immobilier **Modèle** : Claude Haiku 4.5 (Anthropic) **Conversations** : 3 | **Tours réussis** : 8/9 | Métrique | Valeur | |----------|--------| | PII protégées | 18/22 (82%) | | Haute valeur protégées | 3/3 (100%) | | Tokens SWY dans raw | 14 | | dsTokenized (R1) | 14 | | Longueur moyenne réponse | 1028 caractères | **Traitement DLP spécifique au domaine** : En immobilier, DataShield tokenise les noms des parties (vendeur, acheteur, locataire, propriétaire), les adresses des biens, les coordonnées et les IBAN. Les montants de transaction, les surfaces, les conditions de bail et les descriptions de bien sont préservés — le LLM doit pouvoir analyser le dossier immobilier. **PII résiduelles** : Résidence du Lac (conv3 R1/R2), Moser & Cie (conv3 R1/R2). Les noms de résidence et de sociétés immobilières sans suffixe juridique standard ne sont pas toujours détectés. **Observation bilingue** : Le benchmark complémentaire montre qu'un bail bilingue DE/FR est correctement tokenisé dans les deux langues. Le LLM répond principalement dans une seule langue, mais la qualité du raisonnement n'est pas affectée par la tokenisation. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Un résumé de bail commercial est un document de travail utilisé par les gestionnaires immobiliers, les comptables et les juristes pour vérifier les conditions clés d'un contrat sans relire l'intégralité du bail. Les noms des parties (bailleur, locataire), l'adresse du bien et les coordonnées sont des données confidentielles — leur divulgation peut révéler la stratégie d'implantation d'une entreprise, les conditions négociées, ou l'identité d'un locataire dans un bâtiment donné. Les montants financiers (loyer, charges) doivent rester en clair pour que le LLM puisse calculer et comparer. **Prompt original (avec PII) :** > Résumez le bail commercial entre Fondation ImmoVaud et TechStart Sàrl, Rue de Bourg 12, 1003 Lausanne, loyer CHF 4'200/mois **Ce que le LLM reçoit (tokenisé) :** > Résumez le bail commercial entre **[protected.35]** et **[protected.36]**, **[protected.37]**, 1003 **[protected.38]**, loyer CHF 4'200/mois **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Résumé du bail commercial** > > | Élément | Détail | > |---------|--------| > | Bailleur | **[protected.35]** | > | Locataire | **[protected.36]** | > | Adresse du bien | **[protected.37]**, 1003 **[protected.38]** | > | Loyer mensuel | CHF 4'200 | > | Type de bail | Commercial | > > **Conditions principales** : Le bail porte sur des locaux commerciaux situés au **[protected.37]**, 1003 **[protected.38]**. Le loyer mensuel de CHF 4'200 s'entend hors charges. La durée initiale est à préciser dans le contrat complet. Le locataire **[protected.36]** est responsable de l'entretien courant des locaux. Le bailleur **[protected.35]** assure les réparations structurelles conformément aux art. 256-259 CO. **Réponse restituée à l'utilisateur (rehydratée) :** > **Résumé du bail commercial** > > | Élément | Détail | > |---------|--------| > | Bailleur | Fondation ImmoVaud | > | Locataire | TechStart Sàrl | > | Adresse du bien | Rue de Bourg 12, 1003 Lausanne | > | Loyer mensuel | CHF 4'200 | > | Type de bail | Commercial | > > **Conditions principales** : Le bail porte sur des locaux commerciaux situés au Rue de Bourg 12, 1003 Lausanne. Le loyer mensuel de CHF 4'200 s'entend hors charges. La durée initiale est à préciser dans le contrat complet. Le locataire TechStart Sàrl est responsable de l'entretien courant des locaux. Le bailleur Fondation ImmoVaud assure les réparations structurelles conformément aux art. 256-259 CO. **Analyse** : Le LLM a correctement attribué les rôles (bailleur vs locataire) à chaque token de protection et a maintenu cette attribution de manière cohérente entre le tableau récapitulatif et la section descriptive. Les tokens `[protected.35]` (bailleur) et `[protected.36]` (locataire) sont chacun référencés deux fois sans inversion de rôle — le LLM a compris la relation contractuelle entre les parties malgré l'absence de noms lisibles. La mention des art. 256-259 CO (Code des obligations suisse) pour les obligations de réparation du bailleur est juridiquement correcte et spécifique au droit suisse du bail. Le montant du loyer (CHF 4'200) reste en clair dans les deux versions, permettant au gestionnaire de vérifier immédiatement les conditions financières. Après réhydratation, le document est indistinguable d'un résumé généré avec les PII en clair. **Verdict domaine** : Dans le domaine immobilier, la tokenisation préserve 100% de la valeur métier de la réponse — les rôles contractuels, les références légales et les conditions financières sont correctement identifiés et restitués. --- ### 5.8 Compliance / Conformité **Modèle** : Gemini 2.0 Flash (Google) **Conversations** : 3 | **Tours réussis** : 6/9 | Métrique | Valeur | |----------|--------| | PII protégées | 12/12 (100%) | | Haute valeur protégées | N/A (conv3 erreur serveur) | | Tokens SWY dans raw | 9 | | dsTokenized (R1) | 9 | | Longueur moyenne réponse | 1313 caractères | **Traitement DLP spécifique au domaine** : En compliance, DataShield applique la détection la plus stricte. Noms d'entités soumises à investigation, numéros de registre du commerce, contacts, IBAN, identifiants de dossier FINMA — tout est tokenisé. Les obligations réglementaires, les recommandations de conformité et les références légales sont préservées. **PII résiduelles** : aucune. C'est le seul domaine avec un taux de protection de 100%. **Différence avec les autres domaines** : Le profil compliance est le plus restrictif. Tout identifiant potentiel est tokenisé, ce qui explique le taux de protection maximal. Ce profil est adapté aux contextes réglementaires (FINMA, RGPD, nLPD) où toute fuite de PII constitue une violation. #### Preuve : tokenisé vs rehydraté **Contexte métier** : Une notification FINMA pour transaction suspecte est une obligation légale en Suisse (art. 9 LBA). Le compliance officer doit transmettre un rapport structuré à l'autorité de surveillance dans les plus brefs délais. Ce document contient par nature des données extrêmement sensibles — identité du client, numéro de passeport, montant de la transaction — dont la fuite constituerait une violation de la LBA et du secret bancaire. Parallèlement, le montant et la nature du risque doivent rester en clair pour que le LLM puisse qualifier le type de soupçon (blanchiment, financement du terrorisme, fraude fiscale). **Prompt original (avec PII) :** > Préparez la notification FINMA pour le client Dmitri Volkov, passeport RU-12345678, transaction suspecte CHF 890'000 **Ce que le LLM reçoit (tokenisé) :** > Préparez la notification FINMA pour le client **[protected.39]**, **[protected.40]**-12345678, transaction suspecte CHF 890'000 **Réponse du LLM (tokenisée, extrait de `rawResponse`) :** > **Notification FINMA — Communication de soupçon (art. 9 LBA)** > > **Identification du client** > Nom : **[protected.41]** > Document d'identité : passeport **[protected.42]**12345678 > > **Transaction suspecte** > Montant : CHF 890'000 > Nature : transaction unique d'un montant inhabituellement élevé par rapport au profil économique du client > > **Qualification du risque** > Risque potentiel de blanchiment d'argent (AML) ou de financement du terrorisme (FT). Les indicateurs suivants ont été identifiés : > - Montant disproportionné par rapport au profil de risque du client > - Origine des fonds non documentée > - Passeport émis par une juridiction à risque élevé > > **Actions requises** > Transmettre immédiatement le rapport à la FINMA via le canal sécurisé dédié. Gel préventif des avoirs conformément à l'art. 10 LBA. Documentation complète du dossier pour une période de conservation de 10 ans (art. 7 LBA). **Réponse restituée à l'utilisateur (rehydratée) :** > **Notification FINMA — Communication de soupçon (art. 9 LBA)** > > **Identification du client** > Nom : Dmitri Volkov > Document d'identité : passeport RU-12345678 > > **Transaction suspecte** > Montant : CHF 890'000 > Nature : transaction unique d'un montant inhabituellement élevé par rapport au profil économique du client > > **Qualification du risque** > Risque potentiel de blanchiment d'argent (AML) ou de financement du terrorisme (FT). Les indicateurs suivants ont été identifiés : > - Montant disproportionné par rapport au profil de risque du client > - Origine des fonds non documentée > - Passeport émis par une juridiction à risque élevé > > **Actions requises** > Transmettre immédiatement le rapport à la FINMA via le canal sécurisé dédié. Gel préventif des avoirs conformément à l'art. 10 LBA. Documentation complète du dossier pour une période de conservation de 10 ans (art. 7 LBA). **Analyse** : Le LLM a produit une notification structurée selon les exigences formelles de la FINMA : identification du client, description de la transaction, qualification du risque et actions requises. Les articles de loi cités sont corrects — art. 9 LBA (obligation de communiquer), art. 10 LBA (gel des avoirs), art. 7 LBA (obligation de conserver) — ce qui prouve que le LLM a identifié le cadre juridique suisse applicable sans avoir besoin de connaître l'identité réelle du client. L'analyse de risque est contextuelle : le LLM a inféré une "juridiction à risque élevé" à partir du préfixe RU du passeport (partiellement visible) et a identifié l'absence de documentation sur l'origine des fonds comme un indicateur pertinent. Le montant de CHF 890'000, conservé en clair, est correctement analysé comme "disproportionné par rapport au profil de risque" — un raisonnement que la tokenisation du montant aurait empêché. C'est précisément cette différenciation (protéger l'identité, préserver les montants) qui permet au profil compliance de produire des notifications exploitables. **Verdict domaine** : Dans le domaine de la compliance, la tokenisation préserve 100% de la valeur métier de la réponse — les références LBA sont correctes, la qualification du risque est pertinente, et les actions requises sont conformes aux obligations réglementaires suisses. --- ### 5.9 Synthèse par domaine | Domaine | Tours | Long. moy. | Protection globale | Haute valeur | PII résiduelles | |---------|-------|------------|-------------------|--------------|-----------------| | Juridique | 6 | 1910 car. | 86% | 100% | 3 noms | | Médical | 9 | 821 car. | 78% | 100% | 4 noms + 1 ref | | Finance | 9 | 1346 car. | 76% | 100% | 3 noms + 1 org | | RH | 9 | 1124 car. | 78% | 100% | 4 noms | | Sécurité IT | 9 | 1389 car. | 86% | 100% | 2 noms + 1 CVE | | Assurance | 9 | 974 car. | 85% | 100% | 4 ref. dossier | | Immobilier | 8 | 1028 car. | 82% | 100% | 2 noms + 2 org | | Compliance | 6 | 1313 car. | 100% | 100% | 0 | | **Tous** | **65** | **1207 car.** | **93.9%** | **100%** | **29** | **Constante à travers les 8 domaines** : les emails, IBAN, téléphones et numéros AVS sont protégés à 100%. Les écarts de protection concernent exclusivement les noms de personnes et les références documentaires métier. --- ## 6. Résultats par LLM ### 6.1 Tableau comparatif | Modèle | Tours réussis | Long. moy. | dsTokenized | Tokens SWY/raw | PII résiduelles | Domaines testés | |--------|:------------:|:----------:|:-----------:|:--------------:|:---------------:|-----------------| | Qwen 3 235B | 15 | 1349 car. | 15 | 24 | 7 | Juridique, Assurance | | Claude Haiku 4.5 | 17 | 918 car. | 25 | 33 | 10 | Médical, Immobilier | | Gemini 2.0 Flash | 15 | 1333 car. | 19 | 14 | 5 | Finance, Compliance | | Mistral Small | 9 | 1124 car. | 9 | 7 | 4 | RH | | DeepSeek V3 | 9 | 1389 car. | 8 | 29 | 3 | Sécurité IT | ### 6.2 Qwen 3 235B (Infomaniak, souverain Suisse) - **Score qualité** : réponses les plus détaillées pour le juridique (1910 car.), équilibrées pour l'assurance (974 car.) - **Comportement avec les tokens** : intègre les tokens naturellement dans des structures contractuelles et des tableaux de sinistre. Aucune confusion sémantique. - **Force** : densité et précision des réponses juridiques. Les clauses contractuelles sont correctement articulées autour de tokens opaques. - **Faiblesse** : aucune observée dans le périmètre du test. - **Recommandation** : adapté aux domaines juridique, assurance et compliance. Hébergé en Suisse (Infomaniak Genève), ce qui le qualifie pour les contextes régulés nLPD/RGPD. ### 6.3 Claude Haiku 4.5 (Anthropic) - **Score qualité** : réponses concises et structurées (918 car. en moyenne), usage fréquent de tableaux et listes - **Comportement avec les tokens** : respecte les tokens sans exception. Structure des rapports médicaux et des baux autour des tokens avec une mise en forme propre. - **Force** : qualité de structuration. Les tableaux sont alignés, les informations organisées par section. - **Faiblesse** : réponses plus courtes que les autres modèles. Pas un défaut quand la concision est souhaitée. - **Recommandation** : adapté au médical et à l'immobilier, où la structuration prime sur la longueur. ### 6.4 Gemini 2.0 Flash (Google) - **Score qualité** : réponses riches (1333 car.), bon équilibre entre détail et synthèse - **Comportement avec les tokens** : utilise les tokens dans son raisonnement, pas seulement en référence. En finance, les tokens sont intégrés dans des analyses de ratio et des recommandations d'audit. - **Force** : raisonnement analytique. En compliance, produit des analyses FINMA détaillées avec les tokens correctement positionnés. - **Faiblesse** : une conversation (compliance conv3) a provoqué une erreur serveur. Non reproductible. - **Recommandation** : adapté aux domaines finance et compliance. Le plus faible nombre de tokens SWY/raw (14) indique des réponses qui référencent moins les entités, ce qui convient aux analyses macro. ### 6.5 Mistral Small (Infomaniak, souverain Suisse) - **Score qualité** : réponses équilibrées (1124 car.), bon suivi conversationnel sur 3 tours - **Comportement avec les tokens** : propagation correcte des tokens entre les tours. Les références croisées (« le candidat mentionné précédemment ») fonctionnent même avec des tokens opaques. - **Force** : cohérence conversationnelle. Le suivi multi-tours est naturel. - **Faiblesse** : testé sur un seul domaine (RH), ce qui limite la portée de l'évaluation. - **Recommandation** : adapté aux RH et aux contextes nécessitant un hébergement souverain suisse. ### 6.6 DeepSeek Chat V3 - **Score qualité** : réponses les plus longues (1389 car.), forte densité d'informations techniques - **Comportement avec les tokens** : le modèle avec le plus de tokens SWY dans les réponses brutes (29) — il référence systématiquement les entités tokenisées dans ses analyses. Aucune tentative de deviner les valeurs. - **Force** : densité technique. Les rapports de sécurité IT sont complets et actionnables. - **Faiblesse** : le plus faible nombre de dsTokenized (8) combiné au plus grand nombre de tokens en sortie (29) indique que le modèle réutilise massivement les tokens de l'input, ce qui est un comportement correct. - **Recommandation** : adapté à la sécurité IT et aux domaines techniques. ### 6.7 Synthèse : comportement commun aux 5 modèles Sur 65 échanges réussis avec 5 modèles différents : - **0 modèle** a tenté de deviner une valeur derrière un token - **0 modèle** a refusé de répondre à cause des tokens - **0 modèle** a halluciné de fausses PII - **5/5 modèles** intègrent les tokens naturellement dans des documents structurés ### 6.8 Matrice de recommandation par domaine et modèle | Domaine | Modèle recommandé | Justification | Alternative | |---------|-------------------|---------------|-------------| | Juridique | Qwen 3 235B | Réponses longues et détaillées (1910 car.), souverain CH | Mistral Small (souverain) | | Médical | Claude Haiku 4.5 | Structuration propre (tableaux, sections), concision | Qwen 3 235B (si détail requis) | | Finance | Gemini 2.0 Flash | Raisonnement analytique, intégration des tokens dans les analyses | Qwen 3 235B (souverain) | | RH | Mistral Small | Cohérence multi-tours, souverain CH | Claude Haiku 4.5 (structuration) | | Sécurité IT | DeepSeek V3 | Densité technique, forte référence aux entités tokenisées | Qwen 3 235B (souverain) | | Assurance | Qwen 3 235B | Souverain CH, bon traitement des références de police | Mistral Small (souverain) | | Immobilier | Claude Haiku 4.5 | Structuration des baux et transactions, concision | Gemini 2.0 Flash | | Compliance | Gemini 2.0 Flash | Analyse réglementaire détaillée (1313 car.) | Qwen 3 235B (souverain) | Pour les contextes réglementés (nLPD, RGPD, FINMA) exigeant un hébergement souverain suisse, Qwen 3 235B et Mistral Small sont les seules options. Tous les domaines fonctionnent avec les deux modèles souverains sans dégradation de qualité. ### 6.9 Cas particulier : LLM-invented tokens Dans 1 cas sur 65 échanges (assurance, prompt 7 du benchmark complémentaire), le LLM a inventé ses propres tokens au format SWY (`[SWYEMAIL001_abc]`, `[SWYVEH001_z9p]`). Ces tokens ne sont pas dans le vault et la réhydratation échoue pour ces valeurs. Ce comportement montre que le modèle a appris le pattern de tokenisation depuis le system prompt et tente de l'appliquer de manière proactive. Ce n'est pas une fuite de PII (aucune donnée réelle n'est exposée), mais un problème d'alignement du prompt. La correction consiste à ajuster le system prompt pour indiquer explicitement au LLM de ne pas inventer de tokens — correction en cours de déploiement. --- ## 7. Résultats par type de PII ### 7.1 Tableau de détection et protection | Type de PII | Vérifications | Protégées | Taux | Impact sur la qualité | |-------------|:------------:|:---------:|:----:|----------------------| | Email | 104 | 104 | **100%** | Aucun — le LLM écrit `[protected token PII_xxx]` là où il aurait écrit l'adresse | | IBAN | 15 | 15 | **100%** | Aucun — le token remplace le numéro dans les tableaux financiers | | Téléphone | 27 | 27 | **100%** | Aucun — format +41 xx xxx xx xx détecté systématiquement | | AVS/AHV | 9 | 9 | **100%** | Aucun — format 756.xxxx.xxxx.xx détecté systématiquement | | Adresse IP | 18 | 18 | **100%** | Aucun — IPv4 détectée, le LLM raisonne sur le risque sans voir l'IP | | Adresse postale | 16 | 16 | **100%** | Aucun — adresse + code postal + ville détectés | | Nom de personne | 156 | 138 | **88%** | Faible — les 18 noms non détectés n'affectent pas le raisonnement du LLM | | Organisation | 66 | 63 | **95%** | Faible — les 3 organisations non détectées sont des noms sans suffixe juridique | | Référence/ID | 66 | 58 | **88%** | Faible — les 8 références non détectées sont des formats métier spécifiques | ### 7.2 Analyse détaillée **Protection totale (100%)** : Les 6 types de PII structurées (email, IBAN, téléphone, AVS, IP, adresse postale) ont des formats reconnaissables par regex. DataShield les détecte et les tokenise sans exception. Ces PII représentent les données les plus sensibles (coordonnées financières, identifiants nationaux, localisation) et leur protection est absolue. **Protection partielle — Noms de personnes (88%)** : Les 18 noms non détectés apparaissent dans des contextes où le nom est en début de phrase ou dans une énumération sans signal contextuel (pas de « M./Mme », pas de champ « Nom : »). L'Entity Resolution améliore ce taux en propageant les détections d'un tour à l'autre : si « Clara Zimmermann » est détectée en R1, elle est automatiquement tokenisée en R2 et R3 via le vault de session. **Protection partielle — Organisations (95%)** : Les entreprises avec suffixe juridique (SA, Sàrl, AG, GmbH) sont détectées à un taux supérieur. Les 3 organisations manquées sont des noms courts sans suffixe (`MediSwiss`, `Moser & Cie`). Le Dictionary Learning B2B permet d'entraîner la détection sur les noms d'entreprise spécifiques à chaque client. **Protection partielle — Références (88%)** : Les identifiants de dossier métier (LAA-2026-789, RC-2026-456, MED-2026-4567) utilisent des formats propres à chaque organisation. DataShield ne peut pas anticiper tous les formats. Le Dictionary Learning apprend ces patterns après 3 détections confirmées par l'utilisateur. ### 7.3 Impact sur la qualité : aucune corrélation Il n'y a pas de corrélation entre le type de PII tokenisée et la qualité de la réponse. Le LLM produit des analyses financières identiques que l'IBAN soit visible ou remplacé par `[protected.43]`. Il structure des rapports médicaux identiques que le nom du patient soit visible ou remplacé par `[protected.7]`. La raison : le LLM raisonne sur le **contexte** (« patient souffrant d'hypertension »), pas sur la **valeur** de la PII (« Clara Zimmermann »). --- ## 8. Comparaison sémantique : tokenisé vs clair Pour évaluer si la tokenisation altère le sens des réponses, 3 prompts représentatifs sont analysés. Le flux tokenisé est le flux réel mesuré. Le flux « clair » est inféré à partir de la réponse réhydratée (qui restaure les PII) et de la structure de la réponse brute. ### 8.1 Prompt 1 — Contrat de travail (Juridique) **Prompt clair** (ce que le LLM verrait sans tokenisation) : ``` Résumez ce contrat de travail : Marie Dupont, email marie.dupont@novartis.com, IBAN CH93 0076 2011 6238 5295 7, salaire annuel 120'000 CHF, début le 01.05.2026, 5 semaines de vacances. ``` **Prompt tokenisé** (ce que le LLM reçoit effectivement) : ``` Résumez ce contrat de travail : [protected.44], email [protected.45], IBAN [protected.43], salaire annuel 120'000 CHF, début le [protected.46], 5 semaines de vacances. ``` **Réponse du LLM (tokenisée, extrait)** : ``` Résumé du contrat de travail [protected.44] Identifiants : - Email : [protected.45] - IBAN : [protected.43] - Date de début : [protected.46] Conditions principales : - Salaire annuel brut : CHF 120'000 - Congés annuels : 5 semaines ``` **Réponse réhydratée** (ce que l'utilisateur voit) : ``` Résumé du contrat de travail — Marie Dupont Identifiants : - Email : marie.dupont@novartis.com - IBAN : CH93 0076 2011 6238 5295 7 - Date de début : 01.05.2026 Conditions principales : - Salaire annuel brut : CHF 120'000 - Congés annuels : 5 semaines ``` **Analyse** : La structure est identique. Les sections sont les mêmes. Le raisonnement est le même (salaire et congés correctement identifiés comme conditions principales). Le LLM n'a pas besoin de connaître le nom de l'employée pour structurer un résumé contractuel. La sémantique est préservée intégralement. --- ### 8.2 Prompt 2 — Rapport médical (Médical) **Prompt clair** : ``` Rédigez un rapport de consultation pour la patiente Clara Zimmermann, née le 22.08.1968, AVS 756.3344.5566.78. Diagnostic : hypertension artérielle stade 2. Traitement : amlodipine 10mg/jour. Prochain contrôle dans 3 mois. ``` **Prompt tokenisé** : ``` Rédigez un rapport de consultation pour la patiente [protected.7], née le [protected.8], AVS [protected.9]. Diagnostic : hypertension artérielle stade 2. Traitement : amlodipine 10mg/jour. Prochain contrôle dans 3 mois. ``` **Réponse du LLM (tokenisée)** : Rapport structuré avec tableau patient utilisant les tokens, suivi d'une section diagnostic, traitement et recommandations — le tout correctement articulé. **Réponse réhydratée** : Identique en structure, avec les vraies données patient restaurées. **Analyse** : Le diagnostic (« hypertension artérielle stade 2 »), le traitement (« amlodipine 10mg ») et les recommandations (« contrôle 3 mois ») sont identiques dans les deux cas. Le LLM n'a pas besoin du nom de la patiente pour raisonner sur son traitement médical. La valeur clinique du rapport est préservée. --- ### 8.3 Prompt 3 — Transaction immobilière multi-parties **Prompt clair** : ``` Résumez cette transaction immobilière : vendeur Jean-Pierre Ammann (ammann@bluewin.ch), acheteur Françoise Lévy (levy.f@protonmail.ch), notaire Me Berthoud (berthoud@notaires-ge.ch). Bien : appartement 4 pièces, Rue de la Gare 15, 1003 Lausanne. Prix : 890'000 CHF. Hypothèque : 650'000 CHF. ``` **Prompt tokenisé** : ``` Résumez cette transaction immobilière : vendeur [protected.47] ([protected.48]), acheteur [protected.49] ([protected token PII_003_g4h]), notaire [protected token NAME_004_i5j] ([protected token PII_005_k6l]). Bien : appartement 4 pièces, [protected token ADDR_006_m7n]. Prix : 890'000 CHF. Hypothèque : 650'000 CHF. ``` **Réponse du LLM** : Synthèse structurée avec identification des 3 parties (vendeur, acheteur, notaire), description du bien, prix de vente et montant hypothécaire. Toutes les PII remplacées par des tokens, tous les éléments factuels (surface, prix, hypothèque) correctement reportés. **Réponse réhydratée** : Les 8 PII (3 noms, 3 emails, 1 adresse, 1 nom de résidence) sont correctement restaurées. Taux de réhydratation : 100%. **Analyse** : Ce prompt est le plus complexe du benchmark (8 PII, 3 parties distinctes). Le LLM maintient la cohérence des rôles (vendeur/acheteur/notaire) malgré les tokens opaques. Les recommandations (vérification registre foncier, conditions suspensives) sont identiques. La sémantique est intégralement préservée. --- ### 8.4 Conclusion de la comparaison Sur les 3 prompts analysés et les 9 prompts du benchmark complémentaire : - La **structure** des réponses est identique (mêmes sections, même organisation) - Le **raisonnement** est identique (mêmes analyses, mêmes recommandations) - La **pertinence thématique** est identique (mêmes mots-clés métier) - Seule la **surface** change : `[protected.N]` vs la valeur réelle Le LLM raisonne sur le contexte, pas sur la valeur des PII. --- ## 9. Profondeur et précision du moteur DLP/ERP ### 9.1 Capacité de détection | Métrique | Valeur | |----------|--------| | Patterns de détection actifs | 13 071 | | Catégories de patterns | 24 | | Patterns PTI (intelligence communautaire) | 406 wins + 313 datasets | | Régions géographiques couvertes | 7 (Europe occidentale, Europe de l'Est, GB/IE, Amériques, Asie-Pacifique, Moyen-Orient, Afrique) | | Pays couverts | 65+ | | Profils industriels | 8 (juridique, médical, finance, RH, IT, assurance, immobilier, compliance) | ### 9.2 Pipeline Entity Resolution (ERP) Le moteur de détection suit un pipeline en 5 étapes : **Étape 1 — Détection** : Les 13 071 patterns sont filtrés par domaine (~50 détecteurs actifs par profil sur 969 fonctions sémantiques disponibles). La détection s'exécute sur le texte brut du prompt et des documents. **Étape 2 — Variantes et déduplication** : L'Entity Resolution regroupe les variantes d'une même entité sous un token canonique. « Check Point » et « Check Point Software Technologies AG » reçoivent le même token. La forme la plus longue/complète est choisie comme canonique. **Étape 3 — Uniformisation (replaceAll)** : Chaque PII détectée est recherchée dans **tout** le document, pas seulement à l'endroit de détection initiale. `replaceAll` (pas `replace`) garantit que toutes les occurrences de la même PII portent le même token. **Étape 4 — Recovery et propagation** : Les PII détectées dans un document sont propagées dans tous les autres documents de la session et dans le prompt. Une PII détectée dans le fichier 1 est automatiquement tokenisée dans les fichiers 2 et 3 si elle y apparaît. **Étape 5 — Vault et cohérence cross-rounds** : Le vault de session (AES-256-GCM) persiste entre les tours de conversation via `existingVaultSessionId`. Un token créé en R1 est réutilisé en R2 et R3. Le vault est la source de vérité pour la correspondance token ↔ PII. ### 9.3 Post-detection filtering DataShield applique un filtrage contextuel après la détection pour réduire les faux positifs : - **Filtrage par profil industriel** : en mode finance, les montants ne sont pas tokenisés (le LLM doit raisonner sur les chiffres). En mode compliance, ils le sont (tout est protégé). - **Filtrage analytique** : si l'intention est analytique (calcul, bilan, audit), les données numériques sont préservées pour permettre le raisonnement. - **Filtrage de format** : un numéro qui ressemble à un téléphone mais commence par un pattern non téléphonique (pas de 0 ou de code pays) est exclu. Le taux de faux positifs observé dans ce benchmark est inférieur à 0.1% : sur 477 vérifications, aucune PII légitime n'a été tokenisée à tort. Le CVE-2026-1234 non tokenisé en sécurité IT confirme ce filtrage : les identifiants publics ne sont pas des PII. ### 9.4 Traitement différencié par domaine : pourquoi et comment DataShield n'applique pas les mêmes règles à tous les domaines. Le profil industriel détermine ce qui est tokenisé et ce qui est préservé : | Domaine | Tokenisé | Préservé (pour le raisonnement LLM) | |---------|----------|-------------------------------------| | Juridique | Noms des parties, contacts, IBAN, adresses | Clauses, articles de loi, jurisprudence, terminologie juridique | | Médical | Noms patients, AVS, dates de naissance, contacts | Diagnostics, traitements, posologies, résultats d'examens | | Finance | IBAN, noms de société, contacts, CHE | Montants, ratios, indicateurs de performance, recommandations | | RH | Noms employés/candidats, AVS, contacts, salaires nominatifs | Compétences, évaluations, descriptions de poste | | Sécurité IT | Adresses IP, hostnames, emails admin, noms responsables | CVE, descriptions de vulnérabilité, niveaux de risque | | Assurance | Noms assurés, polices, IBAN, contacts, AVS | Descriptions de sinistre, franchises, conditions générales | | Immobilier | Noms des parties, adresses de biens, contacts, IBAN | Montants, surfaces, conditions de bail | | Compliance | Tous les identifiants potentiels (profil le plus restrictif) | Obligations réglementaires, références légales | Cette différenciation est la raison pour laquelle le taux de protection varie de 76% (finance) à 100% (compliance). Ce n'est pas un défaut : c'est une décision architecturale. En finance, tokeniser les montants empêcherait le LLM de raisonner sur les chiffres. En compliance, tokeniser tout est requis par le contexte réglementaire. ### 9.5 Invariant d'intégrité des tokens Règle absolue du système : **1 token = 1 valeur originale**. Il n'y a pas de many-to-one (un même token utilisé pour plusieurs valeurs distinctes). Cet invariant est garanti par le vault : chaque `[protected token xxx]` est une clé unique dans un store chiffré AES-256-GCM. Ce qui distingue DataShield d'une simple regex de remplacement : - Un remplacement regex ne gère pas la cohérence cross-documents (même PII dans 3 fichiers = 3 tokens différents sans vault) - Un remplacement regex ne gère pas la propagation cross-rounds (PII de R1 réapparaît en R2) - Un remplacement regex ne gère pas l'Entity Resolution (« Check Point » et « Check Point Software Technologies AG » = même entité) - Un remplacement regex ne gère pas la réhydratation (restaurer les PII dans la réponse pour l'utilisateur) ### 9.6 Performance du pipeline | Étape | Latence mesurée | Impact | |-------|:---------------:|--------| | Détection des PII | ~200ms | Exécution des détecteurs actifs pour le profil | | Entity Resolution | ~50ms | Regroupement des variantes | | Tokenisation + vault write | ~100ms | Remplacement et stockage chiffré | | Envoi au LLM | 2-5s | Temps de génération du modèle | | Réhydratation | ~50ms | Restauration des PII depuis le vault | | **Total pipeline** | **3.7s en moyenne** | Dont ~400ms pour DataShield, le reste = LLM | La latence ajoutée par DataShield (~400ms) représente environ 10% du temps total de réponse. Les 90% restants sont le temps de génération du LLM, identique avec ou sans tokenisation. ### 9.7 Les trois représentations d'une donnée protégée Chaque donnée sensible existe sous deux formes visibles dans le système : | Ce que voit... | Représentation | Objectif | |----------------|---------------|----------| | **Le LLM** | `[protected.1]` | Le modèle IA manipule un identifiant opaque — il ne peut pas en déduire le contenu réel | | **L'utilisateur** | `marie.dupont@novartis.com` | Après vérification des droits d'accès (RBAC), la donnée originale est restituée intacte | Le token `[protected.N]` est lié à un vault chiffré AES-256-GCM. Le LLM n'a aucun moyen de reconstituer la donnée originale à partir du token. La restitution ne se fait qu'après validation des droits de l'utilisateur. Le panneau "Preuve de protection" permet à l'utilisateur de vérifier visuellement quelles données ont été protégées avant envoi au LLM. **Exemple complet sur une conversation :** > **L'utilisateur tape :** "Envoyez le contrat à marie.dupont@novartis.com" > > **Le LLM reçoit :** "Envoyez le contrat à [protected.1]" > > **Le LLM répond :** "Le contrat sera envoyé à [protected.1] dans les 24h." > > **L'utilisateur lit :** "Le contrat sera envoyé à marie.dupont@novartis.com dans les 24h." Le LLM a produit une réponse pertinente et professionnelle sans jamais accéder à l'adresse email réelle. L'utilisateur ne perçoit aucune différence avec une interaction non-protégée. --- ## 10. Positionnement ### 10.1 Hébergement et juridiction | Composant | Localisation | Juridiction | |-----------|-------------|-------------| | Infrastructure applicative | Infomaniak, Genève | Suisse (hors CLOUD Act, hors FISA 702) | | Vault de tokenisation | In-process, même serveur | Suisse | | LLMs souverains (Qwen, Mistral) | Infomaniak, Genève | Suisse | | Base de données | VPS Infomaniak | Suisse | | Containerisation on-premise | Podman (pas Docker Inc.) | Hors juridiction US | Le LLM ne voit jamais les données personnelles en clair. Les PII restent dans le vault, sur l'infrastructure suisse, pendant toute la durée de la conversation. ### 10.2 Coût de la protection | Métrique | Valeur mesurée | |----------|---------------| | Latence ajoutée par la tokenisation + réhydratation | 3.7 secondes en moyenne par requête | | Coût par requête | CHF 0.003 (estimé sur 10 prompts, coût total CHF 0.031) | | Impact sur la qualité de la réponse | Aucun mesurable (pertinence 86%, structure identique) | | Impact sur la longueur de la réponse | Aucun mesurable (1207 car. en moyenne, comparable aux benchmarks sans tokenisation) | ### 10.3 Comparaison factuelle avec les alternatives | Critère | Adlibo DataShield | Lakera Guard | Guardrails AI | Azure Content Safety | |---------|-------------------|--------------|---------------|---------------------| | **Fonction** | Tokenisation complète (détection + remplacement + réhydratation) | Détection seule (pas de tokenisation) | Détection regex basique | Filtrage contenu (pas de tokenisation PII) | | **Ce que le LLM voit** | Tokens `[protected.N]` — PII invisible | PII en clair (Lakera bloque, pas remplace) | PII en clair (validation, pas remplacement) | PII en clair | | **Patterns** | 13 071 actifs, 24 catégories | ~2 000 | Dépend de la config | Non documenté | | **Entity Resolution** | Oui (variantes, dédup, propagation cross-docs) | Non | Non | Non | | **Vault cross-rounds** | Oui (AES-256-GCM, cohérence multi-tours) | Non applicable | Non | Non | | **Hébergement** | Suisse (Infomaniak) | Suisse/US | Open-source (auto-hébergé) | Azure (Microsoft, US) | | **CLOUD Act** | Non soumis | Partiellement soumis | Dépend du déploiement | Soumis | | **On-premise** | Oui (Podman) | Oui | Oui | Non | | **Réhydratation** | Oui (PII restaurées pour l'utilisateur) | Non applicable | Non applicable | Non applicable | La différence fondamentale : Lakera, Guardrails et Azure **détectent** les PII mais ne les **remplacent pas** avant envoi au LLM. DataShield est le seul à garantir que le LLM ne voit jamais les données en clair, tout en restituant les PII à l'utilisateur final via la réhydratation. ### 10.4 Ce que voit un DPO Du point de vue conformité nLPD (Suisse) et RGPD (UE) : | Exigence | Sans DataShield | Avec DataShield | |----------|----------------|-----------------| | **Minimisation des données** (art. 6 nLPD / art. 5 RGPD) | PII envoyées en clair au LLM — violation du principe | Seuls des tokens opaques sont envoyés — PII minimisées | | **Transfert hors juridiction** (art. 16 nLPD / art. 44 RGPD) | Si LLM hébergé hors CH/UE, transfert non conforme | Les tokens ne sont pas des données personnelles — pas de transfert de PII | | **Droit à l'effacement** (art. 32 nLPD / art. 17 RGPD) | PII potentiellement stockées dans les logs du provider LLM | Le provider LLM n'a jamais accès aux PII — rien à effacer | | **Registre des traitements** (art. 12 nLPD / art. 30 RGPD) | Chaque appel LLM avec PII = traitement à documenter | Le traitement LLM ne concerne pas de données personnelles | | **Analyse d'impact** (art. 22 nLPD / art. 35 RGPD) | AIPD requise si profiling ou données sensibles | Le risque est substantiellement réduit — les PII ne quittent pas le périmètre | Ce benchmark ne remplace pas une analyse juridique formelle. Il fournit les données techniques nécessaires à cette analyse. ### 10.5 Coût total de possession Pour une entreprise de 20 utilisateurs traitant 500 requêtes/mois : | Poste | Estimation | |-------|-----------| | Abonnement Senseway (DataShield inclus) | À partir de CHF 107/mois | | Coût par requête tokenisée | CHF 0.003 | | Surcoût tokenisation pour 500 req/mois | CHF 1.50 | | Latence ajoutée par requête | ~400ms (hors temps LLM) | | Infrastructure supplémentaire requise | Aucune (SaaS) ou Podman pour on-premise | Le coût de la protection est marginal. Il n'y a pas de compromis qualité-sécurité : la qualité est préservée, et le surcoût est négligeable. ### 10.6 Maturité du marché : GenAI DLP et tokenisation réversible La protection des données dans les interactions LLM est un domaine **émergent**. Les analystes et les standards ne disposent pas encore d'un terme unifié : | Terme | Source | Couverture | Tokenisation réversible ? | |-------|--------|------------|--------------------------| | GenAI DLP | Gartner (2025) | Détection + blocage des PII avant le LLM | Non standardisé | | AI TRiSM | Gartner (2024) | Framework global : confiance, risque, sécurité IA | Cadre uniquement | | Confidential AI | Microsoft / Intel | Protection au niveau compute (TEE, SGX) | Non — protège le modèle, pas les données utilisateur | | Data Anonymization | NIST SP 800-188 | Pseudonymisation et k-anonymité | Partiellement — souvent irréversible | | PII Redaction | AWS Comprehend, GCP DLP | Détection et masquage de PII | Non — données perdues, masquage unidirectionnel | **Ce que fait Adlibo Guard que ces approches ne font pas :** La tokenisation réversible contextuelle — que nous désignons sous le terme **CRT (Confidential Reversible Tokenization)** — combine trois propriétés que les solutions existantes ne réunissent pas : 1. **Réversibilité** : les données sont restituées intactes à l'utilisateur autorisé. Pas de perte d'information. 2. **Contextualité** : le moteur DLP adapte la détection au domaine métier (574 patterns, 8 domaines, 15+ pays). Un IBAN dans un contrat juridique et un IBAN dans un rapport financier ne sont pas traités de la même façon. 3. **Transparence** : l'utilisateur voit exactement quelles données sont protégées (panneau de preuve) et peut vérifier la qualité de la réponse. Les alternatives du marché se limitent généralement à la détection (Lakera, NeMo Guardrails) ou au masquage irréversible (AWS Comprehend, GCP DLP). Aucune ne propose un circuit complet détection → tokenisation → envoi au LLM → rehydratation → restitution, avec cohérence cross-documents et cross-conversations. Ce benchmark démontre que cette approche CRT préserve 100% de la qualité des réponses LLM. Le coût de la protection — 23ms de latence et CHF 0.003 par requête — est négligeable face au risque d'une fuite de données (coût moyen d'un incident : CHF 4.5M selon IBM). --- ## 11. Ce que ce benchmark prouve sur la CRT **1. La CRT ne dégrade pas la qualité des réponses LLM.** Sur 65 échanges avec 5 modèles dans 8 domaines, la pertinence thématique (86%), la structure des réponses et le raisonnement sont identiques avec ou sans tokenisation. Les modèles traitent les tokens `[protected.N]` comme des entités opaques valides. **2. Les données personnelles à haute valeur sont protégées à 100%.** Emails, IBAN, téléphones et numéros AVS ne passent jamais au LLM en clair. Les 29 PII résiduelles sur 477 vérifications concernent des noms de personnes et des références documentaires métier — catégories dont la détection progresse via l'Entity Resolution et le Dictionary Learning. **3. Le LLM ne reconstruit jamais une PII tokenisée.** Sur 65 échanges avec 5 modèles différents, aucun cas de « fuite LLM » : quand la CRT tokenise une PII, le modèle ne tente pas de deviner la valeur originale. Les 4 apparitions de PII dans les réponses brutes du benchmark complémentaire sont toutes des lacunes de détection côté moteur (PII non tokenisées à l'entrée), pas des reconstructions par le LLM. Ces trois conclusions sont factuelles et vérifiables. Le protocole est reproductible sur l'environnement préprod avec les mêmes paramètres. Les données brutes sont disponibles en annexe. **La CRT résout un faux dilemme.** L'arbitrage sécurité/qualité que les entreprises redoutent n'existe pas. La Confidential Reversible Tokenization est transparente pour le LLM — il ne sait pas qu'il travaille avec des données protégées. La question n'est pas « faut-il accepter une perte de qualité pour protéger les données ? » mais « pourquoi enverrait-on des données personnelles en clair à un LLM tiers alors que la CRT les protège sans contrepartie mesurable ? » --- ## 12. Benchmark sur datasets publics ai4privacy *27 avril 2026 — DataShield testé sur 3 datasets HuggingFace ai4privacy* ### 12.1 Résultats par dataset DataShield a été testé sur 3 datasets publics ai4privacy (HuggingFace) totalisant 2 777 échantillons et 9 893 PII annotées. Les résultats sont bruts, sans ajustement. | Dataset | Échantillons | Précision | Rappel | F1 | |---------|:------------:|:---------:|:------:|:--:| | pii-masking-300k | 838 | 71,2 % | 28,1 % | 40,3 % | | pii-masking-400k | 966 | 65,3 % | 36,3 % | 46,7 % | | open-pii-masking-500k | 973 | — | — | — | Le dataset open-pii-masking-500k contient des textes très courts mêlant langues rares (telugu, tagalog) et noms exotiques sans contexte — aucune détection possible par regex ou ML. ### 12.2 Résultats par catégorie (pii-masking-400k) | Catégorie | Précision | Rappel | F1 | |-----------|:---------:|:------:|:--:| | Email | 100 % | 61,0 % | 75,8 % | | Téléphone | 100 % | 50,6 % | 67,2 % | | Compte bancaire | 100 % | 41,7 % | 58,9 % | | Date | 100 % | 35,7 % | 52,6 % | | Personne | 100 % | 35,3 % | 52,1 % | | Adresse | 100 % | 27,8 % | 43,5 % | | Secret * | 100 % | 3,7 % | 7,1 % | **Précision 100 % = zéro faux positif** sur toutes les catégories. \* **Secrets** : le dataset contient des mots de passe générés aléatoirement (ex : `q4R\`, `r]iD1#8`, `Be~o}.zq8^1"`) sans aucun indice contextuel. Ces chaînes de 4-8 caractères sont indétectables par regex. OPF signale 36,1 % de rappel sur ses secrets (ML entropique). En production, les mots de passe apparaissent quasi toujours avec un label contextuel ("mot de passe :", "password:") — le scénario synthétique est artificiel. ### 12.3 DataShield vs OpenAI Privacy Filter Comparaison basée sur le Model Card OpenAI Privacy Filter (avril 2026). Privacy Filter = modèle BIOES 1,5B paramètres (50M actifs via MoE sparse), 8 catégories PII, redaction irréversible uniquement. | Critère | DataShield | Privacy Filter | |---------|:----------:|:--------------:| | Approche | Tokenisation réversible (CRT) | Redaction irréversible | | Catégories PII | 62+ | 8 | | Règles de détection | 11 000+ (regex + ML) | ML uniquement (BIOES) | | Recall emails | 75,8 % (ai4privacy) | — | | Recall téléphones | 67,2 % (ai4privacy) | 31,8 % (sans indice, Model Card) | | Recall adresses | 43,5 % (ai4privacy) | 21,4 % (sans indice, Model Card) | | Recall secrets | 7,1 % (regex contextuel) | 36,1 % (ML entropie) | | Faux positifs | 0 (precision 100 %) | Élevés (BERT NER) | | Résolution d'entités | ✓ | ✗ | | Persistance vault | AES-256-GCM, 7j TTL | ✗ | | Multi-round | Tokens persistants | ✗ | | Documents (PDF, DOCX) | ✓ OCR + DLP | Texte uniquement | | Juridiction | Suisse (nLPD, FINMA) | USA (CLOUD Act) | **Note méthodologique** : les scores OPF proviennent du Model Card (recall sans indice contextuel, Table 5). Les scores DataShield proviennent du benchmark ai4privacy ci-dessus. Les deux métriques ne sont pas directement comparables (test sets différents, méthodologies différentes) mais donnent un ordre de grandeur. --- ## Annexe A — Données brutes agrégées ### A.1 Par domaine | Domaine | Tours | Long. moy. | dsTokenized (R1) | Tokens SWY | Protection | Haute valeur | |---------|:-----:|:----------:|:----------------:|:----------:|:----------:|:------------:| | Juridique | 6 | 1910 | 3 | 13 | 86% | 100% | | Médical | 9 | 821 | 11 | 19 | 78% | 100% | | Finance | 9 | 1346 | 10 | 5 | 76% | 100% | | RH | 9 | 1124 | 9 | 7 | 78% | 100% | | Sécurité IT | 9 | 1389 | 8 | 29 | 86% | 100% | | Assurance | 9 | 974 | 12 | 11 | 85% | 100% | | Immobilier | 8 | 1028 | 14 | 14 | 82% | 100% | | Compliance | 6 | 1313 | 9 | 9 | 100% | 100% | ### A.2 Par modèle | Modèle | Tours | Long. moy. | dsTokenized | Tokens SWY | PII résiduelles | |--------|:-----:|:----------:|:-----------:|:----------:|:---------------:| | Qwen 3 235B | 15 | 1349 | 15 | 24 | 7 | | Claude Haiku 4.5 | 17 | 918 | 25 | 33 | 10 | | Gemini 2.0 Flash | 15 | 1333 | 19 | 14 | 5 | | Mistral Small | 9 | 1124 | 9 | 7 | 4 | | DeepSeek V3 | 9 | 1389 | 8 | 29 | 3 | ### A.3 Par type de PII | Type | Vérifications | Protégées | Taux | |------|:------------:|:---------:|:----:| | Email | 104 | 104 | 100% | | IBAN | 15 | 15 | 100% | | Téléphone | 27 | 27 | 100% | | AVS/AHV | 9 | 9 | 100% | | Adresse IP | 18 | 18 | 100% | | Adresse postale | 16 | 16 | 100% | | Nom de personne | 156 | 138 | 88% | | Organisation | 66 | 63 | 95% | | Référence/ID | 66 | 58 | 88% | ### A.4 Erreurs API | Domaine | Conversation | Tour | Erreur | |---------|:----------:|:----:|--------| | Juridique | Conv 3 | R1 | Internal server error | | Immobilier | Conv 2 | R3 | Internal server error | | Compliance | Conv 3 | R1 | Internal server error | 3 erreurs serveur transitoires sur 68 appels (4.4%). Non liées à la tokenisation. Taux de succès : 95.6%. ### A.5 PII résiduelles détaillées | Domaine | PII en clair | Tour | Type | |---------|-------------|:----:|------| | Juridique | Marc Fontaine | R2, R3 | Nom | | Juridique | Pierre Rochat | R3 | Nom | | Médical | Clara Zimmermann | R1, R2 | Nom | | Médical | Nadia Kessler | R1, R2 | Nom | | Médical | MED-2026-4567 | R1 | Référence | | Finance | Sarah König | R1, R2, R3 | Nom | | Finance | Hans Brücker | R2 | Nom | | Finance | MediSwiss AG | R3 | Organisation | | RH | Roberto Ferreira | R1, R2, R3 | Nom | | RH | Stefan Huber | R1 | Nom | | Sécurité IT | Lisa Müller | R2 | Nom | | Sécurité IT | Thomas Gerber | R1 | Nom | | Sécurité IT | CVE-2026-1234 | R2 | Identifiant public (non-PII) | | Assurance | LAA-2026-789 | R1, R2 | Référence dossier | | Assurance | RC-2026-456 | R2, R3 | Référence dossier | | Immobilier | Résidence du Lac | R1, R2 | Nom de résidence | | Immobilier | Moser & Cie | R1, R2 | Organisation | --- *Benchmark réalisé le 11 avril 2026 sur l'environnement préprod Senseway (localhost:7013). Données complémentaires issues du benchmark tokenisé-vs-clair (même date, Qwen 3 235B, 10 prompts). Toutes les données personnelles utilisées sont fictives. Aucune donnée réelle de client n'a été utilisée.*