diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4ae47fc..978ba43 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,5 +1,32 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-02 (suite 10) — le responsable désigné, et la réversibilité nuancée
+
+### Décidé — chaque tenant a un responsable désigné
+Un domaine a un titulaire ; un tenant a un **responsable désigné** — la personne qui engage
+l'organisation, et dont la signature seule vaut mandat de migration.
+
+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.
+
+### Corrigé — la table des états laissait croire que revenir est facile jusqu'au bout
+Elle annonçait une réversibilité « gratuite » entre `préparé` et `libéré`, alors que le §6
+établit qu'elle change de nature à la bascule. Les deux ne se contredisent pas — on peut
+effectivement revenir jusqu'à `libéré` — mais un lecteur pressé s'arrêtant au tableau en
+retirait une fausse impression.
+
+Ce qui reste gratuit est l'adressage, pas le retour : tout dérive d'un seul chiffre, dans les
+deux sens.
+
+### Ajouté aux points à trancher — deux questions de gouvernance
+**Où le responsable désigné est déclaré**, et surtout **comment on en change** : c'est un acte
+au moins aussi sensible que la migration, puisqu'il décide qui pourra la mandater ensuite.
+
+**La durée de rétention** : convenue avec qui, consignée où, attestée par qui. Sur une
+séparation d'hébergeur, un flou ici finit en litige.
+
 ## 2026-08-02 (suite 9) — le retour arrière de la migration
 
 La recette affirmait la réversibilité sans jamais décrire le retour. Or elle **change de
diff --git a/docs/migration-tenant.md b/docs/migration-tenant.md
index ef2ea02..4e467f8 100644
--- a/docs/migration-tenant.md
+++ b/docs/migration-tenant.md
@@ -29,6 +29,16 @@ 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 |
@@ -64,15 +74,22 @@ inaccessible tant que l'état `préparé` n'est pas prouvé.
 | **libéré** | le sortant a **révoqué** ses accès ; horloge de rétention lancée | fin de rétention |
 | **purgé** | le sortant a détruit sa copie | — |
 
-La réversibilité vit entre **préparé** et **libéré** : tant que le sortant n'a pas révoqué,
-on rentre. Elle vient gratuitement du fait que tout l'adressage dérive d'un seul chiffre.
+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
+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
 
 ### Étape 0 — le mandat (chez le tenant)
 
-L'organisation 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.**
+Le **responsable désigné** du tenant (§2) 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.
 
 ### Étape 1 — préparer le terrain (chez le sortant, sans interruption)
 
@@ -209,7 +226,12 @@ a révoqué ses accès, il faudrait les rétablir.
 
 - **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.
-- **La durée de rétention** avant purge, et qui l'atteste.
+- **Où le responsable désigné est déclaré** dans le plan du tenant, et surtout **comment on
+  en change** : c'est un acte au moins aussi sensible que la migration elle-même, puisqu'il
+  décide qui pourra la mandater ensuite.
+- **La durée de rétention** avant purge : convenue **avec qui**, consignée **où**, et attestée
+  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.
 - **L'outillage** : un `devis-migration` dériverait l'index retenu, l'adressage résultant et