Déploiement

AISCouncil est déployé en tant que fichiers statiques sur Cloudflare Pages avec la logique API s'exécutant sur Cloudflare Workers. Un script de déploiement unifié gère toutes les cibles.

Cibles de Déploiement

Cible	URL	Type	Commande
App	`aiscouncil.net`	CF Pages (statique)	`scripts/deploy.sh pages`
Staging	`aiscouncil.net`	CF Pages (statique)	`scripts/deploy.sh pages-staging`
API Worker	`api.aiscouncil.net`	CF Worker	`scripts/deploy.sh worker`
Auth Worker	`auth.aiscouncil.net`	CF Worker	`scripts/deploy.sh worker-auth`
App Store	`store.aiscouncil.net`	CF Pages (statique)	`scripts/deploy.sh store`
Tout	Tout ce qui précède	Tout	`scripts/deploy.sh all`

Variables d'Environnement

Exportez celles-ci dans ~/.bashrc (ne les commitez jamais) :

export CF_ACCOUNT_ID_AISCOUNCIL="votre-cloudflare-account-id"
export CF_PAGES_TOKEN_AISCOUNCIL="votre-pages-api-token"
export CF_WORKER_TOKEN_AISCOUNCIL="votre-worker-api-token"

Overrides optionnels :

export CF_PAGES_PROJECT_AISCOUNCIL="aiscouncil"              # défaut
export CF_PAGES_PROJECT_AISCOUNCIL_STAGING="aiscouncil-staging"  # défaut

avertissement

Ces tokens accordent l'accès de déploiement à votre compte Cloudflare. Ne les commitez jamais dans le référentiel. Le script de déploiement quittera avec une erreur si des variables requises sont manquantes.

Déploiement Pages (Production)

Étape par Étape

Assemblez l'application depuis les sources :

./build.sh

Déployez en production :

scripts/deploy.sh pages

Cette commande :

Crée un répertoire _deploy/ propre
Copie les fichiers statiques via rsync, en excluant les artefacts de développement
Minifie index.html avec html-minifier-terser (~40% de réduction de taille)
Déploie vers Cloudflare Pages avec --branch=main
Nettoie _deploy/

info

Les déploiements de production utilisent toujours --branch=main. Cela est requis pour que CF Pages serve sur le domaine de production (aiscouncil.net).

Ce Qui Est Déployé

L'étape rsync exclut tout ce qui n'est pas un actif destiné au navigateur :

Répertoires exclus : src/, tools/, kernel/, serve/, worker/, worker-auth/, doc.aiscouncil.net/, node_modules/, .git/, .github/, .carl/, .claude/, modules/, scripts/, core-types/, bridge/, i18n/, dist/, build/

Types de fichiers exclus : *.py, *.zig, *.zon, *.md, *.sh, *.css, .env*

Fichiers de config exclus : package.json, package-lock.json, vitest.config.*, tsconfig.json, .cfignore, .gitignore

Ce qui reste sont les actifs de production : index.html, sw.js, icônes, manifest.webmanifest, fichiers JSON registry/, sdk/, ads.json, sitemap.xml et tous les répertoires de mini-programmes ou d'apps.

Minification

Les déploiements de production passent index.html dans html-minifier-terser avec ces options :

Réduire les espaces
Supprimer les commentaires
Supprimer les attributs redondants
Réduire les attributs booléens
Minifier le CSS en ligne
Minifier le JavaScript en ligne

La réduction de taille typique est ~40% (ex., 980 Ko réduit à ~580 Ko).

Déploiement Staging

Déployez vers l'environnement de staging sans minification :

scripts/deploy.sh pages-staging

Staging est servi depuis aiscouncil.net. L'application détecte automatiquement son domaine au runtime et ajuste les URLs API, les domaines de cookies et les références cross-origin en conséquence.

Promouvoir Staging vers Production

Après validation sur staging, promouvez le même build en production :

scripts/deploy.sh promote

Cela redéploie le code actuel vers le projet Pages de production avec minification activée. Le code de l'application est identique — seul le domaine change.

Déploiement Worker

API Worker

scripts/deploy.sh worker

Cela exécute npx wrangler deploy à l'intérieur du répertoire worker/ en utilisant l'ID de compte et le token Worker depuis votre environnement.

Auth Worker

scripts/deploy.sh worker-auth

Même processus pour le répertoire worker-auth/.

Secrets Worker

Les Workers nécessitent des secrets qui sont définis séparément des déploiements de code. Utilisez wrangler secret put depuis le répertoire worker :

