# Préparation réseau — Installation DGX Spark POC en clinique

**Date** : 2026-05-28
**Destinataire** : Nicolas PORQUET — DSI externe, Hôpital privé Wallerstein, 14 Boulevard Javal, 33740 Arès
**Émetteur** : Dom Bazin — porteur projet RPA Vision V3
**Partenaire métier** : Dr Amina [Nom à confirmer] — cabinet médical DIM (Bordeaux). Contribue au volet codage médical. **Interlocuteur projet unique côté technique : Dom Bazin.**
**Objet** : Demande de pré-requis réseau et sécurité pour l'installation d'une machine NVIDIA DGX Spark dans le cadre d'un POC de 3 mois à l'Hôpital privé Wallerstein.

---

## 1. Présentation du projet (résumé non-technique)

RPA Vision V3 est une solution d'automatisation 100 % vision qui assiste les TIM (Techniciens d'Information Médicale) dans la saisie de codes diagnostiques sur Easily Assure. L'assistant **Léa** s'exécute sur le PC du TIM (Windows existant, inchangé) et délègue la compréhension visuelle de l'écran à un serveur d'inférence (le DGX Spark), installé dans une salle technique de l'établissement.

**Objectifs du POC** :
- Mesurer le gain de productivité TIM sur un périmètre pilote restreint (**≤ 5 TIM**, volume de dossiers à cadrer avec le référent métier de l'établissement)
- Valider l'ergonomie et l'acceptation utilisateur
- Vérifier l'intégration dans l'environnement IT de l'établissement

**Durée prévue** : 3 mois — possibilité de retrait à tout moment.

---

## 2. Description matérielle DGX Spark

| Élément | Spécification |
|---------|---------------|
| Modèle | NVIDIA DGX Spark (Founders Edition) |
| Format | Boîtier compact bureau (~150 × 150 × 50 mm) |
| Alimentation | 240 W typique, 300 W crête — prise C13 standard |
| Réseau | 10 GbE + Wi-Fi 7 (Wi-Fi désactivé en clinique) |
| Stockage | 4 To NVMe interne, chiffré au repos (LUKS) |
| OS | DGX OS 7 (Ubuntu 24.04 LTS ARM64) — maintenu par NVIDIA |
| Mises à jour OS | `unattended-upgrades` pour les correctifs de sécurité |
| Antivirus / EDR | Compatible ClamAV. EDR du marché [À DÉFINIR avec DSI] |

**Sécurité physique** :
- Machine à installer en salle technique fermée, accès limité.
- Étiquetage avec contact responsable (Dom Bazin).
- Pas d'accès USB en production (verrouillé via udev).

---

## 3. Description logicielle (services hébergés sur le DGX)

Tous les services tournent **en containers Docker isolés** sur le DGX. Aucune installation native côté OS hors stack NVIDIA / Docker / outils standards Ubuntu.

| Service | Container | Port interne | Exposition |
|---------|-----------|--------------|-----------|
| Reverse proxy TLS local (Caddy ou Traefik) | `proxy` | 443 | LAN clinique uniquement |
| Frontend RPA (VWB React) | `frontend` | 80 (interne) | Via reverse proxy |
| Backend RPA (Flask) | `backend` | 5002 (interne) | Via reverse proxy |
| Streaming agent (Flask SocketIO) | `streaming` | 5005 (interne) | Via reverse proxy |
| Dashboard supervision | `dashboard` | 5001 (interne) | Via reverse proxy |
| Inférence VLM (Ollama / llama-server) | `ollama` | 11434 (interne) | **Jamais exposé**, accès local containers uniquement |

**Aucun service exposé en clair sur le LAN.** Toute communication entrante passe par 443/HTTPS avec authentification (Basic Auth + Bearer token applicatif).

---

## 4. Plan réseau souhaité

```
                          ┌─────────────────────────────┐
                          │   Internet (sortie filtrée) │
                          └──────────────┬──────────────┘
                                         │
                                  Pare-feu clinique
                                         │
                ┌────────────────────────┴────────────────────────┐
                │                                                 │
                │  LAN clinique — VLAN [À CONFIRMER]              │
                │                                                 │
                │   ┌──────────────────┐         ┌──────────────┐ │
                │   │  Poste TIM       │ HTTPS   │  DGX Spark   │ │
                │   │  Windows + Léa   │────────▶│  (headless)  │ │
                │   │  (existant)      │  :443   │              │ │
                │   └──────────────────┘         └──────────────┘ │
                │                                                 │
                └─────────────────────────────────────────────────┘
```

### Pré-requis réseau demandés à la DSI

| Élément | Demande |
|---------|---------|
| Adressage | **1 IP fixe** (DHCP réservation par MAC ou statique) sur VLAN postes de travail ou VLAN dédié |
| MAC | Communiquée à l'installation (étiquette boîtier) |
| Hostname | `rpa-spark-01` (modifiable selon convention DSI) |
| DNS interne | Résolution `rpa-spark-01.[domaine.interne]` |
| Synchronisation horloge | Accès NTP (serveur clinique ou `pool.ntp.org`) |
| Découverte | Pas de mDNS / Bonjour requis |

---

## 5. Flux entrants requis (LAN clinique → DGX Spark)

| Source | Destination | Port | Protocole | Usage |
|--------|-------------|------|-----------|-------|
| Postes TIM (Léa) | DGX Spark | 443 | TCP HTTPS | Accès apps web RPA (VWB, dashboard, API streaming) |
| Postes admin clinique | DGX Spark | 22 | TCP SSH | Maintenance locale [optionnel, peut être supprimé] |

**Pas de flux entrant depuis Internet.** Le DGX n'expose aucun port public.

---

## 6. Flux sortants requis (DGX Spark → Internet)

Justification : maintenance, mises à jour, pull d'images Docker et de modèles d'IA. **Aucune donnée patient ne sort du DGX** (voir §8 Conformité).

### Whitelist FQDN demandée

| Domaine | Port | Usage |
|---------|------|-------|
| `archive.ubuntu.com`, `security.ubuntu.com` | 80, 443 | Mises à jour Ubuntu |
| `ports.ubuntu.com` | 80, 443 | Paquets Ubuntu ARM64 |
| `developer.download.nvidia.com`, `apt.nvidia.com` | 443 | Driver + CUDA NVIDIA |
| `registry-1.docker.io`, `auth.docker.io`, `index.docker.io` | 443 | Images Docker |
| `registry.ollama.ai` | 443 | Modèles d'inférence Ollama |
| `huggingface.co`, `cdn-lfs.huggingface.co` | 443 | Modèles HuggingFace (poids ML) |
| `github.com`, `objects.githubusercontent.com`, `raw.githubusercontent.com` | 443 | Code projet (déploiement / mise à jour) |
| `pypi.org`, `files.pythonhosted.org` | 443 | Dépendances Python |
| `pool.ntp.org` ou NTP clinique | 123 UDP | Synchronisation horloge |
| Résolveur DNS clinique | 53 UDP/TCP | Résolution DNS |

### Flux sortant accès admin distant (selon option choisie §7)

| Option | Domaines / IP | Port | Usage |
|--------|---------------|------|-------|
| OpenVPN clinique | Concentrateur VPN désigné par la DSI | 1194 UDP ou 443 TCP | VPN entrant Dom → réseau clinique |
| Reverse SSH bastion (repli) | IP fixe bastion Dom (à communiquer) | 22 ou 443 TCP | Tunnel SSH inversé |
| Tailscale (alternative, si DSI valide) | `*.tailscale.com`, `controlplane.tailscale.com`, `derpN.tailscale.com` | 443 TCP, 3478/41641 UDP | Mesh VPN sortant |

---

## 7. Accès administrateur distant — options à arbitrer avec la DSI

Le porteur projet (Dom Bazin) doit pouvoir intervenir sur le DGX **depuis son poste de travail externe** pour : déployer les mises à jour applicatives, diagnostiquer les incidents, ajuster les modèles d'IA. **Aucune intervention sur les données patient à distance**.

Dom Bazin utilise habituellement **OpenVPN + SSH par certificat** dans le cadre de ses interventions sur infrastructures clientes. Cette pratique s'aligne sur les standards courants en milieu hospitalier et permet une intégration directe à la politique de la DSI.

| Option | Principe | Avantage DSI | Inconvénient | Préférence Dom |
|--------|----------|--------------|--------------|----------------|
| **A. OpenVPN clinique + SSH par certificat** | Dom devient utilisateur d'un tunnel OpenVPN existant ou monté pour le POC par la DSI. Accès SSH au DGX restreint aux IP du sous-réseau VPN. Authentification SSH par clé publique RSA/Ed25519 (pas de mot de passe). | Politique maîtrisée par la DSI, traçabilité dans les logs OpenVPN + sshd, pas de tiers de confiance externe. Compatible audit ANSSI. | Charge initiale de configuration (création du compte VPN, distribution certificat, ACL pare-feu vers le DGX). | **Recommandé** — pratique habituelle de Dom, simple, conforme |
| **B. Reverse SSH tunnel via bastion** | Le DGX initie un tunnel SSH inversé vers un bastion contrôlé par Dom (clé SSH, MFA TOTP, audit en place). Aucune ouverture de flux entrant côté clinique. | Aucun flux entrant à ouvrir, isolement réseau total. | Repose sur un bastion externe (responsabilité Dom), à auditer si exigence DSI. | Repli si l'option A pose un blocage opérationnel |
| **C. Tailscale (mesh VPN WireGuard)** | Le DGX initie une connexion sortante sur 443 vers le contrôle Tailscale. Aucun port entrant ouvert. ACL stricte, MFA obligatoire. Solution citée par NVIDIA dans les playbooks DGX Spark. | Pas de port entrant, MFA, audit, granularité ACL. | Dépendance fournisseur tiers (Tailscale Inc.), nouveau dans l'environnement Dom — courbe de validation supplémentaire pour le POC. | Alternative si la DSI souhaite éviter le VPN traditionnel |

**Position Dom** : option A si Nicolas PORQUET valide la mise à disposition d'un compte OpenVPN dédié POC, sinon option B avec bastion personnel. Option C laissée à la discrétion de la DSI.

**Engagement Dom** :
- Clé SSH publique communiquée à la DSI, clé privée stockée chiffrée (passphrase + keystore matériel YubiKey si exigé)
- Session SSH limitée au compte `dom` (sudo journalisé), pas de root direct
- Activité distante journalisée et exportable sur demande DSI
- Suppression de l'accès en fin de POC ou sur demande immédiate de la DSI

---

## 8. Conformité — RGPD / HDS / certifications

### Données traitées
- Le DGX traite **uniquement en mémoire vive** des captures d'écran issues du poste TIM (éléments d'interface logiciel Easily Assure).
- **Aucun stockage permanent** des captures sur le DGX, y compris en POC. Les captures sont chargées en RAM, traitées par le pipeline VLM, et **détruites immédiatement** après la réponse au client Léa.
- Pas de copie de base de données patient sur le DGX.
- Pas de communication patient ↔ DGX. Le DGX assiste un TIM qui reste l'utilisateur unique du PMSI.

