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.

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	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	—

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.

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.

É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 4.

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 doit exister avant l'étape 4.

É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.

É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. 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.

7. 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.
• La durée de rétention avant purge, et qui l'atteste.
• 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.