Set-OPS/docs/positionnement.md

# 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** (`instance/plan/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.