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 six registres** — serveurs,
applications, bases de données, serveurs de BD, domaines et nomenclature — ne portent plus de
formulaire écrit à la main : ils 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 il arrive au fichier, parce que la sauvegarde dérive du
même schéma. Ouvrir une vue et enregistrer sans rien toucher renvoie **exactement** le plan qu'on
vient de lire ; c'est mesuré à chaque `make prouver`.

Deux champs gardent volontairement leur propre éditeur, et le schéma le déclare : la **matrice des
intégrations** (elle montre aussi les universelles, non décochables, et les exemptions) et
l'**éditeur de liens** (il contraint le rôle à ce que `meta/liens.yml` accepte). Le générateur
s'efface plutôt que de remplacer un éditeur qui en sait plus que lui.

Deux preuves tiennent le schéma : **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 ; **P62** refuse
qu'un champ accepté par les *validateurs du moteur* manque au schéma — sans quoi le formulaire ne
saurait pas offrir une fonctionnalité que Set-OPS possède déjà.

**Sauvegarder n'efface plus les commentaires du plan.** Les registres portent la mémoire écrite des
décisions — pourquoi `backup-01` a été retiré, dans quel ordre les rôles du runner s'appliquent.
Jusqu'au 2026-09-08, chaque « Sauvegarder » en détruisait **quarante lignes**. Les quatre écrivains
passent désormais par une fusion ligne à ligne : un aller-retour sans modification laisse le
fichier **identique à l'octet**.

**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.

---

### La vue **Assistants** — l'ordre des gestes, pas seulement les gestes

Les huit autres vues éditent le **plan**. Celle-ci conduit des **gestes**, et elle répond à un
trou précis : le `Makefile` porte **132 cibles documentées** qui disent chacune *ce qu'elle
fait*, et **aucune ne dit dans quel ordre**. Un exploitant devant un site neuf n'avait aucun
moyen d'apprendre, depuis la console, que `site-creer` précède `forge-amorcer`, que le premier
passage **s'arrête** sur une forge vide, ni que rien n'est « prêt » avant `valider`. Cette
connaissance vivait en prose dans les documents ; la console offrait des boutons sans séquence.

**Dix-sept assistants, 126 étapes, et la totalité des 132 cibles.** Chaque cible documentée est
soit portée par un assistant, soit **exemptée avec son motif** — et `P83` refuse qu'une cible
échappe aux deux. Sans cette garde, la console cacherait un pouvoir que le moteur possède.

**Le registre ne recopie pas le Makefile.** `docs/runbooks-construction.yml` déclare seulement
ce que le Makefile ne peut pas porter : l'**ordre**, la **nature** du geste, la **portée** et le
**pourquoi**. Le libellé de chaque étape est *lu dans le Makefile au moment de servir*. Une
cible renommée se voit donc immédiatement, elle ne s'invente pas — c'est la règle « une liste
qui suit une autre prend du retard », et la garde est écrite **en même temps** que la liste.

**Trois natures, trois comportements** :

| Nature | Ce que la console fait |
|---|---|
| `mesure` | n'écrit rien ; **toujours offerte**, même après un échec — mesurer pour comprendre est exactement ce qu'on fait ensuite |
| `écriture` | exige que l'étape précédente **non facultative** ait réussi ; sinon on bâtit sur un terrain non vérifié |
| `destructif` | exige d'**écrire `DETRUIRE`**, en plus du `CONFIRMER=true` que la cible réclame déjà |

**Le navigateur ne nomme pas une commande, il nomme une place.** `/api/runbook-etape` ne lance
jamais « la cible que la page demande » : il lance ce que le registre déclare **à cet index-là**,
avec les seules variables déclarées. Une page compromise — ou simplement périmée — ne peut donc
pas réclamer `raser` depuis un assistant de mesure. L'index compte : « Le premier jour d'un
site » lance `site-deployer-tout` **deux fois**, et les deux places n'ont pas le même sens.

**La portée décide, et elle se dérive.** Un assistant de site exige `materialiser`, un assistant
de locataire `configurer`, un assistant de poste **les deux**. Un assistant hors de portée reste
**visible et lisible** : savoir que le geste existe, et chez qui il se fait, fait partie du
métier. Ce qui est refusé, c'est de le lancer — et le refus dit sa raison.

---

## ③ 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).
- Les assistants : `docs/runbooks-construction.yml`, lus par `scripts/runbooks.py` (P83).
  Vérifier le registre sans lancer la console : `python3 scripts/runbooks.py verifier`,
  et le lire en texte : `python3 scripts/runbooks.py lister`.
- 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)**.