Faire du cockpit web un outil DSIO complet et natif de PULSAR-CHU : un poste de conduite d'intervention opérateur-centré (l'humain agit, l'IA assiste), couvrant deux modalités — à distance (la sonde) et sur site (accès physique) — sur un seul socle de gouvernance. Le système ne profite plus seulement aux agents : il outille les administrateurs et produit ses preuves d'intervention automatiquement.
L'IA ne touche jamais directement un système critique. Toute opération mutante/sensible passe par approbation ; les plus sensibles par double validation inter-sites.
Nouveau package chu/cockpit/ monté sur le serveur d'opérations (FastAPI), réutilisant les briques existantes :
| Brique cockpit | Module réutilisé | Rôle |
|---|---|---|
| Auth / RBAC / TOTP | recette/auth.py | qui peut voir/proposer/approuver/exécuter |
| Exécution distante | modèle agent/commande | jouer un playbook via la sonde |
| Exécution locale (sur site) | exécuteurs déterministes | playbooks sur le poste/relais |
| Caviardage PHI | chu/privacy_engine | aucune donnée patient dans logs/IA/rapport |
| Journal inviolable | audit chaîné SHA-256 | chaque étape/approbation/action tracée |
| PV d'intervention | generer_livrable.py | livrable parfait fond + forme (AP-CANON-001) |
auth.py, l'audit et generer_livrable.py en modules partagés (chu/commun/).chu/cockpit/)id, categorie, titre, risque (lecture/mutant/sensible), version, etapes[], signature. Actif signé/versionné (playbooks.yaml).type (read_only / mutant), connecteur/commande, role_requis.id (INC-…), incident, sites[], operateur, statut, timeline liée à l'audit.dry_run, rollback, quorum M / total N, identites_distinctes, proposeur_exclu, approbations[], statut.intervention_id, auteur, role, texte caviardé, hash_source (lien plan d'interaction — AP-CANON-001)./api/cockpit/…)| Endpoint | Rôle | Permission |
|---|---|---|
| GET /catalogue | playbooks (filtrés RBAC) | voir |
| POST /interventions | ouvrir une intervention | proposer |
| POST /interventions/{id}/etape | jouer une étape (lecture directe ; mutante → file) | exécuter |
| POST /interventions/{id}/operation | proposer une opération sensible | proposer |
| POST /operations/{id}/approuver | approuver (TOTP, identité distincte) — M-parmi-N | approuver |
| POST /operations/{id}/appliquer | exécuter (dry-run + rollback) une fois le quorum atteint | exécuter |
| GET/POST /interventions/{id}/chat | chat caviardé | voir / proposer |
| POST /interventions/{id}/pv | générer le PV d'intervention | voir |
Une opération sensible n'est applicable que si quorum atteint avec des identités réellement distinctes, chacune confirmée par TOTP, le proposeur exclu. Extensible en M-parmi-N (ex. 2-sur-3). Toujours : dry-run → application → rollback armé, exécuteur déterministe et à moindre privilège, fenêtre de changement.
| Tranche | Contenu | Impact système |
|---|---|---|
| 0 — Fondations | catalogue (playbooks.yaml) + modèles + UI servie | additif, non-disruptif |
| 1 — Diagnostics lecture | playbooks lecture via sonde/exécuteur, sorties caviardées + tracées | lecture seule |
| 2 — Double validation | OperationSensible M-parmi-N + file + dry-run/rollback + connecteur firewall (simulation) | mutant, gated |
| 3 — Chat d'intervention | chat caviardé, lié au plan d'interaction | additif |
| 4 — PV automatique | generer_livrable → PV signé | additif |
| 5 — Connecteurs réels | firewall / hyperviseur / IGA, least-privilege, fenêtres | sensible, encadré |
lecture vs mutant séparés ; mode ad-hoc fortement restreint et journalisé.