CHAMPS_ECRITS_A_LA_MAIN est vide. Serveurs et applications, les deux plus gros, sont passes au generateur — chargement, rendu et sauvegarde. L EPREUVE QUI COMPTE. Ouvrir chaque vue et enregistrer sans rien toucher doit renvoyer exactement le plan qu on vient de lire : 14 serveurs, 25 applications, 2 domaines, 4 bases, IDENTIQUE partout. C est ce qui separe un formulaire genere d un formulaire qui en a l air — un champ visible a l ecran et perdu en silence a l enregistrement serait le pire des deux mondes. test_rendu_gui.py le mesure a chaque make prouver. TROIS DEFAUTS TROUVES EN CHEMIN. Le formulaire annoncait des defauts INVENTES : 2048 Mo, 2 coeurs, 16G. Il n existe aucun defaut fixe — deriver_ressources calcule depuis les roles portes (1024 et 1 pour infra-pki-01, 5632 et 4 pour collab-01). Un repere faux fait croire qu on connait la valeur. Le schema nomme le champ derive, et l ecran montre la valeur reelle de cet hote. L option vide d un select dit desormais ce qu elle produira : « (defaut : asgard) ». Une SECONDE occurrence du defaut d hier dormait dans sourceDeValeurs : elle lisait encore data.nomenclature. Elle n avait jamais leve parce que la vue Serveurs, seule a emprunter cette source, avait un formulaire ecrit a la main. Elle a leve a la seconde ou le generateur l a prise. Le banc ne voit que les chemins vivants : verifier_gui.py fait donc aussi une verification STATIQUE, qui voit ce qui dort. La validation client s accrochait a data-v, pose a la main sur trois champs. Le formulaire genere l aurait perdu et la validation serait passee au vert sur ZERO champ. Le generateur marque chaque controle, et la sauvegarde refuse si elle n en inspecte aucun. DEUX CHAMPS GARDENT LEUR EDITEUR, et le schema le dit (x-editeur) : la matrice des integrations montre les universelles et les exemptions, et l editeur de liens contraint le role a meta/liens.yml. Le generateur s efface plutot que de remplacer un editeur qui en sait plus que lui. LIMITE : je n ai toujours pas ouvert ces pages dans un navigateur. make prouver : CONFORME, 61 OK, 0 echec, 1 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
9.4 KiB
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.
③ 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). - Le flux plan → apply : unité Infra as Code & idempotence.
- La flotte : unité Multi-instance & fédération.