rpa_vision_v3/docs/POC_ANOUST_PAS.md

# Plan d'Assurance Sécurité (PAS)

**Logiciel** : Léa — RPA Vision V3
**Version** : 3.x
**Date** : 14 avril 2026
**Client** : Clinique Anoust (psychiatrie)
**Objet** : Extraction automatisée de dossiers patients 2024-2025 + constitution d'un Entrepôt de Données de Santé (EDS)

---

## I. Introduction et cadre réglementaire

### 1.1 Finalité du système

Léa est un système RPA (Robotic Process Automation) basé sur la vision, déployé **intégralement en local** sur l'infrastructure de l'établissement. Sa finalité est **exclusivement administrative** :
- Extraction automatisée de données depuis le DPI (OSIRIS)
- Structuration et anonymisation des données extraites
- Alimentation d'un Entrepôt de Données de Santé (EDS)

Le système ne prend **aucune décision clinique**. Il reproduit les gestes d'un opérateur humain naviguant dans les écrans du DPI.

**Lettre de Non-Qualification** : Léa n'est pas un dispositif médical au sens du Règlement (UE) 2017/745. Une lettre de non-qualification est fournie.

### 1.2 Réglementation applicable

| Texte | Applicabilité | Obligations clés |
|-------|--------------|------------------|
| **RGPD** (art. 9) | Données de santé mentale = catégorie spéciale | AIPD obligatoire, DPO, base légale art. 6.1.e ou 6.1.f |
| **Référentiel CNIL EDS** (2021-118) | Entrepôt de données de santé | Déclaration de conformité ou autorisation individuelle |
| **AI Act** (Règlement UE 2024/1689) | Système IA en contexte de santé | Évaluation du niveau de risque (art. 6(3)), documentation écrite |
| **NIS2** (transposition FR juillet 2026) | Établissement de santé = entité importante | Notification incidents 24h, plan de gestion risques cyber |
| **HDS** (L.1111-8 CSP) | **Dispensé si on-premise** | Le déploiement sur l'infrastructure de la clinique ne nécessite pas de certification HDS |
| **PGSSI-S** | Données de santé à caractère personnel | Conformité au palier minimal des référentiels ANS |
| **Programme CaRE** | Établissements de santé | BIA pour services critiques (échéance juin 2026) |

### 1.3 Spécificités psychiatrie

- Les **notes personnelles du psychiatre** (hypothèses, réflexions non formalisées) sont **exclues du périmètre d'extraction** (art. R4127-45 CSP)
- Anonymisation renforcée : risque de re-identification élevé en psychiatrie (pathologies rares, situations uniques)
- Secret médical renforcé (art. 226-13 Code pénal)

### 1.4 AI Act — Évaluation du niveau de risque

Léa invoque l'exception de l'art. 6(3) du AI Act :
- **(a)** Tâche procédurale étroite : extraction de champs depuis des écrans
- **(d)** Tâche préparatoire : alimentation d'un EDS pour analyse humaine ultérieure
- Aucune décision clinique automatisée
- Supervision humaine permanente (mode supervisé)

Cette évaluation est documentée conformément à l'art. 6(4).

---

## II. Architecture et déploiement

### 2.1 Principe : déploiement 100% local

```
┌─────────────────────────────────────────────────────────┐
│                 RÉSEAU CLINIQUE ANOUST                   │
│                                                         │
│  ┌──────────┐         ┌──────────────────────────────┐  │
│  │   Poste  │         │    SERVEUR LÉA (VM/bare)     │  │
│  │   DPI    │◄───────►│                              │  │
│  │ (OSIRIS) │  écran  │  - Moteur RPA (extraction)   │  │
│  └──────────┘         │  - Pipeline anonymisation    │  │
│                       │  - EDS (PostgreSQL + OMOP)   │  │
│                       │  - Dashboard (monitoring)    │  │
│                       └──────────────────────────────┘  │
│                                                         │
│  ⛔ AUCUNE CONNEXION INTERNET SORTANTE                  │
│  ⛔ AUCUNE DONNÉE NE QUITTE L'ÉTABLISSEMENT             │
└─────────────────────────────────────────────────────────┘
```

### 2.2 Prérequis infrastructure — à fournir par la clinique

