ADR-0011 · Studio : dépôt séparé

---

title: ADR-0011 — Le studio interne est un dépôt séparé description: Historique : le studio interne comme dépôt séparé, dont Orbit est reconstruit (remplacé).

Statut

Remplacé · 2026-09-26

Remplace ou amende : Côté studio, rien. Côté plateforme, cette décision contredit l'ADR 0027 et amende l'ADR 0024 §4 et l'ADR 0026 : une ADR plateforme les remplacera en phase 1 des ponts (carte, Q0), sans que ce dépôt y touche.

Origine : ADR 0001 du dépôt applicatif Orbit, renumérotée 0011 à l’intégration dans cette série (une seule série d’ADR vit désormais ici).

Statut dans Orbit (2026-10) : remplacée. Cette décision est gardée comme historique : elle a créé l'ancien dépôt Studio dont Orbit est reconstruit (base figée 94d051c, Base source figée). Ce qu'elle décrivait n'est plus vrai :

• le studio n'est plus un atelier interne séparé d'une plateforme parente : son code vit dans BoostEcom/orbit.easyconnector.app comme Creative Studio, outil natif d'Orbit (/studio), à côté du Brain (ADR 0017 et 0018) ;
• l'ancienne plateforme n'est ni le parent ni une dépendance d'Orbit : les ponts B1 à B10 sont retirés avec leurs variables (PLATFORM_*, CAPTURE_BRIDGE_SECRET, CINEMA_EXCHANGE_ORIGIN, PRODUCT_REPOS_READ_TOKEN), et les ADR « plateforme » citées ci-dessous ne gouvernent plus ce dépôt ;
• le registre ne contient qu'un produit de démonstration, orbit.

Restent valides, et repris par Orbit : une base Neon propre avec migrations committées et garde de cible, un login propre (OTP sur invitation), des crédits par membre, et la copie du workflow de rendu avec une cible de dispatch configurable (CREATIVE_RENDER_REPO). Les identifiants de l'ancien dépôt et de l'ancienne organisation sont neutralisés dans cette copie (règle de nommage de AGENTS.md).

Répond à la question Q0 de la carte de migration (docs/migration/carte-de-migration.md de l'ancien dépôt, non portée dans Orbit ; elle reste dans l'archive du dépôt hérité). Les ADR plateforme citées étaient lues sur le dépôt de l'ancienne plateforme, origin/main à d9c3165ab, sous docs/decisions/.

Contexte

Le plan A (la plateforme produit son propre marketing : visuels, vidéos, films, distribution Growth) vit aujourd'hui dans la plateforme, sous /ops/creative/* et creative/. Il partage le module <Studio> avec le Studio marchand (plan B) depuis l'ADR 0024, et le plan C (agence) a été retiré par l'ADR 0043.

Le 2026-09-20, l'ADR 0027 (« le siège reste dans la codebase ») a refusé explicitement un dépôt séparé. Elle nommait quatre coûts. Le 2026-09-26, le propriétaire a décidé l'inverse : un dépôt Studio séparé, sa base Neon, son login, ses crédits par membre, pour une équipe de deux (le fondateur et son frère), sans toucher la plateforme pour le moment.

Une ADR qui en contredit une autre doit dire pourquoi les coûts nommés ne tiennent plus, ou comment on les paie. C'est l'objet de ce document.

Pourquoi maintenant, alors que 0027 disait non

L'ADR 0027 raisonnait sur un siège qui lit ce que la plateforme produit (Growth, Distribution, Data, Tracking) et sur un défaut de désignation (la boutique personnelle du fondateur affichée dans le siège), corrigé ensuite par l'ADR 0026. Trois faits ont changé depuis :

