Acter le positionnement vs l'existant (docs/positionnement.md)

Le coeur de Set-OPS (plan -> generation d'inventaire) recoupe NetBox ;
l'execution recoupe AWX/Semaphore ; « la definition instancie la flotte »
recoupe NixOS+Colmena/Terraform ; le modele application-pivot recoupe
Backstage.

Decision : garder le plan de controle maison (souverain, bien dimensionne
pour ~13 VM) mais GELER son perimetre ; seuils explicites d'adoption de
l'outil mur. Regle ancree dans AGENTS.md (« plan de controle gele »).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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

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é

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.