Set-OPS-Public/docs/filiation-emancipation.md

Filiation, mutualisation, émancipation

Pour qui : l'architecte de la lignée et l'hébergeur qui abrite des écosystèmes tiers. Décrit les trois âges d'un écosystème et ce qu'ils impliquent au plan.

Le constat

Un écosystème ne naît pas autoportant. Il lui faut une forge pour lire son génome, une source d'artefacts pour ses paquets, un dépôt pour ses sauvegardes — et rien de tout cela n'existe la première seconde. Il emprunte donc à son hôte.

Jusqu'ici, le moteur a rencontré ce besoin trois fois sans le nommer :

client_artefacts_actif    dérivé : « une source existe-t-elle chez moi ? »
serveur_ops_forge_externe « je lis mon génome ailleurs »
client_backup_cible       patient 0 sauvegarde chez eregion — mutualisé, en production

Trois astuces, une seule notion. Ce document la déclare.

Les trois âges

FILIATION       l'enfant emprunte à son parent ce qu'il ne porte pas encore
MUTUALISATION   un état DURABLE et CHOISI — on emprunte parce qu'on le veut
ÉMANCIPATION    l'écosystème porte tout lui-même

L'émancipation n'est pas une obligation. Un petit organisme peut rester mutualisé toute sa vie ; ce qui compte est qu'il puisse s'émanciper, et que la sortie ne soit ni un piège ni une reconstruction. C'est la différence entre un locataire et un captif.

Ce que ça veut dire pour les modèles

Un modèle sans forge n'est pas un modèle amputé : c'est un écosystème au premier âge, dont le runner lit le génome chez son hôte. L'ajout d'une forge n'est pas une correction, c'est une émancipation.

premier âge   serveur_ops_forge_externe: true   + l'adresse de la forge de l'hôte
émancipé      serveur_ops_forge_externe: false  + sa propre serveur_forgejo au plan

Ce que ça veut dire pour l'hébergeur

L'hébergeur ne vend plus seulement des machines : il vend l'abri pendant la jeunesse. Chaque service mutualisé est une ligne de facture, et chaque émancipation est une décision du client — jamais une rupture technique.

Pour une clientèle d'OBNL et de coopératives, c'est le bon geste : on entre à bas coût, on grandit vers l'autonomie, et on n'est jamais captif, puisque le génome est déjà chez soi dès le premier jour.

Ce qui est mutualisable, et ce qui ne l'est pas

service	mutualisable	remarque
forge (génome)	oui	serveur_ops_forge_externe
source d'artefacts	oui	client_artefacts se désactive seul si aucune n'existe
sauvegarde	oui	client_backup_cible pointe déjà hors de l'écosystème
observabilité	oui	l'hébergeur surveille ses locataires
relais courriel	oui
DNS	partiellement	un sous-domaine délégué, pas la zone entière
PKI	à trancher	une AC intermédiaire signée par l'hôte est possible, mais l'AC définit l'identité de l'écosystème
identité (LDAP/SSO)	le plus intime	mutualiser l'annuaire, c'est confier ses gens
la voûte	jamais	les secrets ne se mutualisent pas, à aucun âge

L'insémination — le premier lien, et le seul que le SITE ait le droit d'avoir

Entre tenants, le zéro-confiance est le défaut : la frontière refuse tout ce qui n'est pas déclaré, et c'est cette règle qui rend l'hébergement mutualisé défendable. La parenté est la seule exception, et elle est asymétrique : un écosystème neuf ne peut pas s'amorcer lui-même. Quelqu'un doit poser sa première machine et lui donner de quoi continuer.

Ce geste s'appelle l'insémination :

le SITE matérialise        VNets, VM, routes, flux — le terrain
le SITE amorce ops-01      la première machine, et elle seule
le TENANT achève           ses autres machines, ses rôles, ses intégrations

Le partage d'intelligence qui le rend possible. Les deux runners portent le même moteur ; ils n'en consomment pas la même face :

	ce qu'il lit du moteur	ce qu'il en fait
