Set-OPS-Public/wiki/Le-GUI-console-d-exploitation.md

# Le GUI (console d'exploitation)

> **Unité d'apprentissage.** Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

---

## ① Le concept *(générique)*

Un moteur d'infrastructure a besoin d'une **interface humaine** — sinon il n'est utilisable que
par son auteur (ou une IA). Le principe fondateur : **un opérateur doit tout piloter seul**, sans
l'auteur et sans IA (« exploitable sans IA »).

Une bonne console d'exploitation obéit à trois règles :

- **Elle édite la SOURCE, pas l'artefact.** On modifie le *plan* (l'état voulu), jamais l'inventaire
  généré. La console montre la vérité, elle ne la contourne pas.
- **Elle prévisualise avant d'agir.** *dry-run* (voir ce qui changerait) avant *apply* (changer).
- **Elle empêche l'invalide.** Le meilleur garde-fou n'est pas un message d'erreur : c'est une
  interface où l'erreur est **impossible à saisir**.

---

## ② Comment Set-OPS le fait

`make inventaire-ui` lance une console web **locale** (`127.0.0.1`, protégée par un jeton). Ses vues :

| Vues **éditables** (le plan) | Vues **dérivées** (lecture seule) |
|---|---|
| Serveurs · **Intégrations** · Applications · Bases · Domaines · **Nomenclature** · **Intrants** | Flux · Couches · **Réseau** (flotte + devis) |

Le flux d'exploitation, de bout en bout :