### Anonymisation
- Module `core/anonymisation/pii_blur.py` (EDS-NLP NER médical français + regex de secours) **activé par défaut** sur le pipeline VLM côté serveur. Identités et dates sont floutées avant tout traitement VLM. Le contenu clinique métier (codes, libellés) reste intact.

### Hébergement
- **100 % on-premise dans la clinique** : pas de cloud, pas de sortie de donnée patient hors LAN clinique.
- Le porteur projet ne reçoit **aucune donnée patient** en dehors de la clinique, ni en RAM ni en fichier. Les sessions de maintenance à distance portent exclusivement sur configuration, logs applicatifs et métriques techniques — jamais sur les captures écran.

### Audit / traçabilité
- Logs applicatifs conservés 90 jours sur le DGX (rotation `logrotate`), exportables sur demande DSI.
- Logs accès SSH/VPN tracés.
- Accès admin distant audité (Tailscale / VPN clinique).

### Certifications
- DGX OS 7 = Ubuntu 24.04 LTS, mises à jour de sécurité jusqu'en 2034.
- Pas de certification HDS sur la machine elle-même (POC, pas d'hébergement contractuel). Si industrialisation : hébergement en intra-clinique sous responsabilité de la DSI, ou migration chez hébergeur HDS certifié.

### DPO / contrat
- Convention POC à signer (annexe à fournir) : finalité, durée, responsable de traitement, sous-traitant, mesures de sécurité.
- Désignation des personnes habilitées à l'accès admin distant (nominatif : Dom Bazin).

---

## 9. Sécurité opérationnelle

| Mesure | Mise en œuvre |
|--------|---------------|
| Comptes locaux | 1 compte admin nominatif (`dom`), pas de root direct (sudo) |
| Authentification | Clé SSH uniquement (mots de passe SSH désactivés) |
| Pare-feu local | `ufw` activé, deny par défaut, règles explicites |
| Chiffrement disque | LUKS sur partition de données (clé sous séquestre DSI possible) |
| Mises à jour OS | `unattended-upgrades` automatique pour sécurité, redémarrage planifié hors heures TIM |
| Mises à jour appli | Push contrôlé par Dom via Git + rebuild containers, fenêtre négociée avec TIM |
| Sauvegarde config | Repo Git distant (pas de donnée patient sauvegardée hors DGX) |
| Supervision | Métriques Prometheus + alertes si dégradation |
| Plan d'arrêt | Possibilité d'arrêt à distance par DSI (kill switch via Tailscale ACL ou physiquement) |

---

## 10. Plan d'installation (J-7 → J+0)

| Jalon | Action | Acteur |
|-------|--------|--------|
| J-7 | Validation présent document par Nicolas PORQUET (DSI) | DSI |
| J-5 | Réservation IP + ouverture flux pare-feu + création compte OpenVPN POC | DSI |
| J-3 | Pré-configuration DGX hors clinique (env, containers, modèles d'IA) | Dom |
| J-1 | Livraison et installation physique en salle technique | Dom + DSI |
| J+0 | Connexion réseau, tests de bout en bout avec poste TIM pilote | Dom + DSI + TIM |
| J+1 → J+90 | POC en production limitée (≤ 5 TIM), points hebdomadaires | Dom + référent métier clinique |

---

## 11. Responsabilités

| Domaine | Responsable |
|---------|-------------|
| Hardware DGX + OS + containers RPA | Dom Bazin (porteur projet) |
| Réseau LAN, pare-feu, VLAN, DNS | Nicolas PORQUET (DSI externe) |
| Accès distant administrateur | Dom (config) + DSI (validation politique et fourniture VPN) |
| Conformité RGPD globale | DPO Hôpital Wallerstein + Dom comme sous-traitant |
| Support utilisateur TIM | Dom + référent TIM clinique |
| Volet métier codage médical | Dr Amina [Nom à confirmer] (partenaire) |
| Incident sécurité | DSI (escalade), Dom (action technique) |

---

## 12. Coordonnées

| Rôle | Nom | Contact |
|------|-----|---------|
| Porteur projet, interlocuteur unique, contact technique 24/7 | Dom Bazin | **06 70 45 30 05** — [email à compléter] |
| DSI externe Hôpital Wallerstein | Nicolas PORQUET | [contact à renseigner par DSI] |
| Partenaire métier (cabinet médical DIM, Bordeaux) | Dr Amina [Nom à confirmer] | Non impliquée dans les échanges DSI directs |
| Référent TIM clinique | [À renseigner par Hôpital Wallerstein] | — |
| DPO Hôpital Wallerstein | [À renseigner] | — |

---

## 13. Annexes (à joindre)

- A. Fiche technique DGX Spark (PDF NVIDIA)
- B. Diagramme d'architecture détaillé (data flow Léa ↔ DGX)
- C. Convention POC type (RGPD, finalité, durée, sous-traitance)
- D. Liste exhaustive des FQDN sortants (whitelist firewall)
- E. Procédure d'arrêt d'urgence

---

## Décisions

| # | Décision | Date |
|---|----------|------|
| 1 | Cible POC : Hôpital privé Wallerstein, 14 Boulevard Javal, 33740 Arès — DSI externe Nicolas PORQUET | 2026-05-28 |
| 2 | DGX déployé en salle technique clinique, headless, containers Docker, 100 % on-premise | 2026-05-28 |
| 3 | Aucun flux entrant Internet, tout sortant via whitelist FQDN | 2026-05-28 |
| 4 | Accès distant Dom : **option A privilégiée = OpenVPN clinique + SSH par certificat**, option B repli = reverse SSH bastion, option C = Tailscale si DSI le préfère | 2026-05-28 |
| 5 | Anonymisation PII activée par défaut sur le pipeline VLM en POC | 2026-05-28 |
| 6 | Captures écran traitées **uniquement en RAM**, détruites immédiatement après réponse VLM, jamais persistées sur disque | 2026-05-28 |
| 7 | Périmètre pilote ≤ 5 TIM, volume dossiers à cadrer avec référent métier | 2026-05-28 |
| 8 | Interlocuteur unique côté Dom Bazin (Amina = partenaire métier, hors échanges DSI) | 2026-05-28 |

## Questions ouvertes

- VLAN d'accueil du DGX (poste de travail / dédié / DMZ interne)
- Modalités OpenVPN : OpenVPN existant pour Wallerstein ou à mettre en place pour le POC ?
- EDR / antivirus à installer en sus (politique Nicolas PORQUET)
- Politique de séquestre de clé LUKS (clé conservée par DSI ?)
- Fenêtre d'installation physique (J-1 / J+0)
- Désignation du référent TIM clinique côté Wallerstein
- Coordonnées DPO Wallerstein pour validation convention POC RGPD
- Volume de dossiers cible par TIM par jour (cadrage avec référent métier)
- Email professionnel Dom à inscrire sur le doc final

## Sources et références techniques

- [DGX Spark connectivité et provisioning — NVIDIA Playbooks](https://deepwiki.com/NVIDIA/dgx-spark-playbooks/2.2-connecting-to-your-spark)
- [DGX OS 7 User Guide](https://docs.nvidia.com/dgx/dgx-os-7-user-guide/dgx-os-7-user-guide.pdf)
- [Tailscale architecture et conformité](https://tailscale.com/security/)
- [ANSSI — Guide d'hygiène informatique](https://cyber.gouv.fr/sites/default/files/document/guide_hygiene_informatique_anssi.pdf)
- [HDS — Référentiel ASIP Santé](https://esante.gouv.fr/labels-certifications/hds/referentiel-de-certification)