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 :
