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

# 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
```