BV-PRGA : au cœur de la passerelle de confidentialité

Chaque prompt qui part vers un modèle externe est une exportation de données. La plupart du temps, il exporte plus que ce dont la tâche a besoin : le nom du client quand un client suffisait, l'IBAN complet quand le modèle n'avait qu'à rédiger une relance, une clé d'API collée par erreur. BV-PRGA est la porte placée avant cette sortie — sous forme d'extension de navigateur pour les personnes, de passerelle auto-hébergée pour les équipes — et elle garantit une propriété simple à énoncer : le sensible reste dans votre système ; seul ce dont la tâche a besoin sort.

L'aller-retour, formalisé

Le cœur de BV-PRGA est un masquage réversible dont la clé ne sort jamais. À l'aller, la requête $x$ est transformée en un couple

où $\tilde{x}$ est la version protégée qui part chez le fournisseur et $\kappa$ la table de correspondance — quel jeton remplace quelle valeur — qui reste dans votre environnement. Chaque valeur détectée est remplacée par un marqueur stable de la forme [BV:PERSON:a1b2c3], [BV:IBAN:2e5d8c] : cohérent au sein de la requête (le modèle peut raisonner sur « la même personne ») et opaque en dehors. Au retour, la réponse du fournisseur $\tilde{r}$ est reconstruite localement :

La propriété essentielle tient à l'endroit où vit chaque élément : le fournisseur externe ne voit que $\tilde{x}$ et produit $\tilde{r}$ ; le couple $(\kappa, r)$ ne quitte jamais votre infrastructure, à aucun moment du cycle. La réversibilité est locale par construction, pas par promesse.

Les secrets : bloquer, pas pseudonymiser

Tout ce qui est sensible n'appelle pas le même traitement. Un nom ou un IBAN pseudonymisé permet encore de mener la tâche à bien ; une clé d'API n'a rien à faire dans un prompt, sous quelque forme que ce soit — ni en clair ni masquée, car un marqueur réversible d'un secret reste un secret, à une indirection près. C'est pourquoi la politique distingue deux verbes :

• Pseudonymiser ce que la tâche doit pouvoir désigner : personnes, identifiants, comptes, e-mails.
• Bloquer ce qui ne doit jamais sortir : identifiants de connexion, clés, jetons de session. La requête s'arrête avec une décision explicite — DENY — et le compteur de la passerelle l'enregistre : ce qui a été pseudonymisé, ce qui a été bloqué et pourquoi la requête n'est pas partie.

Échec fermé : la porte se ferme en cas de panne

La détection est un problème d'étiquetage de séquences, et aucun détecteur n'est parfait. La question de conception honnête n'est pas « à quelle fréquence a-t-il raison ? » mais « que se passe-t-il quand il doute ? ». Dans BV-PRGA, la réponse est structurelle : en cas de doute, la porte se ferme. Si l'analyse d'une requête ne peut aboutir avec confiance — le classifieur ne converge pas, la passerelle ne répond pas, le format dépasse ce qui est attendu —, le comportement par défaut est de ne pas envoyer. Formellement, la politique est un treillis où DENY domine : aucune panne de composant ne peut dégrader silencieusement la décision vers « envoyer en clair ».

Ce biais a un prix (il bloque parfois trop) et c'est un prix que nous choisissons volontiers : le coût d'un faux positif est une nouvelle tentative ; le coût d'un faux négatif est une exportation de données qu'on ne peut plus annuler.

Ce que cette porte n'est pas

L'honnêteté fait partie de la spécification. BV-PRGA réduit la surface d'exposition et de conformité — moins de données personnelles envoyées à des tiers, moins de copies hors de votre périmètre —, mais il ne remplace pas votre cadre juridique de protection des données : bases légales, contrats de sous-traitance et analyses d'impact restent de votre ressort. La porte vous apporte un fait technique vérifiable sur lequel appuyer ce cadre : le sensible n'est pas sorti.

Sa place dans la littérature

La détection de données personnelles comme étiquetage de séquences a une longue lignée, et elle vient de la clinique : la tâche partagée i2b2/UTHealth de 2014 a fixé le moule expérimental — corpus annoté, précision/rappel, systèmes hybrides — et son résultat clé : les meilleurs systèmes tournaient autour d'un F1 de 0,90, et aucun n'atteignait une détection parfaite (Stubbs et al., 2015). Cette technologie a été industrialisée dans des outils comme Presidio, dont la propre documentation prévient qu'il n'y a aucune garantie de trouver toutes les informations sensibles (Microsoft / Data Privacy Stack community, 2026). La critique académique est venue ensuite : étiqueter des entités n'est pas mesurer le risque de divulgation (Lison et al., 2021), et le benchmark TAB a transformé cette critique en programme d'évaluation, avec des métriques distinctes pour la protection et l'utilité (Pilán et al., 2022). BV-PRGA s'inscrit ici sans prétendre à un meilleur détecteur : ce qu'il change, c'est la sémantique de l'erreur — si le détecteur doute, le texte ne sort pas. Le prix se paie en utilité, la monnaie bon marché au regard de l'asymétrie même que TAB formalise.

La menace qui motive tout cela est quantifiée. Ce qui entre dans un modèle peut en ressortir : l'extraction verbatim de données d'entraînement est démontrée (Carlini et al., 2021), et la mémorisation croît avec la taille du modèle — « probablement en s'aggravant », selon ses auteurs (Carlini et al., 2022). Et la littérature elle-même ferme les issues faciles : demander de la discrétion au modèle ne fonctionne pas — GPT-4 révèle des informations dans des contextes où un humain ne le ferait pas dans 39 % des cas, et la fuite persiste avec des prompts de confidentialité et un raisonnement pas à pas (Mireshghallah et al., 2024) —, et supprimer les identifiants ne suffit pas non plus, car les LLM infèrent des attributs personnels à partir du texte restant avec jusqu'à 85 % de précision top-1 (Staab et al., 2024). La conclusion commune est structurelle : la protection doit avoir lieu avant le fournisseur, dans l'environnement du client.

