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.

• Le recouvrement de la clé du responsable — elle se perd, se compromet, ou la personne quitte l'organisation. Sans procédure, un tenant devient inmigrable : captif non par contrat mais par accident, ce que toute cette recette existe pour empêcher.

  Deux écueils symétriques. Une procédure trop lourde et le recouvrement n'aboutit jamais, donc le tenant reste bloqué. Trop légère et elle devient le chemin de moindre résistance pour contourner la signature : inutile de forger un mandat si l'on peut se faire attribuer la clé. Le recouvrement doit être au moins aussi difficile que ce qu'il protège.

  C'est vraisemblablement le même mécanisme que le changement de responsable ci-dessus : dans les deux cas, quelqu'un d'extérieur à la clé atteste de l'autorité. Les registraires procèdent hors bande — pièces justificatives, délai d'opposition, contact de secours déclaré d'avance. Ce dernier point est le plus transposable : un contact de secours nommé en même temps que le responsable, tant que personne n'est encore en situation d'urgence.

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