# Comment masquer les données personnelles avant d'envoyer un prompt à OpenAI ?

> Il faut remplacer chaque donnée repérable (e-mail, IBAN, numéro de téléphone, numéro de carte) par un alias avant l'envoi, puis remettre les vraies valeurs dans la réponse. C'est ce que fait le bouclier de Subsidia lorsqu'une demande part vers un fournisseur externe : le fournisseur ne lit que les alias. Ce masquage repère des identifiants, il ne comprend pas le sens d'un texte, et il ne suffit pas à lui seul pour déclarer un usage conforme.

Source : https://subsidia.protypa.fr/guides/masquer-donnees-personnelles-avant-envoi-openai · mis à jour le 2026-10-25 · Protypa

## La réponse courte

Masquer une donnée personnelle avant un envoi à un fournisseur d'IA, c'est la **remplacer par un alias** dans le prompt, envoyer le texte ainsi transformé, puis **remettre la vraie valeur** dans la réponse. Le modèle raisonne sur `[EMAIL_k3j2h]`, vous lisez `jean.dupont@exemple.fr`.

Subsidia le fait automatiquement, mais **seulement quand la demande peut atteindre un fournisseur externe** (OpenAI, Anthropic, Mistral, etc.). Vers un modèle local, il ne masque rien : rien ne quitte la machine.

## Ce que le bouclier remplace, exactement

Le bouclier (appelé « PII shield » dans la documentation) cherche des valeurs qui ont une forme reconnaissable. Voici ce que fait chaque mode, d'après le code du produit.

