# 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. *(Patient 0 en portait 5 ; ses machines n'existent plus.)* Ç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.