Repartir sur une base Neon propre

Runbook du propriétaire, rédigé le 2026-10-08 sur le schéma de l'app BoostEcom/boostecom.app (main à cee5f0f0, plus la PR data-platform/3120). Il répond au GO du propriétaire du 2026-10-08 (« Oui go pour (a) et (b) »), point (b).

En bref

• Pourquoi. Le propriétaire est le seul utilisateur (zéro client). La base de production porte des tables sans lecteur (dont les quatre tables Growth retirées du schéma par data-platform/3120), des données de l'ancien Studio interne et des journaux sans valeur. Une base neuve, créée depuis prisma/schema.prisma, colle exactement au schéma.
• Comment. Une base vide boostecom dans la branche Neon main, le schéma appliqué par prisma db push sur cette base vide, une copie ciblée des seules tables qui ont de la valeur, puis la bascule de DATABASE_URL dans Vercel. L'ancienne base neondb n'est jamais modifiée : c'est l'archive et le chemin de retour.
• Ce que le propriétaire refait à la main : se reconnecter (OTP), recréer son organisation, reconnecter sa boutique Shopify et ses connecteurs, réémettre ses clés. Liste exacte à l'étape 4.8.
• Ce qui se reconstruit tout seul : schéma (cold start), annonces marketplace de BoostEcom, roadmap projetée depuis le backlog, brouillons de changelog, données Shopify ré-ingérées, agrégats et crons.
• Ce qui est perdu si on ne le copie pas : voir la colonne de droite du classement (section 3). Les séries temporelles Intelligence ne se reconstruisent pas.
• Durée : une demi-journée, dont l'essentiel en mesure et vérification. Fenêtre où l'app ne doit pas être utilisée : de l'étape 4.1 à l'étape 4.6.

1. Avant de commencer

[PROPRIÉTAIRE] Cocher, dans l'ordre :

