Set-OPS-Public/docs/pouvoirs-set-ops.md

# 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_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.