1. Le plan A est devenu un atelier de production, pas un tableau de bord. Il génère, rend, filme et publie, pour plusieurs produits (le produit de la plateforme, une extension, un thème, une app, un connecteur) et pour des générations libres. La plateforme ne connaît qu'un tenant fondateur et une boutique : elle n'a pas de modèle pour « un produit qui n'est pas une boutique » (carte, Q6).
2. L'équipe grandit et la dépense n'a aucune porte. La production interne est facturée au coût fournisseur sans porte de solde (canAffordStudioMedia renvoie ok), et les rendus, les films, la Fabrique et les GIF ne sont pas mesurés (carte, §1.2 point 4). Ouvrir le studio à une deuxième personne sans ledger par membre laisse la dépense illimitée (R5). Ce ledger est plus simple à poser sur une base neuve que dans le ledger org de la plateforme.
3. Le plan C est retiré (ADR 0043). Le studio ne produit plus pour des marques clientes : il n'a plus besoin des tenants marchands, seulement de ponts en lecture et d'un pont de capture.

Les quatre coûts de l'ADR 0027, un par un

1. La porte (« une seconde implémentation d'un contrôle d'accès est la chose qu'on rate »)

Payé, et borné. Le studio refait une porte, mais une porte plus petite que celle de la plateforme :

• invitation seule, OTP par Resend (même flux que la plateforme), un autre NEXTAUTH_SECRET (carte §5.4 : le secret plateforme ne sort jamais) ;
• cinq rôles fermés (founder, creator, reviewer, distributor, viewer), relus en base à chaque requête, jamais dans le JWT : c'est la propriété de la porte platform.* que 0027 voulait préserver, reprise telle quelle ;
• le même canonicalEmail que la plateforme, copié octet pour octet (packages/db/src/canonical-email.ts), pour que les mandats AccessGrant existants servent de liste initiale des membres ;
• les motifs de sécurité de la plateforme (lockout OTP, CSRF, rate limit, IP de confiance) sont recopiés, pas réinventés (carte §3.4).

La phase 2 livre cette porte avec ses tests E2E-01 à E2E-04. Ce qu'on accepte : une deuxième implémentation existe. Ce qu'on refuse : qu'elle soit plus permissive que la première. Le schéma est posé dès la phase 1 (StudioMember, rôles, statut, révocation, échéance).

2. Les moteurs sont les mêmes (« il faudrait une API d'écriture interne »)

Évité en copiant, et en ne dépendant que de ponts additifs et étroits. Le studio n'appelle pas la plateforme pour générer : il porte sa copie du moteur (journal, fournisseurs, Remotion, cinéma) et écrit dans sa base. La plateforme garde la sienne pour le plan B, sans aucun changement (carte, Q1 recommandation (a)). Il n'y a donc pas d'API d'écriture interne vers la plateforme.

Les seuls échanges sont des ponts, tous listés (carte §6) :

• en lecture, déjà existants : clés bei_ pour la veille (P10), /api/og (P6), pages publiques (capture anonyme) ;
• à créer, additifs et plus tard : B1 (ticket de capture), B2 (attribution), B3 (demande Bulletin), B6 (report de dépense), puis les autres. B1 est le premier changement de plateforme autorisé, et il est étroit : un endpoint signé par un secret dédié (CAPTURE_BRIDGE_SECRET), une table, un ticket à usage unique.

3. La dérive de forme (« deux copies dans deux dépôts divergent au premier correctif »)

Accepté, et surveillé. La dérive est le vrai prix de cette décision. On la paie de trois façons :

• une copie canonique par sujet. Le studio devient la source du moteur cinéma, du contrat de capture v1 et du catalogue templates.json (carte, Q3). La plateforme les consomme, elle ne les réécrit pas ;
• des contrats, pas des copies silencieuses. Le contrat window.__ORBIT_CINEMA__ v1 ne change qu'en v2 (P1). Le contrat UTM (utmFor(), utm_content = GrowthUnit.id) est gardé par un test dans les deux dépôts (P9). Les ids GrowthUnit sont préservés à l'import ;
• des gardes croisées. Parité du catalogue par hash (E2E-20), derive-design-md --check planifié contre le dernier main de la plateforme (E2E-18), snapshot publié des chiffres affichés par les films (B9).

Le module <Studio> lui-même (ADR 0024) cessera d'être partagé : le plan B garde le sien dans la plateforme, le studio en porte une copie qui évolue pour le plan A. C'est une divergence voulue, pas une dérive : les deux montages n'ont plus les mêmes besoins (produits contre boutiques, crédits par membre contre crédits par organisation).

4. Le même lecteur (« deux applications lui demanderaient deux connexions »)

Accepté pour l'instant. Le fondateur aura deux connexions, avec la même adresse email. La plateforme n'a aujourd'hui aucun côté serveur pour « Se connecter avec la plateforme » (carte, B5). Un SSO sera étudié plus tard, si le coût du second login se fait sentir (Q4). Pour une équipe de deux, un OTP de plus par session est un coût faible face au bénéfice d'une dépense bornée par membre.

Décision

1. Le studio interne vit dans son propre dépôt (l'ancien dépôt Studio, remplacé depuis par BoostEcom/orbit.easyconnector.app), un monorepo pnpm : apps/web (Next 16, React 19), packages/remotion (React 18, Remotion 4.0.242), packages/cinema, packages/engine, packages/db, products/.
2. Il a sa propre base Neon, avec des migrations Prisma committées (prisma migrate deploy en production). Il ne pointe jamais sur la base de la plateforme, et un garde le refuse (packages/db/scripts/guard-target.ts).
3. Il a son propre login (NextAuth v4, OTP Resend, invitation seule) et ses crédits par membre en USD au coût fournisseur (allocation mensuelle UTC sans report, refus dur à zéro, fondateur illimité mais tracé, alerte d'équipe).
4. Il ne modifie pas la plateforme. Tout ce qui est move-to-studio est une copie ; rien n'est retiré de la plateforme avant la phase de nettoyage (carte §8.3), et chaque changement de plateforme (B1 à B10) est un chantier distinct, additif, décidé à part.
5. Il garde sa copie du workflow de rendu (GitHub Actions), avec une cible de dispatch configurable (CREATIVE_RENDER_REPO).

Ce que cette décision ne change pas

• ADR 0017 de la plateforme : Remotion reste le moteur vidéo du plan A. Motion.so et Higgsfield restent hors chemin. La licence : gratuite pour deux personnes, Automators ou Company au-delà de trois avec automatisation (billing/2787).
• ADR 0043 : le plan C reste retiré. clientBrandsFor n'est pas migré (Q8). Le studio produit pour les produits de l'organisation et en mode libre, jamais pour une marque cliente.
• ADR 0026 : son principe, « désigner plutôt que deviner », est repris. Le studio n'a plus de tenant fondateur : il a un registre de produits (products/products.json) où chaque produit est déclaré, et un id inconnu lève une erreur au lieu de retomber sur un produit par défaut.
• ADR 0024 : ses principes « toute génération est une ligne, écrite avant le fournisseur » et « un provider est un adaptateur derrière une capacité » sont repris. Son §4 (« le profil Founder est un tenant de la plateforme ») cesse de décrire le plan A une fois la bascule faite.

Conséquences

• Deux dépôts, deux déploiements Vercel, deux bases, deux jeux de secrets. Les secrets de la plateforme ne sont jamais copiés (carte §5.4).
• Le quota GitHub Actions reste partagé avec la plateforme : un blackout bloque les deux (R10). Le studio affiche un statut « quota » lisible (E2E-14).
• Tant que B1 n'existe pas, le studio filme les pages publiques, des plateaux locaux ou de fixture, et importe les films lancés depuis /ops (carte §6.2).
• La plateforme devra, plus tard et dans ses propres PR : une ADR qui remplace 0027 et amende 0024 §4 et 0026, les ponts B1 à B10, puis le nettoyage.

Alternatives écartées