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 :
- Éditer une vue du plan → Sauvegarder ;
- « Appliquer le plan » → régénère l'inventaire (VMID/IP/VLAN dérivés) ;
- Vérifier (dry-run) sur un hôte → prévisualise sans rien changer ;
- Déployer → applique les rôles (confirmation renforcée si l'instance est en PROD) ;
- 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.
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.
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.
Bases — serveur (éditable) — les moteurs SGBD et les bases applicatives « nom @ serveur », avec les bases hébergées sur chaque serveur.
Bases — fiche (éditable) — portée · consommateur · serveur, secret Vault (jamais en clair, un pointeur seulement) et le DSN dérivé (secret masqué).
Domaines (éditable) — zones DNS publique vs interne, autorité · edge · DNSSEC, expositions.
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).
Couches (dérivée) — l'ordre de déploiement en 6 couches, du socle aux agents ; celui que
make deployer-tout déroule.
Réseau (dérivée) — la flotte multi-instances : adressage dérivé du seed, bascule d'instance, devis de configuration des switches.
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
.mddu 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
- 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 ». - É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.
- 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. - Bascule d'instance. Vue Réseau, bouton « Activer » sur une autre instance. Toutes les vues suivent, sans redémarrer.
- 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.
- 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 parscripts/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.
- La flotte : unité Multi-instance & fédération.