Mise à jour session 2 · 22/07/2026 · directive commanditaire : hébergement front Cloudflare

Dépôt GitLab, stack technique et déploiement

Cette page rend le démarrage de l'implémentation immédiat : organisation GitLab (groupe, sous-groupes, dépôts décrits), arborescence du monorepo, stack complète et explicite, chaîne CI/CD GitLab → Cloudflare Pages + Supabase, secrets, environnements, et bascule du prototype vers Figma. Ce pack lui-même est déployable en 2 minutes (voir README.md et .gitlab-ci.yml à la racine).

1 · Organisation GitLab : groupe, sous-groupes, dépôts

horizon/                                [GROUPE GitLab]
│   Accès par rôle, variables CI protégées communes (jetons Cloudflare, Supabase),
│   modèles de tickets et de demandes de fusion, registre des décisions.
│
├── produit/                            [SOUS-GROUPE : ce qui est livré aux utilisateurs]
│   └── horizon-app                     [DÉPÔT · monorepo applicatif]
│       SPA Vue 3 + paquets partagés + schéma Supabase + fonctions + tests.
│       C'est ici que vivent les 38 lots L-01 à L-38 (HZ-PLN-004 annexe A).
│
├── plateforme/                         [SOUS-GROUPE : ce qui fait tourner le produit]
│   ├── horizon-infra                   [DÉPÔT · infrastructure déclarative]
│   │   Configuration Cloudflare (Pages, DNS, règles, en-têtes de sécurité _headers),
│   │   provisionnement des projets Supabase UE (recette, production),
│   │   gestion et rotation documentée des secrets.
│   └── horizon-ops                     [DÉPÔT · exploitation]
│       Runbooks RB-01 à RB-04 exécutables, sondes de disponibilité,
│       tableaux de bord SLI, scripts d'exercice PITR et de réversibilité.
│
└── horizon-conception                  [DÉPÔT · CE PACK]
    Site statique (wireframes, design system, prototype, documentation,
    présentation), déployé sur Cloudflare Pages par sa propre CI.

Pourquoi un monorepo applicatif unique ? Décision du plan (HZ-PLN-004 §5) : types partagés front/fonctions, une seule CI, atomicité des changements transverses. L'éclatement par dossier reste possible si un composant doit vivre séparément. Les dépôts horizon-infra et horizon-ops sont séparés car leurs cycles de vie, droits d'accès et secrets diffèrent [Proposition P-09].

2 · Arborescence du monorepo horizon-app

