# Set-OPS — moteur d'écosystèmes numériques souverains **Set-OPS est un moteur Ansible générique** qui permet à un hébergeur de **construire et exploiter un écosystème numérique souverain** — DNS interne, AC/PKI, identité (LDAP + SSO), relais courriel, bases de données, observabilité, applications — sur sa propre grappe **Proxmox**, à partir d'un **plan déclaratif**. Le dépôt est le **moteur** (générique, partageable). Chaque déploiement réel est une **instance** (le plan + l'inventaire d'un hébergeur, dans son propre dépôt). Tu crées la tienne à partir d'un **modèle prêt à déployer** (`exemples/modeles/`). ## Par où entrer — selon ce que tu viens faire On n'arrive pas avec un *sujet*, on arrive avec une **situation**. Il y en a six : | Ta situation | Ta porte | |---|---| | « Je veux **monter** mon écosystème sur ma grappe Proxmox » | [`QUICKSTART.md`](QUICKSTART.md) | | « Je **prête mon matériel** à quelqu'un qui déploiera dessus » | [`docs/preparer-un-site-hebergeur.md`](docs/preparer-un-site-hebergeur.md) | | « Je vais **implanter un tenant existant sur un site neuf** » | [`docs/implanter-un-tenant-sur-un-site.md`](docs/implanter-un-tenant-sur-un-site.md) | | « Je viens d'**hériter** d'un écosystème déjà déployé, je dois l'exploiter » | [`wiki/Reprendre-l-écosystème.md`](wiki/Reprendre-l-%C3%A9cosyst%C3%A8me.md) | | « Je dois **modifier** le moteur » | [`docs/carte-set-ops.md`](docs/carte-set-ops.md) | | « J'**apprends** le métier » | [`wiki/Home.md`](wiki/Home.md) | Et si tu veux d'abord savoir *ce que c'est* : continue simplement ci-dessous. > Le wiki (`wiki/`) est **publié depuis ce dépôt** vers la forge. Une page modifiée dans > l'interface de la forge est détruite à la publication suivante : on lit là-bas, on écrit ici. **Souveraineté jusqu'au bout : Set-OPS s'exploite entièrement à la main** — la doc, `make` et le GUI suffisent, **sans aucune IA**. L'outil libère de la dépendance aux géants ; il ne la remplace pas par une dépendance à une IA. --- ## Mission (la vision derrière l'outil) `Set-OPS` ne se limite plus à l'exploitation : il **définit et construit un écosystème numérique souverain** — une infrastructure interne auto-suffisante, sans dépendance SaaS, décrite en code et pilotée par des registres machine-lisibles qui font office de **source unique de vérité** (`instance/plan/serveurs.yml`, `instance/plan/applications.yml`, `instance/plan/bases-donnees.yml`, `instance/plan/domaines.yml`, `instance/plan/nomenclature.yml`, `docs/dependances-groupes.yml`). Piliers de l'écosystème : - **identité** — machines (PKI / certificats) et utilisateurs (annuaire + SSO) ; - **confiance** — autorité de certification interne (ACME) ; - **nommage et adressage** — DNS interne et nomenclature dérivable ; - **données** — bases relationnelles et cache, avec registre des connexions ; - **communication** — service de courriel souverain (boîtes LDAP, SMTP, IMAP, antispam, DKIM), et le relais des notifications système ; - **observabilité et supervision** — métriques, journaux, tableaux de bord, supervision active ; - **applicatif** — services internes (forge, etc.) et couche web. L'état voulu est **déclaratif et convergent** (appliqué par les groupes Ansible), **souverain** par conception, mais **piloté par l'opérateur** (pas d'auto-remédiation : la boucle n'est pas fermée). Ce n'est pas resté sur le papier : la flotte a été **rasée et remontée depuis zéro** le 2026-08-13, puis deux fois le 2026-09-02, sans échec. Le degré de maturité service par service est dans `docs/catalogue-services.md`. Le template Debian 13 reste la fondation, pas la finalité. Cadre et règles d'autorité : voir `AGENTS.md` (section « Mission et identité »). ## Le plan : on édite, l'inventaire se génère `Set-OPS` se pilote par un **plan**, pas par l'édition directe de l'inventaire. `instance/inventories//hosts.yml` est **généré** depuis le plan — **ne pas l'éditer à la main**. ``` éditer le PLAN → make instancier (revoir le diff) → make instancier-appliquer → make deployer ``` - **Plan** : `instance/plan/serveurs.yml` (les VM), `instance/plan/applications.yml` (les services et leurs liens), `instance/plan/bases-donnees.yml`, `instance/plan/domaines.yml`, dérivés via `instance/plan/nomenclature.yml`. - **GUI** (`make inventaire-ui`) : vues **Serveurs** et **Applications** pour éditer, puis « Appliquer le plan » ; la vue **Inventaire** est en lecture seule. - VMID / IP / VLAN sont **dérivés** de la `fonction` ; les groupes d'une VM sont dérivés des applications qui y tournent. Guide complet : **`docs/plan-et-generation.md`**. ## Portée transverse Au-delà des piliers ci-dessus, le dépôt couvre des préoccupations transverses, communes à toutes les VM : - templates de VM Proxmox (la fondation) ; - groupes de conformité et durcissement ; - maintenance ; - sauvegardes. ## Premier chantier Template Debian 13 Proxmox : ```text playbooks/modeles_vm/debian13_proxmox_preparer.yml playbooks/modeles_vm/debian13_proxmox_verifier.yml playbooks/modeles_vm/debian13_proxmox_nettoyer.yml ``` ## Principe Le template contient seulement le socle commun. Les services spécialisés sont installés ensuite sur les clones, par les playbooks de groupes : edge nginx, PostgreSQL et Redis, identité (OpenLDAP, Keycloak), courriel (Postfix, Dovecot, rspamd), observabilité (Prometheus, Loki, Grafana), supervision (Icinga), forge (Forgejo), collaboration (Nextcloud, Collabora), plateforme web. La liste qui fait foi est [`docs/catalogue-services.md`](docs/catalogue-services.md). > **Ni MariaDB, ni Docker, ni Podman.** Cette section les a listés jusqu'au 2026-09-06, > par recopie de la liste de ce que le *template* ne doit pas contenir. Le dépôt n'a pas de > rôle MariaDB, et **plus aucun rôle n'a besoin de Docker** depuis la réécriture native de > `serveur_collabora` — qui en était la dernière exception. Le conteneur n'est pas un > détail d'implémentation ici : c'est un choix fondateur (voir `roles/serveur_collabora/README.md`). ## Exploitation courante Un `Makefile` fournit les commandes d'exploitation principales. Afficher l'aide : ```bash make ``` Valider le dépôt : ```bash make verifier ``` Produire une **preuve de conformité** horodatée (rejoue les preuves du registre des affirmations → `docs/audit/preuve-.md` ; mode d'emploi : `docs/audit/README.md`) : ```bash make prouver ``` Inspecter les inventaires : ```bash make inventaire make hote-afficher HOTE=web-frontal-01 ``` Ouvrir l'interface locale de gestion d'inventaire : ```bash make inventaire-ui ``` Planifier une VM passe désormais par le **plan**, pas par l'édition de l'inventaire : 1. déclarer la VM dans `instance/plan/serveurs.yml` (vue **Serveurs** du GUI, ou `make serveurs`) — `fonction`, `etat`, placement ; VMID/IP/VLAN sont dérivés ; 2. déclarer les services qui y tournent dans `instance/plan/applications.yml` (vue **Applications**) ; 3. régénérer l'inventaire : ```bash make instancier # génère + diff sémantique (que va-t-il changer ?) make instancier-appliquer # régénère instance/inventories//hosts.yml ``` Les anciennes commandes `make hote-planifier` / `hote-ajouter` / `hote-groupes` éditaient l'inventaire **directement** ; elles sont **supplantées** par le plan (l'inventaire est généré, ne pas l'éditer à la main). Chaque groupe opérationnel doit avoir son playbook homonyme dans `playbooks/groupes/`. La conformité normale des VM passe par ces playbooks de groupes. Les rôles de socle et de durcissement sont appliqués par `serveur_debian` et `serveur_durci`, pas par des playbooks de couches séparés. Les groupes opérationnels avec des hôtes, comme `serveur_keycloak` ou `client_pki`, sont validés contre `playbooks/groupes/` par les commandes d'inventaire. Le catalogue des services et intégrations prévus est dans `docs/catalogue-services.md`. Les dépendances causales entre groupes sont dans `docs/dependances-groupes.yml`. Le runbook du DNS interne initial est dans `docs/dns-interne.md`. La nomenclature des noms de VM et des VMID est dans `docs/nomenclature-vm.md`. Créer un clone depuis le modèle Debian 13 via l'API Proxmox : ```bash make config make creer-vm HOTE=web-frontal-01 # VMID/IP/VLAN/passerelle lus dans le plan make deployer HOTE=web-frontal-01 ``` L'hôte doit d'abord être déclaré dans `instance/plan/serveurs.yml` et l'inventaire régénéré (`make instancier-appliquer`) : `creer-vm` ne prend que `HOTE`, le reste est dérivé. Les valeurs Cloud-Init communes déjà présentes dans le modèle Proxmox sont héritées par les clones. Préparer le golden template Debian 13 Proxmox : ```bash make preparer-modele make verifier-modele ``` Le nettoyage final du template est protégé : ```bash make nettoyer-modele CONFIRMER=true ``` Déployer ou remettre en conformité une VM Debian clonée depuis le template : ```bash make deployer HOTE=web-frontal-01 ``` Déployer ou remettre en conformité un groupe : ```bash make deployer-groupe GROUPE=serveur_debian ``` Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement. ## Licence Copyright (C) 2026 Daniel Allaire — Chezlepro / Alliance Boréale. Set-OPS est un logiciel **libre** : vous pouvez le redistribuer et/ou le modifier selon les termes de la **GNU Affero General Public License** telle que publiée par la Free Software Foundation, soit la version 3, soit (à votre choix) toute version ultérieure. Set-OPS est distribué dans l'espoir qu'il sera utile, mais **SANS AUCUNE GARANTIE** ; sans même la garantie implicite de QUALITÉ MARCHANDE ou d'ADÉQUATION À UN USAGE PARTICULIER. Voir la GNU Affero General Public License pour plus de détails. Le texte intégral fait foi dans le fichier [`LICENSE`](LICENSE) et sur . ### Pourquoi l'AGPLv3 Libre **et** copyleft fort. Chacun peut utiliser, exécuter, étudier et modifier Set-OPS — **y compris commercialement**. En contrepartie, quiconque l'**offre comme service en réseau** doit mettre à disposition ses modifications sous la même licence. Cela protège la **souveraineté** (pas de captation propriétaire) **sans jamais interdire l'usage commercial** — cohérent avec le principe fondateur : *tout est libre*. ### Modèle : libre + services Set-OPS est **entièrement libre** ; aucune fonctionnalité n'est réservée ni verrouillée. Les revenus, le cas échéant, proviennent de **services autour** du logiciel, jamais de sa fermeture : - support / SLA, **hébergement géré**, formation, intégration, développement sur mesure ; - **certification** d'écosystèmes (label *Souverain / Résilient / Exemplaire*). Les artisans et coopératives peuvent exploiter Set-OPS pour **leur propre infrastructure sans redevance** : l'usage interne ne déclenche aucune obligation de partage. Le copyleft AGPL ne vise que la captation propriétaire (offrir Set-OPS en service fermé sans en partager les évolutions).