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

7 KiB

Raw Blame History

Les pouvoirs de Set-OPS

Pour qui : qui évalue le moteur — ce qu'il sait faire, et ce qu'il ne sait pas encore.

Bilan des capacités du moteur, au 2026-07-02. Fondé sur l'état réel du dépôt (≈50 rôles, ≈30 playbooks de groupe, le moteur de plan, la GUI).

Deux niveaux de maturité sont distingués honnêtement :

⭐ Prouvé — déployé et vérifié de bout en bout sur cluster Proxmox réel.

🔧 Outillé — le rôle existe et est câblable par le plan, mais n'a pas (encore) été éprouvé en déploiement réel. À valider avant de le déclarer « prouvé » (cf. la méthode « éprouver l'outil avant le rôle »).

En une phrase

Set-OPS est un moteur souverain qui transforme un plan déclaratif en écosystème numérique complet — PKI, identité, DNS, web, courriel — cloné depuis un golden template durci, piloté par une GUI utilisable sans IA, en multi-tenant, tout en logiciel libre.

Le cœur d'infrastructure est prouvé de bout en bout ; la couche des services applicatifs (SSO, données, forge, observabilité) est outillée et prête à éprouver.

1. Le moteur — transformer une intention en écosystème

Pouvoir central : plan déclaratif → écosystème vivant. On décrit quoi (des fichiers plan/*.yml), Set-OPS fait comment.

scripts/instancier.py — lit nomenclature / serveurs / applications / bases-donnees.yml et dérive tout : VMID, IP, groupes d'inventaire, dimensionnement. ⭐
Nomenclature fédérée — un index + catégorie + service produit un VMID {index}{cat}{svc}{seq} et une IP déterministes, sans collision entre instances. ⭐
Dimensionnement automatique — chaque rôle porte une meta/empreinte.yml (cœurs / RAM / disque) ; l'outil somme les empreintes et taille la VM hôte. ⭐
Multi-instance = multi-tenant — le symlink instance/ pointe vers un dépôt par écosystème, avec voûte et identité propres. Lab et prod ne sont qu'un cas particulier. ⭐
Cycle de vie complet (cibles make) : preparer-modele → instancier → creer-vm → deployer → verifier. ⭐

2. Le plan de contrôle — exploitable sans IA

Impératif fondateur : un sysadmin exploite l'outil sans IA ; l'IA n'assiste que le mainteneur.

GUI souveraine (scripts/inventory_gui.py, stdlib pure, aucune dépendance) : visualise le plan, bouton « Pousser » (crée la VM pour un serveur / déploie pour une app ou une base), sonde de vivacité, passage auto en « actif », jeton d'authentification. ⭐
Voûte au déploiement — secrets chiffrés par Ansible Vault, saisis au déploiement, jamais en clair dans la GUI ; usage via le fichier de mot de passe, non interactif. ⭐
Validation intégrée — syntax-check, ansible-lint (profil production), verifier. ⭐

3. Le socle — un golden template durci

⭐ Prouvé : clone + application du socle de bout en bout sur le cluster Proxmox.

Base : common_packages, chrony, qemu_guest_agent, cloud_init, motd, hosts_statiques (plancher de résolution, indépendant du DNS), sudo_ansible, template_cleanup.
SSH : ssh_baseline puis ssh_hardening (bascule mot de passe → clé, seulement après validation de l'accès par clé).
Durcissement : apparmor, auditd, fail2ban_ssh, sysctl_hardening, hardening_packages, unattended_upgrades, journald, core_dumps, nftables_baseline (installé et préparé, non activé par défaut).
Proxmox : clonage depuis le golden template + redimensionnement disque (grow-only).

Séparation nette : Proxmox + cloud-init donnent l'identité initiale de la VM ; Set-OPS + Ansible font la configuration réelle du serveur.

4. Les piliers d'infrastructure — tous prouvés ⭐

Domaine	Rôle(s)	Preuve
PKI	`serveur_step_ca` + `client_pki`	AC interne + mTLS avec SAN, empreinte racine câblée
Identité	`serveur_openldap`	LDAPS réel sur certificat step_ca
DNS interne	`serveur_powerdns`	résolution interne
Reverse-proxy	`serveur_nginx`	frontal web
Courriel (Étape A)	`serveur_dovecot` + `serveur_postfix` + `serveur_rspamd`	flux complet : SMTP → validation LDAP → LMTP → boîte → lecture IMAP + antispam + signature DKIM

La messagerie interne est un service souverain complet : réception SMTP, validation des boîtes par annuaire LDAP, remise LMTP réseau chiffrée step_ca vers le stockage, accès IMAP authentifié LDAP, filtrage antispam et signature DKIM en milter. Topologie MTA dédié en périphérie / boîtes à l'intérieur (défense en profondeur).

5. Les services outillés — rôles présents 🔧

Construits et câblables par le plan ; à éprouver en déploiement réel avant de les déclarer prouvés.

SSO web : serveur_keycloak (architecture décidée : OpenLDAP source de vérité, Keycloak fédéré en OIDC, courriel en bind LDAP direct).
Données : serveur_postgresql, serveur_redis.
Forge logicielle : serveur_forgejo.
Observabilité : serveur_prometheus, serveur_grafana, serveur_loki, serveur_icinga, avec les clients client_metrique, client_journal, client_supervision.
Intégrations transverses : client_pki, client_backup, client_smtp, client_metrique, client_journal, client_unbound.
Méta-rôles d'agrégation : identity, applications, database, web, monitoring, backup, storage.

6. Les patrons d'ingénierie — la valeur invisible ⭐

Pont de certificat step_ca → service, avec resynchronisation au renouvellement (unité systemd .path). Réutilisé par openldap, dovecot, postfix.
Ordonnancement socle-first — le plancher /etc/hosts est posé avant les clients qui en dépendent (ex. client_pki sur un nœud neuf).
Sûreté en check-mode — when: not ansible_check_mode sur les tâches de service, pour un dry-run fiable même quand le service n'est pas encore installé.
Idempotence — changed=0 au redéploiement (prouvé).
Méthode « éprouver l'outil avant le rôle » — inspecter empiriquement le vrai binaire avant d'écrire le rôle qui l'enveloppe. A évité les bugs de premier déploiement (rspamd : zéro bug ; pivot Stalwart → Postfix/Dovecot/rspamd décidé sur preuve).

Prochaines frontières

Éprouver les services outillés (Keycloak fédéré, observabilité, PostgreSQL, Forgejo).
Courriel Étape B (public) : DNS public (MX, SPF, DKIM — clé setops._domainkey déjà générée, DMARC), MX externe et réputation, PTR / FCrDNS.
Seuils d'adoption d'outils tiers (NetBox, AWX) plutôt que de réimplémenter le plan de contrôle maison, qui reste volontairement gelé.

Principe fondateur : tout est libre. L'univers numérique (Alliance Boréale / Chezlepro / Set-OPS) se construit exclusivement avec du logiciel libre.

7 KiB Raw Blame History