Set-OPS-Public/docs/intrants-base-gui-conception.md
Daniel Allaire ac85278366 preuve : P34 — chaque document declare son lecteur (D-74)
La refonte de ce matin posait une convention. Une convention qu'on n'outille
pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique
au corpus documentaire.

Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32
autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus
utile du depot au §6 de autorisation.md.

Les 38 le declarent desormais, lecteur determine document par document et non
colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie,
gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur
externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE).

Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la
premiere page ajoutee : un document qui s'annonce genere, et un fragment sans
titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main
n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche
frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation
dans leur corps — d'etre exemptes a tort.

Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en
nommant deux documents que mon inventaire avait manques (docs/audit/). Puis
test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la
nommant ; restauree -> OK.

Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en
revue ; elle garantit qu'on a du y penser.

P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md
annoncaient encore 30 preuves).

Verifie : prouver.py 0 (34 OK), plan-recette inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 07:53:04 -04:00

5.2 KiB

Note de conception — panneau « Intrants de base » du GUI

Pour qui : le mainteneur du GUI.

But : saisir depuis un endroit unique les intrants communs de l'écosystème, en distinguant constantes et défauts surchargeables.

Extension assumée du plan de contrôle (gelé — cf. positionnement.md), au même titre que le dimensionnement. Décidée le 2026-06-26.

1. Décisions cadre (validées)

  1. Secrets : hors périmètre. Le GUI n'affiche ni ne stocke aucun secret. Les vault_* et tokens Proxmox restent édités via Ansible Vault en ligne de commande. Le panneau peut, au plus, afficher une liste de rappel en lecture seule des secrets attendus (sans valeur).
  2. Nomenclature : lecture seule dans le panneau. L'édition de supernet/VLAN/ catégories reste dans plan/nomenclature.yml (autorité unique du plan réseau).
  3. Conception avant code (cette note).

2. Modèle : constante vs défaut surchargeable

  • Constante — une seule valeur, pas de surcharge. Éditée uniquement au panneau ; apparaît en lecture seule dans les formulaires d'hôte (contexte).
  • Défaut surchargeable — valeur globale qui ressurgit comme défaut là où l'intrant réapparaît (hôte / groupe). Le formulaire d'hôte la montre pré-remplie et marquée « hérité » ; toute saisie locale devient une surcharge (badge « surchargé » + bouton « rétablir le défaut »).

Classification de départ : voir intrants-communs.md §2. Résumé : Constantes = domaine_interne, nomenclature, accès Proxmox, golden template, secrets. Défauts = timezone, nœud/stockage/pont Proxmox, DNS internes, politiques de durcissement, relais SMTP, ciuser/compte ansible.

3. Persistance — fichiers cibles, sans perte de commentaires

Contrainte : pas de dépendance non-stdlib (souveraineté) → pas de round-trip YAML préservant les commentaires (ruamel). Solution : fichiers possédés par le GUI, réécrits en bloc avec un en-tête généré (comme hosts.genere.yml), à côté des fichiers tenus à la main.

Domaine Fichier possédé par le GUI Tenu à la main (coexiste)
Identité + politiques (défauts) group_vars/all/10-intrants.yml group_vars/all/00-instance.yml
Proxmox (constantes + défauts) group_vars/proxmox/10-intrants.yml group_vars/proxmox/00-base.yml
Template/durcissement (défauts) group_vars/modeles_vm/10-intrants.yml group_vars/modeles_vm/00-base.yml

Migration légère : convertir group_vars/all.yml → répertoire group_vars/all/ (Ansible le supporte nativement). Idem proxmox.yml, modeles_vm.yml. Les valeurs existantes sont scindées : commentaires/contexte dans 00-*, valeurs pilotées par le GUI dans 10-intrants.yml. La précédence Ansible reste identique.

Les surcharges par hôte continuent de vivre dans plan/serveurs.yml (déjà supporté) ; par groupe, dans le group_vars/<groupe>/ correspondant.

4. Mécanique d'héritage (côté générateur)

  • Le panneau écrit les défauts dans les 10-intrants.yml.
  • instancier.py / les formulaires lisent ces défauts pour pré-remplir et marquer « hérité » ; une valeur présente dans serveurs.yml (hôte) prime et s'affiche « surchargé » (même logique setdefault que le dimensionnement).
  • Les constantes ne sont jamais réémises par hôte : un seul point de vérité.

5. Écran (UI)

  • Bouton « Intrants de base » dans l'en-tête du GUI → panneau modal/plein écran.
  • Sections repliables par domaine : Identité, Proxmox, Politiques de durcissement, Services centraux, Nomenclature (lecture seule), Secrets attendus (lecture seule).
  • Chaque champ porte un badge Constante / Défaut, et l'info-bulle d'aide (réutilise le mécanisme AIDES déjà en place).
  • Bandeau d'avertissement sur domaine_interne (changement à fort impact : re-dérive zones, FQDN, base DN…) → confirmation explicite.

6. Garde-fous

  • --syntax-check + ansible-inventory --list doivent rester verts après écriture.
  • Discipline diff-vide : make instancier montre l'impact, application via FORCE si intentionnel.
  • Aucune valeur secrète n'entre dans un fichier écrit par le GUI (vérifié par un test).

7. Périmètre proposé (MVP → suite)

  • MVP : domaine_interne (constante, avec garde-fou), fuseau_horaire (défaut), accès Proxmox (constantes), golden template (constantes), placement Proxmox par défaut (nœud/stockage/pont), + nomenclature et secrets en lecture seule.
  • Suite : politiques de durcissement (défauts par groupe), DNS internes, relais SMTP, endpoints services centraux.

8. Points ouverts à confirmer

  • OK pour la migration group_vars/*.yml → répertoires (§3) ? (alternative : réécrire les fichiers existants en bloc, au prix des commentaires).
  • Le panneau affiche-t-il la liste de rappel des secrets attendus (lecture seule), ou on n'en parle pas du tout dans le GUI ?
  • Périmètre MVP (§7) suffisant pour une première itération ?