| Élément | Spécification | Notes |
|---------|--------------|-------|
| **VM ou serveur dédié** | 8 vCPU, 32 Go RAM, 500 Go SSD minimum | GPU optionnel (accélère l'OCR mais pas requis) |
| **OS** | Ubuntu Server 22.04 LTS ou 24.04 LTS | L'établissement gère les MAJ de sécurité OS |
| **Adresse IP fixe** | 1 IP sur le VLAN santé | Pour le serveur Léa |
| **VLAN** | VLAN dédié ou VLAN santé existant | Isolation réseau des données patients |
| **Accès réseau au DPI** | Connectivité vers le poste/serveur OSIRIS | Léa navigue dans l'interface comme un utilisateur |
| **Accès SSH** | Port 22, limité à 1 IP source (notre maintenance) | Ou VPN site-to-site |
| **DNS interne** | Résolution des noms internes | Si OSIRIS est accessible par nom |
| **Compte utilisateur DPI** | Compte OSIRIS dédié "Léa" (lecture seule) | Avec les droits d'accès aux dossiers du périmètre |
| **Sauvegarde** | Intégration au plan de sauvegarde de l'établissement | VM snapshots ou backup du volume données |
| **Certificat TLS** | Certificat interne pour HTTPS (ou auto-signé) | Pour le dashboard de monitoring |

### 2.3 Ports et services

| Port | Protocole | Direction | Usage | Sécurité |
|------|-----------|-----------|-------|----------|
| **443** | HTTPS/TLS | Interne uniquement | Dashboard monitoring + consultation logs | Authentification forte (AD/LDAP clinique) |
| **22** | SSH | Entrant, 1 IP source | Maintenance par nos équipes uniquement | Clé SSH, pas de mot de passe. IP source unique |
| **5432** | TCP | Localhost uniquement | PostgreSQL (EDS) | Écoute 127.0.0.1 uniquement, pas d'accès réseau |

**Ports bloqués** : tout le reste. Aucun port ouvert vers Internet.

### 2.4 Règles de firewall (ufw)

```bash
# Politique par défaut : tout bloquer
ufw default deny incoming
ufw default deny outgoing

# SSH maintenance (IP source unique fournie par la clinique)
ufw allow from <IP_MAINTENANCE> to any port 22 proto tcp

# HTTPS dashboard (VLAN interne uniquement)
ufw allow from <VLAN_SANTE> to any port 443 proto tcp

# DNS interne (si nécessaire)
ufw allow out to <DNS_INTERNE> port 53

# Bloquer explicitement Internet
ufw deny out to 0.0.0.0/0
```

### 2.5 Hardening serveur

- Service RPA sous **compte non-root** à privilèges limités (`lea-svc`)
- **Chiffrement intégral** du disque (LUKS) — protection PI et données
- AppArmor activé avec profil dédié
- Fail2ban sur SSH
- Logs système centralisés (journald)
- Pas de serveur X / interface graphique sur le serveur

---

## III. Sécurité des données et anonymisation

### 3.1 Cycle de vie des données

```
Écran DPI (OSIRIS)
    │
    ▼ capture en RAM uniquement
Extraction RPA
    │
    ▼ destruction immédiate des captures écran
Données structurées brutes (RAM)
    │
    ▼ pipeline anonymisation
Données pseudonymisées
    │
    ▼ chargement
EDS (PostgreSQL, disque chiffré LUKS)
    │
    ▼ requêtage
Dashboard (lecture seule, HTTPS)
```

### 3.2 Traitement des captures d'écran

- Les images sont traitées **en RAM uniquement**
- **Destruction immédiate** après analyse (pas de stockage sur disque)
- Aucune capture d'écran dans les logs
- Les traces d'audit ne contiennent que des **métadonnées** (horodatage, action, résultat), jamais de contenu patient

### 3.3 Pipeline d'anonymisation

| Étape | Technologie | Fonction |
|-------|-------------|----------|
| NER (détection entités) | **EDS-NLP** (AP-HP, open source) | Détection noms, dates, lieux, numéros dans le texte clinique français |
| Dé-identification | Remplacement systématique | Noms → pseudonymes, dates → décalage cohérent, lieux → généralisés |
| Validation | Échantillonnage + relecture clinicien | Contrôle qualité sur un échantillon de dossiers |
| Exécution | **ONNX Runtime (CPU)** | Pas de GPU requis, pas de dépendance cloud |

**Exclusions automatiques** :
- Notes personnelles du psychiatre (détection par métadonnées OSIRIS)
- Données d'identification directe (NIR, IPP) jamais stockées dans l'EDS

### 3.4 Entrepôt de Données de Santé (EDS)

| Aspect | Détail |
|--------|--------|
| **SGBD** | PostgreSQL 15+ |
| **Modèle de données** | OMOP CDM v5.4 (standard Health Data Hub) |
| **Chiffrement au repos** | LUKS (disque) + TDE PostgreSQL optionnel |
| **Chiffrement en transit** | TLS 1.3 pour toute connexion |
| **Accès** | Localhost uniquement (pas d'accès réseau direct) |
| **Sauvegarde** | Intégrée au plan de backup de l'établissement |
| **Rétention** | Selon politique de l'établissement (max 20 ans, R.1112-7 CSP) |

---

## IV. Traçabilité et audit

### 4.1 Journal d'audit (RPA traçable)

Toutes les actions du robot sont enregistrées :

| Donnée enregistrée | Exemple |
|-------------------|---------|
| Horodatage | `2026-04-14T09:32:15+02:00` |
| Action | `extraction_dossier`, `navigation_ecran`, `saisie_champ` |
| Résultat | `succès`, `échec`, `pause_supervisée` |
| Utilisateur superviseur | `dr.martin` (via AD) |
| Session ID | `sess_20260414_a3f2b1` |
| Durée | `2.3s` |

**Ce qui n'est JAMAIS enregistré** : contenu patient, captures d'écran, données de santé.

### 4.2 Consultation des logs

- Accès via **dashboard web sécurisé** (HTTPS/443)
- Authentification via l'annuaire de l'établissement (AD/LDAP)
- **Lecture seule** — aucun accès direct aux fichiers du serveur
- Rétention des logs : 1 an (configurable)

### 4.3 Supervision humaine (AI Act)

- Léa fonctionne en **mode supervisé** : un opérateur peut interrompre, corriger ou stopper le système à tout moment
- En cas d'échec d'une action, Léa se met en **pause** et attend l'intervention humaine (pas de retry aveugle)
- Toutes les interventions humaines sont tracées

---

## V. Sécurité du code et des modèles IA

### 5.1 Gouvernance du modèle IA

- **Entraînement en vase clos** : le modèle apprend exclusivement sur les données d'activité interne, sans export
- **Aucune donnée ni modèle transmis à l'extérieur**
- **Intégrité du modèle** : chaque version est signée numériquement — l'application vérifie la signature au démarrage
- **Modèles VLM** : exécutés localement via Ollama (pas d'API cloud)

### 5.2 Supply chain logicielle

- **SBOM** (Software Bill of Materials) : liste complète des composants open source fournie
- Engagement à patcher les vulnérabilités connues (CVE) sous 30 jours (critique) / 90 jours (autres)
- Dépendances auditées : PyTorch, ONNX Runtime, PostgreSQL, Flask, FastAPI

### 5.3 Protection de la propriété intellectuelle

Le serveur est traité comme une **"Boîte Noire"** :
- L'établissement n'a pas accès au code source ni aux modèles
- Consultation des logs uniquement via l'interface web (lecture seule)
- Pas d'accès direct au système de fichiers

---

## VI. Maintenance et gestion des incidents

### 6.1 Maintenance

| Aspect | Détail |
|--------|--------|
| **Accès** | SSH, limité à 1 IP source, clé SSH uniquement |
| **Intervenant** | Exclusivement nos équipes certifiées |
| **Fenêtre** | En dehors des heures d'extraction (nuit/week-end) |
| **Mises à jour** | Planifiées, testées en pré-production, validées par le DSI |
| **SLA** | Intervention sous 4h (critique) / 24h (normal) |

### 6.2 Gestion des incidents de sécurité

Conformément à **NIS2** (transposition FR juillet 2026) :

| Délai | Action |
|-------|--------|
| **< 1h** | Détection et containment (isolement du serveur si nécessaire) |
| **< 24h** | Notification à l'établissement + ANSSI si incident significatif |
| **< 72h** | Notification CNIL si violation de données personnelles |
| **< 30j** | Rapport d'incident complet |

### 6.3 Plan de continuité

- En cas de panne Léa : **aucun impact sur le DPI** — le robot n'écrit rien dans OSIRIS
- L'extraction peut être reprise là où elle s'est arrêtée (sessions persistantes)
- Les données déjà chargées dans l'EDS restent accessibles

---

## VII. Checklist de conformité

### À réaliser avant le démarrage du POC

| # | Action | Responsable | Statut |
|---|--------|------------|--------|
| 1 | Désigner le DPO (si pas déjà fait) | Clinique | ☐ |
| 2 | Réaliser l'AIPD (Analyse d'Impact) | Conjoint (nous + DPO) | ☐ |
| 3 | Valider la base légale (mission intérêt public ou intérêt légitime) | DPO + direction | ☐ |
| 4 | Déclaration CNIL (conformité référentiel EDS ou autorisation) | DPO | ☐ |
| 5 | Créer le compte OSIRIS dédié "Léa" (lecture seule) | DSI | ☐ |
| 6 | Provisionner la VM (specs §II.2) | DSI | ☐ |
| 7 | Configurer le réseau (VLAN, IP, firewall §II.4) | DSI | ☐ |
| 8 | Configurer l'accès SSH maintenance (1 IP source) | DSI | ☐ |
| 9 | Intégrer la VM au plan de sauvegarde | DSI | ☐ |
| 10 | Signer l'accord de confidentialité | Les deux parties | ☐ |
| 11 | Valider le périmètre des dossiers avec le médecin DIM | Clinique | ☐ |
| 12 | Documenter l'évaluation AI Act art. 6(3) | Nous | ☐ |