docs: bilan des pouvoirs de Set-OPS (docs/pouvoirs-set-ops.md)

Inventaire structuré des capacités du moteur : plan déclaratif,
plan de contrôle GUI, socle durci, piliers d'infrastructure prouvés
(PKI, identité, DNS, web, courriel), services outillés, patrons
d'ingénierie. Distingue « prouvé sur cluster réel » de « outillé ».

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

CHANGELOG.md

@@ -19,6 +19,9 @@
   mis à jour. Réévaluer Stalwart ~2028.
 
 ### Ajouté
+- **`docs/pouvoirs-set-ops.md` — bilan des capacités du moteur.** Inventaire structuré
+  (moteur/plan, plan de contrôle GUI, socle durci, piliers d'infrastructure, services outillés,
+  patrons d'ingénierie), distinguant honnêtement « prouvé sur cluster réel » de « outillé ».
 - **Rôle `serveur_rspamd` (rspamd 3.x) — antispam + DKIM, en milter sur Postfix.** Installé
   sur le nœud edge-mta (avec Postfix), backend **Redis** local, worker proxy en **mode milter
   auto-scan** (`:11332`), **signature DKIM** sortante (clé générée par le rôle de façon

docs/pouvoirs-set-ops.md

@@ -0,0 +1,123 @@
+# Les pouvoirs de Set-OPS
+
+> 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_ldap`, `client_dns`, `client_smtp`.
+- **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.