Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
La revision a commence par un balayage par motifs — chemins morts, cibles make absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque tout le reste : un motif ne voit que ce qui s exprime en motif. make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus haut. Il fallait lire pour la voir. 74 documents lus un par un. 66 corriges, 8 exacts. CE QUI ETAIT FRANCHEMENT FAUX AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre des VM reelles. Elle a ete rasee et remontee depuis zero trois fois. ecosysteme-chezlepro.md, le document montre a un client, portait la meme phrase : il se sous-vendait gravement. courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n est construit alors qu il rapporte des mesures datees du role en fonctionnement. hebergeur-exploitation.md disait rien n est fait d un depot qui existe. filiation-emancipation.md se contredisait a deux ecrans de distance. DES MODELES DECRITS D APRES UN MONDE ANTERIEUR Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le donnaient en exemple d integration FACULTATIVE — il est universel depuis le 2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki qui avait raison. CE QUI CASSE AU PREMIER ESSAI Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le FABRIQUE et le critere R2 de l epreuve d operateur independant. preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait detruite : raser derive du plan, il ne la detruira jamais — le risque est l inverse. Un mot de passe d essai en clair dans un depot public. DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux declarations reelles : 12 annonces, 21 reels. Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une erreur ajoute l assurance a l erreur. CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il nomme existe. P29 tient les positions d authentification, personne ne tient les habilitations. make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
103 lines
5.7 KiB
Markdown
103 lines
5.7 KiB
Markdown
# 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.
|