| Mode | Ce qui est remplacé | Pour quel usage |
|---|---|---|
| Standard (par défaut) | E-mails, numéros de téléphone et de fax, numéros de carte bancaire (validés par la clé de Luhn), IBAN, numéros à la forme du « social security number » américain, adresses IP et MAC | Comptabilité, juridique, trafic professionnel courant |
| Médical | Tout le mode standard, plus les noms de personnes, les dates (l'année est conservée), les âges de 90 ans et plus, les codes postaux, les URL, les numéros de dossier ou de compte, le NIR français, le numéro NHS britannique, les numéros de série de véhicule | Données de santé |
| Désactivé | Rien | Installations qui n'utilisent que des modèles locaux, ou tests |

Deux précisions importantes.

- **Les noms ne sont pas masqués en mode standard.** Un nom de client dans votre prompt part en clair, sauf si vous activez l'option « Masquer aussi les noms de personnes » de l'espace de travail ou le mode médical. Le mode médical retire aussi les dates, donc des faits dont une question comptable ou juridique dépend : ne l'activez que pour un trafic clinique.
- **Le contenu clinique n'est pas touché** en mode médical : diagnostics et médicaments restent, seuls les identifiants sont retirés.

## Des alias cohérents, restitués dans la réponse

Un alias n'est pas un simple « [EMAIL] » : son suffixe est calculé à partir de la valeur (accents, casse et civilité écartés). Conséquences :

- la **même valeur donne le même alias** partout : dans tous les tours d'une conversation, dans des requêtes séparées, dans des documents différents ;
- deux **valeurs différentes restent distinctes** : le modèle ne confond pas deux clients ;
- la restitution se fait depuis une mémoire propre à l'appel, après la réponse du modèle.

C'est ce qui permet à un modèle de suivre « le deuxième e-mail de `[EMAIL_k3j2h]` » sans jamais voir l'adresse.

Voici l'illustration donnée par la documentation du moteur.

| Vous envoyez | Le fournisseur externe reçoit |
|---|---|
| `Répondez à jean.dupont@exemple.fr et confirmez le virement vers FR7630006000011234567890189.` | `Répondez à [EMAIL_k3j2h] et confirmez le virement vers [IBAN_9f2x1a].` |

Les suffixes ci-dessus sont des exemples : ils dépendent de la valeur, ne les analysez pas dans votre code.

## Comment l'utiliser avec votre code OpenAI

Deux chemins existent. Dans l'application Subsidia, l'administrateur choisit le fournisseur et le mode du bouclier dans l'écran des modèles. Dans votre propre code, vous passez par le **Gateway** de Subsidia, qui parle le format OpenAI : vous changez l'URL de base et gardez le reste.

Le fournisseur qui répond est celui que l'installation a configuré (et que Synapse choisit selon la tâche), pas celui que vous écrivez dans `model` : voir le [guide du Gateway](/guides/passerelle-compatible-openai-anthropic). Le snippet ci-dessous envoie des données fictives et lit ce qui a été masqué.

```python
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.subsidia.protypa.fr/v1",
    api_key=os.environ["SUBSIDIA_API_KEY"],  # sk_live_...
)

raw = client.chat.completions.with_raw_response.create(
    model="pulse-auto",
    messages=[{
        "role": "user",
        "content": "Répondez à jean.dupont@exemple.fr et confirmez le virement "
                   "vers FR7630006000011234567890189.",
    }],
)
completion = raw.parse()

print(completion.choices[0].message.content)        # valeurs restituées
print(raw.headers.get("x-pulse-provider"))          # qui a répondu : ollama, openai...
print(raw.headers.get("x-pulse-pii-masked"))        # nombre de valeurs masquées
print(raw.headers.get("x-pulse-proof"))             # identifiant du certificat
```

Si le fournisseur qui a répondu est local, `x-pulse-pii-masked` vaut `0` : le texte n'a pas été modifié, puisqu'il n'est pas sorti. Pour une réponse diffusée en flux, seul `x-pulse-proof` est envoyé dans les en-têtes ; lisez alors le certificat. Les en-têtes et le certificat sont détaillés dans la [documentation du Gateway](https://dev.subsidia.protypa.fr/docs/gateway).

## Vérifier ce qui est réellement parti

Vous n'avez pas à croire le masquage sur parole. Le certificat de chaque réponse indique :

- le **fournisseur et le modèle** qui ont répondu ;
- le **nombre de valeurs masquées** et leurs **catégories** (`EMAIL`, `PHONE`, `IBAN`…), jamais les valeurs ;
- l'**empreinte SHA-256 du texte tel qu'il est parti**, après masquage.

Le certificat ne contient aucun texte, seulement des empreintes. Vous pouvez le contrôler sur la page [Contrôler un certificat](/certificat) ou hors ligne, comme l'explique le [guide de vérification](/guides/verifier-un-certificat-de-reponse-ia).

Si un contrat vous impose qu'une catégorie de données ne parte jamais chez un fournisseur externe, ne vous fiez pas à l'intention : testez, dans votre intégration, que `x-pulse-provider` (ou `egress.provider` dans le certificat) est bien local pour ces appels.

## Ce que cela ne fait pas

- **Le bouclier repère des identifiants, il ne comprend pas le sens.** Une phrase comme « le gérant de la boulangerie du coin, celui dont la fille vient de déménager à Lyon » identifie quelqu'un sans contenir un seul e-mail ni un seul IBAN. Elle part telle quelle.
- **Il peut se tromper dans les deux sens.** Une suite de chiffres qui ressemble à un téléphone peut être masquée à tort (un long numéro de facture, par exemple), et une donnée à la forme inhabituelle peut passer. La détection des noms repose sur des indices (civilités, majuscules) et peut en manquer.
- **Un alias est un pseudonyme, pas une anonymisation.** Il est dérivé de la valeur par un hash court, sans clé secrète : qui devine une valeur peut vérifier si elle correspond à un alias, et le fournisseur voit que deux alias identiques désignent la même entité. Selon le [RGPD, article 4, point 5](https://eur-lex.europa.eu/eli/reg/2016/679/oj), la pseudonymisation suppose que l'information permettant de rattacher la donnée à une personne soit conservée séparément et protégée : une donnée pseudonymisée reste une donnée personnelle.
- **Ce n'est pas une attestation de conformité.** Subsidia n'en délivre aucune, et ce guide n'est pas un avis juridique. Le masquage ne remplace pas votre analyse du secret professionnel ou du contrat avec votre fournisseur.
- **Il peut dégrader la réponse.** Le modèle ne voit plus les valeurs : s'il doit raisonner sur le contenu précis d'un nom ou d'un montant masqué, la qualité baisse. C'est pour cela que le mode médical, qui retire aussi les noms et les dates, est déconseillé pour un cabinet comptable ou juridique.
- **Il ne s'applique qu'à ce qui part.** Un modèle installé chez vous reçoit le texte intact. Pour ce qui ne doit jamais sortir, le seul mode qui l'assure techniquement est le traitement local : voir le guide [Faire tourner une IA sur site, sans GPU](/guides/ia-sur-site-sans-gpu).

## Checklist avant d'envoyer des données à un fournisseur externe

1. Quel mode du bouclier est actif (standard, médical, désactivé) ? Le mode « désactivé » ne masque rien.
2. Vos données sensibles sont-elles des identifiants (couverts) ou du texte libre et des noms (non couverts en mode standard) ?
3. Avez-vous activé « Masquer aussi les noms de personnes » si des noms apparaissent dans les prompts ?
4. Un test automatique vérifie-t-il `x-pulse-pii-masked` et `x-pulse-provider` sur un prompt contenant des données fictives ?
5. Les pièces qui ne doivent jamais sortir passent-elles par `pulse-sensitive` ou par un modèle local ?
6. Qui, chez vous, a validé l'envoi sur le plan juridique ?

## Questions fréquentes

### Que voit OpenAI quand mon prompt contient un e-mail ou un IBAN ?

Avec le bouclier de Subsidia actif sur un fournisseur externe, le fournisseur reçoit un alias à la place de la valeur, par exemple [EMAIL_k3j2h] ou [IBAN_9f2x1a]. La vraie valeur reste dans une mémoire temporaire propre à l'appel et est remise dans la réponse avant que vous la lisiez. Le suffixe exact de l'alias dépend de la valeur.

### Les noms de personnes sont-ils masqués ?

Pas en mode standard : seuls les identifiants à forme rigide le sont (e-mail, téléphone, carte, IBAN, adresse IP, etc.). Les noms sont masqués si le mode médical est choisi, ou si l'option « Masquer aussi les noms de personnes » est activée pour l'espace de travail. Cette détection repose sur des indices (civilités, majuscules) : elle peut en manquer ou en masquer trop.

### Le masquage rend-il l'envoi conforme au RGPD ?

Nous ne pouvons pas l'affirmer et Subsidia ne délivre aucune attestation de conformité. Une donnée pseudonymisée reste une donnée personnelle au sens du RGPD tant que l'information supplémentaire permettant de la rattacher existe. La question de savoir si un envoi est licite relève de votre analyse, avec votre délégué à la protection des données ou votre conseil.

### Comment savoir que le masquage a réellement eu lieu pour un appel donné ?

Par l'API, l'en-tête x-pulse-pii-masked donne le nombre de valeurs masquées (réponse non diffusée en flux), et le certificat de la réponse indique le fournisseur, le nombre de valeurs masquées et leurs catégories (jamais les valeurs). Le certificat se vérifie hors ligne.

### Et si le fournisseur est un modèle local ?

Rien n'est masqué, puisque rien ne sort de la machine : le modèle reçoit le texte tel quel, ce qui donne souvent de meilleures réponses sur les noms et les chiffres. Le bouclier ne s'applique qu'aux fournisseurs externes.

### Peut-on régler le masquage appel par appel ?

Non. Le mode (standard, médical, désactivé) est un réglage du serveur choisi par l'administrateur de l'installation, pas un paramètre de requête. Pour forcer le traitement local d'un appel précis, on utilise l'adresse de modèle pulse-sensitive.