verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

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

2026-09-06 16:18:23 -04:00

5.7 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 — 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.
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.7 KiB Raw Blame History