runner du SITE	roles/*/meta/flux.yml — la face réseau des rôles	SDN, pare-feu Proxmox, frontière OPNsense
runner du TENANT	tasks/, templates/, meta/integration.yml — la face machine	configure ses services

C'est ce partage qui permet au SITE de poser les bonnes règles pour un tenant sans jamais lire sa configuration ni détenir sa voûte. Il sait de quoi les rôles ont besoin sur le fil ; il ignore ce qu'ils font sur la machine.

Ce que le lien doit être, pour ne pas devenir un pouvoir permanent :

• étroit — vers le seul ops-01 du tenant, jamais vers ses autres machines ;
• déclaré — dans meta/flux.yml, comme tout le reste, pour que la frontière et nftables le connaissent au lieu de le subir ;
• borné par un acte, et cet acte appartient à un humain (voir ci-dessous).

Ce qui existe déjà sans être déclaré, au 2026-08-28. make creer-vm exige _instance-requise : pour matérialiser les VM d'un tenant, le runner du SITE doit basculer son symlink instance sur le dépôt de ce tenant — alors que son plan pose serveur_ops_instance: "" et que la doctrine dit qu'un SITE n'a pas de plan monté par ce lien. Le couplage est donc déjà là, et rien ne borne sur quels tenants il porte ni jusqu'à quand. Le déclarer, c'est le rendre limitable ; le taire ne l'a jamais empêché.

Ce que l'émancipation exige — et de qui

Basculer une déclaration ne suffit pas. Mais l'erreur symétrique est plus tentante encore : faire de l'émancipation un automatisme, que la machine déclencherait dès qu'elle constate que le tenant se reproduit sans son parent.

L'émancipation exige toujours la gouverne d'un humain. Le fruit de l'émancipation est livré à quelqu'un — un client qui reprend ses clés, sa forge, son écosystème. Sans quelqu'un pour le recevoir, il n'y a pas de livraison : seulement un lien qui tombe. Une émancipation qui se déclencherait toute seule ne serait pas une émancipation, ce serait une expulsion.

C'est déjà la forme des gestes lourds de ce dépôt : raser exige CONFIRMER=true et le nom de l'instance ; le mot de passe de la voûte se tape à l'exécution — « le seul objet que la reproduction exige d'un humain ». L'émancipation est le deuxième objet de cette liste.

D'où la répartition, qui ne se confond pas :

	qui l'exécute
le lien de filiation — déclaré, étroit, visible au plan	le moteur
le constat d'aptitude — « ce tenant se reproduit sans son parent »	la machine — elle instruit, elle n'agit pas
l'acte d'émancipation — retirer le lien, remettre les clés	l'humain, garde CONFIRMER=true
la preuve que le lien est coupé	la machine, après l'acte

La quatrième ligne est celle qu'on oublie, et c'est elle qui décide si les trois autres ont servi. Sans elle, on croirait s'être émancipé en restant dépendant sans le savoir — exactement le défaut que ce dépôt traque partout ailleurs : un vert sur un périmètre vide. Une émancipation non prouvée est une émancipation non faite.

L'instrument de la quatrième ligne — make emancipation-prouver

Il existe depuis le 2026-09-01, et il coupe au lieu de sonder.

Vérifier que le service local répond ne prouve rien : tant que l'amont répond, une fonction qui marche ne dit pas d'où vient l'octet. L'instrument bloque donc l'amont — table nftables dédiée, retirée par un bloc always quoi qu'il arrive — puis refait marcher la chose.

Le même essai rend les deux verdicts, et c'est ce qui le rend honnête :

coupé, la fonction marche  ->  ÉMANCIPÉ, et c'est prouvé
coupé, la fonction casse   ->  PAS ÉMANCIPÉ, et la dépendance est prouvée RÉELLE

Le second n'est pas un échec de l'outil : c'est son contrôle négatif, rendu par la même commande. Une preuve d'émancipation incapable de montrer la dépendance qu'elle mesure ne prouverait rien le jour où elle passerait au vert.

Un témoin précède la coupure — la fonction marchait-elle seulement avant ? Sans lui, une panne préexistante se lirait comme une dépendance.

make emancipation-prouver SERVICE=artefacts HOTE=forge-01 CONFIRMER=true

Mesuré le jour de sa naissance : obs-01 ne résout plus rien dès que le résolveur du site est coupé — dépendance réelle ; forge-01 installe des paquets le cache du site coupé, listes vidées — émancipation prouvée sur ce service.

Forme attendue d'une déclaration

Tout service mutualisable doit se déclarer de la même façon, pour qu'un exploitant lise l'état de son écosystème d'un coup d'œil plutôt qu'en fouillant chaque rôle :

<service>_externe: true          # je l'emprunte
<service>_amont: "https://…"     # à qui

false — ou l'absence du couple — signifie chez moi. Le rôle refuse de démarrer si le drapeau est levé sans que l'amont soit nommé : emprunter sans dire à qui, c'est ne rien déclarer du tout.

Qui est le parent ? — tranché le 2026-08-31 (D-82)

Le dilemme est resté ouvert trois jours. Les faits l'ont tranché plus que le raisonnement : personne n'est le parent, et la forge du SITE est l'autorité.

Trois issues avaient été posées. C'est la deuxième qui l'emporte, non parce qu'elle était la plus élégante, mais parce que les deux autres avaient cessé d'être disponibles :

• patient 0 redevient la source — impossible sans le rendre atteignable depuis tout site, alors qu'il vit dans la fabric d'un seul, en locataire de son propre descendant ;
• le SITE est la source ✔ — c'est ce que D-81 avait déjà fait, et que le reste du dépôt a suivi sans qu'on le déclare : serveur_forge_site, puis serveur_cache_site, puis serveur_resolveur_site. Trois services prêtés, un seul patron ;
• une famille de pairs — reste vraie pour la redondance. C'est ce que patient 0 gardait : un miroir du génome, comme chaque écosystème. Il perdait le rang, pas la place.

Il a perdu la place aussi : ses machines n'existent plus (2026-09-06). La famille du génome compte donc deux copies vivantes au lieu de trois — eregion et la forge du site. Or c'est précisément le raisonnement ci-dessus qui portait tout : on n'échappe pas à la boucle par la ruse, mais par le nombre. Le nombre a baissé, et le SPOF que patient 0 devait absorber (eregion, hors flotte) est toujours là.

Ce que ça ne règle pas. Le point unique de défaillance que patient 0 devait éliminer — eregion, hors flotte — n'a pas disparu : il alimente maintenant l'autorité. La dette a changé de propriétaire, pas de nature. Elle appartient au SITE.

État — revu le 2026-09-06

Seule la forge porte cette déclaration complète (serveur_ops). Les autres services mutualisés le sont par des mécanismes antérieurs, cohérents mais non uniformes. Les aligner sur la forme ci-dessus reste à faire.

Des trois manques que cette section listait au 2026-08-28, deux sont comblés :

Manque du 2026-08-28	Aujourd'hui
l'instrument de preuve de la dernière ligne — « le lien est coupé » — n'existe pas	make emancipation-prouver, depuis le 2026-09-01 (§ ci-dessus). Il coupe au lieu de sonder, et rend les deux verdicts.
la séparation des voûtes est organisationnelle, pas cryptographique — un seul mot de passe ouvre celle du site et celles des tenants	Séparé le 2026-08-28 même : une voûte, une clé (~/.config/setops-vault-<dépôt>, scripts/voutes.py). L'ancien mot de passe unique n'ouvre plus rien. La séparation précédait nécessairement la distribution des clés aux runners : sinon, poser « la » clé sur le plus petit locataire lui donnait les secrets de l'hébergeur.
le lien d'insémination n'est pas déclaré	Toujours vrai. Il existe, par le symlink instance du runner du SITE, sans borne ni visibilité. C'est le manque qui reste.

(Le paragraphe sur les voûtes se contredisait avec scripts/voutes.py — daté du même jour — et celui sur l'instrument avec la section qui le décrit, deux écrans plus haut. Un document qui se contredit lui-même à cette distance n'est plus lu comme une référence.)