Chemin de migration et validation pratique

Archive de conception. Cette page raconte ce qui etait vise le jour ou elle a ete ecrite, pas l'etat du code aujourd'hui. Ce qui a ete livre depuis est recense dans le README.

← retour au README

12. Chemin de migration et stratégie de déploiement progressif

Comment passer de l'existant à la V2 sans casser les parcours actuels ni effrayer les utilisateurs.

Coexistence pendant la transition

• L'ancienne route /[orgSlug]/[storeSlug]/workspace reste fonctionnelle (LiquidEditor existant) pendant la mise en place de la V2
• La V2 est livrée sous /[orgSlug]/[storeSlug]/workspace/v2 ou derrière un feature flag : pas de bascule brutale
• Une fois la V2 stable et assez adoptée, redirection de l'ancienne vers la nouvelle

Feature flags

• Variable d'env WORKSPACE_V2_ENABLED côté serveur, par organisation via Organization.featureFlags: Json (à ajouter au schéma Prisma)
• Forçage par URL ?v2=true pour les premiers testeurs internes
• Bascule visible dans /[orgSlug]/~/settings pour les admins

Cohorte bêta

• Vague 1 (semaine 1) : équipe BoostEcom interne uniquement (boutiques Boutique Demo + Valise Demo) pour un test de fumée
• Vague 2 (semaines 2-3) : 5-10 clients sélectionnés à la main, retours intensifs (salon Discord privé)
• Vague 3 (semaine 4+) : activation volontaire via une bascule dans les réglages, badge « Beta » visible
• GA : la V2 devient le défaut (désactivation volontaire au lieu d'activation volontaire), l'ancien workspace reste 30 jours en mode legacy puis est supprimé

Plan de rollback

• Si la V2 est boguée après sa livraison : feature flag désactivé → tout le monde revient sur l'ancien workspace
• Les données V2 (Tasks, ThemeBranches, ThemeVersions) restent en base : pas de perte
• ThemeBranches dont le draft Shopify est orphelin : nettoyage automatique après 30 jours (cf. Bloc 4 de la stack)

Communication

• Changelog public à la sortie de la bêta V2 (/changelog de la plateforme)
• Notification dans l'application avec un CTA « Try Workspace V2 » pour les organisations sur liste d'autorisation
• Email aux admins des organisations des vagues 2 et 3
• Documentation complète sur /community/docs avant la GA

14. Validation pratique avant la V1

Scénarios de test à passer avant de considérer la V1 comme livrée. Chaque scénario est exécuté à la main sur les boutiques de développement (Boutique Demo / Valise Demo) :

Scénario 1 — Couche de connaissance

User : "Quelles pages ai-je sur mon store ?"
@Atlas : doit lister toutes les pages CMS via shopify_list_pages

User : "Combien de produits actifs ?"
@Atlas : doit donner le count exact

User : "Quels apps sont installées ?"
@Atlas : doit lister via currentAppInstallation

→ Aucune réponse "je ne sais pas" sur info accessible Shopify

Scénario 2 — File de tâches autonome

User : "Audit le SEO de la home et fix les issues critiques"
→ Task créée, status pending → in_progress
→ @Atlas lance audit, identifie 3 issues
→ Génère 3 sub-tasks (h1 manquant, meta desc, alt images)
→ Pour chacune, edit le fichier theme dans la branch courante
→ Task status → waiting_review
→ User reviewe diff → approve → publish
→ Task → done

Scénario 3 — Sandbox + restauration de version

User édite manuellement un fichier hero.liquid
→ snapshot v1 créé
@Atlas modifie aussi le fichier
→ snapshot v2 créé
User clique sur v1 dans le timeline
→ files restaurés à v1
→ snapshot WIP auto-créé avant restore

Scénario 4 — Rechargement à chaud de la preview live

User édite un fichier CSS dans le worktree
→ save → push themeFilesUpsert
→ broadcast SSE
→ iframe storefront hot-swap CSS sans full reload
→ user voit le changement en <1s

Scénario 5 — Permissions : seul Shopify filtre

User connecte un store avec scopes minimaux (read_themes only)
@Atlas tente d'éditer un produit → Shopify refuse (403 / userErrors)
@Atlas propose : "Étends les scopes via custom app, voir /docs/scopes"
→ User élargit → retry → succès
→ pas de gate côté BoostEcom, tout passe par Shopify

Scénario 6 — Connaissance partagée entre boutiques

Org avec 2 stores : A (BFCM done) + B (BFCM en prep)
User : "Sur store B, applique ce qu'on a fait pour BFCM sur A"
@Atlas : lit les ThemeVersion de store A taggés "BFCM" → recrée dans
        store B branch

Scénario 7 — Suivi des coûts + pause automatique

User a $5 de credits restants
@Atlas lance une task complexe estimée à $7
→ pre-stream estimate refuse 402
→ @Atlas propose : reduce scope ou top up credits
→ user top up via Stripe → retry

Suivant : operations.md