Daniel Allaire a8bea83a91 docs: carte d'orientation (index + mécanismes) + rafraîchir la maturité

Après audit du dépôt : docs/carte-set-ops.md = point d'entrée « à lire
d'abord » (index du corpus) + catalogue des mécanismes transverses (2
directions de binding, pont de cert, résolution BD par registre,
socle-first, check-mode, voûte) avec où ils vivent. But : ne plus
re-découvrir l'existant.

Constat : la cruft était déjà inventoriée dans catalogue-services.md
(rôles-catégories inertes, échafaudages) — référencée, pas dupliquée.
catalogue-services « État d'implémentation » rafraîchi (rôles éprouvés
sur VM réelles : socle, PKI, LDAP, DNS, nginx, pile courriel).
Pointeur ajouté depuis architecture-set-ops.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-03 09:16:14 -04:00

4.9 KiB

Raw Blame History

Carte d'orientation Set-OPS

À lire en premier. Point d'entrée vers le corpus documentaire, et catalogue des mécanismes transverses — ceux qui vivent dans le code et qu'on re-découvre sinon. Créée le 2026-07-03 après un audit du dépôt. But : ne plus re-déterrer ce qui existe.

Le dépôt est déjà bien documenté (~22 docs). Le manque n'était pas la doc du modèle, mais (a) un index « par où commencer » et (b) une carte des mécanismes (dispersés dans le code + les README de rôles). Cette page comble ces deux trous.

1. À lire d'abord (dans l'ordre)

Sujet	Documents
Autorité / gouvernance	`AGENTS.md` (source d'autorité), `CLAUDE.md`, `docs/MISE-A-JOUR-CODEX-CLAUDE.md`
Le modèle (plan)	`docs/architecture-set-ops.md` (survol) → `docs/plan-et-generation.md` (à fond) → `docs/meta-classe.md` (concept)
Services, maturité, dette	`docs/catalogue-services.md` (la carte de maturité + la cruft y sont déjà)
Exploitation / VM	`docs/vm-lifecycle.md`, `docs/procedure-template-debian13-proxmox.md`, `docs/config-proxmox.md`, `docs/nomenclature-vm.md`, `docs/multi-instances.md`
Conceptions de domaine	`docs/identite-sso.md`, `docs/courriel-conception.md`, `docs/bindings-conception.md`, `docs/dns-interne.md`, `docs/dimensionnement-ressources.md`, `docs/integrations-vm.md`
Vision / positionnement	`docs/ecosysteme-chezlepro.md`, `docs/positionnement.md`, `docs/pouvoirs-set-ops.md`

2. Les mécanismes transverses (et OÙ ils vivent)

Ce que je re-découvre sinon. Consulter avant de concevoir un nouveau mécanisme.

Mécanisme	Ce que c'est	Où, dans le code	Doc
Plan → inventaire	`plan/*.yml` → `hosts.yml` généré	`scripts/instancier.py`, `scripts/inventory_rules.py`	`plan-et-generation.md`
Nomenclature dérivée	VMID / IP / VLAN / FQDN dérivés	`inventory_rules.deriver_nomenclature` + `plan/nomenclature.yml`	`nomenclature-vm.md`
Dimensionnement	RAM/CPU/disque sommés par logiciel	`roles/*/meta/empreinte.yml` → `deriver_ressources`	`dimensionnement-ressources.md`
Bindings app→app	lien côté app (`liens`) résolu en host_vars	`plan/applications.yml` `liens:` + `roles/*/meta/liens.yml` + `instancier.resoudre_liens`	`bindings-conception.md`
Bindings app→base	lien côté base (`consommateur`/`portee`) résolu dans le rôle	`plan/bases-donnees.yml` + `include_vars`/`lookup('vars', secret)` dans les rôles consommateurs	`bindings-conception.md` §5
Pont de certificat	cert step_ca → service, resync au renouvellement	script `*-cert-sync` + unité `.path`, dans chaque rôle serveur ; cert déposé par `client_pki`	—
Ordonnancement socle-first	socle/durci avant les `client_*`	`serveur_debian`/`serveur_durci` d'abord (posent `/etc/hosts` via `hosts_statiques`)	—
Sûreté check-mode	dry-run fiable	`when: not ansible_check_mode` sur les tâches de service + handlers	—
Voûte au déploiement	secret jamais en clair	`ANSIBLE_VAULT_PASSWORD_FILE` / `~/.config/setops-vault-pass` ; déréférencé par `lookup('vars', <nom>)`	—
Multi-instance	un dépôt par écosystème	symlink `instance/`	`multi-instances.md`
Exposition → edge	app expose un FQDN public servi par un edge	`plan/domaines.yml` + `expose` (applications)	`bindings-conception.md` §4

⚠️ Deux directions de binding, assumées : app→app côté app (instancier), app→base côté base (registre, résolu en rôle pour que le secret ne quitte jamais le rôle). Ne pas unifier l'un dans l'autre sans raison. Cf. bindings-conception.md.

3. Maturité & dette

Maturité des rôles, échafaudages, rôles-catégories inertes : voir docs/catalogue-services.md « État d'implémentation » (source de vérité, tenue à jour).
Dette repérée en plus (audit 2026-07-03) :
- README manquants sur les rôles récents : serveur_dovecot, serveur_postfix, serveur_rspamd, et hosts_statiques ;
- meta/liens.yml seulement sur serveur_postfix (les autres liens app→app viendront) ;
- requiert / expose : câblés côté GUI (édition + validation valider_applications) mais pas encore consommés au déploiement — expose→vhost nginx = Phase 3 des bindings ; requiert = indice de dépendance (les dépendances de groupes sont dans docs/dependances-groupes.yml, lues par la GUI).

4. Discipline (pour ne plus re-déterrer)

Avant de concevoir ou d'ajouter un mécanisme :

lire cette carte + le doc du sujet ;
arpenter le code (grep) et lire les README des rôles concernés ;
étendre / factoriser l'existant plutôt qu'ajouter un chemin parallèle.

Un seul agent IA travaille dans le dépôt à la fois (Codex ou Claude) — cf. AGENTS.md.

4.9 KiB Raw Blame History