02 — CI/CD & DÉPLOIEMENT DES SERVICES

Objectif

À la fin de ce fichier :

Un pipeline GitLab CI fonctionnel qui build, teste et déploie automatiquement
Le service pilote configuration tourne en staging et répond sur /health
Les 11 microservices sont déployés dans l'ordre de dépendance
Les 2 dashboards Nuxt.js sont déployés sur Firebase Hosting
Chaque service est accessible et connecté à ses dépendances (DB, Redis, services tiers)

Pré-requis : fichier 01_infra_base.md complété, checklist verte.

PARTIE A — SERVICE PILOTE

L'objectif est de valider toute la chaîne sur un seul service avant de généraliser. On choisit configuration parce qu'il n'a aucune dépendance externe (pas de Redis, pas d'Auth0, pas de Firebase). S'il ne démarre pas, le problème vient forcément de l'infra ou du pipeline, pas d'une intégration manquante.

A.1 DOCKERFILE

Objectif

Un Dockerfile standard pour les services NestJS, réutilisable par tous les microservices avec un minimum d'adaptation.

Instructions pour l'agent

Créer un Dockerfile template dans le repo du service configuration. Ce template sera copié et adapté pour chaque service.

Principes :

Multi-stage build : un stage builder pour installer et compiler, un stage runner léger pour l'image finale.
Image de base : node:20-alpine (légère, ~50 Mo au lieu de ~350 Mo pour l'image complète).
Package manager : utiliser pnpm si le service l'utilise, sinon npm. Vérifier le lockfile présent dans le repo.
Build : utiliser SWC (déjà configuré dans les services NestJS). La commande est probablement pnpm build ou npm run build.
User non-root : créer un utilisateur nex dans l'image et exécuter le process sous ce user. Ne jamais tourner en root.
HEALTHCHECK : inclure un healthcheck Docker qui appelle /health sur le port du service.
Port : exposer le port du service (voir les variables du fichier 00).
.dockerignore : exclure node_modules, .git, tests, docs, fichiers IDE.

Recommandations :

Le stage builder installe TOUTES les dépendances (dev incluses pour la compilation). Le stage runner copie uniquement le code compilé et les node_modules de production.
Fixer la version exacte de Node (pas node:20-alpine mais node:20.x.x-alpine selon ce que l'équipe utilise) pour garantir la reproductibilité.
L'image finale doit peser moins de 200 Mo. Si elle dépasse, vérifier qu'on ne copie pas les devDependencies.

Validation

bash

# Build local
docker build -t nex/configuration:test .

# Vérifier la taille
docker images nex/configuration:test --format "{{.Size}}"
# Attendu : < 200 Mo

# Tester le démarrage (sans DB pour l'instant — juste vérifier que le process démarre)
docker run --rm -p 3002:3002 nex/configuration:test
# Le service doit démarrer (il peut crasher si la DB est requise — c'est OK à ce stade)

A.2 PIPELINE GITLAB CI

Objectif

Un pipeline qui se déclenche à chaque push et qui build, teste, scanne et déploie automatiquement.

Instructions pour l'agent

Créer le fichier .gitlab-ci.yml dans le repo du service configuration.

Stages du pipeline :

test → security → build → deploy-staging → notify

Stage test :

Image : node:20-alpine
Installer les dépendances (pnpm install ou npm ci)
Lancer les tests unitaires (pnpm test ou npm run test)
Collecter la couverture de code (format Cobertura pour GitLab)
Collecter les résultats de tests (format JUnit pour GitLab)
Ce stage tourne sur chaque push sur n'importe quelle branche.

Stage security :

Job 1 — Scan d'image Docker avec Trivy : scanner l'image buildée pour les vulnérabilités HIGH et CRITICAL. En staging, allow_failure: true (warning mais ne bloque pas). En production, bloquant.
Job 2 — SonarCloud : analyse statique du code. L'agent doit configurer les properties SonarCloud (project key, organisation, sources). Ce job a besoin de la variable SONAR_TOKEN configurée dans GitLab CI/CD Settings.

Stage build :

Image : docker:24-dind (Docker in Docker)
Se connecter au GitLab Container Registry (docker login $CI_REGISTRY)
Builder l'image Docker avec deux tags :
- $CI_COMMIT_SHORT_SHA (le hash du commit — permet le rollback vers une version précise)
- staging-latest (tag flottant — toujours la dernière version déployée en staging)
Pusher les deux tags vers le registry.
Utiliser --cache-from avec le tag staging-latest pour accélérer les builds suivants.

Stage deploy-staging :

Image : bitnami/kubectl:1.29
Configurer kubectl avec le kubeconfig stocké dans les variables GitLab CI (type File, protégée, masquée)

Mettre à jour l'image du Deployment Kubernetes :

kubectl set image deployment/configuration configuration=$IMAGE:$TAG -n nex-staging

Attendre que le rollout soit terminé (timeout 5 minutes) :

kubectl rollout status deployment/configuration -n nex-staging --timeout=300s

Si le rollout échoue (health check KO) : rollback automatique vers la version précédente :
```
kubectl rollout undo deployment/configuration -n nex-staging
```
Ce stage se déclenche automatiquement sur merge dans la branche staging, manuellement (1 clic) pour les autres branches.

Stage notify :

Envoyer une notification sur Slack (ou Google Chat) avec le résultat du déploiement.
En cas de succès : nom du service, version (commit SHA), lien vers le pipeline.
En cas d'échec : nom du service, erreur, lien vers le pipeline.

Variables à configurer dans GitLab (Settings → CI/CD → Variables) :

Variable	Type	Protégée	Masquée	Usage
`KUBECONFIG_STAGING`	File	Oui	Oui	Kubeconfig pour kubectl
`SONAR_TOKEN`	Variable	Oui	Oui	Token SonarCloud
`SLACK_WEBHOOK`	Variable	Non	Oui	Webhook Slack/Chat

Recommandations :

Ne pas stocker le Doppler token dans GitLab CI. Les secrets applicatifs sont déjà dans K8s via External Secrets Operator. Le pipeline n'a besoin que du kubeconfig pour déployer.
Le stage build doit être rapide. Avec le cache Docker et SWC, un build complet devrait prendre < 3 minutes. Si ça dépasse 5 minutes, vérifier le .dockerignore et le cache.
Le rollback automatique est essentiel. Si la nouvelle version ne passe pas le health check, Kubernetes revient tout seul à la version précédente. Le pipeline doit détecter ça et notifier l'équipe.

Validation

bash

# Pousser un commit sur la branche staging du service configuration
git push origin staging

# Dans GitLab → CI/CD → Pipelines :
# - Stage test : vert
# - Stage security : vert (ou warning acceptable)
# - Stage build : vert, image visible dans Container Registry
# - Stage deploy : vert, rollout status success
# - Stage notify : notification reçue

A.3 MANIFESTS KUBERNETES — SERVICE PILOTE

Objectif

Les fichiers Kubernetes qui décrivent comment le service configuration tourne dans le cluster.

Instructions pour l'agent

Créer le dossier kubernetes/services/configuration/ avec les fichiers suivants :

deployment.yaml :

Namespace : nex-staging
Replicas : 1 (staging, voir fichier 00)
Image : registry.gitlab.com/nex/configuration:staging-latest
Port : 3002
Variables d'environnement : injectées depuis le secret nex-secrets via envFrom.secretRef
Resources requests : 125m CPU, 128Mi mémoire (depuis fichier 00)
Resources limits : 250m CPU, 256Mi mémoire (2x les requests)
Liveness probe : GET /health sur le port 3002, délai initial 15s, intervalle 30s, 3 échecs avant restart
Readiness probe : GET /health sur le port 3002, délai initial 5s, intervalle 10s, 3 échecs avant retrait du trafic
Image pull secret : gitlab-registry
Labels : app: configuration, project: nex, environment: staging, tier: public

service.yaml :

Type : ClusterIP
Port : 3002
Selector : app: configuration

ingress.yaml (service public) :

Host : staging.paywithnex.com
Path : /configuration (prefix)
Backend : service configuration port 3002
TLS : référence au secret cert-manager
Annotations cert-manager pour le ClusterIssuer

hpa.yaml (Horizontal Pod Autoscaler) :

Min replicas : 1 (staging)
Max replicas : 3
Target CPU : 70%

kustomization.yaml :

Référence les 4 fichiers ci-dessus

Recommandations :

La liveness probe redémarre le pod s'il ne répond plus. La readiness probe le retire du trafic s'il n'est pas prêt (par exemple pendant le démarrage ou une surcharge). Les deux sont essentielles.
Le délai initial (initialDelaySeconds) de la liveness doit être suffisant pour que NestJS démarre. 15 secondes est généralement suffisant. Si le service est plus lent à démarrer (migrations TypeORM au boot par exemple), augmenter à 30s.
Les resources limits à 2x les requests donnent de la marge pour les pics sans laisser un pod consommer tout le nœud.

Validation

bash

# Appliquer les manifests
kubectl apply -f kubernetes/services/configuration/ -n nex-staging

# Pod running
kubectl get pods -n nex-staging -l app=configuration
# Attendu : 1/1 Running

# Logs propres
kubectl logs -n nex-staging -l app=configuration --tail=20
# Attendu : logs de démarrage NestJS sans erreur

# Health check interne
kubectl exec -it deploy/configuration -n nex-staging -- wget -qO- http://localhost:3002/health
# Attendu : {"status":"ok"} ou similaire

# Health check via Ingress
curl https://staging.paywithnex.com/configuration/health
# Attendu : {"status":"ok"}

# Le pod peut joindre la DB
kubectl exec -it deploy/configuration -n nex-staging -- sh -c 'nc -zv $DATABASE_HOST 5432'
# Attendu : succeeded

A.4 VALIDATION COMPLÈTE DU PILOTE

Avant de passer à la partie B, tout doit être vert :

[ ] Pipeline GitLab CI passe les 5 stages (test → security → build → deploy → notify)
[ ] Image Docker visible dans GitLab Container Registry
[ ] Pod configuration en status Running (1/1)
[ ] Pas d'erreurs dans les logs du pod
[ ] /health répond via kubectl exec (interne)
[ ] /health répond via curl sur staging.paywithnex.com/configuration/health (externe)
[ ] Le pod se connecte à PostgreSQL
[ ] Un nouveau push sur staging déclenche un redéploiement automatique
[ ] Le rollback fonctionne (tester en déployant volontairement une image cassée)
[ ] Notification Slack/Chat reçue

Si un point est rouge → corriger avant de généraliser.

Le service pilote a validé toute la chaîne : GitLab → Docker → Registry → Kubernetes → Ingress → Cloudflare → utilisateur. Chaque service suivant emprunte exactement le même chemin.

PARTIE B — GÉNÉRALISATION

On déploie les 10 services restants en 4 vagues, dans l'ordre de dépendance défini dans le fichier 00. Chaque vague est déployée en parallèle (les services d'une même vague n'ont pas de dépendance entre eux).

B.1 TEMPLATE DE DÉPLOIEMENT

Instructions pour l'agent

Pour chaque service, l'agent doit :

Créer le Dockerfile dans le repo du service — même structure que le pilote, en adaptant :
- Le port (voir fichier 00)
- Le package manager (pnpm ou npm selon le lockfile)
- Les éventuelles dépendances système (ex: si un service nécessite des packages natifs)
Créer le .gitlab-ci.yml — même structure que le pilote, en adaptant :
- Le nom du service dans les commandes kubectl
- Les tests spécifiques (Cucumber pour orchestrator, tests standard pour les autres)
Créer les manifests Kubernetes (kubernetes/services/<nom>/) :
- deployment.yaml : adapter port, replicas, resources, labels selon fichier 00
- service.yaml : ClusterIP, adapter le port
- hpa.yaml : adapter min/max replicas
- ingress.yaml : uniquement pour les services publics (auth, orchestrator, configuration). Les services internes n'ont pas d'Ingress.
- kustomization.yaml
Pousser sur la branche staging pour déclencher le pipeline
Valider : pod Running + /health OK + logs propres

Particularités par service

L'agent doit prendre en compte ces spécificités :

Service	Particularité à gérer
auth	Nécessite les variables Auth0 (AUTH0_DOMAIN, AUTH0_CLIENT_ID, AUTH0_CLIENT_SECRET). Nécessite Redis. Vérifier que le pod peut joindre Redis en plus de PostgreSQL.
orchestrator	Tests Cucumber dans le pipeline (ajouter un stage ou adapter le stage test). Dépend de TOUS les autres services — son /health peut vérifier la connectivité aux services internes.
customer-profiles-kyc	Pas de particularité. Service standard PostgreSQL.
ledger-wallets	Service critique (argent). Les replicas doivent être à 2 minimum même en staging. A des seeders — vérifier si ils tournent au démarrage ou manuellement.
notifications	Nécessite Firebase FCM (FIREBASE_PROJECT_ID, FIREBASE_SERVER_KEY) et Resend (RESEND_API_KEY). Vérifier que ces secrets sont dans Doppler.
file-service	Nécessite Firebase Storage (FIREBASE_STORAGE_BUCKET). Peut avoir besoin du fichier de credentials Firebase (service account JSON). Si oui, le stocker dans Doppler en base64 et le décoder au démarrage.
providers-gateway	Pas de particularité. Pourrait nécessiter des clés API de providers externes dans le futur.
risk-engine	Pas de particularité. Service standard PostgreSQL.
service-catalog	Nécessite Redis (cache). Vérifier la connectivité Redis comme pour auth.
logs-reporting	Pas de base de données. Ne pas injecter DATABASE_HOST ou les variables PostgreSQL. Le Dockerfile et le deployment doivent refléter ça (pas de health check qui teste la DB).

B.2 WAVE 1 — Services simples (aucune dépendance inter-service)

Services à déployer en parallèle :

logs-reporting
customer-profiles-kyc
providers-gateway
risk-engine

Ces 4 services ne dépendent que de PostgreSQL (sauf logs-reporting qui ne dépend de rien). Ils ne parlent pas aux autres services.

Instructions pour l'agent

Appliquer le template B.1 pour chacun de ces 4 services. L'agent peut les déployer en parallèle — ils sont indépendants.

Attention pour logs-reporting : pas de PostgreSQL. L'agent doit adapter le deployment pour ne pas injecter les variables DB et adapter le health check si nécessaire.

Validation Wave 1

bash

# Tous les pods de la wave 1 sont Running
kubectl get pods -n nex-staging -l app=logs-reporting
kubectl get pods -n nex-staging -l app=customer-profiles-kyc
kubectl get pods -n nex-staging -l app=providers-gateway
kubectl get pods -n nex-staging -l app=risk-engine
# Attendu : chaque pod en 1/1 Running

# Health checks
for svc in logs-reporting customer-profiles-kyc providers-gateway risk-engine; do
  echo "--- $svc ---"
  kubectl exec -it deploy/$svc -n nex-staging -- wget -qO- http://localhost:$(kubectl get svc $svc -n nex-staging -o jsonpath='{.spec.ports[0].port}')/health 2>/dev/null || echo "FAIL"
done

[ ] 4 pods Running
[ ] 4 health checks OK
[ ] Logs propres (pas d'erreurs de connexion DB sauf pour logs-reporting qui n'en a pas)
[ ] Pipelines GitLab verts pour les 4 services

B.3 WAVE 2 — Services avec dépendances externes

Services à déployer :

auth (Redis + Auth0)
service-catalog (Redis)
file-service (Firebase Storage)
ledger-wallets (PostgreSQL + seeders)

Instructions pour l'agent

Avant de déployer cette wave, vérifier que :

Les secrets Auth0 sont dans Doppler et synchronisés dans K8s
Les secrets Firebase sont dans Doppler
Redis est accessible depuis les pods (testé au fichier 01)

Pour auth :

Vérifier que le pod se connecte à Redis ET à PostgreSQL
Tester un flow Auth0 basique (le service doit pouvoir communiquer avec le tenant Auth0)
L'Ingress doit router /auth/* vers ce service

Pour file-service :

Si Firebase Storage nécessite un fichier de credentials (service account JSON), l'agent doit le stocker dans Doppler encodé en base64, et le décoder dans un init container ou au démarrage de l'app.

Pour ledger-wallets :

Vérifier si les seeders tournent automatiquement au démarrage (migration TypeORM). Si oui, le premier démarrage sera plus long — augmenter l'initialDelaySeconds de la liveness probe à 60s.
Ce service gère l'argent. Même en staging, mettre 2 replicas.

Validation Wave 2

bash

# Pods Running
kubectl get pods -n nex-staging -l "app in (auth,service-catalog,file-service,ledger-wallets)"
# Attendu : tous en Running

# Auth connecté à Redis
kubectl exec -it deploy/auth -n nex-staging -- sh -c 'nc -zv $REDIS_HOST 6379'
# Attendu : succeeded

# Auth health via Ingress
curl https://staging.paywithnex.com/auth/health
# Attendu : OK

# Service-catalog connecté à Redis
kubectl exec -it deploy/service-catalog -n nex-staging -- sh -c 'nc -zv $REDIS_HOST 6379'
# Attendu : succeeded

[ ] 4 pods Running (auth en 2 replicas, les autres en 1)
[ ] auth connecté à Redis + PostgreSQL + Auth0
[ ] service-catalog connecté à Redis + PostgreSQL
[ ] file-service connecté à Firebase Storage
[ ] ledger-wallets connecté à PostgreSQL, seeders exécutés
[ ] Ingress /auth fonctionne

B.4 WAVE 3 — Services avec dépendances inter-services

Service à déployer :

notifications (Firebase FCM + Resend)

Instructions pour l'agent

Ce service envoie des notifications push (Firebase) et des emails (Resend). Vérifier que :

FIREBASE_SERVER_KEY est dans Doppler
RESEND_API_KEY est dans Doppler
Le service démarre sans erreur même si aucun autre service ne l'appelle encore

Recommandation : ne pas tester l'envoi réel de notifications en staging pour ne pas spammer. Vérifier uniquement que le service démarre et que son /health passe. Les tests fonctionnels complets viendront avec l'orchestrator.

Validation Wave 3

bash

kubectl get pods -n nex-staging -l app=notifications
# Attendu : 1/1 Running

kubectl logs deploy/notifications -n nex-staging --tail=10
# Attendu : démarrage propre, pas d'erreur Firebase/Resend

[ ] Pod Running
[ ] Logs propres
[ ] Pipeline vert

B.5 WAVE 4 — Orchestrator (dépend de tout)

Service à déployer :

orchestrator

Instructions pour l'agent

L'orchestrator appelle tous les autres services en HTTP. Il ne peut fonctionner correctement que si les 10 autres services sont déployés et sains.

Avant de déployer :

Vérifier que les 10 services précédents sont tous en Running
Vérifier les variables d'environnement de l'orchestrator : il a besoin des URLs internes de chaque service (ex: AUTH_SERVICE_URL=http://auth:3001, WALLETS_SERVICE_URL=http://ledger-wallets:3005, etc.). Ces URLs utilisent les noms de service Kubernetes (DNS interne du cluster).

Variables d'environnement spécifiques :

L'agent doit ajouter dans Doppler (ou directement dans le deployment via env vars) les URLs de chaque service interne. Le format est http://<service-name>:<port> — c'est le DNS interne Kubernetes.

AUTH_SERVICE_URL=http://auth:3001
CONFIGURATION_SERVICE_URL=http://configuration:3002
CUSTOMER_PROFILES_SERVICE_URL=http://customer-profiles-kyc:3004
LEDGER_WALLETS_SERVICE_URL=http://ledger-wallets:3005
NOTIFICATIONS_SERVICE_URL=http://notifications:3006
FILE_SERVICE_URL=http://file-service:3007
PROVIDERS_GATEWAY_SERVICE_URL=http://providers-gateway:3008
RISK_ENGINE_SERVICE_URL=http://risk-engine:3009
SERVICE_CATALOG_SERVICE_URL=http://service-catalog:3010
LOGS_REPORTING_SERVICE_URL=http://logs-reporting:3011

L'Ingress doit router /api/* vers l'orchestrator. C'est le point d'entrée principal de l'API — les apps mobiles et les dashboards appellent /api/... qui est routé vers l'orchestrator, qui lui dispatch vers les services internes.

Tests Cucumber : l'orchestrator a des tests BDD (Cucumber). Le pipeline doit inclure un stage qui exécute ces tests. Ils peuvent nécessiter un environnement avec les services mockés ou réels. Si les tests Cucumber ont besoin des vrais services, les exécuter après le déploiement (en post-deploy) plutôt que dans le CI pré-deploy.

Validation Wave 4

bash

# Pod Running
kubectl get pods -n nex-staging -l app=orchestrator
# Attendu : 2/2 Running (2 replicas)

# Health check externe
curl https://staging.paywithnex.com/api/health
# Attendu : OK

# L'orchestrator peut joindre les services internes
kubectl exec -it deploy/orchestrator -n nex-staging -- sh -c '
  for svc in auth:3001 configuration:3002 customer-profiles-kyc:3004 ledger-wallets:3005 notifications:3006 file-service:3007 providers-gateway:3008 risk-engine:3009 service-catalog:3010 logs-reporting:3011; do
    host=$(echo $svc | cut -d: -f1)
    port=$(echo $svc | cut -d: -f2)
    nc -zv $host $port 2>&1 | tail -1
  done
'
# Attendu : 10 connexions succeeded

[ ] 2 pods Running
[ ] /api/health répond via l'Ingress
[ ] L'orchestrator peut joindre les 10 services internes
[ ] Tests Cucumber passent (si applicables en staging)
[ ] Pipeline vert

B.6 DASHBOARDS NUXT.JS — FIREBASE HOSTING

Objectif

Déployer les 2 dashboards (CMMS et Backoffice) sur Firebase Hosting.

Instructions pour l'agent

Configuration Firebase :

Le fichier firebase/firebase.json doit définir 2 targets de hosting :

Target admin → dossier dashboard/cmms → domaine admin.paywithnex.com
Target backoffice → dossier dashboard/backoffice → domaine bo.paywithnex.com

Build :

Les dashboards utilisent pnpm. La commande de build est probablement pnpm build ou pnpm generate (mode SPA pour CMMS).
Le résultat du build est dans .output/public/ (Nuxt 4) ou dist/ selon la config.

Déploiement :

bash

firebase deploy --only hosting:admin
firebase deploy --only hosting:backoffice

Pipeline GitLab pour les dashboards :

Créer un .gitlab-ci.yml dans le repo des dashboards avec :

Stage build : pnpm install && pnpm build
Stage deploy : firebase deploy --only hosting:<target>
Le token Firebase (FIREBASE_TOKEN) est stocké dans les variables GitLab CI.

Custom domains : Dans la console Firebase Hosting → Custom domains :

Ajouter admin.paywithnex.com
Ajouter bo.paywithnex.com
Firebase fournira des enregistrements DNS à ajouter dans Cloudflare (déjà fait en 01 phase 9).

Recommandations :

Les dashboards appellent l'API sur staging.paywithnex.com. Cette URL doit être configurée comme variable d'environnement au build time (Nuxt runtime config ou .env).
Le CMMS est en mode SPA (SSR désactivé). C'est du pur statique — Firebase Hosting est parfait.
Configurer les redirects dans firebase.json : toutes les routes → index.html (requis pour un SPA avec client-side routing).

Validation

bash

curl -I https://admin.paywithnex.com
# Attendu : HTTP/2 200, headers Firebase

curl -I https://bo.paywithnex.com
# Attendu : HTTP/2 200, headers Firebase

[ ] CMMS Dashboard accessible sur admin.paywithnex.com
[ ] Backoffice accessible sur bo.paywithnex.com
[ ] Les dashboards appellent l'API staging correctement
[ ] Pipeline GitLab déploie automatiquement sur push

CHECKLIST GLOBALE — FIN DU FICHIER 02

Pipeline CI/CD

[ ] Template .gitlab-ci.yml fonctionnel et réutilisé par les 11 services
[ ] Stages : test → security → build → deploy-staging → notify
[ ] Rollback automatique si health check échoue après deploy
[ ] Notifications Slack/Chat fonctionnelles
[ ] Variables GitLab CI configurées (KUBECONFIG, SONAR_TOKEN, SLACK_WEBHOOK)

Microservices (11/11)

[ ] configuration — Running, /health OK (pilote)
[ ] logs-reporting — Running, /health OK (wave 1)
[ ] customer-profiles-kyc — Running, /health OK (wave 1)
[ ] providers-gateway — Running, /health OK (wave 1)
[ ] risk-engine — Running, /health OK (wave 1)
[ ] auth — Running, /health OK, Redis OK, Auth0 OK (wave 2)
[ ] service-catalog — Running, /health OK, Redis OK (wave 2)
[ ] file-service — Running, /health OK, Firebase Storage OK (wave 2)
[ ] ledger-wallets — Running, /health OK, seeders OK (wave 2)
[ ] notifications — Running, /health OK (wave 3)
[ ] orchestrator — Running, /health OK, tous services internes joignables (wave 4)

Dashboards

[ ] CMMS Dashboard déployé sur Firebase Hosting (admin.paywithnex.com)
[ ] Backoffice déployé sur Firebase Hosting (bo.paywithnex.com)
[ ] Pipeline de déploiement Firebase fonctionnel

Ingress (routes publiques)

[ ] staging.paywithnex.com/configuration/* → service configuration
[ ] staging.paywithnex.com/auth/* → service auth
[ ] staging.paywithnex.com/api/* → service orchestrator

Connectivité

[ ] Tous les services avec PostgreSQL peuvent joindre RDS
[ ] auth et service-catalog peuvent joindre Redis
[ ] L'orchestrator peut joindre les 10 services internes
[ ] Les dashboards peuvent appeler l'API staging

Si un point est rouge → corriger avant de passer au fichier 03.

Prochaine étape : 03_gateway_cdn_securisation.md — Cloudflare, WAF, network policies, hardening.

02 — CI/CD & DÉPLOIEMENT DES SERVICES ​

Objectif ​

PARTIE A — SERVICE PILOTE ​

A.1 DOCKERFILE ​

Objectif ​

Instructions pour l'agent ​

Validation ​

A.2 PIPELINE GITLAB CI ​

Objectif ​

Instructions pour l'agent ​

Validation ​

A.3 MANIFESTS KUBERNETES — SERVICE PILOTE ​

Objectif ​

Instructions pour l'agent ​

Validation ​

A.4 VALIDATION COMPLÈTE DU PILOTE ​

PARTIE B — GÉNÉRALISATION ​

B.1 TEMPLATE DE DÉPLOIEMENT ​

Instructions pour l'agent ​

Particularités par service ​

B.2 WAVE 1 — Services simples (aucune dépendance inter-service) ​

Instructions pour l'agent ​

Validation Wave 1 ​

B.3 WAVE 2 — Services avec dépendances externes ​

Instructions pour l'agent ​

Validation Wave 2 ​

B.4 WAVE 3 — Services avec dépendances inter-services ​

Instructions pour l'agent ​

Validation Wave 3 ​

B.5 WAVE 4 — Orchestrator (dépend de tout) ​

Instructions pour l'agent ​

Validation Wave 4 ​

B.6 DASHBOARDS NUXT.JS — FIREBASE HOSTING ​

Objectif ​

Instructions pour l'agent ​

Validation ​

CHECKLIST GLOBALE — FIN DU FICHIER 02 ​

Pipeline CI/CD ​

Microservices (11/11) ​

Dashboards ​

Ingress (routes publiques) ​

Connectivité ​

02 — CI/CD & DÉPLOIEMENT DES SERVICES

Objectif

PARTIE A — SERVICE PILOTE

A.1 DOCKERFILE

Objectif

Instructions pour l'agent

Validation

A.2 PIPELINE GITLAB CI

Objectif

Instructions pour l'agent

Validation

A.3 MANIFESTS KUBERNETES — SERVICE PILOTE

Objectif

Instructions pour l'agent

Validation

A.4 VALIDATION COMPLÈTE DU PILOTE

PARTIE B — GÉNÉRALISATION

B.1 TEMPLATE DE DÉPLOIEMENT

Instructions pour l'agent

Particularités par service

B.2 WAVE 1 — Services simples (aucune dépendance inter-service)

Instructions pour l'agent

Validation Wave 1

B.3 WAVE 2 — Services avec dépendances externes

Instructions pour l'agent

Validation Wave 2

B.4 WAVE 3 — Services avec dépendances inter-services

Instructions pour l'agent

Validation Wave 3

B.5 WAVE 4 — Orchestrator (dépend de tout)

Instructions pour l'agent

Validation Wave 4

B.6 DASHBOARDS NUXT.JS — FIREBASE HOSTING

Objectif

Instructions pour l'agent

Validation

CHECKLIST GLOBALE — FIN DU FICHIER 02

Pipeline CI/CD

Microservices (11/11)

Dashboards

Ingress (routes publiques)

Connectivité