Daniel Allaire
f248bb084f
Un ecosysteme nait fils, peut rester mutualise par choix, et s'emancipe quand il le decide. Le moteur avait rencontre ce motif trois fois sans le nommer : client_artefacts_actif, serveur_ops_forge_externe, client_backup_cible. serveur_ops_forge_externe etait citee par le registre des dependances ET par le README, definie nulle part : l'exemption ne pouvait jamais s'appliquer. Elle existe maintenant, avec un amont obligatoire. Consequence pour les modeles : quatre n'ont pas de forge, ce ne sont pas des lacunes mais des ecosystemes au premier age. Ils le declarent. Reste a faire : l'instrument qui PROUVE qu'une emancipation a coupe le lien. Sans lui, on croirait s'etre emancipe en restant dependant. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
101 lines
4.5 KiB
Markdown
101 lines
4.5 KiB
Markdown
# 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 |
|
|
|
|
## Ce que l'émancipation doit prouver
|
|
|
|
Basculer une déclaration ne suffit pas. Une émancipation est un **acte outillé** en trois
|
|
temps :
|
|
|
|
1. **déclarer** — lever le drapeau au plan, déployer le service chez soi ;
|
|
2. **migrer l'état** — le génome, les sauvegardes, les certificats existants ;
|
|
3. **prouver que le lien est coupé** — et c'est le temps qu'on oublie.
|
|
|
|
Sans cette troisième preuve, on croirait s'être émancipé en restant dépendant sans le
|
|
savoir. C'est 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.
|
|
|
|
## 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.
|
|
|
|
## État au 2026-08-24
|
|
|
|
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 — et l'instrument de preuve de l'étape 3
|
|
n'existe pas encore.
|