# Vision fonctionnelle — avant remise en production

**Date :** 2026-05-28
**Auteur :** Réflexion Claude, à challenger
**Contexte :** Point avant remise en production. Cette note prend du recul sur les fonctionnalités attendues d'un produit de pseudonymisation médicale local, et compare avec l'état actuel du programme.

---

## 1. Modèle mental du produit

Le produit, tel qu'il se dessine aujourd'hui, c'est **un outil de pseudonymisation locale, autonome, multi-établissements, pour des données médicales sensibles**.

- Déploiement **on-premise** (pas de cloud) → contrainte RGPD/santé forte
- Opérateur **humain métier** (pas un développeur) → exigence d'UX
- Chaque établissement a ses **spécificités** : mises en page, terminologie, professionnels locaux, codes internes
- L'output doit être **utilisable en aval** (publication, partage inter-établissements, recherche, archivage) sans risque de ré-identification

---

## 2. Ce qui est déjà aligné avec cette vision

| Fonctionnalité | État |
|---|---|
| Détection multi-signal (NER EDS-Pseudo + GLiNER + CamemBERT-bio + regex + gazetteers INSEE/FINESS/BDPM) | ✅ Robuste |
| Support multi-formats (PDF, DOCX, ODT, RTF, TXT, HTML, images→OCR) — 14 formats | ✅ Pas de friction |
| PDF redaction visuelle (rastérisation + blackout) | ✅ Indispensable pour publier |
| Profils + export/import JSON par email | ✅ Bon levier multi-établissements |
| Whitelist / blacklist / admin_rules | ✅ Personnalisation sans toucher au code |
| Audit JSONL + score qualité automatique | ✅ Traçabilité technique |
| Externalisation des dictionnaires (data/, YAML) | ✅ Modifiable sans recompiler |

---

## 3. Ce qui semble manquer ou faible pour un vrai produit "prêt"

### 3.1 Validation humaine intégrée

**Aujourd'hui :** tout-ou-rien. Le programme tourne, sort des fichiers anonymisés, et l'opérateur fait confiance.

**Manque :** un mode "review" où l'opérateur valide les détections **incertaines** (confidence < seuil) avant écriture finale.

**Pourquoi c'est critique en santé :** un faux négatif (PII manqué) = leak RGPD. Un humain dans la boucle sur les cas limites change la donne.

**Note :** `protocole-validation-humaine.md` et `fiche-validation-humaine-modele.md` existent déjà → la pensée est là, l'implémentation pas encore.

### 3.2 Rapport de campagne

**Aujourd'hui :** après un batch, l'opérateur a un dossier de fichiers, sans synthèse globale.

**Manque :** un rapport PDF/HTML par campagne :
- X documents traités, Y entités masquées par type (NOM, TEL, DATE, FINESS…)
- Z anomalies à vérifier
- Documents en quarantaine (OCR raté, basse confiance)
- Signature : version du code + version des règles + horodatage + opérateur

**Pourquoi c'est critique en santé :** indispensable pour la responsabilité RGPD et la communication avec le DPO.

**Note :** `rapport-analyse-campagne-gui-2026-04-21.md` existe → réflexion entamée, mais pas d'implémentation détectée.

### 3.3 Pré-flight / quarantaine automatique

**Aujourd'hui :** un doc qui passe mal (OCR dégradé, basse confiance globale, format inattendu) sort quand même comme "anonymisé".

**Manque :** isoler ces documents dans un dossier `quarantaine/` avec un fichier d'explication. Le pire scénario, c'est qu'un opérateur croie qu'un doc est anonymisé alors que l'OCR n'a rien capté.

### 3.4 Versioning d'audit (métadonnées de sortie)

**Aujourd'hui :** les fichiers de sortie n'ont pas de métadonnées vérifiables prouvant avec quelle config ils ont été anonymisés.

**Manque :** chaque sortie devrait porter :
- `version_code` (commit SHA ou build_info)
- `version_règles` (hash du YAML actif)
- `horodatage`
- `opérateur` (Windows user ? compte applicatif ?)
- `profil_appliqué`

**Pourquoi c'est critique en santé :** si dans 2 ans on doit prouver qu'une anonymisation a été faite avec quelle config, c'est crucial. Demande type d'un audit DPO ou CNIL.

