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

# 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. Établi le 2026-07-02, **revu le 2026-09-06** : la
> frontière ⭐/🔧 avait cessé de dire vrai — deux reconstructions depuis zéro (2026-08-13,
> puis 2026-09-02) ont fait passer côté ⭐ presque tout ce que le §5 annonçait « à
> éprouver ». Fondé sur l'état réel du dépôt (≈65 rôles, ≈60 playbooks, le moteur de plan,
> la GUI). **Le détail rôle par rôle vit dans [`catalogue-services.md`](catalogue-services.md)** ;
> ici on ne garde que le bilan.
>
> 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 **et** la couche des services applicatifs (SSO, données, forge,
observabilité, supervision, collaboration) sont **prouvés de bout en bout** : la flotte a
été rasée puis remontée d'un seul trait, deux fois, sans échec.

---

## 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** — le seul champ saisi est l'**`index`** ; supernet, VLAN, IP,
  passerelle et **VMID** en dérivent, sans collision possible entre instances. Le VMID est le
  **miroir de l'adresse** sur neuf chiffres — `<VLAN><octet d'hôte><rang>`, soit `117602101`
  pour `1176` · `021` · `01` : on retrouve la VM depuis son adresse, et l'inverse, sans
  registre. **P20** interdit d'écrire un adressage au plan. ⭐
- **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, **jamais en clair** dans la
  GUI, qui n'en montre que les *noms*. **Une voûte, une clé** (2026-08-28) : chaque dépôt a la
  sienne, et le `Makefile` les rassemble tout seul (`scripts/voutes.py`), sans rien exporter
  ni rendre l'exécution interactive. ⭐
- **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** — les **dix** rôles que compose le groupe `serveur_durci` :
  `hardening_packages`, `sysctl_hardening`, `core_dumps`, `unattended_upgrades`, `apparmor`,
  `auditd`, `fail2ban_ssh`, `journald`, `ssh_hardening`,
  `nftables_baseline` (**éteint dans le rôle, armé par le plan** : `hotes_actifs` le met à
  `true`, le gabarit doré le laisse à `false` — le pare-feu n'est pas une propriété du rôle,
  c'est une décision de l'instance). Le jeu de règles n'est pas écrit à la main : il est
  **dérivé du registre des flux** (`meta/flux.yml` → `scripts/resoudre_flux.py`).
- **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 applicatifs — prouvés depuis ⭐

Ce paragraphe annonçait, jusqu'au 2026-09-06, des rôles « construits mais à éprouver ».
Ils l'ont été : **la reconstruction depuis zéro les a tous repris sur machine nue**
(2026-08-13, puis 15/15 et 14/14 hôtes le 2026-09-02, `make valider` à 0 échec).

- **SSO web** : `serveur_keycloak` — OpenLDAP source de vérité, fédération LDAP automatisée,
  courriel en bind LDAP direct. ⭐
- **Passerelle SSO** : `serveur_oauth2_proxy` — met au SSO une application sans OIDC natif
  (éprouvé devant Icinga Web 2). ⭐
- **Données** : `serveur_postgresql`, `serveur_redis` — bases et comptes dérivés du registre,
  TLS `verify-full` de bout en bout. ⭐
- **Forge logicielle** : `serveur_forgejo` — Git + PostgreSQL + SSO OIDC. ⭐
- **Observabilité** : `serveur_prometheus`, `serveur_grafana`, `serveur_loki`, avec les clients
  `client_metrique` et `client_journal`. ⭐
- **Supervision** : `serveur_icinga`, `serveur_icingaweb2` — Icinga 2 + IcingaDB + Web 2 + BPM.
  **Sans agent sur les hôtes** : contrôles actifs depuis le cœur, résultats passifs poussés par
  l'API. ⭐
- **Sauvegardes** : `serveur_backup`, `client_backup` — restic hors-nœud, chaque nœud vérifiant
  son **propre dépôt distant**, restauration éprouvée. ⭐
- **Plateforme webapp** : `serveur_web_frontal`, `serveur_web_dorsal` — statique et natif
  (venv + systemd + nginx), zéro conteneur. ⭐
- **Intégrations transverses** : `client_pki`, `client_backup`, `client_smtp`, `client_metrique`,
  `client_journal`, `client_resolveur`, `client_artefacts`. ⭐

Reste **🔧 outillé** — déployé, mais dont l'*usage* n'est pas consigné comme preuve :

- **Collaboration** : `serveur_nextcloud`, `serveur_collabora` (natif, plus de conteneur). Base
  et client OIDC dérivés du plan, posés par la reconstruction ; le dépôt d'un fichier et
  l'édition partagée à deux, eux, n'ont pas été consignés. 🔧

> Deux noms ont été retirés de ce paragraphe parce qu'ils n'ont jamais existé :
> `client_supervision` (la supervision est sans agent — cf. `catalogue-services.md`) et les
> « méta-rôles d'agrégation » `identity` / `storage`. La conformité passe par
> `playbooks/groupes/`, un playbook par groupe ; les répertoires `playbooks/applications/`,
> `database/`, `web/`, `monitoring/`, `backup/` ne contiennent qu'un README d'espace réservé.

## 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).
- **Machine d'épreuve jetable** (`make cloner-vm`) — l'**instrument** de la méthode ci-dessus :
  une Debian issue du gabarit doré, sur le réseau choisi, en deux minutes, **hors du plan**. Le
  moteur ne la connaît pas — donc aucune politique, aucun certificat, aucune sauvegarde, et
  `make raser` ne la détruira jamais. À détruire à la main. Voir `vm-lifecycle.md` §4bis.

---

## Prochaines frontières

- **Consigner l'usage** de la collaboration (dépôt de fichier, édition partagée) — le seul
  🔧 qui reste.
- **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.
- **Les équipements de l'hébergeur** — hyperviseurs, commutateurs, frontière : ni inventaire,
  ni sauvegarde de configuration, ni supervision. Les *VM* du site en ont depuis le 2026-09-02,
  les *équipements* non (cf. `hebergeur-exploitation.md`).
- **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.