# Vie privée et conformité

:::note
L'auto-hébergement ne vaut **pas** conformité. Cette page décrit des dispositions techniques ;
la validation de la DPO reste requise avant toute activation en production
(voir [a-faire-valider.md](/projet/a-faire-valider)).
:::

## Ce que le POC n'envoie jamais

- Aucun mot de passe, jeton, cookie ni en-tête d'autorisation : les clés correspondantes sont
  remplacées par `[caviardé]` avant la mise en file.
- Aucune adresse électronique, ORCID ni chaîne ressemblant à un jeton, même à l'intérieur d'un texte.
- Aucun terme de recherche brut : le vocabulaire de l'événement `search_performed` se limite à
  l'issue (`results` / `zero_results`) et au nombre de résultats.
- Aucun enregistrement de session, quelle que soit la capacité du fournisseur.

Le caviardage est un **dernier filet**. La première barrière reste le schéma d'événement : une
propriété non déclarée est rejetée avant tout envoi.

## Identité

Anonyme par défaut. `identify()` existe dans l'interface pour que les paquets restent réutilisables,
mais la configuration de ce dépôt pose `identity.allowIdentify: false` : tout appel est **refusé et
compté**, sans interrompre l'application.

C'est une conséquence directe de l'[ADR 006](/decisions/analytics), qui interdit la
collecte de données identifiantes — et du fait que ce site n'a ni compte ni session.

L'identifiant anonyme n'est pas persisté par défaut (`persistAnonymousId: false`) : il ne survit
pas au rechargement, ce qui évite un identifiant durable assimilable à un traceur.

## Consentement

Deux modes :

- **`required`** — rien ne part avant un accord explicite. C'est le défaut.
- **`exempt`** — mesure sans cookie ni identifiant persistant, exemptée de consentement au sens des
  recommandations CNIL. Un refus explicite reste respecté.

Depuis le 26/10/2026, le mode `required` est praticable : une bannière demande l'accord au premier
passage (`src/features/analytics/ConsentBanner.tsx`). Elle respecte trois règles — accepter et
refuser ont le même poids visuel et le même coût, rien n'est envoyé avant la décision, et la
décision se révoque depuis le pied de page, à tout moment. Aucune bannière n'est affichée si aucun
fournisseur n'est activé : il n'y a alors rien à consentir.

Le mode `exempt` ne se justifie que si le paramétrage du fournisseur le permet réellement. C'est le
cas du traqueur Matomo déjà en place dans ce dépôt (sans cookie, sans User ID, sans détection des
fonctionnalités du navigateur, URL sans query string). Il **n'a pas été vérifié** pour Umami ni
Rybbit : les activer suppose de refaire cette analyse.

## Traces et identifiants

`traceId` et `spanId` servent à relier un journal à une trace. Ce ne sont **pas** des identifiants
d'utilisateur et ils ne doivent jamais être utilisés comme tels. Le collecteur supprime en outre
`enduser.id`, `user.email`, les en-têtes d'autorisation et les cookies.

## Conservation

Non configurée dans ce POC. À définir avant toute mise en service :

| Donnée                      | Où                      | Rétention |
| --------------------------- | ----------------------- | --------- |
| Événements d'audience       | Umami / Matomo / Rybbit | à définir |
| Journaux, traces, métriques | OpenObserve             | à définir |

## Droits des personnes

Les chemins d'effacement et d'export diffèrent par fournisseur et **n'ont pas été éprouvés** ici.
C'est un point ouvert à instruire avec la DPO, au même titre que la base légale et la durée de
conservation.

## Points à soumettre à la DPO

1. Trois fournisseurs simultanés n'ont aucune justification fonctionnelle : c'est un dispositif de
   comparaison. Un seul doit être retenu avant mise en service.
2. Le mode d'exemption de consentement n'est établi que pour Matomo.
3. Les durées de conservation ne sont pas fixées.
4. Les procédures d'effacement et d'export ne sont pas éprouvées.