# PULSAR-CHU — Dossier de passation & prompt de reprise

> **Objet :** transmettre l'intégralité du contexte pour qu'un autre agent (ou une future session) reprenne ce travail **sans perte de cohérence**.
> **Auteur :** William MERI (DSIO, CHU de Guyane) · **Date :** 2026-06-13 · **Version :** 1.0
> Garde ce fichier à jour ; il est la source de vérité de la passation.

---

## 1. Mission & vision

PULSAR-CHU est une plateforme d'IA médicale **souveraine**, fork de hermes-agent (NousResearch, MIT), à destination du CHU de Guyane. Au-delà de l'agent médical, la **cible** est une **tour de contrôle souveraine du SI hospitalier** à cerveau IA : AIOps + SOAR + IGA + GRC unifiés, **l'IA conseille, l'humain décide, tout est prouvé**.

Deux modalités d'usage, un seul socle de gouvernance : **à distance** (sonde reverse-polling) et **sur site** (cockpit d'intervention). À l'échelle du territoire : **3 instances fédérées** (une par site/DPI : Cayenne, Kourou, Saint-Laurent).

---

## 2. Principes directeurs (NON négociables)

1. **L'IA ne touche jamais directement un système critique.** Flux : *Capter → Protéger (PHI) → Raisonner → Proposer → Approuver → Agir (déterministe) → Prouver.*
2. **Souveraineté de la donnée de santé.** La PHI ne quitte jamais son site en clair ; **aucune PHI vers le cloud** (Teams/push = signaux caviardés minimaux). Privacy Engine actif par défaut.
3. **Exécution pilotée par l'humain** sur prod/CHU : proposer les commandes, l'admin les exécute (mode « piloté »). Ne jamais lancer d'action sensible sans validation.
4. **Intégrer, pas réimplémenter** : réutiliser les briques existantes ; moteurs tiers open-source sous le control plane PULSAR.
5. **Canonicalisation à 2 plans** (AP-CANON-001) : normaliser la FORME jamais les FAITS ; plan d'interaction (brut, borné RGPD) lié par hash SHA-256 au plan probant (immuable). Ne jamais falsifier ni masquer un écart.
6. **Opérations sensibles = double/triple validation** (four-eyes / M-parmi-N, identités distinctes, proposeur exclu, TOTP ou WebAuthn).
7. **Livrables certifiés** : H(faits) ≠ H(artefact) ; la version opposable est un PDF généré serveur (déterministe + signé PAdES + PDF/A-3 à source embarquée), pas l'impression navigateur.
8. **Doctrine de production** : proposer des versions plus **ambitieuses et cohérentes** que la demande littérale ; rester **pédagogique** ; produire des livrables HTML/CSS autoportants premium.

---

## 3. État actuel — ce qui est construit