1. **Éditer** une vue du plan → **Sauvegarder** ;
2. **« Appliquer le plan »** → régénère l'inventaire (VMID/IP/VLAN **dérivés**) ;
3. **Vérifier** (dry-run) sur un hôte → prévisualise sans rien changer ;
4. **Déployer** → applique les rôles (confirmation **renforcée** si l'instance est en **PROD**) ;
5. **Créer la VM** → clone sur Proxmox depuis le plan.

**L'erreur rendue impossible.** Le champ « Hôte » d'une application est un `<select>` qui ne
propose que des **hôtes réels** : impossible de pointer vers un hôte fantôme. La console couvre le
schéma du plan — et la preuve **P19** le vérifie.

**Les formulaires sont GÉNÉRÉS.** Depuis le 2026-09-08, les vues **Bases** et **Nomenclature** ne
portent plus de formulaire écrit à la main : elles le construisent depuis
`docs/audit/schema-plan.json`, lui-même dérivé des constantes du moteur (`make schema`). Un champ
ajouté au plan apparaît donc à l'écran **sans qu'on touche à l'interface**, et la preuve **P61**
refuse qu'un champ des plans réels manque au schéma — ou que le schéma décrive une **forme** que
les plans n'ont pas.

**La flotte, dans la vue Réseau.** Voir toutes les instances, **basculer** (« Activer »), **créer**
une instance depuis un modèle, repérer une **collision** d'index. Cf.
[Multi-instance & fédération](Multi-instance-et-fédération).

### Les vues, annotées

Chaque figure porte ses **repères** (pastilles + légende). Les vues **éditables** d'abord (le plan),
puis les vues **dérivées** (lecture seule) :

**Serveurs** *(éditable)* — inventaire actif et état de la flotte ; cartes serveur et tuiles
VMID/IP/VLAN **dérivées** du seed ; formulaire **Identité** = le seul endroit où l'on édite le plan.

![Vue Serveurs, annotée](img/Set-OPS-Serveurs-annote.svg)

**Nomenclature** *(éditable)* — le **modèle** dont tout l'adressage dérive : zones de sécurité,
fonctions (catégorie · service), réservations. Chaque fonction montre **ce qu'elle dérive** — zone,
VLAN, sous-réseau, bloc d'hôtes — et les VM qui la portent ; on ne retire pas une fonction encore
portée. L'`index` y est **affiché mais pas éditable** : il est *alloué par le site*, pas décidé par
le tenant (cf. l'en-tête de `plan/nomenclature.yml`), et s'édite depuis le panneau **Intrants**.

**Applications** *(éditable)* — catalogue des applis, éditeur (rôle · hôte · port · FQDN exposé),
relations déclaratives (requiert · liens · bases), dépendances causales.

![Vue Applications, annotée](img/Set-OPS-Applications-annote.svg)

**Bases — serveur** *(éditable)* — les moteurs SGBD et les bases applicatives « nom @ serveur »,
avec les bases hébergées sur chaque serveur.

![Vue Bases (serveur BD), annotée](img/Set-OPS-Bases-annote.svg)

**Bases — fiche** *(éditable)* — portée · consommateur · serveur, **secret Vault** (jamais en clair,
un pointeur seulement) et le **DSN dérivé** (secret masqué).

![Vue Bases (fiche de base), annotée](img/Set-OPS-Bases-2-annote.svg)

**Domaines** *(éditable)* — zones DNS publique vs interne, autorité · edge · DNSSEC, expositions.

![Vue Domaines, annotée](img/Set-OPS-Domaines-annote.svg)

**Intégrations** *(éditable)* — la **matrice serveurs × intégrations**. Les colonnes ✓ vertes
sont la **politique des rôles** : elles s'appliquent à tout hôte et ne se décochent pas ; un `—`
barré signale une **exemption dérivée du service rendu** (l'AC ne s'enrôle pas auprès d'elle-même).
Les autres colonnes sont de vrais choix, cochables ici. La ligne **couverture** ne juge pas — elle
rend le motif visible : c'est au lecteur de savoir si les manquants sont des décisions ou des oublis.

> Cette vue existe parce que la fiche de détail ne montrait les intégrations que **d'un serveur à
> la fois**. Deux serveurs sans supervision ni journaux sont restés invisibles jusqu'à ce qu'un
> devis de pare-feu les énumère : l'information était à l'écran, répartie sur quatorze clics.

**Flux** *(dérivée)* — la **matrice d'audit** : la source de nftables *et* la justification lisible
de chaque flux (sens ingress/egress, chiffrement).

![Vue Flux, annotée](img/Set-OPS-Flux-annote.svg)

**Couches** *(dérivée)* — l'**ordre de déploiement** en 6 couches, du socle aux agents ; celui que
`make deployer-tout` déroule.

![Vue Couches, annotée](img/Set-OPS-Couches-annote.svg)

**Réseau** *(dérivée)* — la **flotte multi-instances** : adressage dérivé du seed, bascule
d'instance, devis de configuration des switches.

![Vue Réseau, annotée](img/Set-OPS-Reseau-annote.svg)

> Chaque figure est un **SVG auto-contenu** (la capture y est intégrée) : un seul fichier portable
> qui rend tel quel dans le wiki, un `.md` du dépôt, ou un navigateur.

---

## ③ Pourquoi c'est transférable

| Set-OPS | Équivalents ailleurs |
|---|---|
| GUI au-dessus d'Ansible | **AWX** / Ansible Automation Platform, **Semaphore** |
| éditer la source de vérité | l'UI de **NetBox** (IPAM/DCIM), une CMDB |
| dry-run → apply | `terraform plan/apply`, tout panneau IaC |
| l'invalide impossible à saisir | *validation à la source*, formulaires contraints |

Tu as appris **la console d'exploitation, éditer-la-source, dry-run-avant-apply, la validation à la
saisie** — pas « le GUI de Set-OPS ».

---

## ④ À toi de jouer

1. **Lance-la.** `make inventaire-ui`, ouvre l'URL affichée. Repère l'inventaire actif et l'état de
   la flotte (en haut), les onglets, « Appliquer le plan », « Sauvegarder ».
2. **Édite → prévisualise.** Vue **Serveurs**, change la mémoire d'un hôte, **Sauvegarder**,
   **Appliquer le plan**, puis **Vérifier** (dry-run) : tu vois ce qui *changerait* avant d'agir.
3. **Répare un hôte fantôme (l'erreur impossible).** Si une appli pointe un hôte inexistant, ouvre
   la vue **Applications**, sélectionne-la : le `<select>` « Hôte » ne montre **que des hôtes
   réels**. Choisis le bon, **Sauvegarder**, **Appliquer**. Tu ne *peux pas* re-saisir le fantôme.
4. **Bascule d'instance.** Vue **Réseau**, bouton **« Activer »** sur une autre instance. Toutes
   les vues suivent, sans redémarrer.
5. **Sens le garde-fou.** Essaie de sauvegarder un plan incohérent (ex. une base dont le
   consommateur n'existe pas) : la console **refuse** avec une raison. L'invalide ne passe pas.
6. **Casse & répare.** Édite `hosts.yml` à la main, reviens dans la GUI, « Appliquer le plan » : ta
   modification est **écrasée** par le plan. La source de vérité, c'est le plan — pas l'inventaire.

---

## Pour aller plus loin *(dépôt)*
- Lancer : `make inventaire-ui` ; le code : `scripts/inventory_gui.py`.
- Ce que le GUI sait écrire (et la preuve) : `scripts/couverture_gui.py` (P19).
- Le flux plan → apply : unité **[Infra as Code & idempotence](Infra-as-Code-et-idempotence)**.
- La flotte : unité **[Multi-instance & fédération](Multi-instance-et-fédération)**.