### 3.5 Réversibilité contrôlée — question fondamentale

**Aujourd'hui :** le programme s'appelle "Pseudonymisation" mais remplace par `[NOM]` non réversible → techniquement, c'est de l'**anonymisation**.

**Différence légale (RGPD) :**
- **Pseudonymisation** : les données restent personnelles (Art. 4.5 RGPD), une table de correspondance chiffrée existe → ré-identification autorisée possible
- **Anonymisation** : irréversible, sort du périmètre RGPD

**À trancher :**
- Soit on renomme le produit "Anonymisation" et on assume l'irréversibilité
- Soit on ajoute une **table de correspondance chiffrée** (clé locale par établissement) qui permet la ré-identification autorisée — fonctionnellement plus puissant, mais ajoute une surface d'attaque

**Indication métier requise :** que veulent réellement faire les établissements avec les documents anonymisés ? Publication scientifique (anon. pure) ou suivi inter-services (pseudo. avec ré-identification) ?

---

## 4. Questions ouvertes qui orienteraient la roadmap

### 4.1 Cible utilisateur réelle

- **DSI hospitalier** qui livre des batches mensuels ? → focus sur le throughput, l'audit, la gouvernance, le pré-flight
- **Médecin / secrétaire** qui anonymise au cas par cas avant publication ? → focus sur l'UX simple, le drag-and-drop, la prévisualisation
- **Les deux** ? → modes utilisateur distincts (Expert / Simple)

L'UX et les garde-fous changent radicalement selon la cible.

### 4.2 Sortie attendue / cas d'usage en aval

- **Publication scientifique** → masquage agressif, irréversible, format texte
- **Partage inter-établissements** → masquage modéré, certificat d'anonymisation
- **Archivage long terme** → versioning fort, métadonnées complètes
- **Recherche / études internes** → pseudonymisation réversible

Chaque cas implique des **réglages par défaut** et un **niveau d'agressivité** différents.

### 4.3 Responsabilité — qui signe ?

- L'outil (auto-validation par score qualité) ?
- L'opérateur (validation manuelle obligatoire) ?
- Le DPO (workflow d'approbation) ?

Cela impacte directement :
- Le besoin d'audit trail
- L'existence d'une UI de validation
- La signature numérique (?) des fichiers de sortie

### 4.4 GUI v6 — re-skin ou refonte fonctionnelle ?

La maquette HTML v6 est validée (06/05) avec 3 onglets + 4 sous-onglets + éditeur de masques + 4 thèmes. Mais elle conserve la logique fonctionnelle actuelle.

**Question :** profite-t-on de v6 pour intégrer les fonctions manquantes (validation humaine, rapport campagne, quarantaine, métadonnées) ? Ou est-ce un v6.0 cosmétique suivi d'un v7.0 fonctionnel ?

---

## 5. Priorisation suggérée (à challenger)

| Priorité | Fonction | Effort | Impact prod santé |
|---|---|---|---|
| 🔴 Critique | Métadonnées de sortie (versioning d'audit) | Faible | Élevé — audit RGPD |
| 🔴 Critique | Pré-flight / quarantaine automatique | Moyen | Élevé — évite faux positifs de "doc anonymisé" |
| 🟠 Important | Rapport de campagne | Moyen | Élevé — gouvernance |
| 🟠 Important | Validation humaine intégrée (mode review) | Élevé | Élevé — qualité finale |
| 🟡 À trancher | Réversibilité chiffrée (vraie pseudonymisation) | Élevé | Dépend du besoin métier |
| 🟢 Cosmétique | GUI v6 thèmes / éditeur masques | Moyen | Modéré — UX |

---

## 6. Décisions à prendre avant de continuer

1. **Pseudonymisation vs Anonymisation** : trancher le positionnement
2. **Cible utilisateur** : DSI batch / médecin individuel / les deux
3. **Cas d'usage en aval** : publication / partage / archive / recherche
4. **Modèle de responsabilité** : qui signe l'anonymisation
5. **Stratégie GUI v6** : cosmétique seul ou refonte fonctionnelle

Sans ces réponses, la roadmap technique reste un best-effort. Avec elles, on peut prioriser intelligemment.
