Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

doc : rangee par lecteur, trois portes d'entree (architecture, setup, usage) et un index

Browse source 
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas
Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index).
Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis.
QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires.

Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous-
dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-10-15 01:01:34 -04:00
parent cdac6d0ea5
commit aab1bcc83a
388 changed files with 1511 additions and 1130 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
AGENTS.md
View file

@ -41,7 +41,7 @@ readlink instance # doit pointer vers le dépôt de l'instance active
find . -maxdepth 3 -type f | sort
```
Lire ensuite `AGENTS.md`, `README.md`, `CHANGELOG.md` (les entrées récentes) et `ansible.cfg`.
Lire ensuite `AGENTS.md`, `README.md`, `docs/README.md` (l'index), `docs/architecture.md`, `CHANGELOG.md` (les entrées récentes) et `ansible.cfg`. Avant de modifier le moteur : `docs/conception/mecanismes.md`.
**Arrêter et demander à l'opérateur** dans deux cas :
@ -135,7 +135,7 @@ Set-OPS se pilote par un **plan**. L'inventaire Ansible est **généré** à par
**`<inventaire>` est une place, pas un nom.** Le moteur le résout dans l'ordre défini par `ORDRE_INVENTAIRE` dans `scripts/inventory_rules.py`. Ne coder aucun nom d'inventaire en dur, ni dans le code ni dans la doc. Dans une recette `make`, utiliser `$SETOPS_INVENTAIRE`, exporté par le `Makefile`. Depuis un shell nu, la variable n'existe pas : passer le chemin réel.
Référence : `docs/plan-et-generation.md`.
Référence : `docs/conception/plan-et-generation.md`.
---
@ -161,7 +161,7 @@ make underlay-plan make placement-plan
Si l'agent ne peut pas joindre la flotte, le devis est déclaré **non exécuté** dans le rapport (section 2). Ne jamais le présumer vert.
Référence : `docs/devis-services.md`.
Référence : `docs/exploitation/devis-services.md`.
---
@ -453,7 +453,7 @@ Il ne s'active jamais dans le gabarit, mais sur un clone ou un serveur final, av
**Ses règles ne s'écrivent pas à la main.** Chaque rôle déclare ce qu'il reçoit dans `meta/flux.yml`, puis `scripts/resoudre_flux.py` dérive les règles. Le même registre alimente l'hôte, l'hyperviseur et la frontière OPNsense.
Références : `docs/flux-conception.md`, `docs/registre-flux.md`.
Références : `docs/conception/flux-conception.md`, `docs/conception/registre-flux.md`.
---
@ -502,7 +502,7 @@ Le GUI, le générateur et la modélisation sont maison et souverains. Leur **p
En cas de doute sur une fonction, **demander à l'opérateur** avant d'écrire du code.
Référence : `docs/positionnement.md`.
Référence : `docs/projet/positionnement.md`.
---
@ -534,16 +534,16 @@ Ce fichier ne contient aucun chiffre mesuré. Pour connaître l'état réel, int
| Question | Source |
|---|---|
| Quels rôles sont éprouvés en production ? | tableau de maturité de `docs/catalogue-services.md`. **Ne jamais présenter comme « en production » un rôle que ce tableau ne donne pas pour tel.** |
| Quels rôles sont éprouvés en production ? | tableau de maturité de `docs/projet/catalogue-services.md`. **Ne jamais présenter comme « en production » un rôle que ce tableau ne donne pas pour tel.** |
| Combien de preuves, et lesquelles passent ? | `make prouver` |
| Le système déployé est-il conforme au dépôt ? | les devis `make *-plan` (section 4) |
| Le plan et l'inventaire concordent-ils ? | `make instancier` |
| Quand la flotte a-t-elle été reconstruite, et avec quel résultat ? | `CHANGELOG.md` |
| Que dit la décision D-xx ? | <!-- À COMPLÉTER : chemin du registre des décisions --> |
| Que garde la preuve Pxx ? | <!-- À COMPLÉTER : chemin des preuves sous scripts/ --> |
| Comment est généré l'inventaire ? | `docs/plan-et-generation.md` |
| Quels seuils ? | `docs/positionnement.md` |
| Quels flux ? | `docs/flux-conception.md`, `docs/registre-flux.md` |
| Que dit la décision D-xx ? | `docs/projet/decisions-architecture.md` |
| Que garde la preuve Pxx ? | `scripts/prouver.py` (registre en fin de fichier), `docs/audit/affirmations.md` |
| Comment est généré l'inventaire ? | `docs/conception/plan-et-generation.md` |
| Quels seuils ? | `docs/projet/positionnement.md` |
| Quels flux ? | `docs/conception/flux-conception.md`, `docs/conception/registre-flux.md` |
---

48
CHANGELOG.md
View file

@ -1,3 +1,51 @@
## 2026-10-15 (154) — La documentation, rangée par lecteur, avec trois portes d'entrée
**95 preuves.** `make verifier` : 94 OK, 1 échec — P60, le wiki publié est en retard depuis
`cdac6d0` (14 octobre) ; `make publier` ne publie pas le wiki, il faut `make wiki-publier`.
Témoin des liens (chaque `docs/…` cité existe, chaque lien relatif d'un document mène à un
fichier) : 0 mort sur 1 078 fichiers, comme avant la refonte ; un déplacement non suivi,
essayé dans une copie, est signalé à 7 endroits.
**Le README ne garde que le rôle du projet et le démarrage rapide** (60 lignes au lieu de 231).
La justification de l'AGPLv3 et le modèle libre + services passent dans
`docs/projet/positionnement.md` §6.
**Trois portes d'entrée et un index**, dans `docs/` :
- `architecture.md` — composants, moteur / site / locataire, du plan au déploiement, ce qu'un
rôle déclare et ce que le moteur dérive, réseau, déclaré / dérivé / mesuré, sécurité ; cinq
schémas Mermaid ;
- `setup.md` — prérequis, instance, voûtes, Proxmox, gabarit, premier déploiement, pannes
connues au premier montage ;
- `usage.md` — conventions (`-plan`, `-appliquer`, `CONFIRMER`, `FORCE`), variables de `make`
et d'environnement, et les 154 cibles publiques rangées en 13 familles ;
- `README.md` — l'index : par situation, par lecteur, registres, « le dépôt en chiffres ».
**Les documents sont rangés par lecteur** (`git mv`, l'histoire suit) : `conception/` (25,
le mainteneur), `exploitation/` (10, l'exploitant), `hebergement/` (6), `projet/` (6). Les
registres YAML lus par le code restent à la racine de `docs/`. 598 chemins réécrits dans 361
fichiers (rôles, wiki, scripts, AGENTS.md) ; les liens relatifs entre documents sont recalculés.
Le CHANGELOG et les rapports de preuve datés ne sont pas réécrits : c'est l'histoire.
**Fondus puis retirés** : `QUICKSTART.md` (→ README et `setup.md`), `SOLUTION.md` (historique,
déjà supplanté), `docs/architecture-set-ops.md` (→ `architecture.md`), `docs/carte-set-ops.md`
(§1 → l'index, §2 à 4 → `conception/mecanismes.md`). `docs/modeles_vm/debian13-proxmox.md`
devient `exploitation/gabarit-debian13-justification.md`, à côté de la procédure.
**Les preuves suivent :**
- P48 lit l'index (chiffres et pointeurs) et `conception/mecanismes.md` (pointeurs) ; un
chiffre faux posé exprès est signalé.
- Les gardes qui lisent « tous les documents » ne parcouraient que le premier niveau de
`docs/` : elles passent par `_documents()`, sous-dossiers compris, hors audit. Sans cela, la
refonte leur aurait retiré quarante documents en silence.
- `preuve_runbooks` exige les quatre portes et `conception/mecanismes.md`.
- **Nouvelle garde** dans la preuve de l'outillage : chaque cible publique du `Makefile` est
citée dans `docs/usage.md`, et chaque cible citée existe. Une cible retirée et une cible
inventée, essayées, sont signalées.
Au passage : la référence morte `docs/zero-confiance.md` (`client_pki`, fichier jamais écrit)
pointe vers le champ `chiffrement` de `conception/flux-conception.md` ; AGENTS.md §14 complète
ses deux « À COMPLÉTER » (décisions, preuves).
## 2026-10-14 (153) — La doc du DNS rattrape les deux sites, avec ses schémas
**95 preuves.** `make verifier` passe (site de Chezlepro). Documentation seulement : aucun

16
Makefile
View file

@ -184,7 +184,7 @@ ansible-runtime: ## Prepare le repertoire temporaire local d'Ansible (prerequis
_instance-requise:
@if [[ ! -f "$(SETOPS_INSTANCE)/plan/serveurs.yml" ]]; then \
printf '%s\n' "Aucune instance configuree : '$(SETOPS_INSTANCE)/plan' introuvable."; \
printf '%s\n' "Demarre avec QUICKSTART.md. En bref :"; \
printf '%s\n' "Demarre avec README.md (demarrage rapide) puis docs/setup.md. En bref :"; \
printf '%s\n' " cp -r exemples/modeles/<modele> ../mon-instance && ln -s ../mon-instance instance"; \
printf '%s\n' " modeles disponibles : $$(ls exemples/modeles 2>/dev/null | grep -v '\.md' | tr '\n' ' ')"; \
exit 2; \
@ -194,7 +194,7 @@ _instance-requise:
aide: ## Affiche l'aide detaillee du moteur (au-dela de cette liste)
@printf '%s\n' 'Set-OPS — moteur d ecosystemes numeriques souverains'
@printf '%s\n' ''
@printf '%s\n' 'Nouveau ? -> QUICKSTART.md (de zero a ton ecosysteme sur Proxmox)'
@printf '%s\n' 'Nouveau ? -> README.md puis docs/setup.md (de zero a ton ecosysteme sur Proxmox)'
@printf '%s\n' 'Flux: editer le plan -> make instancier -> make instancier-appliquer -> make deployer'
@printf '%s\n' ''
@printf '%s\n' 'VM'
@ -202,7 +202,7 @@ aide: ## Affiche l'aide detaillee du moteur (au-dela de cette liste)
@printf '%s\n' ' make creer-vm HOTE=web-frontal-01'
@printf '%s\n' ' Cloner seulement, sans passer par le plan:'
@printf '%s\n' ' make cloner-vm HOTE=web-frontal-01 VMID=95301 VLAN=15 ADRESSE_IP=10.0.2.31 PASSERELLE=10.0.2.1'
@printf '%s\n' ' Configurer Proxmox et le Vault API (parametres: docs/config-proxmox.md):'
@printf '%s\n' ' Configurer Proxmox et le Vault API (parametres: docs/exploitation/config-proxmox.md):'
@printf '%s\n' ' make config'
@printf '%s\n' ''
@printf '%s\n' 'Hotes'
@ -239,10 +239,10 @@ aide: ## Affiche l'aide detaillee du moteur (au-dela de cette liste)
@printf '%s\n' ''
@printf '%s\n' 'Flux reseau (pare-feu / audit)'
@printf '%s\n' ' Matrice d audit + apercus nftables resolus (NON actives):'
@printf '%s\n' ' make flux # -> docs/registre-flux.md + instance/flux-genere/*.nft'
@printf '%s\n' ' make flux # -> docs/conception/registre-flux.md + instance/flux-genere/*.nft'
@printf '%s\n' ' make flux-verifier # valide schema + coherence de matrice'
@printf '%s\n' ''
@printf '%s\n' 'Remise au client — EN DEUX TEMPS (docs/remise-au-client.md)'
@printf '%s\n' 'Remise au client — EN DEUX TEMPS (docs/hebergement/remise-au-client.md)'
@printf '%s\n' ' Temps 1, l IDENTITE : le client gouverne ses gens des le premier jour.'
@printf '%s\n' ' make remise-recenser # ce qui partirait, sans rien ecrire'
@printf '%s\n' ' make ca-racine ; make ca-empreinte # sa racine d AC, et le temoin a comparer'
@ -415,10 +415,10 @@ inseminer: ansible-runtime ## Le SITE amorce le runner d'un tenant — TENANT=<d
printf '\n%s\n' "$$hote porte desormais le moteur, son plan et la carte de la fabric."; \
printf '%s\n' "IL N EST PAS ARME : ni voute, ni cle — le site ne les detient pas."; \
printf '%s\n' "L armer est le geste d un humain, depuis son poste :"; \
printf '%s\n' " make appliquer GROUPE=serveur_ops_tenant (voir docs/filiation-emancipation.md)"
printf '%s\n' " make appliquer GROUPE=serveur_ops_tenant (voir docs/conception/filiation-emancipation.md)"
# PROUVER QU'UN LIEN DE FILIATION EST COUPE — la quatrieme ligne de
# `docs/filiation-emancipation.md`, celle qu'on oublie : « une emancipation non prouvee
# `docs/conception/filiation-emancipation.md`, celle qu'on oublie : « une emancipation non prouvee
# est une emancipation non faite ».
#
# GESTE DESTRUCTIF ET REVERSIBLE : il COUPE l'amont pendant quelques secondes pour voir
@ -1166,7 +1166,7 @@ define VAULT_UNE_FOIS
endef
# LE SITE MATERIALISE UN LOCATAIRE NOMME, D'APRES SA FACE (2026-10-05, docs/conception-contextes.md,
# LE SITE MATERIALISE UN LOCATAIRE NOMME, D'APRES SA FACE (2026-10-05, docs/conception/conception-contextes.md,
# materialisation M2). Avec `TENANT=<depot>`, la liste des machines et leurs parametres de clonage
# viennent de `face-reseau.yml` que le locataire publie — rendus a l'octet pres comme
# `parametres-proxmox` (P93) — et aucune instance n'est montee. Sans `TENANT`, l'ancienne lecture

133
QUICKSTART.md
View file

@ -1,133 +0,0 @@
# Démarrage rapide — de zéro à ton écosystème souverain
Tu débarques avec une **grappe Proxmox vierge** et tu veux monter ton écosystème
numérique. Voici le chemin, de bout en bout. Set-OPS est le **moteur** ; tu vas
créer **ton instance** à partir d'un modèle, puis déployer.
> Concepts en 10 s : tu **décris un plan** (quelles VM, quels services), le moteur
> **génère l'inventaire**, et Ansible **déploie**. Tu n'édites jamais l'inventaire
> à la main. Détails : `docs/plan-et-generation.md`.
## 0. Prérequis (à toi de fournir)
- une **grappe Proxmox** où tu es admin (API activée) ;
- une machine de pilotage Linux avec **Ansible**, **Python 3**, **make**, `git`
(et `node` pour le garde-fou JS du GUI, optionnel) ;
- un **token API Proxmox** ;
- une **paire de clés SSH** (la publique ira dans les VM via cloud-init) ;
- un **mot de passe Ansible Vault** (pour chiffrer tes secrets).
## 1. Cloner le moteur
```bash
git clone <url-de-Set-OPS> Set-OPS && cd Set-OPS
```
## 2. Choisir un modèle et créer ton instance
Le dépôt public fournit **un modèle générique : `socle`** — quatre VM, le minimum
souverain : PKI (`step-ca`), DNS interne (PowerDNS), edge TLS (nginx) et **magasin
courriel** (Dovecot). C'est un magasin de boîtes, pas un relais : le MTA (`serveur_postfix`)
s'ajoute ensuite, comme les autres modules. Les
modèles **assemblés** par offre (`identite`, `observabilite`, `forge`, `collaboration`,
`presence-web`, `integral`) sont un actif à part, dans le dépôt privé `Set-OPS-modeles`
(cf. [`exemples/modeles/README.md`](exemples/modeles/README.md)).
```bash
cp -r exemples/modeles/socle ../mon-instance # ton instance, ailleurs
ln -s ../mon-instance instance # le moteur la trouve via ce lien
```
*(Alternative au symlink : `export SETOPS_INSTANCE=../mon-instance`.)*
## 3. Renseigner ton instance (« tes couleurs »)
> Les chemins ci-dessous disent `production/` parce que **c'est le nom que porte le modèle
> que tu viens de copier**. Ce n'est pas un nom imposé : le moteur cherche `principal`
> d'abord, `production` ensuite. Si tu lis ailleurs `<inventaire>`, c'est cette place-là.
- `instance/inventories/production/group_vars/all/10-intrants.yml` → **`domaine_interne`** (ex. `monorg.internal`) ;
- `instance/plan/nomenclature.yml` → ton **supernet** (ex. `10.20.0.0/16`) ;
- `instance/plan/domaines.yml` → ton **domaine public** ;
- `instance/plan/serveurs.yml` → **placement Proxmox** (nœud, stockage, disque, mémoire, cœurs).
Tu peux aussi le faire dans le GUI plus tard (`make inventaire-ui`).
## 4. Configurer Proxmox et tes secrets
```bash
make config # renseigne API host/user/port, nœud, stockage, VMID du template...
```
Chaque paramètre demandé est expliqué dans [`docs/config-proxmox.md`](docs/config-proxmox.md).
Tous tes secrets (token API + `vault_*`) vont dans **une voûte unique par instance** :
`instance/inventories/production/group_vars/all/vault.yml`, à partir du
gabarit [`exemples/vault.exemple.yml`](exemples/vault.exemple.yml), chiffrée avec
`ansible-vault`.
**Une voûte, une clé** (depuis le 2026-08-28). Le mot de passe de ta voûte se dépose dans un
fichier dont le nom est **dérivé du dossier de ton instance**, en minuscules :
```bash
# instance dans ../mon-instance -> clé dans ~/.config/setops-vault-mon-instance
install -m 600 /dev/null ~/.config/setops-vault-mon-instance
$EDITOR ~/.config/setops-vault-mon-instance # ta phrase de passe, une seule ligne
python3 scripts/voutes.py etat # vérifie que le moteur la trouve
```
Il n'y a **rien à exporter** : le `Makefile` construit `ANSIBLE_VAULT_IDENTITY_LIST` en
appelant `scripts/voutes.py`. Un seul `ANSIBLE_VAULT_PASSWORD_FILE` ne suffirait plus de
toute façon — créer une VM ouvre **deux** voûtes dans la même exécution : la tienne, et
celle de l'hébergeur qui détient le jeton Proxmox.
## 5. Construire le golden template Debian 13 (UNE seule fois)
Une grappe vierge n'a aucun template. Crée une VM **Debian 13 vanille**, rends-la
joignable par Ansible, puis :
```bash
make preparer-modele # socle + durcissement + cloud-init + qemu-guest-agent...
make verifier-modele
make nettoyer-modele CONFIRMER=true
```
Convertis ensuite la VM en **template Proxmox**. Son nom doit être celui que `make config`
a enregistré comme *nom logique du modèle* — **`modeleSetOPS`** par défaut
(`proxmox_clone_source_nom`). Un nom qui ne correspond pas se solde par un clonage qui ne
trouve pas sa source. Détails et procédure : `docs/vm-lifecycle.md` et
`docs/procedure-template-debian13-proxmox.md`.
## 6. Générer ton inventaire depuis le plan
```bash
make instancier # montre ce que le plan produit (diff)
make instancier-appliquer FORCE=1 # 1re génération : écrit instance/inventories/production/hosts.yml
```
Tes hôtes sont là, en état `planifie`. `make serveurs` te montre leurs VMID/IP dérivés.
## 7. Créer les VM (clone du template + cloud-init)
Pour chaque hôte — `creer-vm` lit ses VMID/IP/VLAN/passerelle directement dans
l'inventaire généré (`make serveurs` te les montre) :
```bash
make creer-vm HOTE=infra-dns-01
```
*(Les valeurs de nœud/stockage/template viennent de `make config`. La création
suit désormais le plan de bout en bout : un seul argument, `HOTE`.)*
## 8. Activer puis déployer
Passe l'hôte en `etat: actif` dans `instance/plan/serveurs.yml`, régénère, déploie :
```bash
make instancier-appliquer
make deployer HOTE=infra-dns-01 # configure l'hôte selon ses groupes
# ou, par couche :
make deployer-groupe GROUPE=serveur_powerdns
```
Les déploiements de groupe ne ciblent **que** les hôtes actifs.
## 9. Ensuite : tu vis dans le plan
Édite le plan (GUI `make inventaire-ui`, ou les registres `instance/plan/`),
`make instancier-appliquer`, `make deployer`. Tu ne touches jamais `hosts.yml`.
## Valider à tout moment
```bash
make inventaire-verifier # registres + inventaire + garde-fous
make verifier # + ansible-lint + --syntax-check
```
> Ces cibles chargent l'inventaire complet : pose d'abord la clé de ta voûte
> (étape 4), sinon Ansible s'arrête sur
> « Attempting to decrypt but no vault secrets found ».
---
Ordre de mise en place des services : `docs/catalogue-services.md`. Modèle,
registres et règle d'or : `docs/plan-et-generation.md` et `AGENTS.md`.

257
README.md
View file

@ -1,231 +1,60 @@
# 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**.
Set-OPS construit et exploite un **écosystème numérique souverain** sur une grappe
**Proxmox**, à partir d'un **plan déclaratif** : DNS, AC interne, identité (LDAP + SSO),
courriel, bases de données, observabilité, forge, applications web. Logiciel libre
exclusivement ; ni Docker, ni Podman.
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/`).
- **Moteur** (ce dépôt) : rôles Ansible, playbooks, scripts de dérivation, preuves.
- **Écosystème** : un dépôt par locataire (`OPS-<nom>`) — son plan, son inventaire
généré, sa voûte. Un dépôt par site d'hébergement (`SITE-<nom>`) — son underlay, sa
frontière.
- **Plan → inventaire → déploiement** : on édite le plan, le moteur génère l'inventaire et
l'ordre de déploiement, Ansible applique. L'inventaire ne s'édite jamais à la main.
- **Sans IA** : la doc, `make` et le GUI suffisent à l'exploiter.
## Par où entrer — selon ce que tu viens faire
## Démarrage rapide
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/<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 :
```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 :
Prérequis : une grappe Proxmox et un jeton d'API, un poste Linux avec Python 3, Ansible,
`make` et `git`, une paire de clés SSH.
```bash
make
```
git clone <url-de-Set-OPS> Set-OPS && cd Set-OPS
Valider le dépôt :
# 1. Un écosystème, depuis le modèle public, et la clé de sa voûte
make instance-creer NOM=OPS-MonOrg MODELE=socle
ln -s ../OPS-MonOrg instance
install -m 600 /dev/null ~/.config/setops-vault-ops-monorg # la phrase de passe, une ligne
# renseigner domaine_interne, nomenclature, domaines, placement : docs/setup.md §3
```bash
# 2. Proxmox et le gabarit Debian 13 (une fois par grappe)
make config
make preparer-modele && make verifier-modele && make nettoyer-modele CONFIRMER=true
# 3. Inventaire, VM, déploiement
make instancier && make instancier-appliquer FORCE=1
make creer-vm HOTE=infra-dns-01
make deployer HOTE=infra-dns-01
# 4. Vérifier
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`) :
Chaque étape, ses fichiers et ses pièges : [`docs/setup.md`](docs/setup.md).
```bash
make prouver
```
## Documentation
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/<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 :
```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.
| Document | Contenu |
|---|---|
| [`docs/README.md`](docs/README.md) | l'index : par situation, par lecteur |
| [`docs/architecture.md`](docs/architecture.md) | composants, flux de données, réseau, sécurité |
| [`docs/setup.md`](docs/setup.md) | installation et configuration |
| [`docs/usage.md`](docs/usage.md) | conventions, variables, toutes les commandes |
| [`wiki/Home.md`](wiki/Home.md) | le métier, pas à pas |
| [`AGENTS.md`](AGENTS.md) | les règles d'autorité du dépôt |
## 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
<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).
Copyright (C) 2026 Daniel Allaire — Chezlepro / Alliance Boréale. Logiciel libre sous
**GNU Affero General Public License v3** ou ultérieure : voir [`LICENSE`](LICENSE). Pourquoi
l'AGPLv3, et le modèle libre + services : [`docs/projet/positionnement.md`](docs/projet/positionnement.md) §6.

78
SOLUTION.md
View file

