# Positionnement : ce que Set-OPS fait maison, et quand adopter l'existant

> **Pour qui :** le **mainteneur**, et quiconque arbitre une évolution : ce qui reste maison, et à quel seuil on adopte 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** — mais l'argument a bougé, et il faut le dire honnêtement.
   Ce document a longtemps écrit « ~13 VM ». Le moteur pilote aujourd'hui **cinq plans**
   (mesuré le 2026-09-06) : Chezlepro 14 VM, Technolibre 15, le lab 15, Patient 0 5, plus
   les 7 machines du site — **56 VM déclarées**, réparties sur des écosystèmes qui ne se
   parlent pas. Ça reste très loin de l'échelle entreprise pour laquelle NetBox est fait,
   et le seuil du §4 n'est pas franchi. Mais la courbe monte : c'est **le** chiffre à
   regarder quand on se demande si la décision tient encore.
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.