anonymisation/docs/reflexions/2026-05-28_vision_fonctionnelle_avant_prod.md

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.