@ -1,78 +0,0 @@
# La solution Set-OPS
> **Document historique de décision.** Le parcours opérationnel à jour vit dans
> [`README.md`](README.md) et [`QUICKSTART.md`](QUICKSTART.md) ; l'autorité est
> [`AGENTS.md`](AGENTS.md). Les commandes brutes ci-dessous sont **supplantées** par les
> cibles `make` (`preparer-modele` / `verifier-modele` / `nettoyer-modele`). Conservé pour
> tracer la décision fondatrice.
## Décision
`Set-OPS` est le moteur Ansible global d’exploitation d’écosystèmes numériques souverains.
Le template Debian 13 Proxmox est seulement un chantier dans ce dépôt.
## Ce qu'on fait maintenant
On garde une seule structure simple :
```text
inventories/
playbooks/
roles/
docs/
```
Les rôles sont nommés clairement, sans sous-arborescence complexe.
> Réalité actuelle du dépôt : au-delà de ces quatre dossiers, le moteur comporte aussi
> `scripts/` (plan + GUI), `filter_plugins/`, `exemples/`, `wiki/` et l'instance montée
> (`instance/`). Vue d'ensemble : [`docs/carte-set-ops.md`](docs/carte-set-ops.md).
## Commande principale pour construire le template
Le template se construit avec un **accès SSH par clé dès le départ** (clé injectée par
cloud-init) — pas par mot de passe. La cible opérateur est :
```bash
make preparer-modele
```
Elle exécute `playbooks/modeles_vm/debian13_proxmox_preparer.yml` sur l'inventaire modèle,
après avoir vérifié l'accès SSH par clé et les privilèges sudo du compte `ansible`. Voir
[`AGENTS.md`](AGENTS.md) § SSH pour l'état cible (`PasswordAuthentication no`,
`AuthenticationMethods publickey`).
## Vérification
```bash
make verifier-modele
```
## Nettoyage final avant conversion
```bash
make nettoyer-modele CONFIRMER=true
```
*(Ces deux blocs appelaient `ansible-playbook -i instance/inventories/lab/hosts.yml …`
jusqu'au 2026-09-06. Cet inventaire n'existe pas : le nom est résolu par le `Makefile`,
c'est précisément pourquoi les cibles `make` supplantent les commandes brutes.)*
Ensuite :
```bash
sudo shutdown -h now
```
Puis côté Proxmox :
```bash
qm template VMID
```
## Important
Le pare-feu `nftables` est installé et préparé, mais il n'est pas activé par défaut dans le template.
C'est volontaire pour éviter de couper SSH pendant la construction.

121
docs/README.md Normal file
View file

@ -0,0 +1,121 @@
# Documentation de Set-OPS
> **Pour qui :** tout lecteur qui cherche une page. On entre par sa **situation** ou par son
> **rôle** ; chaque document dit en tête à qui il s'adresse.
## Portes d'entrée
| Document | Contenu |
|---|---|
| [`architecture.md`](architecture.md) | composants, moteur / site / locataire, plan → déploiement, réseau, sécurité (schémas) |
| [`setup.md`](setup.md) | prérequis, instance, voûtes, Proxmox, gabarit, premier déploiement |
| [`usage.md`](usage.md) | conventions, variables, toutes les commandes `make` par famille |
## Par situation
| Ta situation | Ta porte |
|---|---|
| « Je veux **monter** mon écosystème sur ma grappe Proxmox » | [`setup.md`](setup.md) |
| « Je **prête mon matériel** à quelqu'un qui déploiera dessus » | [`hebergement/preparer-un-site-hebergeur.md`](hebergement/preparer-un-site-hebergeur.md) |
| « Je vais **implanter un locataire existant sur un site neuf** » | [`hebergement/implanter-un-tenant-sur-un-site.md`](hebergement/implanter-un-tenant-sur-un-site.md) |
| « Je viens d'**hériter** d'un écosystème déployé, je dois l'exploiter » | [`../wiki/Reprendre-l-écosystème.md`](../wiki/Reprendre-l-%C3%A9cosyst%C3%A8me.md) |
| « Je fais face à une **situation d'exploitation** » | [`exploitation/runbooks-exploitation.md`](exploitation/runbooks-exploitation.md) |
| « Je dois **modifier** le moteur » | [`conception/mecanismes.md`](conception/mecanismes.md), puis `AGENTS.md` |
| « J'**apprends** le métier » | [`../wiki/Home.md`](../wiki/Home.md) |
| « J'**évalue** Set-OPS » | [`projet/pouvoirs-set-ops.md`](projet/pouvoirs-set-ops.md), [`projet/ecosysteme-chezlepro.md`](projet/ecosysteme-chezlepro.md) |
## Par lecteur
### `conception/` — le mainteneur : comment le moteur est fait
| Document | Sujet |
|---|---|
| `mecanismes.md` | les mécanismes transverses et où ils vivent ; maturité, dette, discipline |
| `plan-et-generation.md` | le plan, ses registres, la génération de l'inventaire |
| `meta-classe.md` | pourquoi on écrit *un* plan et pas *un* inventaire |
| `conception-contextes.md` | site et locataire : deux classes, un contrat |
| `multi-instances.md` | le moteur et ses écosystèmes, le seed `index` |
| `filiation-emancipation.md` | ce que le site prête au locataire, et comment il s'en détache |
| `depots-prives-conception.md` | chaque runner ne lit que ses dépôts |
| `nomenclature-vm.md` | noms de VM et VMID |
| `dimensionnement-ressources.md` | RAM, CPU, disque dérivés des empreintes |
| `intrants-communs.md` | valeurs partagées par tout l'écosystème |
| `intrants-base-gui-conception.md` | le panneau « Intrants de base » du GUI |
| `bindings-conception.md` | relations service → service et service → base |
| `integrations-vm.md` | les intégrations `client_*` posées sur toutes les VM |
| `flux-conception.md` | déclarer un flux réseau dans `meta/flux.yml` |
| `registre-flux.md` | la matrice d'audit des flux (**générée** par `make flux`) |
| `schemas-flux.md` | la liste des pages publiées et ce qu'elles montrent |
| `sdn-evpn.md` | le réseau overlay : zones EVPN, VNets |
| `frontiere-opnsense.md` | la bordure nord/sud |
| `frontiere-physique-virtuel.md` | physique et virtuel : qui possède quoi, et où ça vit |
| `dns-interne.md` | DNS interne et public, deux sites (schémas) |
| `identite-sso.md` | les deux couches de l'identité |
| `authentification.md` | la doctrine d'authentification, rôle par rôle |
| `courriel-conception.md` | le service de courriel |
| `supervision-conception.md` | les verdicts, vers Icinga |
| `metriques-conception.md` | les séries, vers Prometheus et Grafana |
### `exploitation/` — l'exploitant : faire tourner un écosystème
| Document | Sujet |
|---|---|
| `runbooks-exploitation.md` | que faire, situation par situation |
| `devis-services.md` | ce qui tourne correspond-il à ce qui est déclaré ? |
| `vm-lifecycle.md` | ce qu'une VM traverse, de la création à la destruction |
| `procedure-template-debian13-proxmox.md` | fabriquer le gabarit d'or |
| `gabarit-debian13-justification.md` | ce que le gabarit contient, et pourquoi |
| `config-proxmox.md` | raccorder le moteur à la grappe |
| `acces-administration.md` | le tunnel nominatif des administrateurs : par où, avec quelle clé |
| `autorisation.md` | habilitations ; §6 : le runbook de reprise |
| `sortir-les-cles-du-poste.md` | les clés et les voûtes hors du poste |
| `theme-forgejo-hors-flotte.md` | le thème Alliance Boréale sur une forge hors flotte |
### `hebergement/` — l'hébergeur et le locataire
| Document | Sujet |
|---|---|
| `preparer-un-site-hebergeur.md` | mettre son matériel à disposition |
| `implanter-un-tenant-sur-un-site.md` | le jour de l'intervention sur un site neuf |
| `hebergeur-exploitation.md` | les services que l'hébergeur se doit à lui-même |
| `migration-tenant.md` | déplacer un locataire d'un hébergeur à un autre |
| `remise-au-client.md` | remettre un écosystème à qui en est responsable |
| `responsabilites-locataire-hebergeur.md` | qui répond de quoi |
### `projet/` — décisions, maturité, positionnement
| Document | Sujet |
|---|---|
| `decisions-architecture.md` | les décisions en vigueur et renversées, et ce qui les garde |
| `catalogue-services.md` | ce que le moteur sait déployer, et sa maturité |
| `positionnement.md` | ce qui reste maison, ce qui s'adopte, et à quels seuils ; la licence |
| `pouvoirs-set-ops.md` | ce que le moteur sait faire, et ce qu'il ne sait pas |
| `ecosysteme-chezlepro.md` | un écosystème réel, pour le lecteur externe |
| `MISE-A-JOUR-CODEX-CLAUDE.md` | pour l'agent IA qui reprend le dépôt |
## Registres et preuves
| Fichier | Rôle |
|---|---|
| `couches-deploiement.yml` | les couches de déploiement — lu par `scripts/orchestrer.py` |
| `dependances-groupes.yml` | le graphe des dépendances entre groupes — lu par l'orchestrateur et les preuves |
| `runbooks-construction.yml` | les runbooks de construction — lu par `scripts/runbooks.py` |
| `audit/affirmations.md` | le registre des affirmations que `make prouver` rejoue |
| `audit/preuve-<date>.md` | les rapports de preuve datés |
Le wiki (`wiki/`) est publié depuis ce dépôt vers la forge (`make wiki-publier`) : on y lit,
on écrit ici. L'autorité est `AGENTS.md` ; l'histoire, `CHANGELOG.md`.
## Le dépôt en chiffres
> Ces valeurs sont **mesurées** : **P48** les recompte et refuse tout écart.
| Ce qu'on compte | Combien | Comment on le mesure |
|---|---|---|
| rôles | 70 | `roles/*/` |
| README de rôles | 70 | `roles/*/README.md` — l'écart avec la ligne au-dessus est la dette |
| documents | 51 | `docs/**/*.md`, hors `audit/` |
| pièces d'audit | 53 | `docs/audit/*` |
| unités de wiki | 27 | `wiki/*.md` |
| décisions en vigueur | 85 | lignes `\| **D-nn** \|` de `decisions-architecture.md` |
| décisions renversées | 3 | lignes `\| **D-nn** —` du même document |

71
docs/architecture-set-ops.md
View file

@ -1,71 +0,0 @@
# Architecture Set-OPS
> **Pour qui :** le **mainteneur** — le survol du modèle. À lire avant `plan-et-generation.md`.
Set-OPS définit et construit l'écosystème numérique souverain. Il se
pilote par un **plan** : l'inventaire Ansible (`instance/inventories/<inventaire>/hosts.yml`)
est **généré** depuis le plan, pas édité à la main.
- **Par où commencer + catalogue des mécanismes transverses : `docs/carte-set-ops.md`.**
- Modèle, registres, commandes et flux de travail : **`docs/plan-et-generation.md`**.
- Règles d'autorité : **`AGENTS.md`** (sections « Mission et identité » et « Le plan et la génération de l'inventaire »).
## Entités du plan
```text
serveur (VM) instance/plan/serveurs.yml fonction, état, placement, intégrations
application instance/plan/applications.yml groupe (rôle), hôte, port, requiert, expose
base instance/plan/bases-donnees.yml serveur de BD, base, propriétaire, secret (Vault), portée
domaine (DNS) instance/plan/domaines.yml zone publique, autorité, edge
nomenclature instance/plan/nomenclature.yml fonctions -> VMID / VLAN / IP (dérivés)
```
L'**application** est l'entité pivot ; le **groupe** Ansible n'est qu'une capacité
(le rôle appliqué). VMID / IP / VLAN et les appartenances de groupes sont **dérivés**.
## Rôles Ansible
Les rôles actifs sont conservés directement sous `roles/`.
Les sous-arborescences catégorielles de rôles ne doivent pas dupliquer un rôle actif. Un nouveau rôle doit être ajouté seulement lorsqu'un besoin opérationnel réel existe.
Les valeurs communes aux rôles doivent rester dans les defaults des rôles quand elles sont valables pour tous les environnements. Les inventaires ne doivent contenir que les politiques propres à leur contexte.
## Groupes et playbooks
Les groupes opérationnels de l'inventaire doivent correspondre à un playbook homonyme :
```text
instance/inventories/<inventaire>/hosts.yml
serveur_debian
playbooks/groupes/serveur_debian.yml
```
Cette relation rend l'exploitation lisible :
```text
appartenance à un groupe
→ playbook correspondant
→ état voulu appliqué par Ansible
```
Les groupes structurels ou vides peuvent exister, mais un groupe assigné à une VM de production doit avoir un playbook s'il exprime une intention de configuration.
## Cycle de vie VM
Le cycle de vie des VM est documenté dans :
```text
docs/vm-lifecycle.md
```
## Intégrations transversales
Elles ne sont plus « futures » : `client_pki`, `client_backup`, `client_metrique`,
`client_journal`, `client_smtp`, `client_resolveur` et `client_artefacts` sont déployés sur
la flotte. Elles sont documentées dans :
```text
docs/integrations-vm.md
```

180
docs/architecture.md Normal file
View file

@ -0,0 +1,180 @@
# Architecture
> **Pour qui :** quiconque doit comprendre comment Set-OPS est construit — avant de
> l'installer, de l'exploiter ou de le modifier. Le détail de chaque mécanisme est dans
> `docs/conception/` ; l'index complet dans [`README.md`](README.md).
Set-OPS est un **moteur** Ansible et Python. Il lit un **plan** déclaratif, en dérive un
inventaire et des politiques, et les applique à des VM Debian 13 clonées sur une grappe
Proxmox. Le moteur est générique ; chaque écosystème réel vit dans **son propre dépôt**.
## Composants
```mermaid
flowchart LR
subgraph POSTE["Poste de l'exploitant (ou runner)"]
MOT["Set-OPS<br/>moteur : roles/, playbooks/, scripts/"]
INST["instance/ → ../OPS-X<br/>le locataire actif"]
UND["underlay.yml → ../SITE-Y/underlay.yml<br/>le site actif"]
CLE["~/.config/setops-vault-*<br/>une clé par voûte"]
end
subgraph SITE["Site d'hébergement"]
PVE["Grappe Proxmox<br/>SDN EVPN, pare-feu est-ouest"]
OPN["Frontière OPNsense<br/>nord/sud"]
RUN["site-ops-01<br/>runner du site"]
FORGE["Forge du site<br/>le génome"]
VMS["VM des locataires<br/>et du site"]
end
MOT -- "lit" --> INST & UND
MOT -- "API Proxmox : clone, SDN, pare-feu" --> PVE
MOT -- "API OPNsense : règles, routes" --> OPN
MOT -- "SSH + Ansible" --> VMS
POSTE -- "make publier / genome-pousser" --> FORGE
RUN -- "tire" --> FORGE
RUN -- "SSH + Ansible" --> VMS
PVE --- VMS
```
| Composant | Ce que c'est | Où |
|---|---|---|
| Moteur | rôles, playbooks, scripts de dérivation, preuves | ce dépôt |
| Locataire (tenant) | un écosystème : son plan, son inventaire généré, sa voûte | dépôt `OPS-<nom>`, monté par `instance/` |
| Site | l'hébergeur : matériel, underlay, frontière, services prêtés aux locataires | dépôt `SITE-<nom>`, désigné par `underlay.yml` |
| Voûtes | secrets chiffrés `ansible-vault`, une par dépôt, une clé par voûte | `group_vars/all/vault.yml` ; clés hors dépôt |
| Runner du site | machine du site qui déploie à la place du poste | `site-ops-01`, compte `setops`, `/opt/setops` |
| Forge du site | Forgejo qui porte le génome (moteur + plans) que les runners tirent | VM du site |
## Moteur, site, locataire
```mermaid
flowchart TB
M["Set-OPS (moteur)"]
S["SITE-Y<br/>underlay.yml · plan/ · opnsense.yml"]
T1["OPS-A<br/>plan/ · inventories/"]
T2["OPS-B<br/>plan/ · inventories/"]
M -. "monte un site" .-> S
M -. "monte un locataire" .-> T1 & T2
S -- "contrat du site → fiche-site.yml" --> T1 & T2
T1 & T2 -- "face réseau publiée" --> S
```
- **Deux classes d'écosystème, un tronc commun** : `scripts/contexte.py` est le seul endroit
qui lit les indices (`instance/`, `underlay.yml`, `SETOPS_*`, dossiers frères) et rend un
`Site` ou un `Locataire`. Conception : `docs/conception/conception-contextes.md`.
- **Le site lit la face réseau des locataires, le locataire lit la fiche du site.** Le
contrat (`make site-intrants`) dérive ce que le site expose : résolveur, cache de paquets,
forge, adresses publiques, serveurs DNS publics. `make fiches-site-deposer` le dépose chez
chaque locataire (`fiche-site.yml`) ; `make site-intrants-verifier` juge l'écart.
- **Multi-instance par convention** : un dépôt par écosystème, découverts comme dossiers
frères. Tout l'adressage dérive d'un seed `index` par écosystème ; P21 refuse une
collision. Détail : `docs/conception/multi-instances.md`.
- **Le site prête trois services** à un locataire jeune — paquets (`serveur_cache_site`),
génome (`serveur_forge_site`), noms (`serveur_resolveur_site`) — jusqu'à ce qu'il ait les
siens. Filiation et émancipation : `docs/conception/filiation-emancipation.md`.
## Du plan au déploiement
```mermaid
flowchart LR
PLAN["plan/<br/>serveurs · applications · bases-donnees<br/>domaines · nomenclature"] --> INS["make instancier<br/>scripts/instancier.py<br/>inventory_rules.py"]
INS -- "diff sémantique" --> APP["make instancier-appliquer"]
APP --> HOSTS["inventories/INVENTAIRE/hosts.yml<br/>GÉNÉRÉ"]
COUCHES["docs/couches-deploiement.yml<br/>docs/dependances-groupes.yml"] --> ORCH["make site<br/>scripts/orchestrer.py"]
ORCH --> SITEYML["playbooks/site.yml<br/>GÉNÉRÉ"]
HOSTS & SITEYML --> ANS["make deployer · deployer-tout<br/>ansible-playbook"]
VAULT["vault.yml<br/>ANSIBLE_VAULT_IDENTITY_LIST"] --> ANS
ANS --> VM["VM : groupes → playbooks/groupes/GROUPE.yml → rôles"]
```
1. **On édite le plan, jamais l'inventaire.** VMID, IP, VLAN, FQDN et appartenances aux
groupes sont dérivés de la `fonction` d'une VM et des applications qui y tournent.
2. **L'inventaire est généré** et comparé à l'existant avant d'être écrit.
3. **L'ordre de déploiement est généré** depuis les couches et le graphe des dépendances
entre groupes.
4. **Un groupe = un playbook homonyme** (`playbooks/groupes/<groupe>.yml`) qui applique ses
rôles. Le socle (`serveur_debian`) et le durcissement (`serveur_durci`) passent en premier.
Les registres du plan :
| Registre | Entité | Champs clés |
|---|---|---|
| `plan/serveurs.yml` | VM | `fonction`, `etat` (`planifie` → `actif`), placement |
| `plan/applications.yml` | service (entité pivot) | `groupe` (rôle), `hote`, `port`, `liens`, `expose` |
| `plan/bases-donnees.yml` | base | serveur, propriétaire, secret en voûte, `consommateur`, `portee` |
| `plan/domaines.yml` | zone DNS | `autorite`, `edge`, `dnssec`, `enregistrements`, `resolution_interne` |
| `plan/nomenclature.yml` | dérivation | `index` (seed), fonctions → VMID / VLAN / IP |
Détail : `docs/conception/plan-et-generation.md`, `docs/conception/meta-classe.md`.
## Ce qu'un rôle déclare, ce que le moteur dérive
Chaque rôle porte ses déclarations dans `roles/<rôle>/meta/`. Le moteur les agrège ; aucune
liste n'est tenue à la main ailleurs.
| Déclaration | Ce que le moteur en dérive | Doc |
|---|---|---|
| `meta/flux.yml` | nftables de l'hôte, pare-feu Proxmox, frontière OPNsense, registre des flux | `conception/flux-conception.md` |
| `meta/liens.yml` | variables de connexion service → service | `conception/bindings-conception.md` |
| `meta/empreinte.yml` | RAM, CPU, disque de la VM | `conception/dimensionnement-ressources.md` |
| `meta/supervision.yml`, `meta/metriques.yml` | services Icinga, cibles Prometheus, tableaux | `conception/supervision-conception.md` |
| `meta/authentification.yml` | portée et mécanisme d'authentification du rôle, gardés par P29 | `conception/authentification.md` |
| `meta/acces.yml` | rôles d'accès projetés dans Keycloak | `exploitation/autorisation.md` |
| `meta/integration.yml` | intégrations universelles (`client_*`) posées sur chaque VM | `conception/integrations-vm.md` |
## Réseau
```mermaid
flowchart TB
NET(("Internet")) --> OPN["Frontière OPNsense<br/>nord/sud · seul équipement L3 de bordure"]
OPN --> SDN["SDN EVPN sur les hyperviseurs<br/>une zone (VRF) par écosystème · passerelles anycast"]
SDN --> PFW["Pare-feu Proxmox<br/>est-ouest, par VM"]
PFW --> NFT["nftables de l'hôte"]
NFT --> SVC["service"]
FLUX["roles/*/meta/flux.yml"] -. "dérive" .-> OPN & PFW & NFT
```
- **Underlay** (`underlay.yml` du site) : la fabric physique — gestion, iSCSI, Ceph, ponts.
`make underlay-plan` le confronte au réel.
- **Overlay** : un écosystème = une zone EVPN et ses VNets, nommés depuis le seed
(`make sdn-plan`). Détail : `docs/conception/sdn-evpn.md`.
- **Quatre couches de filtrage, une seule source** : les flux déclarés par les rôles.
`pair: externe` devient la politique de bordure. Détail :
`docs/conception/frontiere-opnsense.md`, `docs/conception/registre-flux.md`.
- **Deux sites reliés** par un tunnel WireGuard (`opnsense_liens_sites`) : réplication du DNS
public, administration du site pair. DNS : `docs/conception/dns-interne.md`.
## Déclaré, dérivé, mesuré
```mermaid
flowchart LR
D["Déclaré<br/>plan · meta/ · cartes"] --> V["Dérivé<br/>devis : scripts/devis_*.py"]
V --> P["make SUJET-plan<br/>écart, aucune écriture"]
P --> A["make SUJET-appliquer CONFIRMER=true<br/>réconcilie"]
R["Réel<br/>API Proxmox · OPNsense · VM"] --> P
D --> PR["make prouver / verifier<br/>preuves statiques : lisent le dépôt"]
```
- **Les preuves** (`make verifier`, `make prouver`) lisent le dépôt seulement : cohérence du
plan, des rôles, de la doc. Registre : `docs/audit/affirmations.md`.
- **Les devis** lisent le système en marche et le comparent à ce que le plan dérive. Ils
n'écrivent rien ; la cible `-appliquer` correspondante réconcilie, sous `CONFIRMER=true`.
Détail : `docs/exploitation/devis-services.md`.
## Sécurité
| Sujet | Mécanisme | Doc |
|---|---|---|
| Secrets | une voûte par dépôt, une clé par voûte, `scripts/voutes.py` construit `ANSIBLE_VAULT_IDENTITY_LIST` | `exploitation/sortir-les-cles-du-poste.md` |
| Confiance machine | AC interne step-ca (ACME), certificats par `client_pki` | `conception/integrations-vm.md` |
| Identité | OpenLDAP source unique, Keycloak fédéré, `oauth2-proxy` devant les services sans OIDC | `conception/identite-sso.md`, `conception/authentification.md` |
| Habilitations | amorcées par `amorcage_acces`, jamais réconciliées | `exploitation/autorisation.md` |
| Administration | tunnel WireGuard nominatif `admins`, rebond par la frontière | `exploitation/acces-administration.md` |
| Transit | chaque flux déclare son `chiffrement` ; le registre en fait la synthèse | `conception/flux-conception.md`, `conception/registre-flux.md` |
## Invariants
- Logiciel libre exclusivement ; ni Docker, ni Podman.
- L'inventaire et `playbooks/site.yml` sont générés : ne pas les éditer.
- Aucun nom d'inventaire codé en dur : `<inventaire>` est résolu par `ORDRE_INVENTAIRE`.
- Le moteur s'exploite sans IA : la doc, `make` et le GUI suffisent.
- L'autorité est `AGENTS.md`.

56
docs/audit/affirmations.md
View file

