docs : le responsable prend sa section, et la symétrie est dite

Renvoi ambigu corrigé : « en cas de retour arrière (§6) » figurait dans
l'étape 6 — deux « 6 » pour deux choses dans une seule phrase. La section est
nommée plutôt que numérotée.

Le responsable désigné devient le §3 : il vivait sous « le transfert de nom
de domaine » alors que ce n'est pas un emprunt aux registraires mais une
décision de modèle, valable migration ou pas.

Et le §8 énumérait ce que la migration ne déplace PAS sans dire ce qu'elle
déplace. Le responsable, lui, suit le tenant — c'est l'inverse, et le dire
renforce la ligne de partage : ce qui est à l'hébergeur reste, ce qui est au
tenant part avec lui. 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, la frontière est mal tracée.

Sections renumérotées (9 au lieu de 8), six renvois internes vérifiés.

Preuves : 24 OK, 0 échec.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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é

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