Daniel Allaire ac85278366 preuve : P34 — chaque document declare son lecteur (D-74)

La refonte de ce matin posait une convention. Une convention qu'on n'outille
pas tient tant que quelqu'un y pense : c'est le raisonnement de D-70, applique
au corpus documentaire.

Etat de depart mesure : 2 documents sur 34 declaraient leur lecteur. Les 32
autres disaient leur SUJET — ce qui avait enfoui le runbook de reprise le plus
utile du depot au §6 de autorisation.md.

Les 38 le declarent desormais, lecteur determine document par document et non
colle au gabarit : l'exploitant (devis, migration de tenant, cycle de vie,
gabarit d'or), le mainteneur (conceptions, registres, carte), le lecteur
externe (ecosysteme-chezlepro), l'agent IA (MISE-A-JOUR-CODEX-CLAUDE).

Deux exemptions DERIVEES, pas listees — un chemin en dur aurait vieilli a la
premiere page ajoutee : un document qui s'annonce genere, et un fragment sans
titre. Les 13 exemptes verifies un par un ; aucun document ecrit a la main
n'est exempte par accident. La preuve ne lit que l'EN-TETE, ce qui empeche
frontiere-opnsense.md et plan-et-generation.md — qui parlent de generation
dans leur corps — d'etre exemptes a tort.

Eprouvee dans les deux sens. Elle a echoue seule des sa premiere execution en
nommant deux documents que mon inventaire avait manques (docs/audit/). Puis
test negatif delibere : declaration retiree de meta-classe.md -> ECHEC la
nommant ; restauree -> OK.

Ce qu'elle ne teste pas : que le lecteur declare soit le BON. Ca se juge en
revue ; elle garantit qu'on a du y penser.

P01–P34. Comptes perimes corriges au passage (AGENTS.md et devis-services.md
annoncaient encore 30 preuves).

Verifie : prouver.py 0 (34 OK), plan-recette inchange.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-10 07:53:04 -04:00

5.1 KiB

Raw Blame History

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 :

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.
Bon dimensionnement — ~13 VM. NetBox est de la machinerie d'échelle entreprise.
Modèle sur-mesure — NetBox exprimerait nos DSN / expositions à coups de custom fields et de plugins, moins naturellement que nos registres.
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.

5.1 KiB Raw Blame History