Set-OPS-Public/docs/migration-tenant.md

# Migrer un tenant d'un hébergeur à un autre

> **Recette d'exploitation.** Elle décrit la séquence, les états et les gardes ; elle ne
> décrit pas encore un outil, parce que la séquence doit être éprouvée avant d'être figée
> dans du code. Complète `docs/multi-instances.md` (la fédération) et
> `docs/frontiere-opnsense.md` §2 (qui possède quoi).

## 1. Pourquoi ce document existe

Un **hébergeur** possède le matériel et sert plusieurs **tenants** ; il a en général son
propre tenant par défaut. Un tenant doit pouvoir partir chez un autre hébergeur — sans quoi
la souveraineté qu'on lui promet n'est qu'un mot : **une organisation qui ne peut pas partir
est captive, quelle que soit la licence du logiciel.**

La migration est donc une fonctionnalité de premier plan, pas un cas limite.

## 2. Le modèle : le transfert de nom de domaine

La procédure reprend celle des registraires, qui résout depuis trente ans exactement les
mêmes problèmes. Trois propriétés valent d'être empruntées.

**Le mandat appartient au client.** Le code d'autorisation est remis au titulaire, qui le
donne au registraire entrant. Transposé : ni l'hébergeur sortant ni l'entrant ne peut
déplacer un tenant de sa propre initiative. Un hébergeur ne « cède » pas un client ; un
autre ne le « réclame » pas.

**Le verrou par défaut.** Un domaine est verrouillé ; le déverrouiller est un geste
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 |
|---|---|---|
| un **registre** central arbitre | rien de central, par construction | le mandat est **signé** par le tenant, vérifié contre une clé publique inscrite dans son plan — donc versionnée et publique |
| le domaine ne porte **aucune donnée** | boîtes, dépôts, bases | un **gel** + un instantané restic ; c'est là qu'est le vrai risque |
| fenêtre d'objection | — | fenêtre de **réversibilité** : le sortant ne détruit rien avant confirmation |

Un secret partagé ne suffirait pas : transmis à l'hébergeur entrant, il ne lui prouve rien —
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

> **Le receveur doit être prouvé prêt avant que quoi que ce soit ne gèle.**

Construire chez l'entrant pendant que le sortant sert normalement ramène l'interruption au
seul rattrapage final. Geler d'abord et construire ensuite coûterait des heures d'arrêt pour
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

| État | Ce qui est vrai | Comment on en sort |
|---|---|---|
| **verrouillé** | régime normal, aucune migration en cours | un mandat signé apparaît |
| **mandaté** | le tenant a signé ; l'entrant peut commencer | l'entrant a construit |
| **préparé** | l'entrant est déployé, restauré (données tièdes) et **prouvé** — mais **pas public** | *garde : preuves vertes chez l'entrant* |
| **gelé** | le sortant est en lecture seule ; capture du delta | delta restauré chez l'entrant |
| **basculé** | le DNS public pointe l'entrant, qui sert ; **le sortant reste gelé** | l'entrant confirme le service |
| **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 | — |

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)

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)

**Abaisser le TTL** des enregistrements publics du tenant. C'est le geste qu'on oublie
systématiquement, et il conditionne tout : posé à l'étape 6, la bascule traînera des heures
quoi qu'on fasse ; posé maintenant, elle prendra le temps du nouveau TTL.

Vérifier que les sauvegardes du tenant sont saines et récentes — la migration s'appuie
entièrement dessus (`serveur_backup` / `client_backup`).

### Étape 2 — construire chez l'entrant (sans interruption)

1. **Choisir un index libre** dans la fédération de l'entrant (`make instances` le montre ;
   la preuve **P21** refuse une collision). S'il diffère de l'ancien, *tout* l'adressage
   change — IP, VLAN, VMID — et c'est **une seule ligne à changer**, puis `make instancier`.
2. **Vérifier que la fabric de l'entrant porte le tenant** : plage VLAN disponible, lien de
   transit présent, zones du plan couvertes (`make underlay`, preuve **P23**).
3. **Créer et déployer** la flotte du tenant chez l'entrant.
4. **Restaurer** depuis un instantané restic *tiède* — les données auront quelques jours ;
   c'est voulu, le rattrapage viendra à l'étape 5.

Pendant tout ce temps, le sortant sert normalement. Personne ne voit rien.

