# 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 « je sauvegarde chez le site » — 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 > **Le critère, à deux tranchants.** Un rôle appartient au SITE s'il sert la **relation** > avec les locataires, ou les machines du site elles-mêmes. Il appartient au TENANT s'il > sert des **utilisateurs** ou des **applications**. À l'usage, ça se décide sur deux > questions plus dures : > > 1. **Ce que le site ne doit pas pouvoir VOIR** — sinon l'hébergement n'est plus > souverain, quelles que soient les intentions. > 2. **Ce que le tenant doit pouvoir EMPORTER** — sinon l'émancipation est un mot. | 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 ; le site héberge du **chiffré côté client** et ne peut rien en juger | | **disponibilité** (est-ce debout ?) | oui | c'est sa fabric : il doit savoir qu'une VM est tombée | | **métriques** (charge, disque) | oui, avec réserve | révèlent des **rythmes d'activité**, pas du contenu | | **journaux** | **non** | voir ci-dessous — plus intime que l'annuaire | | relais courriel | oui | l'enveloppe transite ; le contenu appartient au locataire | | DNS | partiellement | un sous-domaine délégué, pas la zone entière | | **PKI** | **non** (tranché le 2026-09-10) | voir ci-dessous | | **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 | ### Pourquoi « observabilité » a été découpée en trois La ligne disait : *« observabilité | oui | l'hébergeur surveille ses locataires »*. Elle était trop grossière, et elle **contredisait ce qui tourne** : chaque écosystème a son propre Icinga, et celui du site ne voit que ses sept machines (mesuré le 2026-09-10). Surtout, elle autorisait en une case ce que la ligne du dessous interdit. **Les journaux contiennent du contenu** — un mot de passe dans un message d'erreur, une donnée métier dans une trace, qui a fait quoi et quand. Un hébergeur qui ingère les journaux de son locataire en sait **plus** que s'il détenait son annuaire : l'annuaire dit qui existe, les journaux disent ce qu'ils font. La disponibilité, elle, est légitime : une VM tombée est un fait de la **fabric**, que l'hébergeur porte. Les métriques sont entre les deux — elles ne disent pas *quoi*, mais elles disent *quand* et *combien*, ce qui suffit à lire l'activité d'une organisation. ### Pourquoi la ligne PKI est tranchée : **non** Elle disait « à trancher », en notant qu'*une AC intermédiaire signée par l'hôte est possible*. Elle l'est techniquement — et c'est précisément ce qu'il ne faut pas faire. Une intermédiaire signée par l'hôte lui donne le pouvoir d'**émettre des certificats valides pour les noms du locataire**. Il peut alors se présenter comme n'importe lequel de ses services, y compris devant les propres machines du locataire, qui les accepteront sans sourciller — c'est exactement ce que la chaîne de confiance leur demande de faire. C'est le même pouvoir que l'annuaire, sous une forme **moins visible** : rien n'apparaît dans la configuration du locataire, aucune trace côté locataire, et la vérification passe. **Une PKI par écosystème, jamais dérivée de l'hôte.** C'est déjà ce qui tourne ; la ligne ne fait que cesser de laisser la porte entrouverte. ### Le revers : le site n'a pas d'observabilité du tout Mesure du 2026-09-10 : le site ne porte **ni `client_journal` ni `client_metrique`**, et aucun `loki` ni `prometheus`. Ses sept machines n'expédient rien nulle part — l'hébergeur ne peut pas lire ses propres journaux. C'est la conséquence directe de la frontière : à refuser de voir ceux des locataires, il s'est privé des siens. Le remède n'est pas d'assouplir la règle, c'est de lui donner **sa propre pile** — un `loki` et un `prometheus` du site, pour les machines du site, sans aucun lien avec ceux d'un tenant. ## 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 : ```yaml _externe: true # je l'emprunte _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) **Personne. La forge du SITE fait autorité pour le génome** (D-81) ; toute autre copie est un miroir. Le dépôt l'avait suivi avant de le déclarer : `serveur_forge_site`, puis `serveur_cache_site`, puis `serveur_resolveur_site` — trois services prêtés par le site à ses locataires, un seul patron. **Par où le génome arrive.** Le poste porte les commits en bundle au runner du site (`make genome-pousser`), qui les pousse sur sa forge. Aucune autre forge n'est sur ce chemin. `eregion` (`forge.alliance-boreale.ca`) est une forge **héritée** : la porte publique des contributions, qui ne fera jamais partie de Set-OPS. La redondance ne vient pas d'elle mais du nombre de sites — une forge par site, chacune inséminée du génome. ## É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-`, `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.)*