# Sortir de Bastide, vers Vercel, Supabase ou ailleurs

L'archive de sortie est un droit, pas une fonctionnalité d'un palier : elle est produite sans frais et sans condition, y compris pendant un litige de facturation et trente jours après résiliation. Elle ne contient aucun format propriétaire : chaque fichier s'ouvre avec un outil du domaine public, que son `LISEZMOI.md` nomme. Cette page produit l'archive, la vérifie, la restaure sur votre propre PostgreSQL, puis dit ce qui se rejoue chez Vercel et chez Supabase.

## Ce qu'il faut avant de commencer

- Une paire de clés RSA, que vous gardez : les secrets ne sortent jamais en clair, et l'archive est refusée sans clé publique valide, même s'il n'y a aucun secret.
- Pendant la bêta, la production de l'archive est un geste d'exploitant (`pnpm exporter-projet`), qui lit la plateforme avec la configuration ordinaire de l'API. Aucune opération du registre ne la sert encore : demandez-la à l'exploitant.

## 1. Produire l'archive

```
openssl genrsa -out cle-privee.pem 3072
openssl rsa -in cle-privee.pem -pubout -out cle.pem
pnpm exporter-projet --projet <prj_…> --cle-publique cle.pem --sortie ./archive
```

Le code de sortie dit l'issue : `0` archive complète, `1` refus (clé absente, projet inconnu, lecture impossible), `3` archive écrite mais incomplète : les secrets omis et les avertissements sont listés, nommés, jamais passés sous silence. Le lien de téléchargement d'une archive hébergée vaut 7 jours et se reprend après interruption (plage d'octets, `curl -C -`).

## 2. Ce que l'archive contient

Neuf éléments : `code/` (sources telles que déployées), `database/` (`schema.sql` et un CSV par table), `storage/` (objets, octets d'origine), `auth/utilisateurs.json`, `config/configuration.json`, `secrets/secrets.json` (chiffrés), `logs/journaux.ndjson`, `MANIFEST.json` (SHA-256 de chaque fichier) et `LISEZMOI.md`.

## 3. Vérifier et restaurer sur votre infrastructure

Rien de Bastide n'est nécessaire : PostgreSQL 14 ou plus, `psql`, `jq` et `sha256sum`. Depuis la racine de l'archive, le contrôle d'intégrité :

```
cd archive
jq -r '.fichiers[] | "\(.sha256)  \(.chemin)"' MANIFEST.json | sha256sum -c -
```

La procédure complète de restauration (schéma, chargement des tables avec les contraintes levées le temps du chargement, objets, recomptage des lignes) est le bloc `sh restauration` du `LISEZMOI.md` de l'archive : suivez-le tel quel, c'est ce que l'exercice trimestriel de restauration (`pnpm exercice-restauration`) exécute sur une infrastructure neuve. Si le schéma cite un rôle absent de votre PostgreSQL, `psql` s'arrête en nommant le rôle : créez-le (`create role <nom>;`) et relancez l'étape du schéma.

Les secrets se déchiffrent à part : chaque entrée porte `cle_enveloppee` (clé AES-256 enveloppée en RSA-OAEP SHA-256 pour votre clé publique), `iv`, `etiquette` (GCM) et `chiffre`, en base64. Les noms des variables sont lisibles, les valeurs ne le sont jamais dans l'archive.

## 4. Rejouer chez Supabase

La base restaurée est un PostgreSQL ordinaire : chargez `database/schema.sql` et les CSV dans le projet cible avec `psql`. Les objets de `storage/` se remettent en seaux de votre choix. `auth/utilisateurs.json` se relit avec `jq` et s'importe dans le système d'identité de votre choix. Les écarts propres à Bastide qui jouent à la sortie : les rôles portent le nom de la base en préfixe (`LIM-11`), donc relisez `grant` et `create policy` du schéma avant de les rejouer ; les politiques de sécurité au niveau des lignes sont dans le schéma.

## 5. Rejouer chez Vercel

Le dossier `code/` est un dépôt ordinaire : poussez-le vers Git et raccordez-le à Vercel. `config/configuration.json` et le `glowsoft.json` du dépôt se relisent avec `jq`. Aucun outil de conversion de `glowsoft.json` vers `vercel.json` n'est livré : réécrivez les redirections, réécritures et en-têtes dans `vercel.json`. Les variables sensibles se déchiffrent (étape 3) puis se saisissent chez Vercel.

## Incompatibilités connues

- Aucune restauration de base à partir d'une sauvegarde n'est au catalogue d'outils MCP : la sortie passe par l'archive, pas par un retour arrière de la base.
- `secrets/secrets.json` est chiffré pour votre clé publique : perdre la clé privée, c'est perdre les valeurs. Un secret que la plateforme n'a pas pu ouvrir est nommé en `ARCHIVE INCOMPLÈTE`, jamais omis en silence (code de sortie `3`).
- Les clés historiques `anon` et `service_role` d'un projet importé (`LIM-09`) cessent d'être acceptées douze mois après l'import, et ne valent que chez Bastide : à la sortie, utilisez les clés de la plateforme cible.
- Les extensions et réglages propres à Bastide ne se déplacent pas : la diffusion depuis la base du temps réel (`realtime.diffuser_les_changements`, `LIM-08`) est une fonction de Bastide, à remplacer chez la plateforme d'arrivée.
- L'exercice de restauration par une personne extérieure à l'équipe, sur une infrastructure qui n'est pas la nôtre (EX-MIG-200), reste à mener : l'exercice automatisé règle la partie qu'une machine sait juger.

Voir aussi : [Migrer depuis Vercel](from-vercel.md), [Migrer depuis Supabase](from-supabase.md), [Restaurer](restore.md).