diff --git a/CHANGELOG.md b/CHANGELOG.md index 7347fbb..85bcec9 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,31 @@ # CHANGELOG — Set-OPS +## 2026-08-02 (suite 11) — le responsable prend sa section, et la symétrie est dite + +### Corrigé — un renvoi ambigu +« Il ne dégèle qu'en cas de retour arrière (§6) » figurait **dans l'étape 6**. Deux « 6 » ne +désignant pas la même chose dans une seule phrase, alors que tout le document distingue +soigneusement sections et étapes. La section est désormais nommée plutôt que numérotée. + +### Déplacé — le responsable désigné devient le §3 +Il vivait dans « Le modèle : le transfert de nom de domaine », alors que ce n'est **pas un +emprunt aux registraires** : c'est une décision de modèle, valable migration ou pas. Le §2 ne +traite plus que de ce qui est emprunté et de là où l'analogie casse. + +### Ajouté — ce qui suit le tenant, en regard de ce qui reste +Le §8 énumérait ce que la migration ne déplace **pas** — fabric, frontière, index — sans dire +ce qu'elle déplace. Or le responsable désigné, lui, **suit le tenant** : c'est exactement +l'inverse, et le dire renforce la ligne de partage. + +> Si quelque chose appartenant à l'organisation ne peut pas partir, elle n'est pas vraiment +> souveraine ; si quelque chose appartenant à l'hébergeur devait partir, c'est que la +> frontière entre les deux est mal tracée. + +Cette symétrie est le test le plus simple d'une migration bien conçue. + +Sections renumérotées en conséquence (9 au lieu de 8) ; les six renvois internes vérifiés un +par un. + ## 2026-08-02 (suite 10) — le responsable désigné, et la réversibilité nuancée ### Décidé — chaque tenant a un responsable désigné diff --git a/docs/migration-tenant.md b/docs/migration-tenant.md index db65fe8..ab85d92 100644 --- a/docs/migration-tenant.md +++ b/docs/migration-tenant.md @@ -29,16 +29,6 @@ explicite. Un tenant l'est aussi : pas de migration silencieuse. **Deux actes délibérés, chez deux parties**, et une trace de qui a libéré et qui a reçu. -### Qui signe : le responsable désigné - -Un domaine a un titulaire ; un tenant a un **responsable désigné**. C'est la personne qui -engage l'organisation — le mandat de migration porte sa signature, et elle seule. - -Ce n'est pas une formalité : sans responsable nommé d'avance, la question « qui peut décider -de déménager cette organisation ? » se pose au pire moment, quand les deux hébergeurs ont un -intérêt dans la réponse. Un employé de bonne foi ne peut pas mandater le déménagement de son -employeur ; le responsable désigné, si. - ### Là où l'analogie casse, et par quoi on la remplace | Le monde des domaines | Set-OPS | Substitution | @@ -51,7 +41,20 @@ Un secret partagé ne suffirait pas : transmis à l'hébergeur entrant, il ne lu il pourrait venir du sortant. Une signature, si. C'est plus solide que l'original, et sans tiers de confiance. -## 3. La règle qui commande tout l'ordre +## 3. Le responsable désigné + +Un domaine a un titulaire ; un tenant a un **responsable désigné**. C'est la personne qui +engage l'organisation — le mandat de migration porte sa signature, et elle seule. + +Ce n'est pas un emprunt aux registraires mais une **décision de modèle** : chaque tenant en a +un, migration ou pas. Sans responsable nommé d'avance, la question « qui peut décider de +déménager cette organisation ? » se poserait au pire moment, quand les deux hébergeurs ont un +intérêt dans la réponse. Un employé de bonne foi ne peut pas mandater le déménagement de son +employeur ; le responsable désigné, si. + +Il **suit le tenant** : c'est une propriété de l'organisation, pas de son hébergement (§8). + +## 4. La règle qui commande tout l'ordre > **Le receveur doit être prouvé prêt avant que quoi que ce soit ne gèle.** @@ -62,7 +65,7 @@ une opération qui n'en vaut que quelques minutes. Cette règle n'est pas un conseil : c'est une **garde de transition** — l'état `gelé` est inaccessible tant que l'état `préparé` n'est pas prouvé. -## 4. Les états d'un tenant +## 5. Les états d'un tenant | État | Ce qui est vrai | Comment on en sort | |---|---|---| @@ -76,18 +79,18 @@ inaccessible tant que l'état `préparé` n'est pas prouvé. On peut revenir jusqu'à **libéré** — mais **pas au même prix**. La réversibilité change de nature à la bascule : gratuite avant, elle devient une **migration inverse** après, parce que -les utilisateurs ont commencé à écrire chez l'entrant (§6). Retenir « on peut revenir jusqu'au +les utilisateurs ont commencé à écrire chez l'entrant (§7). Retenir « on peut revenir jusqu'au bout » serait faux ; retenir « revenir est facile jusqu'à la bascule, coûteux ensuite » est juste. Ce qui est gratuit, en revanche, c'est le changement d'adressage : tout dérive d'un seul chiffre, dans les deux sens. -## 5. La séquence +## 6. La séquence ### Étape 0 — le mandat (chez le tenant) -Le **responsable désigné** du tenant (§2) signe une déclaration nommant l'hébergeur entrant. +Le **responsable désigné** du tenant (§3) signe une déclaration nommant l'hébergeur entrant. L'entrant la vérifie contre la clé publique du plan. **Sans mandat vérifié, rien ne commence** — ni l'hébergeur sortant ni l'entrant ne peut suppléer cette signature. @@ -143,7 +146,7 @@ office. L'interruption se termine à la propagation. **Le sortant reste gelé.** Le dégeler maintenant créerait deux copies vivantes du même tenant : un courriel livré chez l'un, un fichier déposé chez l'autre, et plus aucune vérité. Il ne -dégèle qu'en cas de retour arrière (§6), jamais « au cas où ». +dégèle qu'en cas de retour arrière — voir « Le retour arrière » — jamais « au cas où ». ### Étape 7 — confirmer (chez l'entrant) @@ -163,7 +166,7 @@ rattrape ça après coup. Puis rétention — durée convenue — avant purge. -## 6. Le retour arrière +## 7. Le retour arrière La réversibilité n'est pas uniforme : elle change de nature à la bascule. Trois régimes, trois réponses différentes — et il faut les avoir décidées avant, pas à trois heures du matin. @@ -174,7 +177,7 @@ Les étapes 2 et 3 échouent chez l'entrant. Le sortant n'a jamais cessé de ser tout de l'affaire. On corrige ou on jette la construction, on recommence. Aucun utilisateur n'a rien vu. -C'est précisément ce que la règle du §3 achète : **tout ce qui peut échouer sans coût échoue +C'est précisément ce que la règle du §4 achète : **tout ce qui peut échouer sans coût échoue avant le gel.** ### Pendant le gel, avant la bascule — dégeler, et c'est tout @@ -214,7 +217,7 @@ qui compte comme « ça marche » revient à se donner raison après coup. Entre `libéré` et `purgé`, revenir reste possible mais coûte un second re-clétage : le sortant a révoqué ses accès, il faudrait les rétablir. -## 7. Ce que la migration ne déplace pas +## 8. Ce que la migration ne déplace pas - **La fabric** : l'underlay appartient à l'hébergeur. Le tenant en change, il n'en emporte pas. @@ -222,7 +225,17 @@ a révoqué ses accès, il faudrait les rétablir. `make devis-opnsense` est déjà multi-tenant. - **L'index** : c'est une coordonnée locale à une fédération, pas une propriété du tenant. -## 8. Ce qui reste à trancher +En regard, **ce qui appartient à l'organisation la suit** : son plan, ses données, sa voûte +(re-clétée à l'arrivée), ses domaines publics — et son **responsable désigné** avec sa clé de +signature (§3). C'est la même ligne de partage que partout ailleurs : ce qui est à l'hébergeur +reste, ce qui est au tenant part avec lui. + +Cette symétrie est le test le plus simple d'une migration bien conçue. Si quelque chose +appartenant à l'organisation ne peut pas partir, elle n'est pas vraiment souveraine ; si +quelque chose appartenant à l'hébergeur devait partir, c'est que la frontière entre les deux +est mal tracée. + +## 9. Ce qui reste à trancher - **Le format du mandat** et l'emplacement de la clé publique du tenant dans son plan. - **Le chemin de vérification hors DNS public** (étape 3) — le plus structurant. @@ -247,7 +260,7 @@ a révoqué ses accès, il faudrait les rétablir. par qui. Sur une séparation d'hébergeur, un flou ici finit en litige — c'est précisément ce qu'un contrat écrit d'avance évite. - **Les critères de confirmation** de l'étape 7, à fixer par écrit avant la première bascule - (§6) — c'est ce qui décide si un retour arrière s'impose. + (§7) — c'est ce qui décide si un retour arrière s'impose. - **L'outillage** : un `devis-migration` dériverait l'index retenu, l'adressage résultant et la compatibilité de fabric, et refuserait sur un point bloquant — dans l'idiome du dépôt : dériver un plan, le prouver, laisser l'humain l'appliquer. À écrire **après** avoir joué la