cd worker
npx wrangler secret put JWT_SECRET
npx wrangler secret put STRIPE_SECRET_KEY
npx wrangler secret put STRIPE_WEBHOOK_SECRET
npx wrangler secret put WEBHOOK_PATH_SECRET

cd worker-auth
npx wrangler secret put JWT_SECRET
npx wrangler secret put GOOGLE_CLIENT_SECRET
npx wrangler secret put APPLE_CLIENT_SECRET
npx wrangler secret put GITHUB_CLIENT_SECRET

astuce

Les secrets persistent à travers les déploiements. Vous n'avez besoin de les définir qu'une seule fois, ou lors de la rotation des identifiants.

Configuration Worker

Chaque worker a un wrangler.toml qui définit :

Le nom du worker et les routes
Les bindings de namespace KV
Les références de variables d'environnement
Les paramètres de compatibilité

Cache du Service Worker

Le Service Worker côté client (sw.js) utilise un cache versionné :

const CACHE = "ais-v1.0.0";

Quand incrémenter la version du cache :

Changements cassants sur le shell de l'application (structure HTML, CSS critique)
Changements des actifs pré-mis en cache (icônes, manifeste)
Versions majeures

Incrémenter la version fait que le Service Worker :

Crée un nouveau cache avec le nouveau nom
Pré-met en cache tous les actifs listés
Supprime tous les anciens caches à l'activation

avertissement

Oublier d'incrémenter la version du cache après des changements cassants fera que les utilisateurs verront du contenu périmé jusqu'à ce qu'ils effacent manuellement leur cache navigateur ou que l'ancien Service Worker expire.

Tout Déployer

Déployez l'application Pages, le worker API et le worker auth en séquence :

scripts/deploy.sh all

Vérification Post-Déploiement

Après le déploiement, vérifiez que l'application est servie correctement :

# Vérifier la production
curl -s https://aiscouncil.net/ | head -5

# Vérifier la santé de l'API
curl -s https://api.aiscouncil.net/health

# Vérifier la santé de l'auth
curl -s https://auth.aiscouncil.net/health

info

Cloudflare Pages invalide automatiquement son cache CDN lors du déploiement, mais la propagation peut prendre 1-2 minutes globalement. Si vous voyez du contenu périmé, attendez brièvement et réessayez.

Architecture de Domaine

L'application utilise la détection de domaine au runtime pour supporter à la fois la production et le staging :

Domaine	Constante	Production	Staging
App	`AIS.DOMAIN`	`aiscouncil.net`	`aiscouncil.net`
Marketing	`AIS.WWW`	`www.aiscouncil.net`	`www.aiscouncil.net`
API	`API_BASE`	`https://api.aiscouncil.net/v1`	`https://api.aiscouncil.net/v1`
Auth	`AUTH_BASE`	`https://auth.aiscouncil.net/v1`	`https://auth.aiscouncil.net/v1`
Docs	`AIS.DOC_BASE`	`https://doc.aiscouncil.net`	`https://doc.aiscouncil.net`
Store	`AIS.STORE_URL`	`https://store.aiscouncil.net`	`https://store.aiscouncil.net`

Les URLs de base API peuvent aussi être remplacées via localStorage pour le développement local :

localStorage.setItem("ais-api-base", "http://localhost:8787/v1");
localStorage.setItem("ais-auth-base", "http://localhost:8788/v1");

Développement Local

Pour le développement local sans déploiement :

Construisez l'application : ./build.sh
Servez index.html avec n'importe quel serveur de fichiers statiques (ex., python3 -m http.server 8080)
Exécutez les Workers localement avec Wrangler :

cd worker && npx wrangler dev
cd worker-auth && npx wrangler dev --port 8788

Remplacez les URLs de base API dans la console du navigateur :

localStorage.setItem("ais-api-base", "http://localhost:8787/v1");
localStorage.setItem("ais-auth-base", "http://localhost:8788/v1");
location.reload();

Cibles de Déploiement​

Variables d'Environnement​

Déploiement Pages (Production)​

Étape par Étape​

Ce Qui Est Déployé​

Minification​

Déploiement Staging​

Promouvoir Staging vers Production​

Déploiement Worker​

API Worker​

Auth Worker​

Secrets Worker​

Configuration Worker​

Cache du Service Worker​

Tout Déployer​

Vérification Post-Déploiement​

Architecture de Domaine​

Développement Local​