1. La PR data-platform/3120 (retrait de GrowthUnit, ContentRender, ContentReview, AttributionEvent) est mergée et déployée. Sinon la base neuve recrée ces quatre tables, vides.
2. Un poste avec psql (client PostgreSQL 16 ou plus), Node et pnpm, et un clone à jour de main : pnpm install passe, puis pnpm db:guard:check dit OK.
3. Dans ce clone, AUCUN fichier .env qui pointe vers la production. Les commandes ci-dessous passent l'URL explicitement. Vérifier : grep -c DATABASE_URL .env 2>/dev/null doit rendre 0 ou rien.
4. Accès à la console Neon (projet boostecom-app) et à Vercel (projet boostecom.app, Settings > Environment Variables).
5. Dans Stripe (le mode que la production utilise) : aucun abonnement actif lié à l'organisation du fondateur qu'on ne veuille pas perdre, et aucun webhook en ré-essai (Developers > Webhooks > l'endpoint de production). Un webhook rejoué après la bascule ne trouvera plus son organisation.
6. Noter, AVANT d'y toucher, la valeur actuelle de chaque variable de base dans Vercel Production (voir 4.6), dans un endroit sûr hors de ce dépôt. C'est le rollback.

2. Ce que la bascule change, et ce qu'elle ne change pas

3. Classement des 185 modèles

Règle : une table n'est copiée que si elle porte une valeur qu'aucun seed, aucune synchronisation et aucun cron ne recrée. Tout le reste repart vide. Les sous-classes de (a) sont toutes de la donnée de référence ou de tiers ; (b) est le compte du fondateur ; (c) est jetable.

Le schéma compte 185 modèles (14 tables préfixées bst_ via @@map). La colonne « Table » donne le nom PHYSIQUE, celui des requêtes SQL. Chaque classe porte un code (A1 à C) que l'étape 4.0 réutilise.

3.1 Les quatre tables orphelines

GrowthUnit, ContentRender, ContentReview, AttributionEvent ne sont plus dans le schéma (data-platform/3120). Elles n'existeront pas dans la base neuve et restent dans l'archive. La procédure de DROP cible de data-platform/3121 (voir Maintenance des index) devient sans objet dès que la bascule est faite.

La requête de l'annexe B liste toute autre table présente en production et absente du schéma : même traitement, elle reste dans l'archive.

3.2 Les 185 modèles, un par un

A1. Registres et réglages plateforme : COPIER (15)

A2. Reconstruits automatiquement : NE PAS copier, sauf filtre indiqué (5)

A3. Données de tiers, consentements, conformité : COPIER si non vide (12)

A4. Corpus Intelligence (Store Graph, découverte) : COPIER, recommandé (10)

B1. Compte du fondateur : à REFAIRE à la main (20)

B2. Données d'usage du fondateur : PERDUES (32)

Copiables seulement avec les identités, voir 3.3.

C!. Attendus VIDES : une seule ligne, et on ARRÊTE pour décider (16)

C. Jetables : journaux, files, caches, événements, données ré-ingérées (75)

3.3 Et si le fondateur veut garder son historique (B2) ?

Les tables B2 référencent User, Organization et Store par id. Les copier impose de copier ces lignes avec les MÊMES ids (plus Account, OrganizationMember, StoreContext, Subscription, Credit, IntegrationConnection, Connector), et de suivre l'ordre des clés étrangères. C'est faisable avec la même méthode que l'annexe C, mais ce n'est plus repartir sur une base propre, et cela reporte dans la base neuve l'état exact qu'on voulait quitter.

Recommandation : ne pas le faire, sauf pour garder les mêmes storeId si les médias Blob du fondateur comptent. Décision du propriétaire.

4. Procédure

Chaque étape est faite par le propriétaire, dans l'ordre. $SRC, $DST et $DST_POOLED sont des URL de connexion que le propriétaire relève dans la console Neon et garde dans son terminal : elles ne s'écrivent ni dans un fichier du dépôt, ni dans un ticket, ni dans une conversation.

SELECT relname AS t, n_live_tup AS approx_rows,
       pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;

pnpm exec prisma db push --url "$DST"

DATABASE_URL="$DST" pnpm exec prisma migrate diff \
  --from-config-datasource --to-schema prisma/schema.prisma --exit-code

psql "$SRC" -f export.sql      # écrit un CSV par table
psql "$DST" -f import.sql      # tout ou rien : BEGIN ... COMMIT
psql "$SRC" -f compare.sql > src.txt
psql "$DST" -f compare.sql > dst.txt
diff src.txt dst.txt           # attendu : aucune différence

DATABASE_URL="$DST" pnpm db:seed

5. Garder l'archive

[PROPRIÉTAIRE, décision] Durée de conservation de neondb et de la branche d'archive : proposition 30 jours, à trancher. L'archive contient des données personnelles (abonnés, candidatures, journaux) : ne pas la garder indéfiniment (voir data-platform/0520, décision RGPD ouverte).

Pendant ce temps : ne rien y écrire. À l'échéance, et seulement si 4.9 est resté vert tout du long :

1. si utile, un pg_dump complet de $SRC conservé hors Neon, avec son sha256sum ;
2. supprimer la branche archive-avant-base-propre-AAAAMMJJ ;
3. supprimer la base neondb de main (Databases > neondb > Delete) ;
4. fermer data-platform/3121 (« sans objet : base reconstruite le ... »).

6. Rollback

• Avant 4.6 : rien n'a changé pour l'app. Supprimer la base boostecom et recommencer.
• Après 4.6 : remettre dans Vercel les valeurs notées en 1.6, puis redéployer. L'app repart sur neondb, intacte. Ce qui a été créé entre-temps dans boostecom (compte, organisation, boutique) n'existe pas dans neondb : à refaire ou à recopier à la main.
• Code : aucun. Le retrait des quatre modèles Growth n'impose pas la bascule et ne se revert pas pour elle.

7. Risques et points ouverts

• Variables Vercel gérées par l'intégration Neon (4.6) : seul point où la procédure peut bloquer ; elle s'arrête au lieu d'improviser.
• Une table C! non vide (4.0) arrête tout jusqu'à décision.
• Les séries temporelles Intelligence et les historiques Shopify antérieurs ne reviennent pas si on ne les copie pas.
• Blob : les médias de l'ancien storeId restent stockés et facturés tant qu'on ne les purge pas (voir Vercel Blob).
• Les comptes et listes de colonnes de ce runbook datent du schéma du 2026-10-08 : si prisma/schema.prisma a changé depuis, régénérer les annexes C, D, E avant de s'en servir (une colonne en trop ou en moins fait échouer l'export ou l'import, sans rien écrire à moitié).

Annexes

Requêtes générées depuis le schéma du 2026-10-08, à coller par le propriétaire. Aucune ne contient d'URL ni de secret : la connexion vient de psql "$SRC" ou psql "$DST".

Annexe A. Compte exact par table (lecture seule, sur neondb)

Annexe B. Tables en base absentes du schéma (lecture seule)

Annexe C. export.sql (sur $SRC, lecture seule)

Annexe D. import.sql (sur $DST, une transaction)

Annexe E. compare.sql (sur $SRC puis $DST, lecture seule)