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 ; 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.