@ -41,9 +41,9 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
| AFF-007 | « Inspecter … `make hote-afficher HOTE=web-frontal-01` » (README:98) | procédurale | `make hote-afficher HOTE=web-frontal-01` | 🟡 | La cible existe et fonctionne, mais l'hôte d'exemple `web-frontal-01` n'existe pas dans l'instance courante → l'exemple littéral échoue (exemple générique, pas garanti par instance). |
| AFF-008 | « Chaque groupe opérationnel doit avoir son playbook homonyme dans `playbooks/groupes/` » (README:120 ; AGENTS:316) | structurelle | `python3 scripts/inventory_host.py --inventaire instance/inventories/principal/hosts.yml verifier-playbooks --dossier-playbooks playbooks/groupes` | ✅ | rc=0. Les 30 groupes opérationnels ont leur playbook. Seuls `hotes_actifs`, `hotes_planifies`, `modeles_vm` (groupes méta/état) n'en ont pas — exclus par conception. |
| AFF-009 | « Les dépendances causales entre groupes sont dans `docs/dependances-groupes.yml` » (README:128 ; AGENTS:413) | structurelle | `python3 scripts/inventory_host.py … verifier-dependances …` | ✅ | rc=0. Aucune entrée ne référence un rôle/groupe inexistant. |
| AFF-010 | « Le runbook du DNS interne initial est dans `docs/dns-interne.md` » (README:130) | structurelle | `test -f docs/dns-interne.md` | ✅ | Fichier présent. |
| AFF-011 | « La nomenclature … est dans `docs/nomenclature-vm.md` » (README:132) | structurelle | `test -f docs/nomenclature-vm.md` | ✅ | Fichier présent. |
| AFF-012 | « Le catalogue des services … `docs/catalogue-services.md` » (README:126) | structurelle | `test -f docs/catalogue-services.md` | ✅ | Fichier présent. |
| AFF-010 | « Le runbook du DNS interne initial est dans `docs/conception/dns-interne.md` » (README:130) | structurelle | `test -f docs/conception/dns-interne.md` | ✅ | Fichier présent. |
| AFF-011 | « La nomenclature … est dans `docs/conception/nomenclature-vm.md` » (README:132) | structurelle | `test -f docs/conception/nomenclature-vm.md` | ✅ | Fichier présent. |
| AFF-012 | « Le catalogue des services … `docs/projet/catalogue-services.md` » (README:126) | structurelle | `test -f docs/projet/catalogue-services.md` | ✅ | Fichier présent. |
| AFF-013 | « `make creer-vm HOTE=… ` VMID/IP/VLAN/passerelle lus dans le plan » (README:138) | fonctionnelle | `python3 scripts/inventory_host.py … parametres-proxmox --hote <h>` | 🟡 | La dérivation existe (sous-commande `parametres-proxmox`), mais l'exécution réelle touche Proxmox → non testable localement (hors production). Mécanique de dérivation seule vérifiable. |
| AFF-014 | « Les déploiements de groupes ciblent automatiquement les hôtes actifs seulement » (README:171) | fonctionnelle | lecture `Makefile:261` : `--limit '$(GROUPE):&$(GROUPE_HOTES_ACTIFS)'` | ✅ | Intersection `groupe ∩ hotes_actifs` codée dans la cible `appliquer`. |
| AFF-015 | « Set-OPS est un logiciel libre … AGPLv3 … texte intégral dans `LICENSE` » (README:177-186) | structurelle | `test -f LICENSE` | ✅ | `LICENSE` présent. |
@ -52,6 +52,9 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
## 2. QUICKSTART.md
> **Retiré le 2026-10-15**, fondu dans `README.md` (démarrage rapide) et `docs/setup.md`.
> Les affirmations ci-dessous gardent leurs références d'origine : c'est la trace de l'audit.
| ID | Affirmation (source) | Type | Commande de preuve | Statut | Écart constaté |
|---|---|---|---|---|---|
| AFF-020 | « Les modèles sont dans `exemples/modeles/` … Choisis : `socle`, `presence-web`, `forge`, `identite`, `observabilite`, `integral` » (QUICKSTART:25-26) | structurelle | `ls exemples/modeles/` | ✅ | Le dossier public ne contient que `socle` (+ `README.md`). Les 5 autres modèles sont dans un dépôt **privé** `Set-OPS-modeles` (correctement expliqué dans `exemples/modeles/README.md`, mais **pas** dans QUICKSTART). — **rejugé le 2026-08-08 : RÉSOLU.** QUICKSTART §2 annonce désormais **un seul modèle générique `socle`** et renvoie les modèles assemblés au dépôt privé — la promesse s'est alignée sur la décision, pas l'inverse |
@ -94,6 +97,9 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
## 5. SOLUTION.md
> **Retiré le 2026-10-15** : document historique, déjà supplanté (AFF-060/061). La décision
> fondatrice reste dans l'histoire du dépôt ; le parcours du gabarit est dans `docs/setup.md` §6.
| ID | Affirmation (source) | Type | Commande de preuve | Statut | Écart constaté |
|---|---|---|---|---|---|
| AFF-060 | « On garde une seule structure : `inventories/ playbooks/ roles/ docs/` » (SOLUTION:11-18) | structurelle | `ls` racine | 🟡 | Réel : aussi `scripts/`, `filter_plugins/`, `exemples/`, `wiki/`, `instance/`. Description obsolète (antérieure au plan/GUI). |
@ -107,7 +113,7 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
| ID | Affirmation (source) | Type | Commande de preuve | Statut | Écart constaté |
|---|---|---|---|---|---|
| AFF-070 | « `make site-verifier` valide la cohérence couches/graphe » (Makefile aide:133) | fonctionnelle | `python3 scripts/orchestrer.py verifier` | ✅ | « Orchestration cohérente : 30 groupes classés, aucun cycle, aucune arête en arrière. » |
| AFF-071 | « `make flux` → `docs/registre-flux.md` + `instance/flux-genere/*.nft` » (Makefile aide:146) | fonctionnelle | `python3 scripts/resoudre_flux.py verifier` ; en-tête de `docs/registre-flux.md` | ✅ | « Flux cohérents : 29 rôles, 63 flux ». Le registre porte l'en-tête « GÉNÉRÉ par `scripts/resoudre_flux.py` ». |
| AFF-071 | « `make flux` → `docs/conception/registre-flux.md` + `instance/flux-genere/*.nft` » (Makefile aide:146) | fonctionnelle | `python3 scripts/resoudre_flux.py verifier` ; en-tête de `docs/conception/registre-flux.md` | ✅ | « Flux cohérents : 29 rôles, 63 flux ». Le registre porte l'en-tête « GÉNÉRÉ par `scripts/resoudre_flux.py` ». |
| AFF-072 | « `make deployer-tout` — déploiement orchestré de la flotte ; garde `CONFIRMER` » (Makefile aide:138) | fonctionnelle | lecture Makefile:352-357 | 🟡 | Garde `CONFIRMER=true` vérifiée (refuse sinon, rc=2). Déploiement réel hors production → non exécuté. |
| AFF-073 | « `make wiki-publier` … refuse sans `WIKI_REMOTE` » (Makefile aide:151) | fonctionnelle | lecture Makefile:320-326 | ✅ | Garde présente : refus + message d'usage si `WIKI_REMOTE` vide. |
| AFF-074 | « `make devis-reseau` — dérivé des nomenclatures » (Makefile:309) | fonctionnelle | `python3 scripts/devis_reseau.py` | 🟡 | Dérive des instances fédérées `../*/plan/nomenclature.yml` (schéma `ip-miroir`) ; sortie dépend du voisinage de dépôts → vérifiable seulement dans un contexte fédéré. |
@ -119,12 +125,12 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
| ID | Affirmation (source) | Type | Commande de preuve | Statut | Écart constaté |
|---|---|---|---|---|---|
| AFF-080 | « `make help` — liste des cibles » (docs/config-proxmox.md:114) | procédurale | `grep -E '^help:' Makefile` | ✅ | Aucune cible `help`. La cible réelle est `aide` (défaut). Commande citée inexistante. — **rejugé le 2026-08-08 : RÉSOLU.** plus aucune occurrence de `make help` dans le dépôt ; la cible s'appelle `aide`, et les **85** cibles portent leur texte d'aide (P31) |
| AFF-081 | « `make syntax-template` » (docs/modeles_vm/debian13-proxmox.md:77) | procédurale | `grep syntax-template Makefile` | ✅ | Aucune cible `syntax-template`. Réel : `syntaxe-modele`. Nom périmé. — **rejugé le 2026-08-08 : RÉSOLU.** `syntax-template` n'apparaît plus nulle part hors de ce registre ; la cible est `syntaxe-modele` |
| AFF-082 | « `make syntax-template` » (docs/MISE-A-JOUR-CODEX-CLAUDE.md:146) | procédurale | idem | ✅ | Même nom périmé, second emplacement. — **rejugé le 2026-08-08 : RÉSOLU.** idem AFF-081 |
| AFF-080 | « `make help` — liste des cibles » (docs/exploitation/config-proxmox.md:114) | procédurale | `grep -E '^help:' Makefile` | ✅ | Aucune cible `help`. La cible réelle est `aide` (défaut). Commande citée inexistante. — **rejugé le 2026-08-08 : RÉSOLU.** plus aucune occurrence de `make help` dans le dépôt ; la cible s'appelle `aide`, et les **85** cibles portent leur texte d'aide (P31) |
| AFF-081 | « `make syntax-template` » (docs/exploitation/gabarit-debian13-justification.md:77) | procédurale | `grep syntax-template Makefile` | ✅ | Aucune cible `syntax-template`. Réel : `syntaxe-modele`. Nom périmé. — **rejugé le 2026-08-08 : RÉSOLU.** `syntax-template` n'apparaît plus nulle part hors de ce registre ; la cible est `syntaxe-modele` |
| AFF-082 | « `make syntax-template` » (docs/projet/MISE-A-JOUR-CODEX-CLAUDE.md:146) | procédurale | idem | ✅ | Même nom périmé, second emplacement. — **rejugé le 2026-08-08 : RÉSOLU.** idem AFF-081 |
| AFF-083 | Tous les docs cités par README/QUICKSTART/AGENTS existent (`plan-et-generation`, `positionnement`, `bindings-conception`, `flux-conception`, `couches-deploiement.yml`, `registre-flux.md`, `carte-set-ops`, `runbooks-exploitation`, `vm-lifecycle`, `procedure-template-…`, `dns-interne`, `nomenclature-vm`, `config-proxmox`, `catalogue-services`, `dimensionnement-ressources`, `exemples/vault.exemple.yml`, `exemples/instance.exemple.yml`) | structurelle | `test -f` sur chaque chemin | ✅ | 17/17 présents. |
| AFF-084 | « `docs/dependances-groupes.yml` — chaque groupe existant y figure, aucune entrée ne référence un rôle supprimé » (AGENTS:345,413) | structurelle | `verifier-dependances` (AFF-009) | ✅ | Validé ; graphe sans cycle, tri topologique réussi (via `orchestrer verifier`). |
| AFF-097 | Chemins d'inventaire `lab/` codés en dur pour la config/voûte **Proxmox** et le template, alors que `make config`/`cloner-vm` résolvent `lab > principal > production` (modèle `socle` = `production/`) | procédurale | `grep -rn 'inventories/lab/group_vars' docs playbooks` ; `scripts/config_proxmox.py:31` | 🟡 | **Découvert en Phase 3 (lot A).** Reste `lab/` codé en dur dans `docs/vm-lifecycle.md:171`, `docs/procedure-template-debian13-proxmox.md:741,747`, `docs/modeles_vm/debian13-proxmox.md:89`, `playbooks/proxmox/README.md:31,43,49,50`, `playbooks/proxmox/cloner_vm_debian.yml:45` (message). Non bloquant (l'outillage résout), mais trompeur pour le socle. **Différé** au lot « voûte Proxmox » (couplé à AFF-098). |
| AFF-097 | Chemins d'inventaire `lab/` codés en dur pour la config/voûte **Proxmox** et le template, alors que `make config`/`cloner-vm` résolvent `lab > principal > production` (modèle `socle` = `production/`) | procédurale | `grep -rn 'inventories/lab/group_vars' docs playbooks` ; `scripts/config_proxmox.py:31` | 🟡 | **Découvert en Phase 3 (lot A).** Reste `lab/` codé en dur dans `docs/exploitation/vm-lifecycle.md:171`, `docs/exploitation/procedure-template-debian13-proxmox.md:741,747`, `docs/exploitation/gabarit-debian13-justification.md:89`, `playbooks/proxmox/README.md:31,43,49,50`, `playbooks/proxmox/cloner_vm_debian.yml:45` (message). Non bloquant (l'outillage résout), mais trompeur pour le socle. **Différé** au lot « voûte Proxmox » (couplé à AFF-098). |
| AFF-099 | Le modèle public `socle` livre un `plan/domaines.yml` **invalide** : `exemple.internal` en `autorite: interne`, rejeté par le validateur (`auto-heberge`/`delegue`/`primaire-cache` attendus) | fonctionnelle | `SETOPS_INSTANCE=exemples/modeles/socle python3 scripts/domaines.py verifier` | ✅ | **Découvert Phase 5.** Un opérateur suivant QUICKSTART bute à la validation (étape 9 / `make inventaire-verifier`). `interne` = valeur périmée (déjà corrigée ailleurs en `auto-heberge`, cf. CHANGELOG 2026-07-07). — **rejugé le 2026-08-08 : RÉSOLU.** `SETOPS_INSTANCE=exemples/modeles/socle python3 scripts/domaines.py verifier` → « Registre des domaines valide. » (gardé par P15) |
| AFF-100 | `instancier.py`/`inventory_gui.py` résolvent `principal > production` mais **retombent sur `principal`** quand aucun `hosts.yml` n'existe encore ; le socle est en `production/` → 1ʳᵉ génération dans `principal/`, à côté des `group_vars` restés en `production/` (split-brain) | fonctionnelle | parcours QUICKSTART hors-ligne sur une copie du socle (`generer`→`appliquer`) | ✅ | **Découvert Phase 5.** `config_proxmox.py` détecte le répertoire existant (→ `production/`) ; `instancier`/GUI non → incohérence. QUICKSTART étapes 6-9 cassées pour le socle. — **rejugé le 2026-08-08 : RÉSOLU.** parcours hors-ligne sur copie du socle : `instancier generer` écrit dans `inventories/production/hosts.genere.yml` — plus de repli sur `principal` |
| AFF-098 | Contradiction fonctionnelle voûte Proxmox : `make config` écrit le token dans la voûte unifiée `all/vault.yml` (et `config-proxmox.md` dit de **supprimer** `proxmox.vault.yml`), mais le clonage `cloner_vm_debian.yml` (lancé `-i localhost,`) ne charge le secret **que** depuis `proxmox.vault.yml`/`proxmox.local.yml` ou les variables d'env — **jamais** `all/vault.yml` | fonctionnelle | lecture `playbooks/proxmox/cloner_vm_debian.yml:11-12,51-64` vs `scripts/config_proxmox.py:35` | ✅ | **Découvert en Phase 3 (lot B).** Un opérateur qui suit la voûte unifiée met le token dans `all/vault.yml` → `make creer-vm` échoue l'assert (`proxmox_api_token_secret` vide), sauf variables d'env ou `proxmox.vault.yml` conservé. **Traitement B (code)** : faire lire `all/vault.yml` par le clonage, ou faire écrire `proxmox.vault.yml` par `make config`. À arbitrer dans le lot « voûte Proxmox ». — **rejugé le 2026-08-08 : RÉSOLU.** `cloner_vm_debian.yml` et `config_proxmox.py` disent tous deux « voûte UNIQUE de l'instance » ; `config-proxmox.md` §« `proxmox.vault.yml` n'est plus lue (retirée le 2026-08-03) » |
@ -158,18 +164,18 @@ Légende du statut : ✅ prouvée · 🟡 partielle · ❌ fausse · ⚪ invéri
| ID | Affirmation (source) | Type | Commande de preuve | Statut | Écart constaté |
|---|---|---|---|---|---|
| AFF-101 | « Tout l'adressage dérive du seul seed `index` ; aucune adresse n'est stockée » (`docs/sdn-evpn.md` §2 ; wiki *Multi-instance*) | structurelle | `python3 scripts/prouver.py` → **P20** | ✅ | Aucun `supernet`/`sous_reseau`/`passerelle`/`vlan` stocké dans une nomenclature. |
| AFF-102 | « Aucune paire d'instances fédérées ne partage un `index` » (`docs/multi-instances.md`) | fonctionnelle | **P21** (`scripts/instances.py --verifier`) | ✅ | 3 instances, aucune collision. Le garde-fou refuse la création en doublon. |
| AFF-101 | « Tout l'adressage dérive du seul seed `index` ; aucune adresse n'est stockée » (`docs/conception/sdn-evpn.md` §2 ; wiki *Multi-instance*) | structurelle | `python3 scripts/prouver.py` → **P20** | ✅ | Aucun `supernet`/`sous_reseau`/`passerelle`/`vlan` stocké dans une nomenclature. |
| AFF-102 | « Aucune paire d'instances fédérées ne partage un `index` » (`docs/conception/multi-instances.md`) | fonctionnelle | **P21** (`scripts/instances.py --verifier`) | ✅ | 3 instances, aucune collision. Le garde-fou refuse la création en doublon. |
| AFF-103 | « L'underlay ne chevauche aucun supernet tenant et reste sous la plage VLAN tenant » (`underlay.yml.example` ; wiki) | structurelle | **P23** (`scripts/underlay.py --verifier`) | ✅ | Sauté si aucun `underlay.yml` monté (dépôt public nu). |
| AFF-104 | « La frontière déclare toujours une source d'administration ; un devis dont `nftables_admin_ssh` est vide est refusé » (`docs/frontiere-opnsense.md` §5) | fonctionnelle | **P24** (`scripts/devis_opnsense.py --verifier`) | ✅ | Garde anti-lockout : sans cet intrant, la règle SSH n'aurait aucune source et le `block` final fermerait l'accès. |
| AFF-104 | « La frontière déclare toujours une source d'administration ; un devis dont `nftables_admin_ssh` est vide est refusé » (`docs/conception/frontiere-opnsense.md` §5) | fonctionnelle | **P24** (`scripts/devis_opnsense.py --verifier`) | ✅ | Garde anti-lockout : sans cet intrant, la règle SSH n'aurait aucune source et le `block` final fermerait l'accès. |
| AFF-105 | « Les modèles publics valident, underlay compris » (`exemples/modeles/socle/README.md`) | structurelle | **P17** (`scripts/modeles.py verifier`) | ✅ | Underlay facultatif ; validé pour sa cohérence **interne** seulement — un modèle est un gabarit, pas un site déployé. |
| AFF-107 | « Le filtrage est-ouest intra-tenant est dérivé du registre des flux, et redit la même politique que les nftables d'hôte » (`docs/sdn-evpn.md` §3) | structurelle | **P25** (`scripts/devis_proxmox_fw.py --verifier`) | ✅ | 34 groupes, 40 règles sur 2 tenants. Les deux barrières lisent le registre par les **mêmes fonctions** : elles ne peuvent pas diverger. |
| AFF-108 | « Une intégration universelle est déclarée par le rôle, pas recopiée par serveur : aucun hôte n'y échappe et le plan ne la redit pas » (`docs/decisions-architecture.md` D-33) | structurelle | **P26** (`scripts/prouver.py`) | ✅ | L'exemption se dérive du **service rendu** (`sauf_role`), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. |
| AFF-109 | « Ce qui appartient à l'hébergeur (cluster, fabric, frontière) vit dans son dépôt, jamais recopié chez un tenant » (`docs/decisions-architecture.md` D-35) | structurelle | **P27** (`scripts/prouver.py`) | ✅ | Le chemin se dérive du symlink `underlay.yml` : l'hébergeur n'est toujours pas déclaré (D-17). Sautée si aucun underlay n'est monté. |
| AFF-110 | « Chaque tenant a son pool Proxmox, dérivé, sans collision de nom ni de VMID » (`docs/decisions-architecture.md` D-37) | structurelle | **P28** (`scripts/devis_proxmox_pools.py --verifier`) | ✅ | Le nom dérive du dossier d'instance et de l'`index`, déjà unique par P21 — aucun registre de plus. Le devis ne lit pas le cluster : il affirme la cohérence du **plan**, pas l'état appliqué. |
| AFF-111 | « Chaque rôle `serveur_*` déclare sa position d'authentification, et la déclaration est cohérente avec son code » (`docs/authentification.md`, D-38 à D-41) | structurelle | **P29** (`scripts/prouver.py`) | ✅ | 23 rôles déclarés. La preuve refuse l'oubli **et** le mensonge : une déclaration `web-sso natif` sans variable `<rôle>_oidc`, ou `ldap-direct` sans variable `<rôle>_ldap`, échoue. Les indices sont **nommés** — une première version cherchait les mots « ldap »/« oidc » et le mot LDAP dans un commentaire suffisait à valider un mensonge. Les 2 portées `interne-sans-auth` (Prometheus, Loki) sont des lacunes **comptées, pas masquées**. |
| AFF-112 | « Ajouter un tenant implique une zone EVPN, ses VNets et ses sous-réseaux, tous dérivés du seed » (`docs/sdn-evpn.md` §2) | structurelle | **P30** (`scripts/devis_sdn.py --verifier`) | ✅ | 2 zones, 12 VNets, 12 sous-réseaux. La dérivation **reproduit à l'identique** les deux zones déjà présentes sur le cluster (nom, VNI de VRF, MTU, contrôleur) — vérifié par lecture de l'API. La garde refuse un identifiant de VNet de plus de 8 caractères, limite Proxmox qui aurait fait échouer le devis à l'application. Les **nœuds de sortie manquants** sont signalés, pas inventés. |
| AFF-106 | « Le panneau couvre le schéma du plan : aucun champ n'oblige à éditer le YAML » (`docs/intrants-base-gui-conception.md`) | fonctionnelle | **P19** (`scripts/couverture_gui.py`) | 🟡 | Vrai des registres du plan. **Exceptions assumées** : `reseaux` et `hotes` de l'underlay (listes de tables) restent hors du panneau ; les ports physiques et le nœud de sortie EVPN se nomment à la main. |
| AFF-107 | « Le filtrage est-ouest intra-tenant est dérivé du registre des flux, et redit la même politique que les nftables d'hôte » (`docs/conception/sdn-evpn.md` §3) | structurelle | **P25** (`scripts/devis_proxmox_fw.py --verifier`) | ✅ | 34 groupes, 40 règles sur 2 tenants. Les deux barrières lisent le registre par les **mêmes fonctions** : elles ne peuvent pas diverger. |
| AFF-108 | « Une intégration universelle est déclarée par le rôle, pas recopiée par serveur : aucun hôte n'y échappe et le plan ne la redit pas » (`docs/projet/decisions-architecture.md` D-33) | structurelle | **P26** (`scripts/prouver.py`) | ✅ | L'exemption se dérive du **service rendu** (`sauf_role`), jamais d'un nom d'hôte : l'AC ne s'enrôle pas auprès d'elle-même, et l'exemption suit step-ca si on le déplace. |
| AFF-109 | « Ce qui appartient à l'hébergeur (cluster, fabric, frontière) vit dans son dépôt, jamais recopié chez un tenant » (`docs/projet/decisions-architecture.md` D-35) | structurelle | **P27** (`scripts/prouver.py`) | ✅ | Le chemin se dérive du symlink `underlay.yml` : l'hébergeur n'est toujours pas déclaré (D-17). Sautée si aucun underlay n'est monté. |
| AFF-110 | « Chaque tenant a son pool Proxmox, dérivé, sans collision de nom ni de VMID » (`docs/projet/decisions-architecture.md` D-37) | structurelle | **P28** (`scripts/devis_proxmox_pools.py --verifier`) | ✅ | Le nom dérive du dossier d'instance et de l'`index`, déjà unique par P21 — aucun registre de plus. Le devis ne lit pas le cluster : il affirme la cohérence du **plan**, pas l'état appliqué. |
| AFF-111 | « Chaque rôle `serveur_*` déclare sa position d'authentification, et la déclaration est cohérente avec son code » (`docs/conception/authentification.md`, D-38 à D-41) | structurelle | **P29** (`scripts/prouver.py`) | ✅ | 23 rôles déclarés. La preuve refuse l'oubli **et** le mensonge : une déclaration `web-sso natif` sans variable `<rôle>_oidc`, ou `ldap-direct` sans variable `<rôle>_ldap`, échoue. Les indices sont **nommés** — une première version cherchait les mots « ldap »/« oidc » et le mot LDAP dans un commentaire suffisait à valider un mensonge. Les 2 portées `interne-sans-auth` (Prometheus, Loki) sont des lacunes **comptées, pas masquées**. |
| AFF-112 | « Ajouter un tenant implique une zone EVPN, ses VNets et ses sous-réseaux, tous dérivés du seed » (`docs/conception/sdn-evpn.md` §2) | structurelle | **P30** (`scripts/devis_sdn.py --verifier`) | ✅ | 2 zones, 12 VNets, 12 sous-réseaux. La dérivation **reproduit à l'identique** les deux zones déjà présentes sur le cluster (nom, VNI de VRF, MTU, contrôleur) — vérifié par lecture de l'API. La garde refuse un identifiant de VNet de plus de 8 caractères, limite Proxmox qui aurait fait échouer le devis à l'application. Les **nœuds de sortie manquants** sont signalés, pas inventés. |
| AFF-106 | « Le panneau couvre le schéma du plan : aucun champ n'oblige à éditer le YAML » (`docs/conception/intrants-base-gui-conception.md`) | fonctionnelle | **P19** (`scripts/couverture_gui.py`) | 🟡 | Vrai des registres du plan. **Exceptions assumées** : `reseaux` et `hotes` de l'underlay (listes de tables) restent hors du panneau ; les ports physiques et le nœud de sortie EVPN se nomment à la main. |
**Non enregistré volontairement.** Les devis eux-mêmes (`make devis-reseau`,
`make devis-opnsense`) ne font l'objet d'aucune affirmation de *justesse* : leur syntaxe
@ -310,16 +316,16 @@ les 🟡 relèvent de la **Phase 3 (arbitrage)**. *(Tous traités depuis — voi
renvoyés au dépôt privé `Set-OPS-modeles`, cohérent avec `exemples/modeles/README.md`.
- **AFF-023 (❌ → résolu, A + correctif d'exemple)** — Chemin de voûte corrigé
`lab/` → `production/` dans `QUICKSTART.md`, `exemples/vault.exemple.yml` et
`docs/config-proxmox.md`. **Piège corrigé** : le modèle `socle` livrait ses intrants en
`docs/exploitation/config-proxmox.md`. **Piège corrigé** : le modèle `socle` livrait ses intrants en
`production/group_vars/all.yml` (forme fichier) ; ajouter `all/vault.yml` (forme dossier)
**masque silencieusement** le fichier `all.yml` (vérifié empiriquement : seul le dossier
est chargé). Le modèle a été converti en forme dossier (`all/10-intrants.yml`), alignée
sur l'instance prouvée `principal`. Validé : `ansible-inventory --host` charge bien
`domaine_interne` depuis la nouvelle disposition.
- **AFF-080/081/082 (❌ → résolu, A)** — Commandes `make` périmées corrigées :
`make help` → `make` (`docs/config-proxmox.md`) ; `make syntax-template` →
`make syntaxe-modele` (`docs/modeles_vm/debian13-proxmox.md`,
`docs/MISE-A-JOUR-CODEX-CLAUDE.md`).
`make help` → `make` (`docs/exploitation/config-proxmox.md`) ; `make syntax-template` →
`make syntaxe-modele` (`docs/exploitation/gabarit-debian13-justification.md`,
`docs/projet/MISE-A-JOUR-CODEX-CLAUDE.md`).
- **AFF-097 (🟡, découvert)** — `lab/` codé en dur restant dans les docs template/clone
(étapes 5+). Consigné ci-dessus ; **non traité dans ce lot** (lot séparé à prévoir).
@ -356,8 +362,8 @@ les 🟡 relèvent de la **Phase 3 (arbitrage)**. *(Tous traités depuis — voi
le token est bien chargé depuis `all/vault.yml` et l'hôte depuis `proxmox.yml`
(assert vert). **Suite, 2026-08-03** : `proxmox.vault.yml` n'est plus chargée du tout — tolérée, elle restait le seul porteur du jeton chez un tenant, dans un fichier gitignoré. Migrée vers `all/vault.yml`, supprimée, et `voute.py verifier` contrôle désormais la voûte RÉELLE quand elle est déchiffrable (ce que la seule vérification du gabarit ne pouvait pas voir).
- **AFF-097 (🟡 → résolu, A)** — `lab/` codé en dur retiré des docs Proxmox/template :
`playbooks/proxmox/README.md`, `docs/procedure-template-debian13-proxmox.md`,
`docs/vm-lifecycle.md`, `docs/modeles_vm/debian13-proxmox.md` → `production/` + voûte
`playbooks/proxmox/README.md`, `docs/exploitation/procedure-template-debian13-proxmox.md`,
`docs/exploitation/vm-lifecycle.md`, `docs/exploitation/gabarit-debian13-justification.md` → `production/` + voûte
unifiée. Plus aucune référence `inventories/lab/group_vars` dans les fichiers suivis
(hors `tmp/` gitignoré et la section *migration* de `config-proxmox.md`, intentionnelle).
@ -394,7 +400,7 @@ commande morte, chemin faux ni étape manquante.*
- **AFF-100 (❌ → résolu, B)** — `instancier.py` et `inventory_gui.py` : le repli sans
`hosts.yml` vise maintenant le **répertoire d'inventaire existant** (→ `production/` pour le
socle) avant de retomber sur `principal`. Instances existantes (avec `hosts.yml`) inchangées.
- **Cohérence GUI/doc** — `docs/intrants-communs.md` : `group_vars/all.yml` →
- **Cohérence GUI/doc** — `docs/conception/intrants-communs.md` : `group_vars/all.yml` →
`group_vars/all/10-intrants.yml` (le GUI écrit déjà en forme dossier). `QUICKSTART.md`
étape 8 : exemple `serveur_postgresql` → `serveur_powerdns` (groupe présent dans le socle).
- **Preuve bout-en-bout (hors-ligne)** : parcours QUICKSTART rejoué sur une copie du socle —

2
docs/audit/plan-de-recette.md
View file

@ -150,7 +150,7 @@ le côté humain **est** la preuve de l'affirmation « exploitable sans IA » (c
| 1 | Lis ton réseau physique | : make underlay. Repère les VLAN sous 1000 (l'underlay) et les MTU. Pourquoi le transport doit-il être à 1500 quand l'overlay est à 1450 ? | 👁 observe | — |
| 2 | Regarde sans écrire | : make sdn-plan. Si le cluster dit déjà ce que le plan dit, la sortie tient en une ligne. | 👁 observe | — |
| 3 | Trouve la sortie d'un tenant | : dans make devis-sdn, repère la strophe FRR et l'adresse du prochain saut. À quel équipement appartient-elle ? | 👁 observe | — |
| 4 | Change `index` dans un modèle | (jamais en production) et régénère : combien de valeurs ont bougé ? C'est la mesure exacte de ce que la dérivation t'épargne. Pour aller plus loin : docs/sdn-evpn.md dans le dépôt (référence technique), Le plan & l'adressage dérivé, Mult… | 👁 observe | — |
| 4 | Change `index` dans un modèle | (jamais en production) et régénère : combien de valeurs ont bougé ? C'est la mesure exacte de ce que la dérivation t'épargne. Pour aller plus loin : docs/conception/sdn-evpn.md dans le dépôt (référence technique), Le plan & l'adressage d… | 👁 observe | — |
*Source : [Le réseau des tenants — du câble au VRF](../../wiki/Le-r%C3%A9seau-des-tenants.md) · § À toi de jouer.*

4
docs/audit/protocole-operateur-independant.md
View file

@ -17,7 +17,7 @@ principe 10).
## Ce que l'épreuve mesure
**Mesuré** : ce que le dépôt public transmet, seul, à un sysadmin compétent qui ne
connaît pas Set-OPS — depuis `QUICKSTART.md`, sur sa propre grappe Proxmox, du dépôt nu
connaît pas Set-OPS — depuis `README.md` et `docs/setup.md`, sur sa propre grappe Proxmox, du dépôt nu
jusqu'à un socle déployé.
**Non mesuré** : les modèles assemblés (dépôt privé `Set-OPS-modeles`), les services
@ -74,7 +74,7 @@ sysadmin.
Rien d'autre. En particulier, l'auteur ne prépare **ni** le jeton API Proxmox, **ni** les
clés SSH, **ni** le mot de passe Vault, **ni** le moindre fichier d'instance : ce sont
les prérequis de `QUICKSTART.md` §0, et savoir les produire fait partie de l'épreuve.
les prérequis de `docs/setup.md`, et savoir les produire fait partie de l'épreuve.
## Périmètre matériel et sécurité

2
docs/authentification.md → docs/conception/authentification.md
View file

@ -107,7 +107,7 @@ déclaration que le code contredit.
**Et depuis le 2026-09-07, sa sœur `P58` garde les habilitations** — ce que P29 ne fait
pas : elle tient les *positions* (qui s'authentifie comment), pas les *droits* (qui obtient
quoi). Voir [`autorisation.md`](autorisation.md) §5.
quoi). Voir [`autorisation.md`](../exploitation/autorisation.md) §5.
**Depuis le 2026-09-06, elle refuse aussi que ce tableau mente.** Les chiffres et les listes
de la troisième colonne sont confrontés aux déclarations réelles. Ils avaient cessé d'être

2
docs/bindings-conception.md → docs/conception/bindings-conception.md
View file

@ -192,7 +192,7 @@ du secret. La §3.1 est donc raffinée, pas contredite.
~~Reste comme valeur réelle (non bloquant) : **factoriser** le bloc de résolution copié-collé
dans les 4 rôles en un include partagé.~~ **Fait.** Le rôle utilitaire
[`roles/resoudre_base/`](../roles/resoudre_base/README.md) porte la résolution, et **cinq**
[`roles/resoudre_base/`](../../roles/resoudre_base/README.md) porte la résolution, et **cinq**
rôles consommateurs l'incluent (`serveur_forgejo`, `serveur_icinga`, `serveur_icingaweb2`,
`serveur_keycloak`, `serveur_nextcloud`). Le DRY a bien été validé **en le déployant**, comme
prévu — l'épreuve de Keycloak. Cf. §9.