### Étape 3 — prouver l'entrant, sans le rendre public

Faire passer la batterie de preuves et la recette **contre les adresses de l'entrant**, pas
par le DNS public.

C'est le point délicat de toute la procédure : le tenant tourne alors **aux deux endroits**,
mais un seul doit servir. Si l'entrant répondait publiquement, le courrier arriverait des deux
côtés et l'identité se dédoublerait. Il faut donc un chemin de vérification qui ne dépende pas
du DNS public — résolution locale, `/etc/hosts` du poste de vérification, ou vues DNS
séparées. **Ce chemin est un prérequis de cette étape** : sans lui, pas de vérification, donc
pas de garde, donc pas de gel.

### Étape 4 — geler (chez le sortant)

*Garde : l'étape 3 est verte.*

Le tenant passe en lecture seule. L'interruption commence **ici**, et seulement ici.

### Étape 5 — rattraper le delta

Instantané restic incrémental, restauré chez l'entrant. Court, parce que le gros est déjà
passé à l'étape 2.

### Étape 6 — basculer

Le DNS public pointe l'adresse publique de l'entrant. Le TTL abaissé à l'étape 1 fait son
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ù ».

### Étape 7 — confirmer (chez l'entrant)

Le service répond publiquement, les preuves passent, le tenant valide. **C'est ce qui autorise
l'étape 8, rien d'autre.**

### Étape 8 — libérer (chez le sortant)

**Révoquer, pas transmettre.** La voûte voyage avec le dépôt, chiffrée, mais son mot de passe
est celui de l'opérateur sortant. Migrer proprement ne consiste pas à le communiquer : c'est
**re-cléer chez l'entrant** — nouveau mot de passe de voûte, rotation des secrets applicatifs,
révocation des certificats et des clés SSH émis par le sortant.

C'est l'équivalent du re-verrouillage chez le nouveau registraire. Sans lui, l'ancien
hébergeur garde **à vie** l'accès aux secrets d'un client parti, et aucune procédure ne
rattrape ça après coup.

Puis rétention — durée convenue — avant purge.

## 6. 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.

### Avant le gel — sans conséquence

Les étapes 2 et 3 échouent chez l'entrant. Le sortant n'a jamais cessé de servir et ignore
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
avant le gel.**

### Pendant le gel, avant la bascule — dégeler, et c'est tout

Le rattrapage du delta échoue, ou une vérification de dernière minute déraille. L'entrant ne
sert pas encore : rien n'y a été écrit qui compte.

On dégèle le sortant. L'interruption aura duré le temps du gel — quelques minutes. La
construction chez l'entrant reste debout pour un nouvel essai.

### Après la bascule — ce n'est plus un retour, c'est une migration inverse

Dès que l'entrant sert, les utilisateurs y écrivent : courriels reçus, fichiers déposés,
commits poussés. **Ces données n'existent nulle part ailleurs.** Repointer simplement le DNS
vers le sortant les perdrait — et silencieusement, ce qui est pire.

Le retour arrière devient donc une migration dans l'autre sens, avec la même mécanique :
geler l'entrant, capturer le delta, le restaurer chez le sortant, repointer le DNS, dégeler le
sortant. C'est faisable — c'est le même outillage — mais ça se prépare, ça ne s'improvise pas.

Bonne nouvelle : le sortant est **encore gelé** (étape 6), donc il n'a pas divergé de son côté.
Le delta est à sens unique, et la fusion n'a pas lieu d'être.

### Ce qui en découle

**Les critères de confirmation se définissent avant l'étape 6, pas pendant l'étape 7.** La
bascule est le moment où le coût d'un échec change d'ordre de grandeur ; décider *ensuite* ce
qui compte comme « ça marche » revient à se donner raison après coup.

**Deux points de non-retour**, à ne pas confondre :

| Point | Ce qu'on perd | Ce qu'il reste |
|---|---|---|
| **la bascule** (étape 6) | le retour gratuit | le retour par migration inverse |
| **la purge** (fin de rétention) | la copie du sortant | rien — c'est le vrai point de non-retour |

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

- **La fabric** : l'underlay appartient à l'hébergeur. Le tenant en change, il n'en emporte
  pas.
- **La frontière** : l'entrant a la sienne. Ses règles pour le tenant se **régénèrent** —
  `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

- **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.
- **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
  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
  séquence au moins une fois.