horizon-app/
  apps/web/                      SPA Vue 3 (modules d'écran, stores Pinia, routes)
    src/modules/                 tableau-bord | clients | simulateur | portefeuilles |
                                 documents | conformite | parametres | auth
    src/stores/                  session, clientCourant, simulation, echeancier, notifications
    public/_headers              en-têtes de sécurité servis par Cloudflare Pages (CSP, HSTS...)
    public/_redirects            /* -> /index.html 200 (routage SPA côté Cloudflare)
    functions/_middleware.ts     passerelle d'accès (clé HORIZON_ACCESS_KEY) — cf. §5 bis
  packages/ui/                   composants Hz* + documentation vivante (états)
  packages/coeur-calcul/         formules RG (pur, déterministe, couverture 90 %+)
  packages/types/                schémas zod partagés front / fonctions
  packages/api-client/           accès REST (PostgREST sous RLS) + fonctions
  supabase/
    migrations/                  0001_schema · 0002_rls · 0003_audit · 0004_seed_demo
    functions/                   simuler | echeance-transition | export-pdf | generer-occurrences
    config.toml                  auth (sessions 30 min, TOTP), storage (bucket privé « rapports »)
  tests/e2e/                     Playwright : parcours CU, non-régression visuelle CA-08, axe
  tests/rls/                     suite de cloisonnement (bloquante en CI)
  agents/                        fiches de mission de la fabrication augmentée par IA
  docs/                          corpus HORIZON + registre des décisions D-xx
  .gitlab-ci.yml                 pipeline complet (§4)
  wrangler.toml                  projet Cloudflare Pages (nom, dossier de build dist/)

3 · Stack technique explicite (aucune zone d'ombre)

4 · Pipeline CI/CD de l'application (GitLab → Cloudflare + Supabase)

# .gitlab-ci.yml du dépôt horizon-app (extrait de référence)
stages: [verifier, tester, construire, valider, deployer_recette, fumee, deployer_production]

verifier:      lint + typage strict + détection secrets/termes proscrits + audit dépendances
tester:        unitaires coeur-calcul (90 %+, cas B-01..B-06 gelés) + composants Hz*
               + suite RLS sur base éphémère (BLOQUANTE)
construire:    build SPA (Vite -> dist/) + fonctions ; budgets taille/performance
valider:       Playwright e2e (CU-01..08) + non-régression visuelle 1440/1280 (CA-08)
               + accessibilité axe-core
deployer_recette:   (auto sur main)
  - supabase db push --db-url $SUPABASE_DB_URL_RECETTE          # migrations d'abord
  - supabase functions deploy --project-ref $SUPABASE_REF_RECETTE
  - wrangler pages deploy dist --project-name horizon-recette
fumee:         sonde de santé + parcours critique automatique sur recette
deployer_production: (manuel, sur étiquette vX.Y.Z, double approbation)
  - mêmes étapes vers $SUPABASE_REF_PROD + projet Pages horizon-prod
  - surveillance renforcée 48 h post-déploiement

Règles héritées du plan : migrations toujours appliquées avant le code qui les utilise, répétition à blanc sur recette avant production, retour arrière par redéploiement de l'étiquette précédente, clé de service uniquement côté fonctions et CI.

5 · Déployer CE pack (horizon-conception) sur Cloudflare Pages

• Direct upload (2 minutes) : Cloudflare → Workers & Pages → Create → Pages → Upload assets → glisser le contenu du zip du projet. URL publique immédiate. Aucun build : site statique à liens relatifs.
• Ligne de commande : wrangler pages deploy . --project-name horizon-conception
• CI fournie : le fichier .gitlab-ci.yml à la racine du pack déploie automatiquement la branche main et publie un aperçu par branche.
• En local : servir le dossier (npx serve . ou python3 -m http.server 8080). L'ouverture en double-clic (file://) fonctionne pour l'essentiel mais certains navigateurs restreignent ce mode : le serveur local ou Cloudflare Pages est la voie garantie.

5 bis · Protéger l'accès par une clé d'authentification

Le pack est confidentiel. Une passerelle Cloudflare Pages Functions (functions/_middleware.js, fournie à la racine) protège l'intégralité du site par une clé, sans jamais écrire de secret dans le dépôt. La clé vit à deux endroits, en miroir :

# .gitlab-ci.yml — injection de la cle avant chaque deploiement (extrait)
before_script:
  - npm install -g wrangler
  - if [ -n "$HORIZON_ACCESS_KEY" ]; then \
      printf "%s" "$HORIZON_ACCESS_KEY" | \
      wrangler pages secret put HORIZON_ACCESS_KEY --project-name "$CF_PAGES_PROJECT"; \
    fi
script:
  - wrangler pages deploy . --project-name "$CF_PAGES_PROJECT" --branch "$CI_COMMIT_BRANCH"

Si HORIZON_ACCESS_KEY n'est pas définie, le site reste ouvert : pratique en local et sur les aperçus, verrouillé dès que la clé est posée en production. La même mécanique (variable GitLab miroir d'un secret Cloudflare / Supabase) s'applique à tous les secrets de l'application : jetons, clé de service Supabase, DSN Sentry.

6 · Environnements

7 · Bascule du prototype vers Figma

Le prototype est du HTML/CSS propre alimenté par les tokens : il s'importe fidèlement dans Figma via un plugin d'import HTML (par exemple « html.to.design ») pointé sur l'URL Cloudflare Pages du prototype (.../03-prototype/index.dc.html), écran par écran (accueil, simulateur, clients, conformité...). Les calques arrivent éditables ; les couleurs correspondent aux tokens du design system à recréer en styles Figma. Sens inverse déjà couvert : la maquette Figma source reste la loi (V-04).

8 · Liste de contrôle « prêt à implémenter » (J0)