Les passerelles réversibles existent déjà, et il faut les citer. Hide and Seek (HaS) propose explicitement le schéma : anonymiser le prompt localement, interroger le LLM distant, désanonymiser la réponse localement (Chen et al., 2023) ; PAPILLON en est la variante moderne en ensemble local/distant, avec le compromis chiffré — 85,5 % de la qualité conservée en limitant la fuite à 7,5 % (Siyan et al., 2025). Face à eux, la différence de BV-PRGA est triple : une reconstruction déterministe $r=\kappa^{-1}(\tilde{r})$ par une table de marqueurs stables — et non un second modèle local qui réintroduit une erreur probabiliste au retour —, la distinction pseudonymiser/bloquer — un secret ne se substitue pas : il se refuse — et une sémantique d'échec fermé, absente des deux précédents, qui traitent la fuite résiduelle comme une métrique à optimiser plutôt que comme un événement à empêcher. La confidentialité différentielle appliquée au texte est le pôle méthodologique opposé (Feyisetan et al., 2020) : une garantie formelle $\epsilon$ face à des adversaires arbitraires, au prix de la fidélité — le domaine reconnaît lui-même que ses mécanismes d'assainissement « offrent encore une faible utilité » (Yue et al., 2021) — et de la réversibilité exacte, que la DP exclut par construction.

L'ancrage réglementaire boucle la boucle avec une symétrie remarquable. La définition de la pseudonymisation à l'article 4, point 5, du RGPD décrit $m(x)=(\tilde{x},\kappa)$ presque littéralement : des données qui ne peuvent plus être attribuées à une personne concernée « sans avoir recours à des informations supplémentaires », pour autant que ces informations soient « conservées séparément » et soumises à des mesures techniques et organisationnelles (European Parliament and Council of the European Union, 2016). Les lignes directrices 01/2025 du CEPD valident expressément la pseudonymisation conçue pour être inversée, avec des tables pseudonyme-valeur ou des clés cryptographiques comme informations supplémentaires (European Data Protection Board, 2025) — la description réglementaire de $\kappa$ —, et l'ENISA fournit l'ingénierie des pseudonymes et de leurs attaques : des marqueurs aléatoires stables (et non des hachages de la valeur substituée) échappent précisément aux attaques par dictionnaire qu'analyse son rapport (ENISA (European Union Agency for Cybersecurity), 2019). Le rappel honnête vient du CEPD lui-même : des données pseudonymisées restent des données personnelles ; BV-PRGA réduit le risque vis-à-vis du fournisseur, il ne vous dispense pas du RGPD.

Problèmes ouverts

1. De l'étiquetage au risque de divulgation. Le domaine manque de méthodes qui intègrent au processus des mesures explicites du risque de réidentification (Lison et al., 2021) ; la façon dont une passerelle estime ce risque en ligne reste ouverte.
2. L'inférence d'attributs déjoue l'anonymisation actuelle. Avec des atténuations courantes jugées « actuellement inefficaces » et jusqu'à 85 % de précision dans l'inférence d'attributs à partir du texte résiduel (Staab et al., 2024), la protection du signal contextuel et stylistique qu'aucun substituteur d'entités ne touche reste ouverte. C'est la frontière déclarée de cette porte.
3. La fuite contextuelle ne se règle pas par le prompt. La fuite persiste même avec des instructions de confidentialité et un raisonnement pas à pas (Mireshghallah et al., 2024) ; tant que les modèles ne respectent pas une notion opérationnelle d'intégrité contextuelle, seules les solutions structurelles tiennent.
4. Une mémorisation croissante sans atténuation active. La mémorisation croîtra avec l'échelle, « du moins sans atténuations actives » (Carlini et al., 2022) — et ces atténuations échappent à tout client du fournisseur.
5. Une évaluation propre aux passerelles. TAB existe parce que les métriques standard ne saisissent pas à la fois la protection et l'utilité (Pilán et al., 2022) ; il manque des métriques de consensus — et des corpus ni cliniques ni juridiques — qui rendent compte de l'asymétrie faux négatif irréversible / faux positif bon marché dans les scénarios de passerelle.
6. Garantie formelle + fidélité + réversibilité. La DP apporte la première en renonçant aux deux autres (Feyisetan et al., 2020; Yue et al., 2021) ; les passerelles réversibles apportent les deux dernières en renonçant à la première (Chen et al., 2023; Siyan et al., 2025). Concilier les trois reste le problème ouvert du domaine.

Note : les chiffres de cette section (F1 de la tâche partagée, 39 %/57 %, 85 %, 85,5 %/7,5 %...) proviennent de la littérature citée et décrivent ces travaux ; ce ne sont pas des mesures de BV-PRGA.

Où en est-il aujourd'hui

BV-PRGA existe comme produit indépendant sur privacy.bivelio.com, sous deux formes : une extension de navigateur gratuite (Chrome, Edge et Brave) qui protège les personnes dans ChatGPT et Claude avant que le texte ne quitte l'appareil, et une passerelle auto-hébergée pour les développeurs et les équipes, publiée sur PyPI, qui applique la même politique devant n'importe quelle API d'IA — OpenAI, Anthropic, DeepSeek et bien d'autres. Au sein de BiVelio, c'est la couche Protect : la même porte, devant chaque interaction avec un modèle.

Références