diff --git a/AGENTS.md b/AGENTS.md index 9ea664d..0612bc5 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -51,6 +51,8 @@ L’inventaire Ansible est **généré** depuis le plan. Référence complète : **`docs/plan-et-generation.md`**. +**Plan de contrôle gelé en périmètre** : le GUI, le générateur, l'IPAM et la modélisation sont volontairement *maison* et **souverains**, mais leur périmètre est gelé. Ne pas y ajouter de fonctionnalités de type NetBox/AWX (RBAC, historique d'audit, détection de conflits IPAM, API riche) : le besoin réel d'une de ces fonctions est le **signal d'adopter l'outil mûr correspondant** (NetBox pour la source de vérité, AWX pour l'exécution), pas de le réimplémenter. Décision et seuils : **`docs/positionnement.md`**. + --- ## Règle d’or IA diff --git a/CHANGELOG.md b/CHANGELOG.md index cfe3ecd..486388b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -3,6 +3,7 @@ ## 2026-06-23 ### Ajouté +- **`docs/positionnement.md` — décision de positionnement vs l'existant.** Acte que le cœur de Set-OPS (plan déclaratif → génération d'inventaire) recoupe **NetBox/Nautobot** (+ `nb_inventory`), le GUI d'exécution recoupe **AWX/Semaphore**, le « la définition instancie la flotte » recoupe **NixOS+Colmena / Terraform**, et le modèle application-pivot recoupe **Backstage**. Décision en vigueur : on **garde** le plan de contrôle maison (souverain, bien dimensionné pour ~13 VM) mais on **gèle son périmètre** ; seuils explicites d'adoption de l'outil mûr (RBAC/audit → AWX ; IPAM/source de vérité partagée → NetBox). Règle ancrée dans `AGENTS.md`. - **Documentation — passe complète (le dépôt « dit ce qu'il fait »).** Nouveau guide central **`docs/plan-et-generation.md`** : le modèle (entités + liens), les registres et leurs schémas, la référence des commandes `make`/CLI et des vues GUI, le flux « éditer le plan → `instancier` → appliquer », les garde-fous. `AGENTS.md` gagne la section « Le plan et la génération de l'inventaire » (règle d'or : `hosts.yml` est généré, ne pas l'éditer). `README.md` : section « Le plan : on édite, l'inventaire se génère » + remplacement du flux legacy `hote-planifier`/`ajouter` par le flux par le plan. Rafraîchissement de `docs/architecture-set-ops.md` (entités du plan), `docs/nomenclature-vm.md` et `docs/catalogue-services.md` ; correction de la terminologie **domaine → fonction** dans la prose (collision avec le DNS levée jusque dans la doc). ### Modifié diff --git a/docs/positionnement.md b/docs/positionnement.md new file mode 100644 index 0000000..b0aacef --- /dev/null +++ b/docs/positionnement.md @@ -0,0 +1,95 @@ +# Positionnement : ce que Set-OPS fait maison, et quand adopter l'existant + +Ce document **acte une décision** pour ne plus la redébattre à chaque évolution : +quelles parties de Set-OPS sont volontairement *maison*, pourquoi, et à partir de +quel **seuil** il vaudra mieux adopter un outil du marché plutôt que continuer à +le réimplémenter. + +> En une phrase : le cœur de Set-OPS (un plan déclaratif qui génère l'inventaire +> Ansible) **existe déjà sous forme mûre** — c'est NetBox. Set-OPS en est une +> version **souveraine, légère et sur-mesure**, assumée comme telle. Le risque à +> surveiller est de réimplémenter NetBox/AWX brique par brique. + +--- + +## 1. La carte : chaque facette a un équivalent du marché + +| Facette de Set-OPS | Équivalent mûr | Remarque | +| --- | --- | --- | +| Source de vérité déclarative → **génère l'inventaire Ansible** | **NetBox** / **Nautobot** + plugin `netbox.netbox.nb_inventory` | Le plus proche du **cœur** de Set-OPS (le « plan »). | +| GUI qui **exécute** Ansible (déployer, RBAC, planification) | **AWX** / Ansible Automation Platform ; **Semaphore** | Set-OPS a un GUI plus modeste (lancer `make`). | +| « La **définition instancie** toute la flotte » | **NixOS + Colmena/morph** ; **Terraform** (provider Proxmox) pour créer les VM | L'idée « méta-classe » au sens littéral. | +| **Application = entité pivot** avec ses dépendances et ressources | **Backstage** (catalogue de composants + graphe) | Le modèle `requiert`/`utilise`/`expose` y ressemble fortement. | +| IPAM / dérivation d'adressage | **NetBox** (IPAM natif) | Set-OPS dérive depuis la nomenclature. | + +**Aucun** produit ne fait l'**assemblage exact** : Proxmox + Ansible + le modèle +bespoke (DSN, exposition DNS, dérivation par fonction) en **un seul outil +souverain et léger**. Cet assemblage-là est propre à Set-OPS. + +--- + +## 2. Ce que Set-OPS fait sciemment maison (et pourquoi) + +- **Le plan déclaratif** (`docs/serveurs.yml`, `applications.yml`, `bases-donnees.yml`, + `domaines.yml`, `nomenclature.yml`) et le **générateur d'inventaire** (`make instancier`). +- Le **modèle application-hub** : bindings DSN (portée application/groupe/hôte) et + exposition DNS, taillés exactement pour nos concepts. +- Le **GUI** (Python stdlib, fichier unique) et les **validateurs / garde-fous** + (diff-vide, `node --check`, vérificateurs de registres). + +Raisons assumées : + +1. **Souveraineté** — mission explicite du dépôt. NetBox + AWX + Backstage = trois + applications lourdes à héberger et maintenir (Django + PostgreSQL, etc.). Set-OPS + reste possédé en entier, sans dépendance. +2. **Bon dimensionnement** — ~13 VM. NetBox est de la machinerie d'échelle entreprise. +3. **Modèle sur-mesure** — NetBox exprimerait nos DSN / expositions à coups de + *custom fields* et de plugins, moins naturellement que nos registres. +4. **Maîtrise** — chaque ligne est comprise et auditable. + +--- + +## 3. Ce que le maison NE fait PAS (et que les outils mûrs ont) + +À garder en tête honnêtement — ce sont des fonctions qu'on n'a pas, pas des bugs : + +- historique/audit des changements (au-delà de `git`) ; +- RBAC multi-utilisateurs ; +- détection de conflits IPAM, réservations, gestion d'adresses à grande échelle ; +- webhooks / intégrations tierces, API riche (REST/GraphQL) ; +- écosystème de plugins, communauté, correctifs de sécurité maintenus par d'autres. + +--- + +## 4. La règle : plan de contrôle **gelé en fonctionnalités** + +Set-OPS continue d'évoluer pour **décrire et déployer l'écosystème** (rôles, +services, registres applicatifs). En revanche, le **plan de contrôle** (le GUI, +le générateur, l'IPAM, la modélisation) est considéré **gelé en périmètre** : on +ne lui ajoute pas de fonctionnalités de type NetBox/AWX. + +### Seuils d'adoption (les signaux de bascule) + +Adopter l'outil du marché — **sans réécrire**, en branchant Ansible/notre GUI +par-dessus — dès qu'un de ces besoins devient réel : + +| Besoin qui apparaît | Adopter | +| --- | --- | +| RBAC, plusieurs opérateurs, historique d'audit, secrets/credentials centralisés | **AWX** (exécution) | +| IPAM sérieux, détection de conflits, source de vérité partagée, API/webhooks | **NetBox** (et `nb_inventory` remplace notre générateur) | +| Catalogue de services / portail développeur, ownership, scaffolding | **Backstage** | +| Provisionnement de VM déclaratif et reproductible à plus grande échelle | **Terraform** (Proxmox) ou **NixOS + Colmena** | + +**Test simple** : si on se surprend à vouloir réimplémenter une de ces fonctions +dans Set-OPS, c'est le signal d'adopter l'outil correspondant plutôt que de +prolonger le maison. + +--- + +## 5. Décision en vigueur + +- On **garde** le plan de contrôle maison : il fonctionne, il est souverain et + bien dimensionné pour aujourd'hui. Pas de réécriture sur NetBox « par principe ». +- On **gèle** son périmètre fonctionnel (voir §4). +- On **réévalue** à l'échéance d'un seuil ci-dessus, ou si la charge de + maintenance du maison dépasse le coût d'héberger l'outil mûr.