0
docs/conception-contextes.md → docs/conception/conception-contextes.md
View file

0
docs/courriel-conception.md → docs/conception/courriel-conception.md
View file

0
docs/depots-prives-conception.md → docs/conception/depots-prives-conception.md
View file

0
docs/dimensionnement-ressources.md → docs/conception/dimensionnement-ressources.md
View file

0
docs/dns-interne.md → docs/conception/dns-interne.md
View file

0
docs/filiation-emancipation.md → docs/conception/filiation-emancipation.md
View file

4
docs/flux-conception.md → docs/conception/flux-conception.md
View file

@ -63,7 +63,7 @@ Un **résolveur** (miroir de `instancier`) agrège, par serveur, les `flux.yml`
(services + intégrations), résout les `pair`, et produit :
- **`nftables`** : ruleset par serveur (allow des flux résolus, `policy drop` par défaut), consommé
par le rôle `nftables_baseline` ;
- **le registre d'audit** : `docs/registre-flux.md` (généré) + une cible `make flux`.
- **le registre d'audit** : `docs/conception/registre-flux.md` (généré) + une cible `make flux`.
## Activation prudente
@ -105,7 +105,7 @@ déploiement graduel (garder l'accès SSH/Ansible, tester par nœud).
1. ✅ figer le schéma (ce doc) + **piloter** sur postgresql / client_metrique / nginx ;
2. ✅ le **résolveur** (`scripts/resoudre_flux.py`) — agrégation → règles + registre ;
3. ✅ **remplir** tous les rôles (transcription du travail zéro-confiance) ;
4. ✅ **générer** + registre d'audit (`docs/registre-flux.md`, gardé par **P49**) ; puis
4. ✅ **générer** + registre d'audit (`docs/conception/registre-flux.md`, gardé par **P49**) ; puis
**activer** nftables nœud par nœud — fait.
Ce qui a suivi la séquence n'y était pas prévu : le même registre alimente désormais aussi

4
docs/frontiere-opnsense.md → docs/conception/frontiere-opnsense.md
View file

@ -4,8 +4,8 @@
> Le pare-feu de bordure de l'écosystème. Ce document fixe les décisions d'architecture
> prises le **2026-07-29**, et décrit le devis **dérivé** qui en découle
> (`make devis-opnsense`). Il complète `docs/flux-conception.md` (le modèle des flux) et
> `docs/registre-flux.md` (la matrice d'audit).
> (`make devis-opnsense`). Il complète `docs/conception/flux-conception.md` (le modèle des flux) et
> `docs/conception/registre-flux.md` (la matrice d'audit).
## 1. Le partage des rôles

0
docs/frontiere-physique-virtuel.md → docs/conception/frontiere-physique-virtuel.md
View file

2
docs/identite-sso.md → docs/conception/identite-sso.md
View file

@ -39,7 +39,7 @@
> annonçait « Système / services (SSSD, etc.) → LDAP direct » jusqu'au 2026-09-06. Le dépôt
> ne fait pas ça : le rôle `client_ldap` a été **retiré le 2026-07-04, hors conception**, et
> aucun rôle n'installe SSSD. L'annuaire sert les **applications** ; l'accès à un hôte se
> fait par **clé SSH**, et l'élévation par `sudo`. Voir `docs/authentification.md` §2.
> fait par **clé SSH**, et l'élévation par `sudo`. Voir `docs/conception/authentification.md` §2.
## Sens de provisionnement

0
docs/integrations-vm.md → docs/conception/integrations-vm.md
View file

2
docs/intrants-base-gui-conception.md → docs/conception/intrants-base-gui-conception.md
View file

@ -5,7 +5,7 @@
But : saisir depuis **un endroit unique** les [intrants communs](intrants-communs.md)
de l'écosystème, en distinguant **constantes** et **défauts surchargeables**.
> Extension assumée du plan de contrôle (gelé — cf. [`positionnement.md`](positionnement.md)),
> Extension assumée du plan de contrôle (gelé — cf. [`positionnement.md`](../projet/positionnement.md)),
> au même titre que le [dimensionnement](dimensionnement-ressources.md). Décidée le
> 2026-06-26.

4
docs/intrants-communs.md → docs/conception/intrants-communs.md
View file

@ -33,7 +33,7 @@ fois**, depuis un endroit unique, puis les laisser se **dériver** ou se **propa
l'instance, `group_vars/all/vault.yml`. **`proxmox.vault.yml` n'est plus lue** (retirée le
2026-08-03) : tolérée « en compatibilité », elle était restée le *seul* porteur du jeton
chez un tenant — et comme `*.vault.yml` est gitignoré, ce jeton ne voyageait avec aucun
dépôt. Une voûte unique qui ne l'était pas. Cf. `docs/config-proxmox.md`.
dépôt. Une voûte unique qui ne l'était pas. Cf. `docs/exploitation/config-proxmox.md`.
- Golden template : `proxmox_clone_vmid_modele`, `proxmox_clone_source_nom`.
- Placement par défaut : `proxmox_clone_noeud`, `proxmox_clone_stockage`,
`proxmox_clone_pont`, format, complet, timeout, disque, interface, démarrer.
@ -63,7 +63,7 @@ journald (rétention) · core_dumps · systemd_ssh_auto.
### H. Secrets Vault communs 🔒 — **voûte unique** `group_vars/all/vault.yml`
> Tous les secrets de l'instance dans **un seul fichier chiffré par environnement**
> (`inventories/<env>/group_vars/all/vault.yml`), gabarit
> [`exemples/vault.exemple.yml`](../exemples/vault.exemple.yml). Un mot de passe, un
> [`exemples/vault.exemple.yml`](../../exemples/vault.exemple.yml). Un mot de passe, un
> endroit. Édité via `ansible-vault edit` (jamais par le GUI).
**La liste ne s'écrit pas ici.** Elle se *recense*, depuis le plan, les rôles des groupes
actifs et les `group_vars` :

65
docs/carte-set-ops.md → docs/conception/mecanismes.md
View file

@ -1,58 +1,11 @@
# Carte d'orientation Set-OPS
# Les mécanismes transverses
> **Pour qui :** le **mainteneur** — celui qui va *modifier* le moteur. À lire avant
> d'ajouter quoi que ce soit.
>
> Tu viens plutôt **exploiter** un écosystème déjà déployé ? Wiki →
> **Reprendre l'écosystème**. Tu **apprends** le métier ? Wiki → **Accueil**.
> d'ajouter quoi que ce soit : ces mécanismes vivent dans le code et les README de rôles, et
> on les re-découvre sinon. Le survol est dans `docs/architecture.md` ; l'index des
> documents dans `docs/README.md`.
Point d'entrée vers le corpus documentaire, et **catalogue des mécanismes transverses** —
ceux qui vivent dans le code et qu'on *re-découvre* sinon. Créée le 2026-07-03 après un audit
du dépôt, **revue le 2026-07-29**. But : ne plus re-déterrer ce qui existe.
Le dépôt est **déjà bien documenté**. Le manque n'était pas la doc du *modèle*, mais (a) un
index « par où commencer » et (b) une carte des *mécanismes* (dispersés dans le code + les
README de rôles). Cette page comble ces deux trous.
### Le dépôt en chiffres
> Ces valeurs sont **mesurées**, pas recopiées : **P48** les recompte et refuse tout écart.
> Elles étaient toutes fausses le 2026-08-26 — de 6 rôles, de 12 pièces d'audit, de 8
> décisions. Aucune ne faisait travailler personne ; mais une carte dont les faits
> vérifiables sont faux cesse d'être consultée, et c'est alors ses **pointeurs** qu'on perd.
| Ce qu'on compte | Combien | Comment on le mesure |
|---|---|---|
| rôles | 70 | `roles/*/` |
| README de rôles | 70 | `roles/*/README.md` — l'écart avec la ligne au-dessus est la dette |
| documents | 47 | `docs/*.md` |
| pièces d'audit | 53 | `docs/audit/*` |
| unités de wiki | 27 | `wiki/*.md` |
| décisions en vigueur | 85 | lignes `\| **D-nn** \|` de `decisions-architecture.md` |
| décisions renversées | 3 | lignes `\| **D-nn** —` du même document |
## 1. À lire d'abord (dans l'ordre)
| Sujet | Documents |
|---|---|
| **Autorité / gouvernance** | `AGENTS.md` (source d'autorité), `CLAUDE.md`, `docs/MISE-A-JOUR-CODEX-CLAUDE.md` |
| **Le modèle (plan)** | `docs/architecture-set-ops.md` (survol) → `docs/plan-et-generation.md` (à fond) → `docs/meta-classe.md` (concept) → `docs/conception-contextes.md` (site et locataire : deux classes, un contrat) → `docs/depots-prives-conception.md` (chaque runner ne lit que ses dépôts ; chantier) |
| **Services, maturité, dette** | `docs/catalogue-services.md` (**la carte de maturité + la cruft y sont déjà**) |
| **Exploitation / VM** | `docs/vm-lifecycle.md`, `docs/procedure-template-debian13-proxmox.md`, `docs/config-proxmox.md`, `docs/nomenclature-vm.md`, `docs/multi-instances.md` |
| **Conceptions de domaine** | `docs/identite-sso.md`, `docs/courriel-conception.md`, `docs/bindings-conception.md`, `docs/dns-interne.md`, `docs/dimensionnement-ressources.md`, `docs/integrations-vm.md` |
| **Supervision & métriques** | `docs/supervision-conception.md` (les verdicts, vers Icinga) → `docs/metriques-conception.md` (les séries, vers Prometheus et Grafana) — deux questions, deux fichiers `meta/`, un même patron : le rôle déclare, le moteur dérive |
| **Réseau / pare-feu** | `docs/flux-conception.md` (le modèle) → `docs/registre-flux.md` (**généré**, matrice d'audit) → `docs/frontiere-opnsense.md` (la bordure nord/sud) ; underlay : `underlay.yml.example` + `make underlay` |
| **Ordre de déploiement** | `docs/couches-deploiement.yml` (couches) + `docs/dependances-groupes.yml` (graphe) → `playbooks/site.yml` (**généré**, `make site`) |
| **Conformité du déployé** | `docs/devis-services.md` — les **cinq devis de service** (`make identite-plan`, `certificats-plan`, `expositions-plan`, `postgresql-plan`, `courriel-plan`) **et les cinq devis d'infrastructure** (`frontiere-plan`, `proxmox-fw-plan`, `sdn-plan`, `underlay-plan`, `placement-plan`). Répondent à ce que `make prouver` ne demande jamais : *ce qui tourne correspond-il à ce qui est déclaré ?* |
| **Preuve / recette** | `docs/audit/affirmations.md` (registre), `make prouver` → `docs/audit/preuve-<date>.md` — **statique** : lit le dépôt, aucun appel réseau ; la conformité du déployé est l'affaire des devis de service (ligne au-dessus), `docs/audit/plan-de-recette.md` (**généré** du wiki), `docs/audit/protocole-operateur-independant.md` |
| **Décisions d'architecture** | `docs/decisions-architecture.md` — les décisions en vigueur (comptées ci-dessus), pourquoi, où lire le détail, et ce qui les garde ; plus les **décisions renversées** et leur cause |
| **SDN / routage** | `docs/sdn-evpn.md` — décision du 2026-08-02 : le routage inter-zone passe des commutateurs aux hyperviseurs (zones EVPN = VRF). **En service** depuis le 2026-08-03 (`routage_tenants: sdn` dans l'`underlay.yml` du site) : les trunks ne portent plus que deux VLAN d'underlay au lieu de quinze, les passerelles `.1` sont anycast sur chaque hyperviseur. Écart mesuré par `make sdn-plan` |
| **Migration de tenant** | `docs/migration-tenant.md` — recette en **neuf étapes (0 à 8)**, machine à états, gardes ; le receveur se construit **avant** tout gel |
| **Exploitation courante** | `docs/runbooks-exploitation.md`, `docs/intrants-communs.md`, `docs/intrants-base-gui-conception.md`, `docs/theme-forgejo-hors-flotte.md` |
| **Pédagogie (le wiki)** | `wiki/` — les unités (comptées ci-dessus) publiées par `make wiki-publier` ; entrer par `wiki/Home.md` |
| **Vision / positionnement** | `docs/ecosysteme-chezlepro.md`, `docs/positionnement.md`, `docs/pouvoirs-set-ops.md` |
## 2. Les mécanismes transverses (et OÙ ils vivent)
## Les mécanismes transverses, et où ils vivent
Ce que je re-découvre sinon. **Consulter avant de concevoir un nouveau mécanisme.**
@ -88,10 +41,10 @@ Ce que je re-découvre sinon. **Consulter avant de concevoir un nouveau mécanis
> `app→base` côté base (registre, résolu en rôle pour que le secret ne quitte jamais le rôle).
> Ne pas unifier l'un dans l'autre sans raison. Cf. `bindings-conception.md`.
## 3. Maturité & dette
## Maturité et dette
- **Maturité des rôles, échafaudages, rôles-catégories inertes** : voir
`docs/catalogue-services.md` « État d'implémentation » (source de vérité, tenue à jour).
`docs/projet/catalogue-services.md` « État d'implémentation » (source de vérité, tenue à jour).
- **Dette (audit 2026-07-03, revu le 2026-07-29)** :
- ✅ **soldé** — README de rôles : **tous les rôles en ont un** (les 12 manquants écrits le
2026-07-29 : `serveur_debian`, `hosts_statiques`, `resoudre_base`, `resoudre_annuaire`,
@ -110,10 +63,10 @@ Ce que je re-découvre sinon. **Consulter avant de concevoir un nouveau mécanis
`docs/dependances-groupes.yml` + `docs/couches-deploiement.yml`, et sont bel et bien
consommées par l'orchestrateur (`scripts/orchestrer.py` → `playbooks/site.yml`).
## 4. Discipline (pour ne plus re-déterrer)
## Discipline
Avant de concevoir ou d'ajouter un mécanisme :
1. lire **cette carte** + le doc du sujet ;
1. lire **cette page**, l'index (`docs/README.md`) et le document du sujet ;
2. **arpenter le code** (`grep`) et **lire les README des rôles** concernés ;
3. **éprouver l'outil AVANT d'écrire le rôle** qui l'enveloppe — une machine jetable hors
plan se fabrique en deux minutes (`make cloner-vm`, cf. `vm-lifecycle.md` §4bis). C'est

2
docs/meta-classe.md → docs/conception/meta-classe.md
View file

@ -7,7 +7,7 @@ Set-OPS se comporte comme une **méta-classe** : on n'écrit pas onze serveurs,
engendre la flotte entière, cohérente. Le réseau, la taille des VM, les groupes, les
liens de bases (DSN) et l'exposition DNS sont **dérivés** — jamais saisis deux fois.
> Concept acté dans [`positionnement.md`](positionnement.md) : « la définition
> Concept acté dans [`positionnement.md`](../projet/positionnement.md) : « la définition
> instancie toute la flotte ». La dérivation des ressources est décrite dans
> [`dimensionnement-ressources.md`](dimensionnement-ressources.md).

2
docs/metriques-conception.md → docs/conception/metriques-conception.md
View file

@ -18,7 +18,7 @@ des données différentes, pour des consommateurs différents.
| `supervision.yml` | une **sonde** qui rend un verdict avec un TTL | *est-ce cassé ?* | Icinga |
| `metriques.yml` | un **exportateur** qui expose une série | *depuis quand, et vers où ?* | Prometheus → Grafana |
Ce n'est pas une frontière inventée pour l'occasion. `docs/supervision-conception.md` la
Ce n'est pas une frontière inventée pour l'occasion. `docs/conception/supervision-conception.md` la
pose déjà dans l'autre sens :
> Une **métrique à seuil** — durée de collecte, volume de journaux, taux d'occupation —

8
docs/multi-instances.md → docs/conception/multi-instances.md
View file

@ -129,7 +129,7 @@ sable met `false` et affiche « bac à sable ».
2. Régler l'identité (`10-intrants.yml` : domaine **distinct**), le réseau
(`nomenclature.yml` : **`index` distinct** — tout l'adressage en dérive, cf. plus bas)
et la cible Proxmox (`proxmox.yml`).
3. Créer la voûte unique depuis le gabarit (cf. [`config-proxmox.md`](config-proxmox.md)) :
3. Créer la voûte unique depuis le gabarit (cf. [`config-proxmox.md`](../exploitation/config-proxmox.md)) :
`cp exemples/vault.exemple.yml …/group_vars/all/vault.yml` puis `ansible-vault encrypt`.
**Et poser SA clé** — une voûte, une clé : `~/.config/setops-vault-ops-clientx`, nom
dérivé du dossier en minuscules. `python3 scripts/voutes.py etat` confirme que le moteur
@ -146,7 +146,7 @@ moteur, isolé. C'est la base concrète de la **portabilité des tenants**.
> Garde-fou de positionnement : si le nombre d'instances explose, le besoin d'un
> **registre** (lister/choisir, IPAM, secrets centralisés) relève d'outils établis
> (NetBox, AWX, un coffre type Vault HashiCorp) **à adopter aux seuils**, pas à
> réimplémenter dans le moteur. Cf. [`positionnement.md`](positionnement.md).
> réimplémenter dans le moteur. Cf. [`positionnement.md`](../projet/positionnement.md).
## Adressage fédéré : tout dérive du seed `index`
@ -184,9 +184,9 @@ site. Le décalage de +10, retiré le 2026-08-12, confisquait dix valeurs — et
empêchait de lire l'index directement dans l'adresse. Le VLAN (≤ 4094) autoriserait
jusqu'à 308, le VMID bien plus : c'est donc l'adressage IP qui plafonne. Au-delà d'une poignée d'instances
co-localisées, confier l'allocation à un **IPAM** (NetBox) plutôt qu'au moteur — cf.
[`positionnement.md`](positionnement.md).
[`positionnement.md`](../projet/positionnement.md).
## Voir aussi
- [`meta-classe.md`](meta-classe.md) — le plan d'une instance instancie sa flotte.
- [`config-proxmox.md`](config-proxmox.md) — voûte unique + cible Proxmox par instance.
- [`config-proxmox.md`](../exploitation/config-proxmox.md) — voûte unique + cible Proxmox par instance.
- [`intrants-communs.md`](intrants-communs.md) — intrants de base d'une instance.

0
docs/nomenclature-vm.md → docs/conception/nomenclature-vm.md
View file

2
docs/plan-et-generation.md → docs/conception/plan-et-generation.md
View file

@ -61,7 +61,7 @@ propriété des *rôles*, la même pour toutes les instances.
- **Nommage/adressage** : tout part du seed `index` et de la `fonction` de l'hôte.
`supernet = 10.<index>.0.0/16`, `zone = 10.<index>.(15+catégorie)`,
`VLAN = 1000 + index×10 + zone`, `VMID = <VLAN><octet-hôte><rang>` — neuf chiffres,
miroir de l'IP. Voir `docs/nomenclature-vm.md`. *(Les formules à cinq chiffres et le
miroir de l'IP. Voir `docs/conception/nomenclature-vm.md`. *(Les formules à cinq chiffres et le
réseau unique `10.0.x` qui figuraient ici décrivaient le modèle d'avant le
multi-instance.)*
- **DSN** (lien application↔base) : `<type>://<proprietaire>:<secret>@<hôte>:<port>/<base>`.

0
docs/registre-flux.md → docs/conception/registre-flux.md
View file

2
docs/schemas-flux.md → docs/conception/schemas-flux.md
View file

@ -11,7 +11,7 @@ que personne ne devine, et elle vieillira sans que quiconque s'en aperçoive.
La série des flux, elle, obéit à une règle propre : ces pages expliquent **comment les
choses sont configurées et interconnectées**. Ce ne sont pas des comptes rendus — elles ne
relatent aucun incident, ne datent aucune panne et ne comptent aucune machine tombée. Ce
travail-là appartient au `CHANGELOG.md` et à `docs/decisions-architecture.md`. Une page de
travail-là appartient au `CHANGELOG.md` et à `docs/projet/decisions-architecture.md`. Une page de
cette série répond à une seule question : *par où passe telle chose, et pourquoi par là*.
## La série

4
docs/sdn-evpn.md → docs/conception/sdn-evpn.md
View file

@ -3,7 +3,7 @@
> **Pour qui :** le **mainteneur** du réseau overlay.
> **Décision d'architecture du 2026-08-02.** Elle remplace le routage inter-zone sur les
> commutateurs L3 par des zones EVPN de Proxmox SDN. Complète `docs/frontiere-opnsense.md`
> commutateurs L3 par des zones EVPN de Proxmox SDN. Complète `docs/conception/frontiere-opnsense.md`
> (la bordure, inchangée) et `underlay.yml.example` (la fabric, très allégée).
>
> **Décidé le 2026-08-03** : une zone EVPN **par tenant** ; le routage **et le filtrage**
@ -220,4 +220,4 @@ l'interface étiquetée dédiée retenue.
`voisins_site` (2026-08-24), né du besoin de chaîner les caches d'artefacts. Cf. §3.
- **La migration depuis l'existant** : le tenant Chezlepro tourne déjà sur des VLAN. Passer à
EVPN est un changement de plan de transport pour des VM en service — la recette de
`docs/migration-tenant.md` s'applique-t-elle, ou faut-il un chemin plus court ?
`docs/hebergement/migration-tenant.md` s'applique-t-elle, ou faut-il un chemin plus court ?

0
docs/supervision-conception.md → docs/conception/supervision-conception.md
View file

0
docs/acces-administration.md → docs/exploitation/acces-administration.md
View file

2
docs/autorisation.md → docs/exploitation/autorisation.md
View file

@ -405,7 +405,7 @@ en fonctionnement. L'état réel :
| Les `meta/acces.yml` | **écrits pour les cinq services `web-sso`** : `serveur_forgejo`, `serveur_grafana`, `serveur_icingaweb2`, `serveur_keycloak`, `serveur_nextcloud` |
| La preuve | **écrite le 2026-09-07 — c'est P58** |
Le §5 de [`authentification.md`](authentification.md) formule la règle : *une directive
Le §5 de [`authentification.md`](../conception/authentification.md) formule la règle : *une directive
qu'aucune garde ne vérifie finit par ne plus être vraie*. `meta/acces.yml` a été dans ce cas
jusqu'au 2026-09-07 : rien ne vérifiait qu'un service `web-sso` en porte un. **P29** gardait
les *positions* d'authentification ; **P58** garde désormais les *habilitations*.

8
docs/config-proxmox.md → docs/exploitation/config-proxmox.md
View file

@ -22,7 +22,7 @@ la connexion au cluster Proxmox et les valeurs de clonage par défaut. Il pose
sans tout retaper.
> Ces paramètres sont des **intrants communs** de l'écosystème (cf.
> [`intrants-communs.md`](intrants-communs.md) §C). L'accès au cluster et le golden
> [`intrants-communs.md`](../conception/intrants-communs.md) §C). L'accès au cluster et le golden
> template sont des **constantes** ; le placement par défaut est **surchargeable
> par hôte** dans `instance/plan/serveurs.yml`.
@ -77,7 +77,7 @@ par écosystème — fini les voûtes éparpillées.
> et le `Makefile` les rassemble dans `ANSIBLE_VAULT_IDENTITY_LIST` via
> `scripts/voutes.py`. Créer une VM ouvre d'ailleurs **deux** voûtes dans la même
> exécution : celle du tenant, et celle de l'hébergeur qui détient le jeton Proxmox. Gabarit committé :
[`exemples/vault.exemple.yml`](../exemples/vault.exemple.yml) (les deux clés du token
[`exemples/vault.exemple.yml`](../../exemples/vault.exemple.yml) (les deux clés du token
Proxmox + **15 clés `vault_*`** pour PKI, LDAP/SSO, bases, forge, observabilité).
L'assistant demande « Configurer la voûte de secrets maintenant ». Si `oui` :
@ -159,7 +159,7 @@ Dans l'interface Proxmox (ou en CLI `pveum`) :
## Voir aussi
- [`intrants-communs.md`](intrants-communs.md) — tous les intrants communs de l'écosystème.
- [`nomenclature-vm.md`](nomenclature-vm.md) — réseau, VLAN, fonctions.
- [`intrants-communs.md`](../conception/intrants-communs.md) — tous les intrants communs de l'écosystème.
- [`nomenclature-vm.md`](../conception/nomenclature-vm.md) — réseau, VLAN, fonctions.
- [`vm-lifecycle.md`](vm-lifecycle.md) — cycle de vie d'une VM (création → conformité).
- `make` — liste des cibles (l'aide est la cible par défaut).

2
docs/devis-services.md → docs/exploitation/devis-services.md
View file

@ -137,7 +137,7 @@ Reste un écart de nature différente, et le devis le nomme comme tel : *livré
livré* = la bordure autorise et l'hôte refuse. Rien ne fuit, mais les deux couches ne
déclarent pas la même politique — et une politique qu'on ne peut plus lire est une politique
qu'on ne tient plus. C'est ce qui a fait naître le mot-clé `poste: false` dans
`meta/flux.yml` (voir [`frontiere-opnsense.md`](frontiere-opnsense.md)).
`meta/flux.yml` (voir [`frontiere-opnsense.md`](../conception/frontiere-opnsense.md)).
## Le devis des expositions

6
docs/modeles_vm/debian13-proxmox.md → docs/exploitation/gabarit-debian13-justification.md
View file

@ -13,7 +13,7 @@ Le template doit rester un socle commun, clonable et sécuritaire. Il ne doit pa
L'état de départ attendu est décrit dans :
```text
docs/procedure-template-debian13-proxmox.md
docs/exploitation/procedure-template-debian13-proxmox.md
```
Résumé :
@ -326,11 +326,11 @@ clés privées
Les intégrations futures sont documentées dans :
```text
docs/integrations-vm.md
docs/conception/integrations-vm.md
```
Le cycle complet VM vanille, golden template, clone et conformité continue est documenté dans :
```text
docs/vm-lifecycle.md
docs/exploitation/vm-lifecycle.md
```

2
docs/procedure-template-debian13-proxmox.md → docs/exploitation/procedure-template-debian13-proxmox.md
View file

@ -13,7 +13,7 @@ Ce document s’arrête au point de bascule vers le `Makefile`.
Les ajouts appliqués ensuite par Ansible, leur validation et leur justification sont documentés dans :
```text
docs/modeles_vm/debian13-proxmox.md
docs/exploitation/gabarit-debian13-justification.md
```
---

2
docs/runbooks-exploitation.md → docs/exploitation/runbooks-exploitation.md
View file

@ -58,7 +58,7 @@ Mapping (défaut du rôle grafana) : `grafana-admin`→Admin, `grafana-editor`
> `personnel ⇒ Viewer`. Ajouter quelqu'un au **groupe** lui ouvre Grafana, Forgejo, Icinga et
> le courriel d'un seul geste — alors qu'une assignation nominative crée une dette qu'on
> découvre le jour du départ, service par service. L'assignation explicite ci-dessus reste
> le geste de dépannage, pas la façon normale d'accorder un accès. Voir `docs/autorisation.md` §5.
> le geste de dépannage, pas la façon normale d'accorder un accès. Voir `docs/exploitation/autorisation.md` §5.
---

0
docs/sortir-les-cles-du-poste.md → docs/exploitation/sortir-les-cles-du-poste.md
View file

0
docs/theme-forgejo-hors-flotte.md → docs/exploitation/theme-forgejo-hors-flotte.md
View file

4
docs/vm-lifecycle.md → docs/exploitation/vm-lifecycle.md
View file

@ -63,7 +63,7 @@ nftables préparé mais désactivé
Les détails et justifications sont dans :
```text
docs/modeles_vm/debian13-proxmox.md
docs/exploitation/gabarit-debian13-justification.md
```
## 3. Validation et cleanup
@ -249,5 +249,5 @@ visualisation
Elles sont documentées dans :
```text
docs/integrations-vm.md
docs/conception/integrations-vm.md
```

0
docs/hebergeur-exploitation.md → docs/hebergement/hebergeur-exploitation.md
View file

10
docs/implanter-un-tenant-sur-un-site.md → docs/hebergement/implanter-un-tenant-sur-un-site.md
View file

@ -36,7 +36,7 @@ par une **commande qui interroge le système**, jamais par une conviction.
- [ ] **Créer le dépôt de l'hébergeur** — un dossier frère, avec deux fichiers :
`underlay.yml` et `proxmox-hebergeur.yml` (squelettes en annexe).
- [ ] **Emporter le gabarit** `modeleSetOPS` sur disque (`vzdump`), *et* la procédure de
fabrication en repli : [`procedure-template-debian13-proxmox.md`](procedure-template-debian13-proxmox.md).
fabrication en repli : [`procedure-template-debian13-proxmox.md`](../exploitation/procedure-template-debian13-proxmox.md).
- [ ] **Préparer la voûte** de l'instance à recevoir les deux paires de secrets
(hyperviseur, frontière). Jamais dans un dépôt git, jamais dans une conversation.
- [ ] **Vérifier la version de Proxmox.** Tout ce dépôt a été éprouvé sur PVE 8. Sur PVE 9,
@ -174,7 +174,7 @@ make frontiere-plan make sdn-plan make placement-plan
- [ ] **La sauvegarde emporte-t-elle quelque chose ?** Compter les fichiers, pas les
succès. Une sauvegarde verte sur zéro fichier a tenu six semaines ici.
- [ ] **Éprouver une restauration** — [`runbooks-exploitation.md`](runbooks-exploitation.md) §5.
- [ ] **Éprouver une restauration** — [`runbooks-exploitation.md`](../exploitation/runbooks-exploitation.md) §5.
Une sauvegarde jamais restaurée n'est pas une sauvegarde.
- [ ] **La supervision voit-elle l'unité de sauvegarde ?** Sans
`vault_icinga_api_depot`, personne ne surveille les sauvegardes — et rien ne le dit.
@ -267,6 +267,6 @@ grosses meurent, et rien n'est signalé. `make mtu-mesurer` tranche.
- [`preparer-un-site-hebergeur.md`](preparer-un-site-hebergeur.md) — ce que l'hébergeur prépare.
- [`migration-tenant.md`](migration-tenant.md) — déplacer un tenant **vivant**.
- [`multi-instances.md`](multi-instances.md) — un moteur, N écosystèmes.
- [`sdn-evpn.md`](sdn-evpn.md) — pourquoi une zone EVPN par tenant.
- [`decisions-architecture.md`](decisions-architecture.md) — D-71 (PKI/DNS d'abord), D-77, D-78, D-80.
- [`multi-instances.md`](../conception/multi-instances.md) — un moteur, N écosystèmes.
- [`sdn-evpn.md`](../conception/sdn-evpn.md) — pourquoi une zone EVPN par tenant.
- [`decisions-architecture.md`](../projet/decisions-architecture.md) — D-71 (PKI/DNS d'abord), D-77, D-78, D-80.

4
docs/migration-tenant.md → docs/hebergement/migration-tenant.md
View file

@ -4,8 +4,8 @@
> **Recette d'exploitation.** Elle décrit la séquence, les états et les gardes ; elle ne
> décrit pas encore un outil, parce que la séquence doit être éprouvée avant d'être figée
> dans du code. Complète `docs/multi-instances.md` (la fédération) et
> `docs/frontiere-opnsense.md` §2 (qui possède quoi).
> dans du code. Complète `docs/conception/multi-instances.md` (la fédération) et
> `docs/conception/frontiere-opnsense.md` §2 (qui possède quoi).
## 1. Pourquoi ce document existe

10
docs/preparer-un-site-hebergeur.md → docs/hebergement/preparer-un-site-hebergeur.md
View file

@ -169,7 +169,7 @@ un artefact du **moteur**, pas d'un tenant. Une VM Debian minimale avec
> C'est arrivé, et il a fallu recapturer le gabarit puis reconstruire pour s'en défaire.
En cas de doute, laisser l'exploitant le fabriquer : c'est une demi-heure, et la procédure
est écrite (`docs/procedure-template-debian13-proxmox.md`).
est écrite (`docs/exploitation/procedure-template-debian13-proxmox.md`).
## 7. Ce que l'exploitant doit recevoir
@ -252,7 +252,7 @@ réseaux **défait en silence l'isolation inter-tenant**. WireGuard s'y prête b
## Voir aussi
- [`sdn-evpn.md`](sdn-evpn.md) — pourquoi une zone EVPN par tenant.
- [`config-proxmox.md`](config-proxmox.md) — les intrants côté hyperviseur, et le token.
- [`frontiere-opnsense.md`](frontiere-opnsense.md) — la frontière, hors flotte Ansible.
- [`procedure-template-debian13-proxmox.md`](procedure-template-debian13-proxmox.md) — fabriquer `modeleSetOPS`.
- [`sdn-evpn.md`](../conception/sdn-evpn.md) — pourquoi une zone EVPN par tenant.
- [`config-proxmox.md`](../exploitation/config-proxmox.md) — les intrants côté hyperviseur, et le token.
- [`frontiere-opnsense.md`](../conception/frontiere-opnsense.md) — la frontière, hors flotte Ansible.
- [`procedure-template-debian13-proxmox.md`](../exploitation/procedure-template-debian13-proxmox.md) — fabriquer `modeleSetOPS`.

0
docs/remise-au-client.md → docs/hebergement/remise-au-client.md
View file

0
docs/responsabilites-locataire-hebergeur.md → docs/hebergement/responsabilites-locataire-hebergeur.md
View file

4
docs/MISE-A-JOUR-CODEX-CLAUDE.md → docs/projet/MISE-A-JOUR-CODEX-CLAUDE.md
View file

@ -19,8 +19,8 @@
> l'« incident récent » et son correctif. Les deux `handlers/main.yml` existent
> (`ssh_baseline`, `ssh_hardening`) depuis longtemps.
>
> **Où aller à la place** : `AGENTS.md` (autorité), `docs/carte-set-ops.md` (par où entrer
> pour modifier le moteur), `docs/catalogue-services.md` (ce qui est éprouvé et ce qui ne
> **Où aller à la place** : `AGENTS.md` (autorité), `docs/README.md` (l'index) et
> `docs/conception/mecanismes.md` (par où entrer pour modifier le moteur), `docs/projet/catalogue-services.md` (ce qui est éprouvé et ce qui ne
> l'est pas).
## État du dépôt *(juillet 2026)*

8
docs/catalogue-services.md → docs/projet/catalogue-services.md
View file

@ -15,11 +15,11 @@ rôles** de durcissement, et dans cet ordre — `hardening_packages`, `sysctl_ha
`core_dumps`, `unattended_upgrades`, `apparmor`, `auditd`, `fail2ban_ssh`, `journald`,
`ssh_hardening`, `nftables_baseline` — plutôt qu'un rôle homonyme.
La nomenclature des VM et des VMID est documentée dans `docs/nomenclature-vm.md`.
La nomenclature des VM et des VMID est documentée dans `docs/conception/nomenclature-vm.md`.
Un service central peut partager un hôte avec d'autres services de la même fonction opérationnelle (plusieurs applications par VM). La relation stricte est entre groupe et playbook, pas entre groupe et VM.
> Modèle à jour : chaque service est une **application** (`instance/plan/applications.yml`). Voir `docs/plan-et-generation.md`.
> Modèle à jour : chaque service est une **application** (`instance/plan/applications.yml`). Voir `docs/conception/plan-et-generation.md`.
## État d'implémentation des rôles
@ -227,7 +227,7 @@ L'ordre ci-dessous privilégie les dépendances structurantes avant les applicat
est une couche distincte (`serveur_resolveur` / `client_resolveur`, Unbound), et le
**plancher `/etc/hosts`** posé par `hosts_statiques` précède les deux — c'est lui qui
permet à l'écosystème de se résoudre DNS éteint. Trois couches, pas un choix de design
(`docs/dns-interne.md`).
(`docs/conception/dns-interne.md`).
- Raison : les autres intégrations auront besoin de noms stables plutôt que d'adresses IP.
2. `serveur_step_ca`
@ -325,7 +325,7 @@ Les groupes clients peuvent être ajoutés aux VM existantes quand le service ce
Les dépendances exécutables sont déclarées dans `docs/dependances-groupes.yml`.
Le runbook DNS initial est dans `docs/dns-interne.md`.
Le runbook DNS initial est dans `docs/conception/dns-interne.md`.
Ce fichier sert à deux usages :

12
docs/decisions-architecture.md → docs/projet/decisions-architecture.md
View file

@ -55,7 +55,7 @@ sont les seules vérifiables.
| # | Décision | Pourquoi | Détail | Garde |
|---|---|---|---|---|
| **D-82** | **Patient 0 n'est le parent de personne.** Il est la **mise en œuvre de référence** du modèle `origine` — le plus petit écosystème complet — et un pair de la famille du génome, pas sa racine | trois faits l'ont retiré un par un : D-81 a donné l'autorité du génome à la forge du SITE (son dernier lecteur corrigé le 2026-08-26, Technolibre le 08-31) ; le dénominateur commun vit dans les modèles depuis le 08-24 ; et **l'ancêtre était locataire de son enfant** — index 29 sur la fabric de `SITE-Chezlepro`, qui descend de lui. `eregion` (`forge.alliance-boreale.ca`) n'est PAS sur le chemin du génome : le poste porte les commits en bundle au runner du site (`make genome-pousser`), qui pousse sur sa forge. `eregion` est une forge héritée, porte publique des contributions, qui ne fera jamais partie de Set-OPS — la redondance vient d'une forge par site, chacune inséminée du génome *(corrigé le 2026-09-28 : cette ligne l'avait dite « SPOF promu », sans mesurer le chemin)* | `OPS-Patient0/README.md`, `docs/filiation-emancipation.md` | — |
| **D-82** | **Patient 0 n'est le parent de personne.** Il est la **mise en œuvre de référence** du modèle `origine` — le plus petit écosystème complet — et un pair de la famille du génome, pas sa racine | trois faits l'ont retiré un par un : D-81 a donné l'autorité du génome à la forge du SITE (son dernier lecteur corrigé le 2026-08-26, Technolibre le 08-31) ; le dénominateur commun vit dans les modèles depuis le 08-24 ; et **l'ancêtre était locataire de son enfant** — index 29 sur la fabric de `SITE-Chezlepro`, qui descend de lui. `eregion` (`forge.alliance-boreale.ca`) n'est PAS sur le chemin du génome : le poste porte les commits en bundle au runner du site (`make genome-pousser`), qui pousse sur sa forge. `eregion` est une forge héritée, porte publique des contributions, qui ne fera jamais partie de Set-OPS — la redondance vient d'une forge par site, chacune inséminée du génome *(corrigé le 2026-09-28 : cette ligne l'avait dite « SPOF promu », sans mesurer le chemin)* | `OPS-Patient0/README.md`, `docs/conception/filiation-emancipation.md` | — |
| **D-83** | **Patient 0 a été retiré** — ses machines n'existent plus (constaté le 2026-09-06) | D-82 lui avait laissé une raison d'être : la mise en œuvre de référence du modèle `origine`, et un **témoin** de plus du génome. Le retrait solde les deux : l'une vit dans le modèle `origine`, l'autre revient aux forges de site. **Son plan a été effacé le 2026-09-27** : l'index 29 est libéré, et le site n'ouvre plus rien à `10.29.0.0/16` | `SITE-Chezlepro/underlay.yml` (`tenants`), `SITE-Chezlepro/flux-genere/` | **P21** (index), **P23** |
| **D-84** | **Le plan de contrôle reste gelé — c'est la CARTE DES SEUILS qui était fausse** | La question « et si on retirait le gel ? » a mis à l'épreuve les cinq seuils de `positionnement.md`, et deux ne tenaient pas. **RBAC** : couvert depuis que trois classes d'acteurs aux pouvoirs disjoints existent — poste, runner de site, runners de tenant — séparés **cryptographiquement** (une voûte, une clé, 2026-08-28) et non par une table de permissions qu'une faille applicative contournerait ; adopter AWX pour ce besoin serait **régresser**. **IPAM** : sans objet par construction — rien ne s'alloue, tout dérive du seed, et P20/P21/P23/P28/P33 tiennent déjà ce qu'un IPAM vérifierait *a posteriori*. Les deux lignes sont retirées du tableau : les garder aurait fait adopter un outil pour un besoin déjà rempli. **Et un seuil manquait** — l'**émancipation** : le GUI est mono-utilisateur (`127.0.0.1` + jeton), or la trajectoire mène à plusieurs humains aux portées disjointes, sur des machines qui ne sont pas les nôtres. Ce seuil n'appelle pas AWX, il appelle une décision non prise. *Un seuil qu'on ne nomme pas est un seuil qu'on franchit sans le voir.* Corollaire consigné : le gel porte sur les **fonctions**, jamais sur les **vues** — montrer à l'écran ce que le moteur sait déjà ne franchit aucun seuil | `positionnement.md` §3, §4, §5 | — |
| **D-85** | **cloud-init naît avec la VM et ne lui survit pas** | cloud-init n'est pas un logiciel d'installation : c'est une **source de vérité externe**, qui se réveille à *chaque* démarrage et relit le lecteur attaché par l'hyperviseur — lequel peut redéfinir comptes, clés SSH autorisées, mots de passe et réseau. Sur une machine que le plan possède, c'est un **second maître** : le plan ne le décrit pas, `make valider` ne le mesure pas, et il parle en premier. Sa tâche est pourtant finie à la première seconde — c'est parce qu'il a **réussi** à poser l'adresse et les clés qu'Ansible a pu entrer. **Trois moitiés, qui se défont séparément** : le **gabarit** le garde (sans lui un clone ne naît pas — P56) ; le **socle** ne l'installe plus (le garder produisait un va-et-vient à chaque déploiement : le socle installe, le durcissement retire, deux `changed` par passage) ; le **durcissement** le retire (`cloud_init_retrait`, en dernier). **Ce qui rend le retrait sûr est mesuré, pas supposé** (2026-09-09, `obs-01`) : `/etc/network/interfaces.d/50-cloud-init` n'appartient à aucun paquet — `dpkg -S` ne le trouve pas — et le `postrm` ne le nomme jamais, même en `purge`. L'adresse survit. Le rôle le **vérifie** malgré tout, avant et après : une VM qui perd ce fichier ne se plaint pas, elle repart sans adresse et plus personne ne peut entrer pour le constater. **⚠ CE QUE CETTE DÉCISION NE FERME PAS — et il faut le dire, sinon elle se lit comme une émancipation qu'elle n'est pas.** Retirer cloud-init **n'ôte aucun pouvoir à l'hébergeur**. `qemu-guest-agent` est au gabarit (P56 : il doit y être — c'est par lui que `creer-vm` confirme la matérialisation sans entrer chez le tenant), et l'API Proxmox expose sur son dos, sur toute VM vivante de la flotte, un pouvoir **strictement plus grand** que le lecteur cloud-init : `exec`, `file-write`, `file-read`, `set-user-password`, `shutdown` (relevé le 2026-09-09 sur `edge-mta-01`, jeton d'API du site). Ce que D-85 ferme est donc **précis et étroit** : (a) une réapplication **automatique, à chaque démarrage**, depuis un support que le plan ne possède pas et qu'aucune preuve ne lit ; (b) le code de cloud-init lui-même — un interpréteur Python complet, exécuté en root au démarrage, et ses ~29 dépendances. Elle ne ferme **pas** la mainmise de l'hyperviseur sur ses invités : celle-là est une propriété de la virtualisation, pas de cloud-init, et elle appelle sa propre décision — non prise. **Le seuil où le remplacer deviendrait juste** : le jour où une première seconde ne peut plus être amorcée par Proxmox (autre hyperviseur, métal nu, hébergeur sans API), le chemin par l'agent invite cesse d'être une réimplémentation d'un standard — que `positionnement.md` interdit — et devient **le chemin portable**. Tant que ce seuil n'est pas atteint, écrire soi-même l'amorçage serait échanger un standard éprouvé contre du code maison au moment le plus fragile, dont le mode de panne est le pire : une VM injoignable | `roles/cloud_init_retrait/`, `serveur_durci.yml`, `positionnement.md` | **P63** |
@ -121,14 +121,14 @@ sont les seules vérifiables.
| **D-73** | Tout port **lié** se déclare, et deux rôles co-localisés ne peuvent pas revendiquer le même | un port n'appartient à personne : le premier démarré le prend, l'autre échoue — parfois **en silence**. Sur `infra-mail-01`, le SASL de Dovecot et l'interface d'Alloy se disputaient le 12345 depuis le premier jour, et c'est Dovecot qui perdait sans que rien ne le dise. Le contrôle n'était possible qu'une fois le port d'Alloy — un défaut amont **subi** — déclaré. `partage: true` distingue « j'ouvre cette écoute » de « je décris celle d'un autre » | `scripts/verifier_ports.py`, `make ports-verifier` | **P33** |
| **D-70** | La documentation **dit et explique tout ce que le dépôt fait** — et l'exigence est **outillée**, pas seulement énoncée | une exigence qu'on n'outille pas pourrit en silence : la carte annonçait « 28 décisions » quand il y en avait 66, et disait les accès « non construits » alors qu'ils tournaient en production. **P31** garde le couvert — chaque script s'explique et reste atteignable, chaque cible `make` porte son aide (sauf les internes préfixées `_`), chaque rôle a son README. Elle ne garde **pas** la qualité du « pourquoi » : ça se juge en revue, et ça vit dans `CHANGELOG.md` et ici | `devis-services.md`, `CHANGELOG.md` | **P31** |
| **D-75** | Un ecart **lisible dans le plan** se prouve dans le plan, pas au deploiement | l'assert de `resoudre_base` fait son travail — mais il s'est declenche a la 92e tache de `collab-01`, apres quarante minutes, pour une application declaree sans base au registre. L'information etait entierement statique. **P35** derive les roles qui exigent une base (ceux qui incluent `resoudre_base`) et le groupe qu'ils reclament (le DEFAUT de la variable passee, jamais leur nom : `serveur_icingaweb2` reclame la base d'`serveur_icinga`). Meme raisonnement que **D-72**/P32 pour les intrants : une garde de deploiement gagne a etre doublee d'une preuve statique | `scripts/prouver.py`, `plan/bases-donnees.yml` | **P35** |
| **D-74** | **Chaque document déclare son lecteur** en tête — un lecteur et sa situation, pas une catégorie de sujet | la documentation était rangée par SUJET, ce qui est juste pour de la référence — mais personne n'arrive avec un sujet, on arrive avec une **situation**. Symptôme exact : `autorisation.md` portait le runbook de reprise le plus utile du dépôt, enfoui au §6, parce que son sujet est l'autorisation ; personne n'allait l'y chercher. Un document qui déclare son lecteur se range tout seul, et un intrus s'y voit. Deux exemptions, **dérivées et non listées** : un document qui s'annonce généré, et un fragment sans titre | `README.md`, `wiki/Reprendre-l-écosystème.md`, `docs/carte-set-ops.md` | **P34** |
| **D-74** | **Chaque document déclare son lecteur** en tête — un lecteur et sa situation, pas une catégorie de sujet | la documentation était rangée par SUJET, ce qui est juste pour de la référence — mais personne n'arrive avec un sujet, on arrive avec une **situation**. Symptôme exact : `autorisation.md` portait le runbook de reprise le plus utile du dépôt, enfoui au §6, parce que son sujet est l'autorisation ; personne n'allait l'y chercher. Un document qui déclare son lecteur se range tout seul, et un intrus s'y voit. Deux exemptions, **dérivées et non listées** : un document qui s'annonce généré, et un fragment sans titre | `docs/README.md`, `wiki/Reprendre-l-écosystème.md` | **P34** |
| **D-71** | **Une PKI et un DNS fonctionnels avant toute chose** ; puis, par VM : socle → enrôlement PKI → enregistrement DNS (A **et** PTR) | `deployer-tout` déroule par COUCHES — correct, mais chaque VM réclame alors un certificat à une autorité pas encore debout, et l'échec se lit comme un défaut du rôle et non d'ordre. Les deux hôtes d'amorçage se **dérivent** de `applications.<step_ca\|powerdns>.hote` : déplacer l'autorité déplace l'amorçage. **Deux exceptions structurelles assumées** — l'AC s'auto-signe, le DNS pose son propre enregistrement | `Makefile` `_amorcer-socle`, `scripts/socle_amorcage.py` | — |
| **D-76** | Le **gabarit doit se FABRIQUER par le dépôt**, pas se façonner à la main — décidée le 2026-08-12, **volontairement différée** après Technolibre | tout dérive d'un plan et se prouve ; le gabarit est la **seule pièce faite à la main** — 853 lignes de procédure manuelle — et il est en amont des quatorze VM. Le 2026-08-09 l'a démontré : l'ancien portait une **clé privée d'hôte SSH** et un `/etc/resolv.conf` figé, recopiés dans chaque clone, et il a fallu le recapturer. La preuve de reconstruction s'arrête donc un cran trop tôt : on reconstruit la flotte, pas ce dont elle est clonée. **Cible** : image cloud Debian officielle → signature vérifiée contre une empreinte épinglée (`verifier_signature.py`, déjà écrit) → import, réglages, conversion. **Coût honnête** : la recette doit être COMPARÉE au gabarit courant avant bascule — un réglage oublié serait hérité par les quatorze VM, et découvert loin de sa cause. **En attendant**, un gabarit se transporte d'un cluster à l'autre par `vzdump` / `qmrestore` | `docs/procedure-template-debian13-proxmox.md`, `scripts/verifier_signature.py` | — *(à construire)* |
| **D-76** | Le **gabarit doit se FABRIQUER par le dépôt**, pas se façonner à la main — décidée le 2026-08-12, **volontairement différée** après Technolibre | tout dérive d'un plan et se prouve ; le gabarit est la **seule pièce faite à la main** — 853 lignes de procédure manuelle — et il est en amont des quatorze VM. Le 2026-08-09 l'a démontré : l'ancien portait une **clé privée d'hôte SSH** et un `/etc/resolv.conf` figé, recopiés dans chaque clone, et il a fallu le recapturer. La preuve de reconstruction s'arrête donc un cran trop tôt : on reconstruit la flotte, pas ce dont elle est clonée. **Cible** : image cloud Debian officielle → signature vérifiée contre une empreinte épinglée (`verifier_signature.py`, déjà écrit) → import, réglages, conversion. **Coût honnête** : la recette doit être COMPARÉE au gabarit courant avant bascule — un réglage oublié serait hérité par les quatorze VM, et découvert loin de sa cause. **En attendant**, un gabarit se transporte d'un cluster à l'autre par `vzdump` / `qmrestore` | `docs/exploitation/procedure-template-debian13-proxmox.md`, `scripts/verifier_signature.py` | — *(à construire)* |
| **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.<index>.0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168.<vlan>.0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10.<index>.(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/preparer-un-site-hebergeur.md` | **P23** |
| **D-77** | **L'underlay d'un site dérive du même `index` que son tenant**, dans la **bande basse** `10.<index>.0–15.x` ; les réseaux de **stockage** en sortent et sont **identiques partout**, en `192.168.<vlan>.0/24` | tant qu'il n'existait qu'un site, `10.0.x.x` suffisait. Deux sites qui doivent se joindre — reprise mutuelle, sauvegardes croisées, exploitation à distance — **ne peuvent pas** porter les mêmes plages : chaque routeur croit que le réseau est chez lui. Un « numéro de site » a d'abord été proposé : **rejeté**, c'était un SECOND SEED à tenir et à synchroniser, alors que tout dérive déjà d'`index` (D-17). La bande basse est sûre **par la règle, pas par chance** : les zones valent `10.<index>.(15+categorie).0/24`, donc troisième octet ≥ 16 — les octets 0 à 15 ne sont jamais alloués. Les troisièmes et derniers octets de l'underlay actuel sont ainsi **préservés** : seul le deuxième change, et l'invariant `.1` (D-04) survit intact. Le **stockage** en est sorti parce qu'il est jumbo, non routé, et ne quitte jamais son site : il n'a aucun besoin d'être unique, et l'aligner sur le VLAN (`192.168.20.x` ↔ VLAN 20) fait dire son VLAN à l'adresse. Contrepartie assumée : ces réseaux ne pourront jamais traverser un lien inter-sites — sans conséquence, puisque ce qui voyage entre deux sites est l'**état**, par le dépôt de sauvegarde, pas le stockage bloc | `underlay.yml` (`index`), `scripts/underlay.py`, `docs/hebergement/preparer-un-site-hebergeur.md` | **P23** |
| **D-80** | **Un tenant est agnostique de son underlay.** Les deux symlinks composent deux axes INDEPENDANTS : `instance` designe le tenant, `underlay.yml` la fabric qui l'accueille. Seule exception : une **liaison de placement** de trois cles vivantes | le commentaire disait « la fabric reste celle de l'hebergeur, quel que soit le tenant actif » — vrai, mais centre sur l'hebergeur. Le cadrage juste est centre sur le TENANT : tout son adressage derive du seed `index`, donc son plan se deplace d'une fabric a l'autre **sans y toucher**. Ce qui ne se deplace pas, c'est le **placement** : `proxmox_clone_noeud`, `_stockage` et le gabarit `_vmid_modele` — trois valeurs cote tenant, parce que c'est lui qui choisit ou se poser, mais qui NOMMENT des objets de l'hebergeur. Trois, pas trente : c'est ce qui separe « portable » de « theoriquement portable ». **Le PONT n'en fait pas partie** (mesure le 2026-08-13) : `instancier` pose `proxmox_pont` par hote, derive du VNet de sa zone. `proxmox_clone_pont` n'est qu'un REPLI pour un clone manuel hors flotte — d'ou son intitule dans le GUI, et d'ou le fait que `vmbr3` ait pu y rester faux dix jours | `underlay.py`, `inventories/*/group_vars/proxmox.yml`, `proxmox-hebergeur.yml` | **P37** |
| **D-79** | Le filtrage que l'hyperviseur applique aux VM tourne encore sur **iptables *legacy***. Le passer à `proxmox-firewall` (nftables natif) est une **dette à rembourser**, pas une option — et c'est le même geste qui rend le **pare-feu de VNet** opérant. Décidée le 2026-08-12, **différée après la reconstruction** | mesuré sur `asgard` : `iptables v1.8.9 (legacy)` — pas `(nf_tables)` ; `nftables v1.0.6` installé mais inutilisé par Proxmox ; `proxmox-firewall 0.7.1` **installé et absent des services en cours** ; seul `pve-firewall 5.1.3` tourne. Le pare-feu de VNet est **entièrement expressif** (`type/action/proto/source/dest/dport`, et `policy_forward` ∈ `ACCEPT,DROP` — donc un vrai default-deny inter-zone) : une règle d'essai a été créée, relue, puis retirée. **Mais il n'est implémenté QUE par le moteur nftables** : posée aujourd'hui, une règle serait acceptée, stockée, visible dans l'interface, et n'appliquerait rien. Trois gains dans le même geste — le moteur rejoint la doctrine (« tout est nftables »), le pare-feu de VNet devient réel, et ses règles **survivent à la reconstruction** là où les groupes par VM doivent être ré-attachés à chaque cycle | `devis_proxmox_fw.py`, `docs/sdn-evpn.md` | P25 *(sur le mécanisme actuel)* |
| **D-79** | Le filtrage que l'hyperviseur applique aux VM tourne encore sur **iptables *legacy***. Le passer à `proxmox-firewall` (nftables natif) est une **dette à rembourser**, pas une option — et c'est le même geste qui rend le **pare-feu de VNet** opérant. Décidée le 2026-08-12, **différée après la reconstruction** | mesuré sur `asgard` : `iptables v1.8.9 (legacy)` — pas `(nf_tables)` ; `nftables v1.0.6` installé mais inutilisé par Proxmox ; `proxmox-firewall 0.7.1` **installé et absent des services en cours** ; seul `pve-firewall 5.1.3` tourne. Le pare-feu de VNet est **entièrement expressif** (`type/action/proto/source/dest/dport`, et `policy_forward` ∈ `ACCEPT,DROP` — donc un vrai default-deny inter-zone) : une règle d'essai a été créée, relue, puis retirée. **Mais il n'est implémenté QUE par le moteur nftables** : posée aujourd'hui, une règle serait acceptée, stockée, visible dans l'interface, et n'appliquerait rien. Trois gains dans le même geste — le moteur rejoint la doctrine (« tout est nftables »), le pare-feu de VNet devient réel, et ses règles **survivent à la reconstruction** là où les groupes par VM doivent être ré-attachés à chaque cycle | `devis_proxmox_fw.py`, `docs/conception/sdn-evpn.md` | P25 *(sur le mécanisme actuel)* |
> **Ce qui n'a PAS été établi, et qu'il faudra éprouver.** `nft list tables` exige root et le
> compte `ansible` ne l'a pas sur les hyperviseurs : **le jeu de règles réellement chargé n'a
@ -147,7 +147,7 @@ sont les seules vérifiables.
> filtrage par VM tient toujours, puis poser un `policy_forward: DROP` sur un VNet et
> **prouver qu'il bloque, avec son contrôle négatif**.
| **D-78** | Un réseau d'underlay est soit une **destination**, soit un **chemin**. Les destinations gardent l'adressage dérivé (`10.<index>.0–15.x`) ; les chemins sortent de cet espace en **`192.168.<vlan>.0/24`, identiques à tous les sites** — décidée le 2026-08-12, **appliquée au déplacement physique** | D-77 sortait déjà le stockage, mais par une exception nommée plutôt que par une règle. Le critère n'est pas « y a-t-il des VM dedans » — le VLAN de gestion n'en a pas non plus — c'est : **ce réseau est-il jamais une destination, ou seulement un chemin ?** Transit (40) : rien que des prochains sauts, deux extrémités adjacentes en L2. Transport VXLAN (**VLAN 50**) : VTEP ↔ VTEP, destination de rien. Stockage (20/30/31) : baie ↔ hyperviseurs. **Gestion (10) : le poste de l'exploitant, un VPN, demain le lien inter-sites doivent l'atteindre** — elle reste dérivée et unique. Effet : sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs, et « unique » redevient signifiant — seul ce qui doit l'être l'est | `underlay.yml`, `docs/preparer-un-site-hebergeur.md` | P23 *(la borne de bande basse ne s'applique qu'aux destinations)* |
| **D-78** | Un réseau d'underlay est soit une **destination**, soit un **chemin**. Les destinations gardent l'adressage dérivé (`10.<index>.0–15.x`) ; les chemins sortent de cet espace en **`192.168.<vlan>.0/24`, identiques à tous les sites** — décidée le 2026-08-12, **appliquée au déplacement physique** | D-77 sortait déjà le stockage, mais par une exception nommée plutôt que par une règle. Le critère n'est pas « y a-t-il des VM dedans » — le VLAN de gestion n'en a pas non plus — c'est : **ce réseau est-il jamais une destination, ou seulement un chemin ?** Transit (40) : rien que des prochains sauts, deux extrémités adjacentes en L2. Transport VXLAN (**VLAN 50**) : VTEP ↔ VTEP, destination de rien. Stockage (20/30/31) : baie ↔ hyperviseurs. **Gestion (10) : le poste de l'exploitant, un VPN, demain le lien inter-sites doivent l'atteindre** — elle reste dérivée et unique. Effet : sur six réseaux, **cinq** cessent d'exiger la moindre coordination entre deux hébergeurs, et « unique » redevient signifiant — seul ce qui doit l'être l'est | `underlay.yml`, `docs/hebergement/preparer-un-site-hebergeur.md` | P23 *(la borne de bande basse ne s'applique qu'aux destinations)* |
> **Ce que D-78 coûte, et ce qui la renverserait.** Le jour où l'un de ces liens devrait
> **franchir un site**, il redeviendrait une destination et exigerait une adresse unique.

4
docs/ecosysteme-chezlepro.md → docs/projet/ecosysteme-chezlepro.md
View file

@ -74,7 +74,7 @@ objet fragile patiemment bricolé — c'est un artefact reproductible.
> Ce qui reste honnête à dire : la reconstruction prouve qu'un plan mène des machines nues à
> l'état voulu. Elle ne dit rien de la tenue d'un service **sous charge**, ni de sa mise à
> jour dans la durée — deux questions distinctes, et non traitées ici. Le degré de maturité,
> service par service, est tenu à jour dans `docs/catalogue-services.md`, et nous ne
> service par service, est tenu à jour dans `docs/projet/catalogue-services.md`, et nous ne
> présentons jamais comme « en production » un service que ce tableau ne donne pas pour tel.
---
@ -161,4 +161,4 @@ Trois principes résument la posture de Chezlepro :
---
*Détails techniques et runbooks : voir `AGENTS.md` (autorité du dépôt),
`docs/catalogue-services.md`, `docs/plan-et-generation.md`, `docs/positionnement.md`.*
`docs/projet/catalogue-services.md`, `docs/conception/plan-et-generation.md`, `docs/projet/positionnement.md`.*

27
docs/positionnement.md → docs/projet/positionnement.md
View file

@ -116,7 +116,7 @@ couverts (§3), et les garder ici aurait fait adopter un outil pour un besoin d
**L'émancipation.** Le GUI écoute sur `127.0.0.1` avec un jeton par session : un modèle
**mono-utilisateur**, parfait tant que l'exploitant est une personne à son poste. Le jour où
un tenant est exploité par **son** organisation — c'est la trajectoire de
[`filiation-emancipation.md`](filiation-emancipation.md), et l'offre destinée aux OBNL y
[`filiation-emancipation.md`](../conception/filiation-emancipation.md), et l'offre destinée aux OBNL y
mène — il y a plusieurs humains, aux portées disjointes, sur des machines qui ne sont pas
les tiennes.
@ -148,3 +148,28 @@ autrement** — c'est exactement l'erreur que ce tableau portait.
> le périmètre sur lequel un ✅ a porté, les témoins du génome et lequel a décroché — ne
> franchit aucun seuil : rien de tout cela n'existe dans NetBox ou AWX, parce que rien de
> tout cela n'existe hors de ce modèle.
## 6. Licence et modèle
> Déplacé du `README.md` le 2026-10-15 : le README ne garde que le rôle du projet et le
> démarrage rapide. Le texte de la licence fait foi dans `LICENSE`.
### 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).

0
docs/pouvoirs-set-ops.md → docs/projet/pouvoirs-set-ops.md
View file

34
docs/runbooks-construction.yml
View file

@ -5,8 +5,8 @@
#
# Les 132 cibles documentees du Makefile disent chacune CE QU'ELLE FAIT. Aucune ne dit
# dans quel ORDRE, ni pourquoi maintenant, ni ce qu'il faut avoir mesure avant. Cette
# connaissance-la vivait en prose dans `docs/runbooks-exploitation.md`,
# `docs/implanter-un-tenant-sur-un-site.md` et `docs/preparer-un-site-hebergeur.md` — et
# connaissance-la vivait en prose dans `docs/exploitation/runbooks-exploitation.md`,
# `docs/hebergement/implanter-un-tenant-sur-un-site.md` et `docs/hebergement/preparer-un-site-hebergeur.md` — et
# la console offrait des boutons sans sequence.
#
# ON NE RECOPIE PAS LE LIBELLE D'UNE CIBLE. `scripts/runbooks.py` va le lire dans le
@ -114,7 +114,7 @@ runbooks:
- id: site-premier-jour
titre: "Le premier jour d'un site"
portee: site
doc: docs/runbooks-exploitation.md
doc: docs/exploitation/runbooks-exploitation.md
but: >-
Faire naitre un site hebergeur depuis une fabric nue : les machines, puis le moteur,
puis la forge qui permettra aux locataires de se reproduire. L'ordre n'est pas une
@ -184,7 +184,7 @@ runbooks:
- id: site-tenir
titre: "Tenir un site en etat"
portee: site
doc: docs/hebergeur-exploitation.md
doc: docs/hebergement/hebergeur-exploitation.md
but: >-
Les gestes reguliers de l'hebergeur : porter le genome a jour, appliquer un role aux
machines du site, et regarder ce que la fabric fait vraiment.
@ -288,7 +288,7 @@ runbooks:
- id: locataire-naitre
titre: "Faire naitre un ecosysteme de locataire"
portee: tenant
doc: docs/multi-instances.md
doc: docs/conception/multi-instances.md
but: >-
Du modele au plan monte : creer le dossier de l'ecosysteme, le rendre actif, puis
generer son inventaire. Tout l'adressage descend du seed `index` — on ne l'ecrit
@ -341,7 +341,7 @@ runbooks:
- id: locataire-materialiser
titre: "Preparer le terrain d'un locataire sur la fabric"
portee: site
doc: docs/implanter-un-tenant-sur-un-site.md
doc: docs/hebergement/implanter-un-tenant-sur-un-site.md
but: >-
Tout ce que l'HEBERGEUR pose avant qu'un locataire puisse exister : le placement, les
pools, le SDN, les pare-feux et la frontiere. Chaque devis se mesure avant de
@ -441,7 +441,7 @@ runbooks:
- id: locataire-deployer
titre: "Materialiser et deployer la flotte d'un locataire"
portee: tenant
doc: docs/vm-lifecycle.md
doc: docs/exploitation/vm-lifecycle.md
but: >-
Des VM au service rendu : creer les machines manquantes, deployer couche par couche,
puis mesurer. Rien n'est « pret » avant la recette.
@ -496,7 +496,7 @@ runbooks:
- id: machine-une
titre: "Ajouter ou reprendre une seule machine"
portee: tenant
doc: docs/vm-lifecycle.md
doc: docs/exploitation/vm-lifecycle.md
but: >-
Le cycle d'UNE machine, du plan au service : la voir derivee, la creer, la deployer,
la verifier. Le meme chemin sert pour une machine neuve et pour une machine a
@ -535,7 +535,7 @@ runbooks:
- id: flotte-refaire
titre: "Raser et reconstruire un ecosysteme"
portee: tenant
doc: docs/vm-lifecycle.md
doc: docs/exploitation/vm-lifecycle.md
but: >-
La preuve la plus dure du moteur : detruire un ecosysteme et le refaire depuis le
code seul. A ne lancer que sur un chantier — la prod vit ailleurs.
@ -618,7 +618,7 @@ runbooks:
- id: gabarit
titre: "Le gabarit dore"
portee: site
doc: docs/procedure-template-debian13-proxmox.md
doc: docs/exploitation/procedure-template-debian13-proxmox.md
but: >-
La VM de reference que toute la flotte clone. Elle nait en q35/OVMF et ne se convertit
jamais : convertir depuis i440fx casse interfaces et disques.
@ -644,7 +644,7 @@ runbooks:
- id: mesurer
titre: "Mesurer sans rien ecrire"
portee: tenant
doc: docs/devis-services.md
doc: docs/exploitation/devis-services.md
but: >-
Les devis de service : ils confrontent ce que le plan derive a ce que le systeme rend
VRAIMENT, et sortent en erreur s'il y a un ecart. Une tache verte ne prouve pas qu'un
@ -730,7 +730,7 @@ runbooks:
- id: acces-admin
titre: "L'acces d'administration (tunnel WireGuard)"
portee: site
doc: docs/acces-administration.md
doc: docs/exploitation/acces-administration.md
but: >-
Un tunnel nominatif par locataire, declare par lui et borne a lui. Sans garde, un
ecosysteme s'ouvrirait un acces chez son voisin depuis son propre plan.
@ -747,7 +747,7 @@ runbooks:
- id: dns-public
titre: "Le DNS public et sa signature"
portee: tenant
doc: docs/dns-interne.md
doc: docs/conception/dns-interne.md
but: >-
Publier les zones du locataire, signees avant d'etre exposees. Les DS partent chez le
registraire : c'est le seul maillon que le moteur ne peut pas poser lui-meme.
@ -770,7 +770,7 @@ runbooks:
- id: filiation
titre: "Filiation, insemination, emancipation"
portee: tenant
doc: docs/filiation-emancipation.md
doc: docs/conception/filiation-emancipation.md
but: >-
D'ou vient cet ecosysteme, de quoi depend-il encore, et que faut-il couper pour qu'il
tienne seul. L'emancipation se mesure ; elle ne se decrete pas.
@ -824,7 +824,7 @@ runbooks:
- id: remise
titre: "La remise au client"
portee: poste
doc: docs/remise-au-client.md
doc: docs/hebergement/remise-au-client.md
but: >-
Deux temps qui ne se confondent pas : le paquet qu'on remet, puis le re-cle qui
mesure la revocation reelle. Tant que le temps 2 n'est pas fait, on detient encore
@ -857,7 +857,7 @@ runbooks:
- id: cles
titre: "Les cles hors du poste"
portee: poste
doc: docs/sortir-les-cles-du-poste.md
doc: docs/exploitation/sortir-les-cles-du-poste.md
but: >-
Ce qui n'existe QUE sur le poste meurt avec lui : les CLES, et les VOUTES qu'elles
ouvrent (gitignorees, donc sur aucune forge). Les deux sortent, sur un support qu'on
@ -900,7 +900,7 @@ runbooks:
- id: lire-le-plan
titre: "Lire le plan et ce qu'il derive"
portee: tenant
doc: docs/plan-et-generation.md
doc: docs/conception/plan-et-generation.md
but: >-
Tout ce qui se regarde sans rien changer : les registres du plan, leur validation, et
l'inventaire qui en descend. Le premier geste devant un ecosysteme qu'on ne connait pas.

152
docs/setup.md Normal file
View file

@ -0,0 +1,152 @@
# Installation et configuration
> **Pour qui :** l'exploitant qui monte son premier écosystème sur une grappe Proxmox. Le
> résumé est dans le [README](../README.md) ; ce document donne chaque étape, ses fichiers
> et ses pièges. Préparer le matériel d'un hébergeur est un autre parcours :
> [`hebergement/preparer-un-site-hebergeur.md`](hebergement/preparer-un-site-hebergeur.md).
## Prérequis
| Quoi | Détail |
|---|---|
| Grappe Proxmox | droits d'administration, API joignable depuis le poste |
| Jeton d'API Proxmox | utilisateur `ansible@pve` ou équivalent |
| Poste de pilotage | Linux, Python 3, Ansible, `make`, `git` ; `node` optionnel (garde JS du GUI) |
| Paire de clés SSH | la publique est injectée dans les VM par cloud-init |
| Phrase de passe de voûte | une par écosystème |
## 1. Cloner le moteur
```bash
git clone <url-de-Set-OPS> Set-OPS && cd Set-OPS
```
## 2. Créer l'instance
Une instance est un dépôt frère du moteur, créé depuis un modèle. Le dépôt public fournit
`socle` : PKI (step-ca), DNS interne (PowerDNS), edge TLS (nginx), magasin de courriel
(Dovecot). Les modèles assemblés par offre sont dans le dépôt privé `Set-OPS-modeles`
(`SETOPS_MODELES` les rend visibles).
```bash
make instance-modeles # modèles disponibles
make instance-creer NOM=OPS-MonOrg MODELE=socle # crée ../OPS-MonOrg ; INDEX=<n> fixe le seed
ln -s ../OPS-MonOrg instance # l'instance active (ou : make instance-utiliser NOM=OPS-MonOrg)
make instances # écosystèmes découverts, collisions d'index
```
`instance-creer` refuse un `index` déjà pris par un écosystème voisin : tout l'adressage en
dérive. Il ne bascule pas le lien `instance/` et ne fait pas `git init`.
## 3. Renseigner l'instance
`<inventaire>` est `principal` ou, à défaut, `production` (le nom que porte le modèle).
| Fichier | Valeur |
|---|---|
| `instance/inventories/<inventaire>/group_vars/all/10-intrants.yml` | `domaine_interne` (ex. `monorg.internal`) |
| `instance/plan/nomenclature.yml` | `index` (seed) et supernet |
| `instance/plan/domaines.yml` | domaine public, `autorite`, `edge` |
| `instance/plan/serveurs.yml` | placement Proxmox : nœud, stockage, disque, mémoire, cœurs |
Le GUI (`make inventaire-ui`) édite les mêmes registres. Valeurs communes :
[`conception/intrants-communs.md`](conception/intrants-communs.md).
## 4. Proxmox
```bash
make config # API, nœud, stockage, VMID et nom du gabarit
```
Chaque paramètre : [`exploitation/config-proxmox.md`](exploitation/config-proxmox.md).
Les identifiants Proxmox appartiennent à l'hébergeur : ils vivent dans **sa** voûte (celle
de l'underlay), pas dans celle du locataire.
## 5. Voûtes et clés
Une voûte par dépôt, chiffrée par `ansible-vault`, depuis le gabarit
[`exemples/vault.exemple.yml`](../exemples/vault.exemple.yml) :
`instance/inventories/<inventaire>/group_vars/all/vault.yml`.
Une clé par voûte, dans un fichier nommé d'après le dossier de l'écosystème, en minuscules :
```bash
install -m 600 /dev/null ~/.config/setops-vault-ops-monorg
$EDITOR ~/.config/setops-vault-ops-monorg # la phrase de passe, une ligne
python3 scripts/voutes.py etat # le moteur trouve-t-il chaque clé ?
```
Rien à exporter : le `Makefile` construit `ANSIBLE_VAULT_IDENTITY_LIST` avec
`scripts/voutes.py`. Créer une VM ouvre deux voûtes dans la même exécution (locataire et
hébergeur) : un seul `ANSIBLE_VAULT_PASSWORD_FILE` ne suffit pas.
Les clés n'existent que sur le poste. Les sortir sur un support chiffré :
[`exploitation/sortir-les-cles-du-poste.md`](exploitation/sortir-les-cles-du-poste.md).
## 6. Gabarit Debian 13 (une fois par grappe)
Créer une VM Debian 13 minimale, joignable par SSH avec clé, puis :
```bash
make preparer-modele
make verifier-modele
make nettoyer-modele CONFIRMER=true
```
Convertir la VM en gabarit Proxmox sous le nom enregistré par `make config`
(`proxmox_clone_source_nom`, `modeleSetOPS` par défaut). Un autre nom fait échouer le
clonage. Machine **q35/OVMF** : ne jamais convertir depuis i440fx.
Procédure : [`exploitation/procedure-template-debian13-proxmox.md`](exploitation/procedure-template-debian13-proxmox.md) ;
contenu justifié : [`exploitation/gabarit-debian13-justification.md`](exploitation/gabarit-debian13-justification.md).
## 7. Générer l'inventaire
```bash
make instancier # ce que le plan produit, en diff
make instancier-appliquer FORCE=1 # première génération seulement
make serveurs # VMID / IP dérivés
```
Les hôtes naissent en `etat: planifie`.
## 8. Créer et déployer
```bash
make creer-vm HOTE=infra-dns-01 # clone + cloud-init, attend que la VM réponde
# passer l'hôte en etat: actif dans instance/plan/serveurs.yml, puis :
make instancier-appliquer
make deployer HOTE=infra-dns-01 # couche par couche, dans l'ordre du graphe
```
Toute la flotte : `make flotte-creer CONFIRMER=true` puis `make deployer-tout CONFIRMER=true`,
ou `make reconstruire CONFIRMER=true` (créer puis déployer). Les déploiements ne visent que
les hôtes actifs.
## 9. Vérifier
```bash
make inventaire-verifier # registres, inventaire, gardes
make verifier # lint, tests, inventaire, ordre, flux, syntaxe, puis les preuves
make valider # recette sur la flotte déployée
```
## Configuration de référence
| Élément | Rôle | Défaut |
|---|---|---|
| `instance/` | lien vers le dépôt du locataire actif | — |
| `underlay.yml` | lien vers l'underlay du site actif | `underlay.yml` à la racine |
| `ansible.cfg` | configuration Ansible du moteur | dans le dépôt |
| `.ansible/` | répertoires temporaires d'Ansible | créé par `make` |
Variables d'environnement et de `make` : [`usage.md`](usage.md).
## Pannes connues au premier montage
| Symptôme | Cause | Remède |
|---|---|---|
| `Attempting to decrypt but no vault secrets found` | clé de voûte absente ou mal nommée | étape 5, `python3 scripts/voutes.py etat` |
| `make instancier-appliquer` refuse d'écrire | diff non vide, première génération | `FORCE=1` la première fois seulement |
| le clonage ne trouve pas sa source | nom du gabarit ≠ `proxmox_clone_source_nom` | renommer le gabarit ou refaire `make config` |
| une sortie d'Ansible vide, sans erreur | Ansible exige un tube sur sa sortie | `set -o pipefail; make … < /dev/null 2>&1 \| cat` |

315
docs/usage.md Normal file
View file

@ -0,0 +1,315 @@
# Utilisation
> **Pour qui :** l'exploitant et le mainteneur — la référence de l'outil en ligne de
> commande. Set-OPS est un outil CLI : tout passe par `make`, qui appelle Ansible et les
> scripts de `scripts/`. Installation : [`setup.md`](setup.md).
## Conventions
| Convention | Sens |
|---|---|
| `make <sujet>-plan` | compare le réel à ce que le plan dérive ; **n'écrit rien** |
| `make <sujet>-appliquer CONFIRMER=true` | réconcilie ; sans `CONFIRMER=true`, refuse |
| `make <sujet>-verifier` | contrôle ; n'écrit rien (la plupart lisent le dépôt seul) |
| `make <sujet>-etat`, `-mesurer`, `-recenser` | regarde le réel ; ne corrige rien |
| `DESTRUCTIF` dans l'aide | exige `CONFIRMER=true` **et** le nom de la cible (`INSTANCE=`, `SITE=`) |
| `FORCE=1` | passe outre le diff de `instancier-appliquer` ; première génération seulement |
| `MODE_CHECK=1` | `deployer-tout` en essai à blanc (`--check`) |
| `ARGS="…"` | arguments passés tels quels au script ou au playbook (ex. `ARGS=--check`) |
`make` seul (ou `make aide`) affiche l'aide détaillée. L'aide de chaque cible (`## …` dans
le `Makefile`) est la source des tableaux ci-dessous ; une preuve exige que chaque cible
publique y figure.
**Sortie d'Ansible.** Ansible exige une sortie bloquante : depuis un shell non interactif,
toujours `set -o pipefail; make … < /dev/null 2>&1 | cat`. Sans tube, l'échec est silencieux.
## Variables de `make`
| Variable | Sens | Cibles |
|---|---|---|
| `HOTE` | une VM, par son nom court | `deployer`, `creer-vm`, `hote-afficher`, … |
| `GROUPE` | un groupe Ansible (= un playbook de `playbooks/groupes/`) | `deployer-groupe`, `appliquer`, `site-appliquer` |
| `TENANT` | le dépôt d'un locataire (`OPS-X`) vu depuis le site | `locataire-creer`, `inseminer`, `placement-plan`, … |
| `INSTANCE` | le nom court d'un écosystème, exigé par les cibles destructives | `raser`, `locataire-raser`, `parefeu-*-flotte` |
| `SITE` | le dépôt d'un site, exigé par `site-raser` | `site-raser` |
| `CONFIRMER` | `true` pour écrire | toute cible `-appliquer` ou destructive |
| `LIMITE` | motif d'hôtes Ansible | `faits`, `verifier-hote` |
| `VERS` | un répertoire de destination (support externe) | `cles-exporter`, `voutes-exporter`, `remise-paquet`, … |
| `DEPOT` | un seul dépôt du génome | `publier`, `genome-pousser` |
| `PARALLELE` | nombre de VM créées à la fois | `flotte-creer`, `locataire-creer` |
| `NOM`, `MODELE`, `INDEX` | nouvel écosystème | `instance-creer`, `instance-utiliser`, `model-creer` |
| `DIALECTE` | CLI du commutateur (`cisco`, `binardat`) | `devis-reseau` |
## Variables d'environnement
| Variable | Sens | Défaut |
|---|---|---|
| `SETOPS_INSTANCE` | dépôt du locataire visé | `instance` (le lien) |
| `SETOPS_UNDERLAY` | underlay du site visé | `underlay.yml` (le lien) |
| `SETOPS_INVENTAIRE` | inventaire de l'instance ; exporté par le `Makefile` | `principal`, puis `production` |
| `ANSIBLE_VAULT_IDENTITY_LIST` | les clés de toutes les voûtes ; construit par `scripts/voutes.py` | dérivé de `~/.config/setops-vault-*` |
| `SETOPS_PROXMOX_API` | `hote:port` de l'API Proxmox le temps d'une commande (par un rebond) | l'adresse de la carte |
| `SETOPS_SSH_KEY` | clé SSH vers les nœuds Proxmox | l'agent SSH |
| `SETOPS_MODELES` | dossiers de modèles en plus de `exemples/modeles/` | — |
| `SETOPS_DIALECTE` | CLI du commutateur pour `devis-reseau` | `dialecte` de l'underlay |
| `SETOPS_FORGE_URL` | adresse de la forge pour `forge_cles.py` | — |
| `SETOPS_FORGE_MDP`, `FORGEJO_ADMIN` | mot de passe d'administration de la forge, depuis la voûte, le temps d'une commande | — |
Viser un autre site ou un autre locataire sans toucher aux liens :
```bash
SETOPS_UNDERLAY=../SITE-Technolibre/underlay.yml make frontiere-plan
SETOPS_INSTANCE=../OPS-Chezlepro make instancier
```
## Flux de travail courants
```bash
# Modifier l'écosystème
$EDITOR instance/plan/applications.yml
make instancier && make instancier-appliquer && make deployer HOTE=<vm>
# Contrôler une couche d'infrastructure, puis la réconcilier
make frontiere-plan
make frontiere-appliquer CONFIRMER=true
# Publier le moteur et les plans vers les forges
make publier
make wiki-publier WIKI_REMOTE=<url>.wiki.git
```
## Scripts appelés directement
Les cibles `make` couvrent l'exploitation. Quelques scripts s'utilisent aussi seuls ; chacun
documente ses options (`--help`) dans sa docstring.
| Script | Usage |
|---|---|
| `scripts/voutes.py etat` | les voûtes et leurs clés, vues par le moteur |
| `scripts/contexte.py` | le contexte actif (site, locataire) et ce que dit chaque indice |
| `scripts/orchestrer.py ordre` | l'ordre de déploiement des groupes |
| `scripts/dnssec.py generer <zone>` | crée la clé DNSSEC d'une zone, dans la voûte du locataire |
| `scripts/vpn_admin.py cle-appareil`, `config` | un appareil dans le tunnel des administrateurs |
| `scripts/dns_bascule.py --serveur <ip>` | le devis de bascule DNS contre un serveur précis |
## Commandes
### Vérifier et prouver
| Commande | Effet |
|---|---|
| `make aide` | Affiche l'aide detaillee du moteur (au-dela de cette liste) |
| `make verifier` | Rejoue les preuves SANS reecrire le rapport (verification rapide) |
| `make prouver` | Execute les preuves et ecrit docs/audit/preuve-<date>.md |
| `make test` | Lance les tests unitaires (derivation de nomenclature et d'inventaire) |
| `make lint` | Passe ansible-lint sur tout le depot |
| `make syntaxe` | Verifie la syntaxe de TOUS les playbooks (modele, hote, groupes, proxmox) |
| `make syntaxe-modele` | Verifie la syntaxe du playbook de preparation du gabarit dore |
| `make syntaxe-verification-modele` | Verifie la syntaxe du playbook de verification du gabarit |
| `make syntaxe-nettoyage` | Verifie la syntaxe du playbook de nettoyage du gabarit |
| `make syntaxe-verification-hote` | Verifie la syntaxe du playbook de verification d'hote |
| `make syntaxe-groupes` | Verifie la syntaxe de TOUS les playbooks de groupe (playbooks/groupes/*.yml) |
| `make syntaxe-proxmox` | Verifie la syntaxe du playbook de clonage de VM |
| `make ci` | Verifie le depot comme la CI : modele public monte a l'ecart, sans toucher ton instance |
| `make inventaire-verifier` | Verifie que l'inventaire se parse (voute dechiffree) |
| `make serveurs-verifier` | Valide le registre des serveurs |
| `make bases-verifier` | Valide le registre des bases de donnees |
| `make domaines-verifier` | Valide le registre des domaines |
| `make applications-verifier` | Valide le registre des applications |
| `make ports-verifier` | Deux roles co-localises revendiquent-ils le meme port ? (lecture seule) |
| `make intrants-verifier` | Tout intrant qu'un role EXIGE est-il fourni par l'instance ? (lecture seule) |
| `make site-verifier` | Verifie que playbooks/site.yml correspond aux couches declarees |
| `make flux-verifier` | Verifie que le registre des flux correspond aux meta/flux.yml des roles |
| `make schema` | Regenere docs/audit/schema-plan.json depuis les registres et les validateurs |
| `make plan-recette` | Regenere docs/audit/plan-de-recette.md depuis le wiki |
| `make sonder` | Sonde une cible et DIT ce qui distingue — CIBLE=<hote\|ip> [PORTS="22 443"] |
| `make valider` | Passe la recette de validation sur la flotte |
### Instances et modèles
| Commande | Effet |
|---|---|
| `make instance-modeles` | Liste les modeles d'ecosysteme disponibles |
| `make instance-creer` | Cree un nouvel ecosysteme depuis un modele — NOM=<nom> MODELE=<modele> |
| `make instance-utiliser` | Bascule l'instance active (symlink instance/) vers un dossier frere — NOM=<dossier> |
| `make instance-courante` | Affiche vers quel ecosysteme pointe l'instance active |
| `make instances` | Liste les ecosystemes decouverts (dossiers freres) et signale les collisions d'index |
| `make model-creer` | Cree un modele d'ecosysteme — MODE=<mode> NOM=<nom> |
| `make genome` | Les depots requis a la reproduction de cet ecosysteme, et leur etat |
| `make genome-inscrire` | Inscrit la parente dans l'instance (instance/parente.yml) |
| `make genome-verifier` | La parente inscrite tient-elle encore ? (code de sortie) |
### Plan et inventaire
| Commande | Effet |
|---|---|
| `make config` | Affiche la configuration Proxmox lue par le moteur |
| `make inventaire-ui` | Ouvre la console d'exploitation (GUI web) sur l'inventaire actif |
| `make instancier` | Genere hosts.yml depuis le plan (sans l'appliquer) |
| `make instancier-appliquer` | Applique l'inventaire genere — FORCE=1 pour passer outre le diff |
| `make serveurs` | Liste les serveurs declares au plan |
| `make serveurs-bootstrap` | REPRISE : (re)constitue plan/serveurs.yml depuis un inventaire existant |
| `make bases` | Liste les bases de donnees declarees au plan |
| `make domaines` | Liste les domaines declares au plan |
| `make applications` | Liste les applications declarees au plan |
| `make applications-bootstrap` | Amorce les applications declarees au plan |
| `make hote-afficher` | Affiche tout ce que le plan derive pour un hote — HOTE=<nom> |
| `make inventaire` | Verifie l'inventaire et en affiche le graphe (lab puis production) |
| `make inventaire-lister` | Affiche l'inventaire complet (JSON) |
| `make inventaire-graphe` | Affiche le graphe des groupes de l'inventaire |
| `make inventaire-hote` | Affiche les variables derivees d'un hote — HOTE=<nom> |
| `make inventaire-lab` | Affiche le graphe de l'inventaire de laboratoire |
| `make inventaire-production` | Affiche le graphe de l'inventaire de production |
### Gabarit et VM
| Commande | Effet |
|---|---|
| `make preparer-modele` | Prepare le gabarit dore (VM de reference clonee pour chaque hote) |
| `make verifier-modele` | Verifie le gabarit dore |
| `make nettoyer-modele` | Nettoie le gabarit avant capture — exige CONFIRMER=true |
| `make cloner-vm` | Clone une VM depuis le gabarit dore — HOTE=<nom> VMID=<id> |
| `make creer-vm` | Cree une VM et attend qu'elle soit joignable — HOTE=<nom> [TENANT=<depot>] |
| `make flotte-creer` | Cree les VM manquantes de la flotte depuis le plan — PARALLELE=n |
| `make raser` | DESTRUCTIF : detruit les VM derivees du plan — exige CONFIRMER=true ET INSTANCE=<nom> [TENANT=<depot>] |
| `make reconstruire` | Reconstruit un ecosysteme depuis zero : VM puis deploiement complet |
| `make myDay` | Alias strict de `reconstruire` (meme cible, memes gardes) |
| `make monter-flotte` | Monte une flotte deja creee : flux, AC et DNS, tout le reste, recette — CONFIRMER=true |
| `make reconstruire-locataire` | Rase et reconstruit un locataire, du site a la recette, etat remis — TENANT=OPS-X CONFIRMER=true |
### Déployer
| Commande | Effet |
|---|---|
| `make ansible-runtime` | Prepare le repertoire temporaire local d'Ansible (prerequis interne des cibles qui deploient) |
| `make site` | Regenere playbooks/site.yml depuis les couches et le graphe de dependances |
| `make appliquer` | Applique un groupe a la flotte — GROUPE=<groupe> |
| `make deployer` | Deploie un hote, couche par couche, dans l'ordre du graphe — HOTE=<nom> |
| `make deployer-groupe` | Deploie un seul groupe sur toute la flotte — GROUPE=<groupe> |
| `make deployer-tout` | Deploie TOUTE la flotte dans l'ordre des couches |
| `make verifier-deploiement` | Verifie l'etat de la flotte apres deploiement |
| `make verifier-hote` | Passe le playbook de verification sur un hote |
| `make faits` | Interroge les faits Ansible de la flotte — LIMITE=<motif> |
| `make cacher-paquets` | Tire les paquets NON DEBIAN dans le cache du controleur (a faire en ligne) |
### Réseau : flux, frontière, SDN, pare-feu
| Commande | Effet |
|---|---|
| `make flux` | Regenere le registre des flux et les regles nftables depuis les meta/flux.yml |
| `make devis-reseau` | Devis switch (VLANs/SVIs/ACLs) du reseau converge, derive des nomenclatures. DIALECTE=cisco\|binardat |
| `make devis-opnsense` | Devis OPNsense (frontiere nord/sud), derive du registre des flux (pair: externe) |
| `make devis-opnsense-verifier` | Verifie le devis de la frontiere nord/sud (aucune ecriture) |
| `make frontiere-plan` | Ecart entre la frontiere OPNsense et son devis (aucune ecriture) |
| `make frontiere-appliquer` | Reconcilie la frontiere : cree ce qui manque, RETIRE ce qui est perime. CONFIRMER=true |
| `make frontiere-mesurer` | La frontiere refuse-t-elle ce qui n'est pas declare ? (sonde reelle, aucune ecriture) |
| `make devis-proxmox-fw` | Devis pare-feu Proxmox (est-ouest intra-tenant), derive du registre des flux |
| `make devis-proxmox-fw-verifier` | Verifie le devis du pare-feu est-ouest Proxmox (aucune ecriture) |
| `make proxmox-fw-plan` | Ecart entre le pare-feu est-ouest Proxmox et son devis (aucune ecriture) — ARGS="--objets-seulement" ou "--vm <vmid>" |
| `make proxmox-fw-appliquer` | Reconcilie le pare-feu est-ouest : IPSets, groupes, affectations. CONFIRMER=true |
| `make proxmox-fw-eprouver` | Verifie qu'activer le pare-feu d'UNE VM ne coupe rien (aucune ecriture) — TENANT=<OPS-X> HOTE=<vm> |
| `make proxmox-fw-activer-vm` | Active le pare-feu d'UNE VM en le prouvant avant/apres — TENANT= HOTE= CONFIRMER=true |
| `make parefeu-verifier-flotte` | La sonde `connectivite` est-elle saine sur chaque VM (prealable a l'activation) — INSTANCE=OPS-X |
| `make parefeu-activer-flotte` | Active le pare-feu Proxmox de toutes les VM, juge par la sonde `connectivite` — INSTANCE=OPS-X CONFIRMER=true |
| `make devis-sdn` | Devis SDN EVPN (zone + VNets + sous-reseaux par tenant), derive du seed |
| `make devis-sdn-verifier` | Verifie le devis SDN EVPN — zones, VNets, sous-reseaux (aucune ecriture) |
| `make sdn-plan` | Ecart entre le SDN EVPN (+ sortie des VRF) et son devis (aucune ecriture) |
| `make sdn-appliquer` | Reconcilie le SDN : cree ce qui manque, RETIRE ce qui est perime. CONFIRMER=true |
| `make devis-proxmox-pools` | Devis des pools Proxmox (un par tenant), derive du plan |
| `make devis-proxmox-pools-verifier` | Verifie le devis des pools Proxmox (aucune ecriture) |
| `make placement-plan` | Le noeud, stockage, pont et gabarit du tenant existent-ils sur ce cluster ? (aucune ecriture) [TENANT=<depot>] |
| `make underlay` | Underlay (fabric physique cluster-global : mgmt/iSCSI/Ceph) : affiche + valide (P23) |
| `make underlay-plan` | Confronte l'underlay DECLARE au reel (API du cluster + sonde TCP) — n'ecrit rien |
| `make mtu-mesurer` | L'invite porte-t-il le MTU de sa zone SDN ? (aucune ecriture) |
| `make routes-fabric-etat` | Les hyperviseurs routent-ils toutes les zones du SITE ? — ne corrige rien |
| `make vpn-admin-plan` | Acces WireGuard des admins : ce que la frontiere porte face au plan (aucune ecriture) |
| `make vpn-admin-appliquer` | Pose l'instance et les pairs declares, retire ceux qui ne le sont plus — CONFIRMER=true |
### Devis de service
| Commande | Effet |
|---|---|
| `make identite-plan` | Ecart entre l'identite deployee et ce que le plan derive (aucune ecriture) |
| `make certificats-plan` | Ecart entre les certificats sur disque et ceux reellement servis (aucune ecriture) |
| `make expositions-plan` | Chaque exposition du plan repond-elle ? (edge et poste, aucune ecriture) |
| `make expositions-etat` | Chaque exposition est-elle servie sous un certificat qui la porte ? — ne corrige rien |
| `make postgresql-plan` | Chiffrement impose et portee des acces PostgreSQL (aucune ecriture) |
| `make courriel-plan` | Chaine Postfix -> LDAP -> Dovecot -> IMAP (aucune ecriture) |
| `make versions-mesurer` | De combien nos epinglages ont-ils vieilli ? (interroge les amonts, aucune ecriture) |
### PKI et DNS
| Commande | Effet |
|---|---|
| `make ca-racine` | Recupere la racine de l'AC interne + son empreinte (a verifier AVANT de l'installer) |
| `make ca-empreinte` | Empreinte de la racine, lue SUR l'AC (le temoin de comparaison) |
| `make dnssec-ds` | DS a remettre au registraire, calcules depuis la voute du locataire (aucune ecriture) |
| `make dnssec-verifier` | Cle en voute pour chaque zone signee, et DS du registre conforme ? (aucune ecriture) |
| `make dns-bascule-devis` | Basculer nos serveurs de noms changerait-il quelque chose ? Plan contre DNS en service (aucune ecriture) |
### Site et locataires
| Commande | Effet |
|---|---|
| `make site-intrants` | Les intrants que le SITE monte expose a ses locataires (derives) |
| `make site-intrants-verifier` | Le locataire monte suit-il encore son site ? (aucune ecriture) |
| `make face-reseau-publier` | Chaque locataire publie sa face reseau pour son site (a commiter chez lui, apres `make flux`) |
| `make fiches-site-deposer` | Le site depose chez chacun de ses locataires la fiche qu'il lui destine (a commiter chez eux) |
| `make site-decrire` | Les machines de l'hebergeur declarees dans l'underlay |
| `make site-inventaire` | L'inventaire dynamique du site, tel qu'Ansible le voit |
| `make site-appliquer` | Applique un role aux machines du site — GROUPE=<serveur_ops_site\|...> |
| `make site-deployer-tout` | Deploie TOUT le site dans l'ordre des couches — CONFIRMER=true |
| `make site-creer` | Cree les machines du site depuis l'underlay — CONFIRMER=true |
| `make site-raser` | DESTRUCTIF : detruit les VM du SITE — CONFIRMER=true ET SITE=<depot> |
| `make locataire-creer` | Le SITE cree les VM d'un locataire d'apres sa face reseau — TENANT=<depot> CONFIRMER=true [PARALLELE=n] |
| `make locataire-raser` | DESTRUCTIF : le SITE rase les VM d'un locataire d'apres sa face reseau — TENANT=<depot> CONFIRMER=true INSTANCE=<nom court> [HOTE=h] |
| `make gabarit-etat` | Le gabarit porte-t-il ce que le SITE declare ? — ne corrige rien, regarde |
| `make inseminer` | Le SITE amorce le runner d'un tenant — TENANT=<dossier> [HOTE=<nom>] |
| `make emancipation-prouver` | Prouve qu un lien est coupe — SERVICE=<artefacts\|genome\|resolveur> [HOTE=] CONFIRMER=true |
### Génome, forge, publication
| Commande | Effet |
|---|---|
| `make publier` | Publie le genome d'un geste : eregion PUIS la forge du site, et le verifie — DEPOT=<nom> pour un seul |
| `make genome-pousser` | Le runner du site pousse le genome sur la forge du site — DEPOT=<nom> pour un seul |
| `make genome-etat` | Ce que la forge du site porte, face au poste — ne corrige rien, regarde |
| `make forge-amorcer` | Amorce la forge d'un SITE neuf avec le genome — CONFIRMER=true |
| `make forge-cles` | Le site enregistre sur le depot de chaque locataire la cle de lecture que sa face publie — CONFIRMER=true pour ecrire |
| `make forge-comptes` | Les comptes de la forge du site : un par mainteneur (plan du site), et le lecteur de la console — CONFIRMER=true pour ecrire |
| `make forge-etancheite` | La forge du site laisse-t-elle chaque runner lire ses depots, et personne d'autre ? (mesure, aucune ecriture) |
| `make depots-perimes` | Depots qu'un runner ne declare plus : regarde, et retire avec CONFIRMER=true |
| `make wiki-publier` | Publie le wiki (wiki/) vers la forge |
| `make fiches` | Regenere la fiche de chaque role (docs/roles/) — ROLE=<nom> pour une seule |
### Sauvegardes et état
| Commande | Effet |
|---|---|
| `make sauvegarder-maintenant` | Depose l'etat de chaque noeud TOUT DE SUITE (avant de raser) — HOTE=<hote> optionnel |
| `make restauration-etat` | Ce qui attend dans le depot, et ce que chaque jeu est devenu — HOTE=<hote> optionnel |
| `make temoins-etat` | L'etat vivant est-il celui d'avant le rasage ? (lecture seule) — HOTE= SOURCE=candidat optionnels |
| `make restauration-renoncer` | Ecarte l'etat anterieur d'un jeu, sans le remettre — HOTE= JEU= CONFIRMER=true |
| `make depot-hors-site` | Copie le depot de sauvegarde du site HORS du site — VERS=<repertoire> |
### Clés et voûtes
| Commande | Effet |
|---|---|
| `make cles-recenser` | Montre ce qui n'existe QUE sur ce poste (sans rien ecrire) |
| `make voutes-recenser` | Montre les voutes de ce poste (gitignorees : sur aucune forge), sans rien ecrire |
| `make voutes-exporter` | Sort les voutes (deja chiffrees) vers un support, relues — VERS=<repertoire> NOM=<base> |
| `make cles-exporter` | Sort les cles du poste, chiffrees et relues — VERS=<repertoire> |
| `make cles-compagnons` | Depose le script de restauration sur une cle DEJA faite — VERS=<repertoire> |
| `make cles-restaurer` | Remet les cles en place depuis une archive — ARCHIVE=<fichier> |
### Remise au client
| Commande | Effet |
|---|---|
| `make remise-recenser` | Ce qu'une remise au client emporterait, sans rien ecrire |
| `make remise-paquet` | Temps 1 : fabrique le paquet de remise, chiffre et relu — VERS=<repertoire> |
| `make remise-inscrire` | Inscrit la remise chez le locataire — RECU_PAR="…" COURRIEL="…" [DANS=30] |
| `make remise-verifier` | Etat de la remise : temps 1 fait ? temps 2 du, ou echu ? |
| `make remise-recleer` | Temps 2 : mesure la revocation reelle, puis estampille — CONFIRMER=true |

2
exemples/instance.exemple.yml
View file

@ -5,7 +5,7 @@
# generateur) est generique ; c'est ici qu'on dit "qui on est". A placer dans
# inventories/<env>/group_vars/all.yml de l'instance.
#
# Voir docs/plan-et-generation.md et docs/positionnement.md.
# Voir docs/conception/plan-et-generation.md et docs/projet/positionnement.md.
# Domaine DNS interne de l'instance. Les roles en derivent zones, FQDN, base DN
# LDAP, expediteurs courriel, etc. (ex. dc=acme,dc=local pour acme.local).

2
playbooks/groupes/serveur_debian.yml
View file

@ -47,7 +47,7 @@
# l'URL absolue, et c'est LUI qui traduit le nom. La machine n'a donc besoin d'aucun
# DNS pour installer ses paquets — seulement d'une ADRESSE.
#
# C'EST DE LA FILIATION, PAS UNE RUSTINE (docs/filiation-emancipation.md). L'hébergeur
# C'EST DE LA FILIATION, PAS UNE RUSTINE (docs/conception/filiation-emancipation.md). L'hébergeur
# nourrit la première machine de son locataire le temps que celui-ci monte son propre
# cache. L'emprunt est DÉCLARÉ — l'intrant nomme l'amont — et il s'efface de lui-même :
# `client_artefacts` écrit `00-setops-artefacts`, qui trie APRÈS ce fichier-ci, donc

4
playbooks/maintenance/emancipation-prouver.yml
View file

@ -1,7 +1,7 @@
---
# PROUVER QU'UN LIEN EST COUPÉ — l'instrument de la quatrième ligne.
#
# `docs/filiation-emancipation.md` décrit quatre temps, et n'en outillait que trois :
# `docs/conception/filiation-emancipation.md` décrit quatre temps, et n'en outillait que trois :
#
# le lien de filiation déclaré au plan le moteur
# le constat d'aptitude « tu pourrais » la machine INSTRUIT
@ -79,7 +79,7 @@
SERVICE doit valoir l'un de {{ emancipation_services.keys() | join(', ') }},
et cet écosystème doit DÉCLARER l'amont correspondant. Un emprunt qu'aucune
variable ne nomme ne peut pas être prouvé coupé — c'est la forme normée de
`docs/filiation-emancipation.md` qui rend cette preuve possible.
`docs/conception/filiation-emancipation.md` qui rend cette preuve possible.
# PAS de `run_once` : l'amont se lit dans les variables de CHAQUE hote. Un
# ecosysteme peut tres bien emprunter sur une machine et pas sur une autre — c'est
# meme le cas ici, ou seul le porteur du cache chaine vers celui du site. Verifier

2
playbooks/maintenance/forge_cles.yml
View file

@ -1,7 +1,7 @@
---
# LE SITE ENREGISTRE LA CLE DE LECTURE DE CHAQUE LOCATAIRE SUR SON DEPOT (2026-10-11).
#
# Voir `docs/depots-prives-conception.md` et `scripts/forge_cles.py`. Le script tourne SUR le
# Voir `docs/conception/depots-prives-conception.md` et `scripts/forge_cles.py`. Le script tourne SUR le
# runner du site : il y lit les faces que le site tire (et rien d'autre de ses locataires), et
# il y joint la forge. Le mot de passe d'administration vient de la voute du site, par
# l'environnement, et n'est jamais affiche.

2
playbooks/maintenance/forge_comptes.yml
View file

@ -1,7 +1,7 @@
---
# LES COMPTES DE LA FORGE DU SITE (2026-10-11, lot 3b).
#
# Voir `docs/depots-prives-conception.md` et `scripts/forge_comptes.py`. Le script tourne SUR le
# Voir `docs/conception/depots-prives-conception.md` et `scripts/forge_comptes.py`. Le script tourne SUR le
# runner du site : il y lit le plan du site (`mainteneurs`) et les faces de ses locataires, et
# il y joint la forge. Le mot de passe d'administration vient de la voute du site, par
# l'environnement, et n'est jamais affiche.

2
playbooks/proxmox/README.md
View file

@ -46,7 +46,7 @@ instance/inventories/production/group_vars/all/vault.yml
`make config` la sème depuis le gabarit et y place le token. Le clonage lit cette voûte
unifiée. (`proxmox.vault.yml` n'est plus lue — retirée le 2026-08-03.) Détail des
paramètres : [`docs/config-proxmox.md`](../../docs/config-proxmox.md).
paramètres : [`docs/exploitation/config-proxmox.md`](../../docs/exploitation/config-proxmox.md).
Créer un clone Debian depuis le modèle :

4
playbooks/proxmox/cloner_vm_debian.yml
View file

@ -30,7 +30,7 @@
# Meme derivation que le fichier ci-dessus : le symlink `underlay.yml` designe deja
# l'hebergeur, on n'a rien a redeclarer. Depuis le 2026-08-22 ces secrets ne vivent
# plus dans la voute d'un tenant : recopies chez chacun, ils ne pouvaient plus etre
# revoques isolement (docs/frontiere-physique-virtuel.md).
# revoques isolement (docs/conception/frontiere-physique-virtuel.md).
setops_voute_underlay: "{{ setops_carte_underlay | realpath | dirname }}/underlay.vault.yml"
tasks:
@ -144,7 +144,7 @@
# L'exploitant doit garder son acces a la machine qu'il vient de creer : ecraser sa
# cle par celle du runner rendrait le runner seul maitre du terrain, ce qui est
# exactement l'inverse de la doctrine (c'est l'humain qui arme, cf.
# docs/filiation-emancipation.md). Deux cles, deux lignes, et cloud-init les pose
# docs/conception/filiation-emancipation.md). Deux cles, deux lignes, et cloud-init les pose
# toutes les deux.
#
# Elle n'arrive ICI que pour le runner d'un tenant : `inventory_host.py` la rend vide

2
promo/histoire.html
View file

@ -532,7 +532,7 @@
{"hash":"e17ae54fda0884f2b74830bb92d7069dc2c10c59","date":"2026-07-02","subject":"serveur_postfix : résolution du plancher /etc/hosts (native + chroot)"},
{"hash":"5846a08667bfbc712078f3520a9ca08dde56636d","date":"2026-07-02","subject":"serveur_dovecot : remise LMTP fonctionnelle — flux courriel interne prouvé"},
{"hash":"8df1db3b4740ecb1d34082fc13e0cfcd4231c3eb","date":"2026-07-02","subject":"serveur_rspamd (rspamd 3.x) : antispam + DKIM en milter Postfix — prouvé"},
{"hash":"defe16d1769d17c2d87776f10deef65219c2e35c","date":"2026-07-02","subject":"docs: bilan des pouvoirs de Set-OPS (docs/pouvoirs-set-ops.md)"},
{"hash":"defe16d1769d17c2d87776f10deef65219c2e35c","date":"2026-07-02","subject":"docs: bilan des pouvoirs de Set-OPS (docs/projet/pouvoirs-set-ops.md)"},
{"hash":"60b7de980f3763489c547a9787230844f35b1b47","date":"2026-07-02","subject":"Licence : CC BY-NC-SA 4.0 → AGPLv3 (verbatim) + modèle libre/services"},
{"hash":"4454e1e18bff73eed1290b5135db4a3fedb23b3c","date":"2026-07-03","subject":"docs: conception des bindings (relations app/base/serveur/domaine)"},
{"hash":"d95b26c2430012f7e665617212cc87e56282a6c1","date":"2026-07-03","subject":"bindings Phase 1 : résolveur de liens dans instancier (relations déclaratives)"},

4
roles/amorcage_acces/README.md
View file

@ -6,7 +6,7 @@ seule fois, pour que l'exploitant puisse prendre la main. Puis se retire.
## Ce qu'il ne fait pas
Ce n'est **pas** un gestionnaire de comptes. Après son passage, créer, suspendre ou
réaffecter relève d'une personne — pas du dépôt (D-67, `docs/autorisation.md`).
réaffecter relève d'une personne — pas du dépôt (D-67, `docs/exploitation/autorisation.md`).
## Idempotence par existence, pas par conformité
@ -39,6 +39,6 @@ connexion à l'annuaire est dérivée par `resoudre_annuaire`, jamais écrite.
## Après
`docs/autorisation.md` §6 est le runbook de reprise : où administrer quoi, comment se
`docs/exploitation/autorisation.md` §6 est le runbook de reprise : où administrer quoi, comment se
rouvrir si on se ferme dehors, et ce qu'il faut régénérer pour que la livraison soit un
vrai transfert.

2
roles/amorcage_acces/defaults/main.yml
View file

@ -8,7 +8,7 @@
# promu, deplace — c'est le droit de celui qui exploite. Reconcilier effacerait
# le compte cree la veille pour un nouvel employe.
#
# Voir docs/autorisation.md (§6 = runbook de reprise).
# Voir docs/exploitation/autorisation.md (§6 = runbook de reprise).
amorcage_acces_actif: true

8
roles/amorcage_acces/tasks/main.yml
View file

@ -1,6 +1,6 @@
---
# Amorcage des acces — D-67. Voir defaults/main.yml pour la doctrine, et
# docs/autorisation.md §6 pour le runbook de reprise.
# docs/exploitation/autorisation.md §6 pour le runbook de reprise.
- name: Résoudre la connexion à l'annuaire
ansible.builtin.include_role:
@ -23,7 +23,7 @@
fail_msg: >-
`vault_sysadmin_amorcage` et `vault_openldap_admin` sont requis (voûte).
Le premier est un jeton d'amorçage à usage unique — pas un mot de passe
permanent : voir docs/autorisation.md §6.
permanent : voir docs/exploitation/autorisation.md §6.
when: amorcage_acces_actif | bool
# --- LE CŒUR DU RÔLE : on REGARDE avant d'agir --------------------------------
@ -54,7 +54,7 @@
msg: >-
Compte `{{ amorcage_acces_uid }}` déjà présent : Set-OPS n'y touche pas.
Les habilitations sont gouvernées par une personne (D-67) — voir
docs/autorisation.md §6.
docs/exploitation/autorisation.md §6.
when:
- amorcage_acces_actif | bool
- amorcage_acces_deja_fait | bool
@ -186,7 +186,7 @@
(amorcage_acces_reset_possible | bool)
| ternary('Changement FORCÉ à la première ouverture (ppolicy actif).',
'ATTENTION : rien ne force le changement — l overlay ppolicy n est pas chargé. '
~ 'Le changer à la main dès la première connexion (docs/autorisation.md §6).'),
~ 'Le changer à la main dès la première connexion (docs/exploitation/autorisation.md §6).'),
'À partir d ici, Set-OPS ne touche plus aux habilitations (D-67).'
] }}
when:

2
roles/auditd/templates/sonde-audit.sh.j2
View file

@ -9,7 +9,7 @@
# dont le demon depend. Une sonde qui aurait compte les regles aurait dit « vert » pendant
# toute la panne. On mesure donc la COLLECTE — le service, puis l'ecriture.
#
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Contrat : docs/conception/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Mise en defaut PAR PARAMETRE : `auditd_sonde_age_max` (le baisser a 1).
set -uo pipefail

2
roles/chrony/templates/sonde-horloge.sh.j2
View file

@ -14,7 +14,7 @@
# tombe en panne de l'interieur, avec des symptomes qui ressemblent a tout sauf a une
# horloge.
#
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Contrat : docs/conception/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Mise en defaut PAR PARAMETRE : `chrony_sonde_ecart_max` (le baisser a 0).
set -uo pipefail

2
roles/client_artefacts/meta/integration.yml
View file

@ -1,6 +1,6 @@
---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
# raisonnement, et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
#

2
roles/client_backup/README.md
View file

@ -58,7 +58,7 @@ Sans eux, le rôle refuse de s'exécuter (assertion).
from-zero, déclencher une première sauvegarde plutôt que d'attendre 02:30.
- Restauration : **faite par la reconstruction elle-même** depuis le 2026-09-30 — chaque rôle
propriétaire inclut `tasks/restaurer.yml` et remet l'état de l'incarnation précédente ;
l'outil de nœud est `setops-restaurer` (cf. `docs/runbooks-exploitation.md` §5.0).
l'outil de nœud est `setops-restaurer` (cf. `docs/exploitation/runbooks-exploitation.md` §5.0).
- Témoins : `setops-restaurer temoins` (comparateur `setops-temoins`) confronte l'état vivant
à l'instantané d'avant rasage ; `make temoins-etat`, et l'étape `bilan` de la reconstruction.

2
roles/client_backup/meta/flux.yml
View file

@ -1,5 +1,5 @@
---
# Flux réseau du client de sauvegarde (restic -> dépôt hors-nœud). Voir docs/flux-conception.md.
# Flux réseau du client de sauvegarde (restic -> dépôt hors-nœud). Voir docs/conception/flux-conception.md.
flux:
- sens: egress
port: 22

2
roles/client_journal/meta/flux.yml
View file

@ -1,5 +1,5 @@
---
# Flux réseau du client journal (Alloy -> Loki). Voir docs/flux-conception.md.
# Flux réseau du client journal (Alloy -> Loki). Voir docs/conception/flux-conception.md.
flux:
- sens: egress
port: 3100

2
roles/client_journal/meta/integration.yml
View file

@ -1,6 +1,6 @@
---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
# raisonnement, et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
#

2
roles/client_journal/meta/supervision.yml
View file

@ -1,5 +1,5 @@
---
# Supervision derivee du role. Voir docs/supervision-conception.md.
# Supervision derivee du role. Voir docs/conception/supervision-conception.md.
#
# CE QUE CETTE SONDE MESURE : les journaux SORTENT-ILS ? Pas « Alloy tourne », pas
# « le port de Loki repond » — un connect() ne prouve rien, et cette lecon a deja ete

2
roles/client_journal/tasks/main.yml
View file

@ -312,7 +312,7 @@
enabled: true
state: started
# LA SONDE VIT AVEC LE ROLE QU'ELLE MESURE (docs/supervision-conception.md). Le porteur
# LA SONDE VIT AVEC LE ROLE QU'ELLE MESURE (docs/conception/supervision-conception.md). Le porteur
# `client_sante` fait tourner tout ce qui vit dans ce repertoire ; il n'a pas a savoir ce
# que celle-ci mesure.
- name: Assurer le repertoire des sondes de supervision

2
roles/client_journal/templates/sonde-journaux.sh.j2
View file

@ -3,7 +3,7 @@
#
# SONDE « journaux » — les lignes SORTENT-ELLES vers Loki ?
#
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Contrat : docs/conception/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Mise en defaut PAR PARAMETRE : `client_journal_sonde_url` (port ferme).
set -uo pipefail

2
roles/client_metrique/meta/flux.yml
View file

@ -1,5 +1,5 @@
---
# Flux réseau de node_exporter (propriété du rôle). Voir docs/flux-conception.md.
# Flux réseau de node_exporter (propriété du rôle). Voir docs/conception/flux-conception.md.
flux:
- sens: ingress
port: 9100

2
roles/client_metrique/meta/integration.yml
View file

@ -1,7 +1,7 @@
---
# Politique d'integration. Declaree ICI, une fois, plutot que recopiee sur chaque
# serveur du plan : une ligne recopiee 14 fois n'existe que pour etre oubliee une
# quinzieme. Voir docs/integrations-vm.md et docs/decisions-architecture.md (D-33).
# quinzieme. Voir docs/conception/integrations-vm.md et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
#

2
roles/client_metrique/meta/supervision.yml
View file

@ -1,5 +1,5 @@
---
# Supervision derivee du role. Voir docs/supervision-conception.md.
# Supervision derivee du role. Voir docs/conception/supervision-conception.md.
#
# CE QUE CETTE SONDE MESURE. La question utile n'est pas « node_exporter tourne-t-il ? »
# — un service actif qui ne rend aucune metrique est vert pour systemd et muet pour

2
roles/client_metrique/tasks/main.yml
View file

@ -122,7 +122,7 @@
enabled: true
state: started
# LA SONDE VIT AVEC LE ROLE QU'ELLE MESURE (docs/supervision-conception.md). Le porteur
# LA SONDE VIT AVEC LE ROLE QU'ELLE MESURE (docs/conception/supervision-conception.md). Le porteur
# `client_sante` fait tourner tout ce qui vit dans ce repertoire ; il n'a pas a savoir ce
# que celle-ci mesure.
- name: Assurer le repertoire des sondes de supervision

2
roles/client_metrique/templates/sonde-metriques.sh.j2
View file

@ -3,7 +3,7 @@
#
# SONDE « metriques » — cette machine offre-t-elle vraiment ses metriques ?
#
# Contrat : docs/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Contrat : docs/conception/supervision-conception.md (API des greffons Nagios) — une ligne, 0/1/2.
# Mise en defaut PAR PARAMETRE : `client_metrique_sonde_url` (port ferme, mauvais schema).
set -uo pipefail

2
roles/client_pki/defaults/main.yml
View file

@ -119,7 +119,7 @@ client_pki_reload_services: []
# (~14 min), serre devant la duree de vie (24 h).
client_pki_marge_renouvellement: 3600
# --- Sonde de supervision (docs/supervision-conception.md) --------------------------
# --- Sonde de supervision (docs/conception/supervision-conception.md) --------------------------
#
# LES SEUILS DECOULENT DU MOMENT OU LE RENOUVELLEMENT EST DU — pas d'une intuition.
#

2
roles/client_pki/meta/flux.yml
View file

@ -1,5 +1,5 @@
---
# Flux réseau du client PKI (émission ACME + racine step-ca). Voir docs/flux-conception.md.
# Flux réseau du client PKI (émission ACME + racine step-ca). Voir docs/conception/flux-conception.md.
flux:
- sens: egress
port: 8443

4
roles/client_pki/meta/integration.yml
View file

@ -1,6 +1,6 @@
---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
# raisonnement, et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
#
@ -15,7 +15,7 @@ integration:
universelle: true
raison: >-
Tout hote fait confiance a l'AC interne et porte un certificat : c'est le
prerequis du chiffrement est-ouest (voir docs/zero-confiance.md). Un hote sans
prerequis du chiffrement est-ouest (voir docs/conception/flux-conception.md, champ `chiffrement`). Un hote sans
certificat ne peut ni presenter ni verifier — il retombe en clair en silence.
# AUCUNE exemption, et l'autorite non plus. Elle ne s'ENROLE pas aupres d'elle-meme —
# sa racine est deja sur son disque — mais elle a besoin de CERTIFICATS comme tout le

2
roles/client_pki/meta/supervision.yml
View file

@ -1,5 +1,5 @@
---
# Supervision derivee du role. Voir docs/supervision-conception.md.
# Supervision derivee du role. Voir docs/conception/supervision-conception.md.
#
# CE QUE CETTE SONDE MESURE, ET POURQUOI CELA PLUTOT QUE LE RESTE.
#

2
roles/client_pki/tasks/main.yml
View file

@ -418,7 +418,7 @@
state: started
daemon_reload: true
# --- Sonde de supervision (docs/supervision-conception.md) --------------------------
# --- Sonde de supervision (docs/conception/supervision-conception.md) --------------------------
#
# LE ROLE QUI POSSEDE LA VERITE DEPOSE SA PROPRE SONDE. Il connait ses chemins, ses
# seuils, son consommateur — le superviseur, lui, ne connait que le verdict. C'est la

2
roles/client_pki/templates/sonde-certificat.sh.j2
View file

@ -3,7 +3,7 @@
#
# SONDE : le certificat d'hote tiendra-t-il jusqu'au prochain renouvellement ?
#
# Contrat (docs/supervision-conception.md) : une ligne sur la sortie standard,
# Contrat (docs/conception/supervision-conception.md) : une ligne sur la sortie standard,
# 0 = OK, 1 = AVERTISSEMENT, 2 = CRITIQUE. Aucun acces reseau requis — c'est le porteur
# (`client_sante`) qui pousse le resultat a Icinga.
set -uo pipefail

2
roles/client_resolveur/README.md
View file

@ -2,7 +2,7 @@
**Résolveur local** par nœud (Unbound) : cache + récursion, avec une **stub-zone** vers
l'autoritatif interne (PowerDNS). Rend la résolution *dynamique* sans casser Internet.
Troisième et dernière couche du DNS interne (`docs/dns-interne.md`).
Troisième et dernière couche du DNS interne (`docs/conception/dns-interne.md`).
## Les trois couches
1. `hosts_statiques` — plancher `/etc/hosts`, toujours là, indépendant de tout service ;

2
roles/client_resolveur/meta/flux.yml
View file

@ -1,5 +1,5 @@
---
# Flux réseau du client de résolution. Voir docs/flux-conception.md.
# Flux réseau du client de résolution. Voir docs/conception/flux-conception.md.
#
# Il n'écoute plus rien : depuis 2026-08-24, le résolveur est un service du tenant et
# non un démon local. L'hôte ne fait qu'interroger.

2
roles/client_resolveur/meta/integration.yml
View file

@ -1,6 +1,6 @@
---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
# raisonnement, et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND, ET POURQUOI L'ORDRE COMPTE.
#

2
roles/client_sante/defaults/main.yml
View file

@ -63,7 +63,7 @@ client_sante_delai_sonde: 20
# CE QUE LE PORTEUR INSTALLE. `curl` pousse le resultat vers l'API d'Icinga ;
# `monitoring-plugins-basic` apporte les greffons standard que les roles reutilisent au
# lieu d'ecrire du shell (voir docs/supervision-conception.md). Ils vivent dans
# lieu d'ecrire du shell (voir docs/conception/supervision-conception.md). Ils vivent dans
# `/usr/lib/nagios/plugins/`.
client_sante_paquets:
- curl

2
roles/client_sante/meta/flux.yml
View file

@ -1,6 +1,6 @@
---
# Flux reseau du rapport de sante (resultat passif -> API Icinga). Voir
# docs/flux-conception.md.
# docs/conception/flux-conception.md.
flux:
- sens: egress
port: 5665

2
roles/client_sante/meta/integration.yml
View file

@ -1,6 +1,6 @@
---
# Politique d'integration. Voir roles/client_metrique/meta/integration.yml pour le
# raisonnement, et docs/decisions-architecture.md (D-33).
# raisonnement, et docs/projet/decisions-architecture.md (D-33).
integration:
# DE QUI CETTE INTEGRATION DEPEND. Le noeud pousse un resultat PASSIF vers Icinga :
# sans destinataire, le rapport n'irait nulle part, et un timer qui echoue chaque

Some files were not shown because too many files have changed in this diff Show more