Set-OPS-Public/README.md

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
« Je prête mon matériel à quelqu'un qui déploiera dessus »	docs/preparer-un-site-hebergeur.md
« Je vais implanter un tenant existant sur un site neuf »	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
« Je dois modifier le moteur »	docs/carte-set-ops.md
« J'apprends le métier »	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/<inventaire>/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 :

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.

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 :

make

Valider le dépôt :

make verifier

Produire une preuve de conformité horodatée (rejoue les preuves du registre des affirmations → docs/audit/preuve-<date>.md ; mode d'emploi : docs/audit/README.md) :

make prouver

Inspecter les inventaires :

make inventaire
make hote-afficher HOTE=web-frontal-01

Ouvrir l'interface locale de gestion d'inventaire :

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 :

make instancier             # génère + diff sémantique (que va-t-il changer ?)
make instancier-appliquer   # régénère instance/inventories/<inventaire>/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 :

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 :

make preparer-modele
make verifier-modele

Le nettoyage final du template est protégé :

make nettoyer-modele CONFIRMER=true

Déployer ou remettre en conformité une VM Debian clonée depuis le template :

make deployer HOTE=web-frontal-01

Déployer ou remettre en conformité un groupe :

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 et sur https://www.gnu.org/licenses/agpl-3.0.html.

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