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, 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.