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 n'existe pas encore. C'est la pièce manquante nommée
au bas de ce document.*

## 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 :

```yaml
<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 ? — dilemme ouvert au 2026-08-28

Ce document décrit la filiation sans dire **de qui** un écosystème descend. La question
n'est plus théorique depuis que les runners savent reconstruire : chaque écosystème rebâti
grave sa réponse dans son plan (`serveur_ops_forge_amont`), et N réponses différentes font
N lignées qu'on ne saura plus rapprocher.

La chaîne réelle, mesurée :

```
poste de l'exploitant ──push──▶ eregion.chezlepro.ca:2222
                                = forge.alliance-boreale.ca     ◀── HORS FLOTTE
        │ git bundle                          │ miroir 8 h
        ▼                                     ▼
  forge du SITE  ★ autorité (D-81)     forge de patient 0  ★ « la forge mère »
        │                                     │
        ▼                                     ▼
  les tenants du site                   (plus aucun lecteur)
```

Trois faits qui ne tiennent pas ensemble :

1. **Patient 0 ne sert plus personne.** Chezlepro était son dernier lecteur, corrigé le
   2026-08-26 vers la forge du site. Son dépôt affirme toujours sa raison d'être — *« porter
   les dépôts qui fabriquent les écosystèmes, et les servir à ses enfants »*.
2. **Le point unique de défaillance n'a pas été éliminé, il a été promu.** Patient 0 existe
   explicitement pour remplacer une machine hors flotte que Set-OPS ne déploie ni ne prouve
   — or c'est de cette machine que la forge faisant autorité tire son contenu.
3. **Le parent est locataire de son enfant.** Patient 0 est un tenant de la fabric d'un
   site qui descend de lui. L'ancêtre ne peut pas être le chemin de reprise de son hôte.

Trois issues, à trancher par l'exploitant — et par lui seul, comme toute émancipation :

| issue | ce qu'elle impose |
|---|---|
| **patient 0 redevient la source** ; chaque forge de SITE en miroite | le rendre atteignable depuis **tout** site — il vit aujourd'hui dans la fabric d'un seul |
| **le SITE est la source** ; patient 0 devient une **référence**, non un ancêtre | assumer que la racine est le poste + la machine hors flotte, donc l'intégrer à la flotte ou la remplacer |
| **pas de racine — une famille de pairs** ; D-81 se restreint à « autorité pour les tenants d'un site » | bâtir non pas une hiérarchie mais une **preuve de convergence** entre toutes les copies vivantes |

*Aucune n'est bloquante pour la reconstruction en cours : les tenants pointent déjà sur la
forge de leur site, ce qui reste vrai dans les trois.*

## État au 2026-08-28

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.

**Les deux pièces manquantes**, l'une et l'autre nommées plus haut :

- le **lien d'insémination** n'est pas déclaré — il existe pourtant, par le symlink
  `instance` du runner du SITE, sans borne ni visibilité ;
- l'**instrument de preuve** de la dernière ligne — « le lien est coupé » — n'existe pas.
  Tant qu'il manque, aucune émancipation ne peut être déclarée faite.

**Une limite mesurée le 2026-08-28, à connaître avant de s'appuyer sur cette frontière :**
la séparation des voûtes est **organisationnelle, pas cryptographique**. Les fichiers sont
bien séparés — le runner du SITE ne détient que `underlay.vault.yml`, vérifié sur la
machine — mais **un seul mot de passe ouvre la voûte du site et celles des tenants**. « Deux
pouvoirs, aucun omnipotent » décrit donc la répartition des fichiers, pas celle des clés.