**Socle recette (opérationnel) :** `recette/serveur_recette.py` (FastAPI:9333, auth + audit chaîné + modèle agent + gouvernance 3 modes), `recette/auth.py` (PBKDF2 + TOTP + RBAC + sessions HMAC), `recette/agent-recette.ps1` (sonde Windows, **correctif TLS PS 5.1 délégué C# natif committé**). Console en **HTTPS** ; **mTLS en cours** (cf. §4).

**Privacy Engine (intégré, actif) :** `chu/privacy_engine/` (middleware, glass-break, 7 patches couvrant 100 % des flux) + `src/privacy-engine/` (anonymizer NER CamemBERT-bio, microservice). 12 types de PHI, pseudonymisation réversible.

**Principes d'architecture :** `docs/architecture/PRINCIPE_CANONICALISATION_INTENTION.md` (AP-CANON-001) · `docs/architecture/PRINCIPE_COCKPIT_DSIO.md` (AP-COCKPIT-001).

**Fondations cockpit (non-disruptif) :** `chu/cockpit/` → `models.py` (Intervention, Playbook, **OperationSensible** avec logique M-parmi-N à identités distinctes), `playbooks.yaml` (catalogue tiéré par risque), `catalogue.py`, `__init__.py`.

**Livrables visuels (HTML autoportants) :**
- `docs/charte-pulsar.html` — charte visuelle (design system tickets).
- `docs/pipeline-reformulation.html` — schéma canonicalisation (log brut → PV).
- `docs/orchestration-federee.html` — schéma fédération 3 sites + Teams/Power Automate + lane directeur.
- `chu/cockpit/templates/pv-direction.html` — PV explicatif (tenants & aboutissants).
- `chu/cockpit/templates/pv-exemple-3sites.html` — **PV technique** (commandes rétractables par site, captures SVG embarquées, triple validation).
- `chu/cockpit/templates/pv-intervention.html` — **déprécié** (ancien « PV de preuve », scindé en direction + technique ; devenu page de redirection).
- `chu/cockpit/templates/maquette-mobile.html` — PWA d'approbation Face ID/WebAuthn.
- `recette/demo-kit/` — sonde portable + PKI (`generer-certs.sh`) + `DEMO-RUNBOOK.md` + `mode-operatoire.html` + `presentation.html` (deck) + `dossier-livrable.html` + `cockpit-mockup.html`.

---

## 4. Reste à faire (priorisé)

1. **mTLS Phase C/D** — serveur en `CERT_OPTIONAL` (stable). Déployer l'agent à cert client (`agent-client.pfx`), puis créer le marqueur `recette/tls/mtls-required` et redémarrer → `CERT_REQUIRED`. **Touche la sonde live → feu vert humain requis.**
2. **Note d'archi « Certification des livrables »** (H(faits) vs H(artefact), déterminisme, PAdES, PDF/A-3 à source embarquée).
3. **Câbler `generer_livrable.py`** → produire PV direction + technique depuis une intervention réelle, puis PDF/A-3 signé (WeasyPrint + PAdES) + ancrage de l'empreinte dans le journal.
4. **Cockpit — tranches 1→5** (cf. AP-COCKPIT-001 §7) : router FastAPI `chu/cockpit/router.py`, montage sur le serveur d'ops, connecteurs (firewall/hyperviseur/IGA) least-privilege, file de double validation.
5. **PWA mobile** : WebAuthn (Face ID/Touch ID) pour signer les approbations, Web Push caviardé (réveil minimal).
6. **Note d'archi « Orchestration fédérée »** (AP-FEDERATION) : mesh 3 instances, coordinateur basculable, escalade Power Automate/Teams (payload caviardé), matrice de gravité.

---

## 5. Contraintes & garde-fous opérationnels

- **Ne pas perturber la sonde connectée** : tout redémarrage de `serveur_recette.py` la déconnecte → prévenir / feu vert.
- **Le canal sonde est l'unique voie vers Windows** : ne jamais tuer l'agent sans voie de récupération (cf. mémoire `recette_agent_tls`).
- **Bash potentiellement bloqué** : dans la session d'origine, le classifieur de sécurité a bloqué tout shell (contexte sonde/C2). Les outils d'écriture de fichiers fonctionnent. Une session neuve peut retrouver le shell.
- **Commits** : le dépôt est `/home/tarzzan/codex/PULSAR-CHU`. Committer uniquement les chemins pertinents (le working tree contient beaucoup de fichiers non liés). Co-auteur requis.

---

## 6. Comment vérifier l'état

- Mode de gouvernance : `recette/mode.json` (autonome/hybride/piloté).
- État mTLS : présence de `recette/tls/{cert,key,ca}.pem` et du marqueur `mtls-required`.
- Tester la couche cockpit (sans serveur) : `python3 -c "from chu.cockpit import charger_catalogue; print(len(charger_catalogue()))"`.
- Logique four-eyes : `chu/cockpit/models.py` → `OperationSensible.peut_approuver / quorum_atteint / applicable`.

---

## 7. Le prompt à copier (reprise par un agent)

> Copie le bloc ci-dessous dans un agent neuf, accompagné de ce fichier.

```
Tu reprends le projet PULSAR-CHU (CHU de Guyane), une plateforme d'IA médicale
souveraine dont la cible est une « tour de contrôle souveraine du SI hospitalier »
(l'IA conseille, l'humain décide, tout est prouvé). Lis d'abord
docs/HANDOFF-CONTINUATION.md (contexte, état, roadmap, garde-fous) et les notes
d'architecture docs/architecture/AP-CANON-001 et AP-COCKPIT-001.

Respecte impérativement les principes directeurs (§2 du handoff) : l'IA ne touche
jamais directement un système critique ; aucune PHI vers le cloud ; exécution
pilotée par l'humain sur prod/CHU (tu proposes, l'admin exécute) ; canonicalisation
à deux plans sans falsification ; opérations sensibles en double/triple validation ;
livrables certifiés (PDF serveur déterministe + signé, pas l'impression navigateur) ;
intégrer plutôt que réimplémenter.

Adopte la doctrine de production : propose des versions plus ambitieuses et
cohérentes que la demande littérale, reste pédagogique, et produis des livrables
HTML/CSS autoportants conformes à la charte (docs/charte-pulsar.html).

Avant toute action sensible (redémarrage du serveur de recette, bascule mTLS,
exécution sur la sonde) : demande le feu vert humain — la sonde connectée est
l'unique voie vers le poste distant. Ne committe que les chemins pertinents.

Prochaine priorité : [INDIQUER ICI la tâche choisie dans la roadmap §4 du handoff,
ex. « câbler generer_livrable.py vers les templates PV + PDF/A-3 signé »].
Commence par récapituler l'état que tu observes, puis propose un plan avant d'agir.
```

---

*Ce dossier respecte les principes qu'il transmet : précis, tracé, versionné.*