Set-OPS-Public/docs/positionnement.md

# 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 **quatre plans
   vivants** (mesuré le 2026-09-06) : Chezlepro 14 VM, Technolibre 15, le lab 15, plus les
   7 machines du site — **51 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)

> **Cette liste a été corrigée le 2026-09-08.** Deux de ses cinq lignes n'étaient plus
> vraies : elles décrivaient des manques que le dépôt a comblés **autrement**, et les
> garder en « manques » aurait fini par justifier d'adopter un outil pour un besoin déjà
> couvert. Une carte des seuils qui se trompe ne fait pas perdre du temps : elle fait
> franchir un seuil qui ne l'est pas.

Ce qui manque vraiment :

- **historique/audit des changements** au-delà de `git` — un journal applicatif, avec ses
  auteurs et ses motifs, que `git log` ne rend qu'imparfaitement ;
- **webhooks / intégrations tierces, API riche** (REST/GraphQL) — il n'y en a aucune, et
  aucun consommateur ne la réclame aujourd'hui ;
- **écosystème de plugins, communauté, correctifs de sécurité maintenus par d'autres.**
  C'est le seul point qui joue contre le maison **en permanence** : il ne dépend d'aucun
  seuil, il s'aggrave tout seul avec le temps. À relire chaque année, pas quand un besoin
  apparaît.

Ce qui était listé comme manquant et ne l'est plus :

| Ancien manque | Ce qui le couvre, et pourquoi c'est différent |
|---|---|
| ~~RBAC multi-utilisateurs~~ | **Résolu, et par un mécanisme plus fort.** Trois classes d'acteurs aux pouvoirs disjoints existent — le poste de l'exploitant, le **runner de site** (matérialiser ; ne rentre jamais chez un tenant) et les **runners de tenant** (configurer). La séparation est **cryptographique** — une voûte, une clé (2026-08-28) — et non applicative : c'est la *présence des fichiers* qui borne le pouvoir, jamais une table de permissions qu'une faille de l'application contournerait. |
| ~~Détection de conflits IPAM, réservations~~ | **Sans objet par construction.** Un IPAM sert à *allouer* ; ici rien ne s'alloue, tout dérive du seed `index`. Et cinq preuves tiennent déjà ce qu'un IPAM vérifierait : **P20** (aucun adressage stocké), **P21** (collisions d'index), **P23** (chevauchement d'underlay), **P28** (pools), **P33** (ports co-localisés). Adopter un IPAM remplacerait une propriété *par construction* par un contrôle *a posteriori*. |

---

## 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 :

> **Ce tableau a été écrit avant que les runners existent**, et deux de ses lignes visaient
> des besoins depuis couverts (§3). Corrigé le 2026-09-08.

| Besoin qui apparaît | Adopter |
| --- | --- |
| **Plusieurs HUMAINS, aux portées disjointes, sur des machines qui ne sont pas les tiennes** | à trancher — voir ci-dessous, c'est le seuil qui approche et qu'aucune ligne ne nommait |
| Historique d'audit applicatif, secrets/credentials centralisés pour des tiers | **AWX** (exécution) |
| Source de vérité **partagée** entre organisations, API/webhooks avec des consommateurs réels | **NetBox** (et `nb_inventory` remplacerait 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** |

*Retiré de ce tableau : « RBAC » et « IPAM sérieux, détection de conflits ». Les deux sont
couverts (§3), et les garder ici aurait fait adopter un outil pour un besoin déjà rempli.*

### Le seuil qui approche, et qu'aucune ligne ne nommait

**L'émancipation.** Le GUI écoute sur `127.0.0.1` avec un jeton par session : un modèle
**mono-utilisateur**, parfait tant que l'exploitant est une personne à son poste. Le jour où
un tenant est exploité par **son** organisation — c'est la trajectoire de
[`filiation-emancipation.md`](filiation-emancipation.md), et l'offre destinée aux OBNL y
mène — il y a plusieurs humains, aux portées disjointes, sur des machines qui ne sont pas
les tiennes.

Ce n'est **pas** AWX qu'appelle ce seuil : les runners portent déjà la séparation des
pouvoirs, cryptographiquement. Ce qu'il appelle, c'est une décision sur la **façon dont le
GUI s'ouvre à quelqu'un d'autre** — et elle n'est pas prise. La nommer ici est le minimum :
*un seuil qu'on ne nomme pas est un seuil qu'on franchit sans le voir.*

**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. **Mais vérifier d'abord que le besoin n'est pas déjà couvert
autrement** — c'est exactement l'erreur que ce tableau portait.

---

## 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). **Le 2026-09-08, c'est la carte des
  seuils qui a été corrigée, pas le gel qui a été levé** — la question « et si on retirait
  le gel ? » a montré que deux seuils étaient mal posés, pas que le gel était de trop.
- 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.

> **Ce que le gel n'interdit pas, et qu'on confond souvent avec lui.** Il porte sur les
> *fonctions de type NetBox/AWX*, pas sur les **vues**. Montrer à l'écran ce que le moteur
> sait déjà — l'écart des dix devis, l'état du diff entre « Sauvegarder » et « Appliquer »,
> le périmètre sur lequel un ✅ a porté, les témoins du génome et lequel a décroché — ne
> franchit aucun seuil : rien de tout cela n'existe dans NetBox ou AWX, parce que rien de
> tout cela n'existe hors de ce modèle.