☁️ GCP (Google Cloud Platform)

Responsabilité partagée (la cause n°1 des incidents)

“Shared Responsibility Matrix” (ultra pratique)

Piège classique : “C’est dans le cloud donc c’est sécurisé.” → Faux. Le cloud est sécurisable, mais la sécurité dépend surtout de vos configurations.

Correspondances rapides (AWS / GCP / Azure)

Astuce : les noms changent, mais les patterns restent les mêmes (réseau + identité + logs + sécurité + coûts).

Vocabulaire clé (celui qui évite 80% des confusions)

Latence / HA (mini rappel)

Même zone     -> meilleure latence
                    Même région   -> bonne latence + HA multi-zone possible
                    Multi-région  -> HA ++ mais design plus exigeant (coûts, cohérence)

“Philosophie” GCP (ce qui le rend différent)

Mental model “GCP = plateformes”

Si ton objectif = aller vite, scaler proprement :
                    - Cloud Run / GKE Autopilot + Cloud SQL + GCS + LB/Armor + Monitoring
                    Si ton objectif = data & analytics :
                    - BigQuery + Pub/Sub + Dataflow + exports logs

Checklist “Jour 1” (anti-bêtises)

“Landing Zone” minimal (pattern entreprise)

Org
                    ├─ Folder: Prod
                    │    ├─ Project: app-prod
                    │    ├─ Project: data-prod
                    │    └─ Project: sec-prod
                    └─ Folder: Dev
                    ├─ Project: app-dev
                    └─ Project: data-dev

                    Guardrails:
                    - Budgets + alerting
                    - Policies (deny public bucket si possible)
                    - Logs export (vers BigQuery si analytics)
                    - SA par workload (pas de clés statiques)

Pièges & anti-patterns (les vrais)

3 règles “anti-galère”

1. Tout ce qui est public doit être volontaire (et documenté).
2. IAM minimal + service accounts dédiés = sécurité + lisibilité.
3. Budgets + logs propres = contrôle coûts + debug rapide.

Si tu veux, on peut ajouter une mini-section “exemples concrets IDEO-Lab” directement ici (web + i18n + NetGuard), mais je l’ai laissée plutôt dans la modal 13.1.

Mapping rapide des services (noms équivalents)

Compute (VM) : modèles de pricing + exemples (ordre de grandeur)

Attention : les VM ne sont pas “1:1” comparables (CPU, perf, burst, réseau, disque, régions). Ici on donne des exemples uniquement, pour illustrer l’écart. Pour du réel : utiliser les calculators officiels.

Exemples VM “general purpose” (USD/heure, on-demand, régions typiques)

Ce qu’il faut comparer “vraiment”

• Perf réelle (CPU génération, turbo, steal/burst), pas que vCPU.
• Disque (IOPS/throughput), réseau (egress), et services annexes (LB, NAT, logs).
• Engagements : Spot/Preemptible, réservations, savings plans, committed use.

Compute : pages pricing officielles

• AWS EC2 On-Demand pricing :contentReference[oaicite:4]{index=4}
• GCP Compute Engine pricing :contentReference[oaicite:5]{index=5}
• Azure VM pricing (Windows page, tables par région/OS) :contentReference[oaicite:6]{index=6}

Kubernetes & containers : EKS vs GKE vs AKS

Règle simple de choix

Tu veux K8s mais moins d’ops :
                    - GKE Autopilot (souvent un très bon départ)
                    - sinon AKS si ton monde est Microsoft
                    - sinon EKS si ton écosystème outillage est déjà AWS

Serverless : Lambda vs Cloud Functions/Run vs Azure Functions

Pourquoi Cloud Run est souvent “ultra simple”

• Tu pousses un container HTTP, et tu gères revisions + traffic split facilement.
• Bon fit microservices / API / workers HTTP.

Stockage objet & réseau : là où les surprises de facture arrivent

Object storage (ordre de grandeur)

Réseau : “egress” = poste n°1 de surprise

Règles universelles (tous clouds)
                    1) Co-localiser compute + data (même région)
                    2) Utiliser CDN pour statique
                    3) Surveiller l’egress (dashboards + alertes)
                    4) Éviter flux inter-région permanents

Exemple GCP : le coût change selon intra-zone / inter-zone / inter-region / internet egress. :contentReference[oaicite:10]{index=10}

Bases de données managées : choix “prod”

Conseil “platform”

Si tu héberges une plateforme (IDEO-Lab)
                    - SQL managé + backups testés + private networking
                    - stateless app (Run/GKE/EKS/AKS) + cache si besoin
                    - limiter connexions DB (pooling) + observabilité

Analytics / DWH : BigQuery vs Athena/Redshift vs Synapse

Diagramme : “coût = données scannées”

RAW logs (10 TB/jour)  --->  Query sans filtre  ---> facture $$$$$$$
                    |
                    +--> Partition (date) + clustering + Parquet
                    |
                    +--> Query filtrée (ex: 1 jour) ---> facture $

Sur les 3 clouds, la discipline “partition + columnar + filtrage” est le meilleur levier coût/perf. :contentReference[oaicite:14]{index=14}

Sécurité & gouvernance : IAM, WAF, keys, posture

Règles universelles “prod”

1) Least privilege (pas "Admin/Editor" partout)
                    2) Service accounts / managed identities dédiées
                    3) WAF + rate-limit devant tout endpoint public
                    4) Secrets hors repo/images
                    5) Audit logs + alerting (5xx, auth, spikes)

Observabilité : logs, métriques, traces

Anti-pattern

Activer "tout le debug" en prod -> logs massifs -> facture + bruit
                    Solution: logs curated + rétention + export uniquement utile

FinOps : réductions & engagements (SUD/CUD vs Savings Plans vs Reservations)

Articles comparatifs (pour le modèle de réductions)

• Comparatif discounts / engagements :contentReference[oaicite:15]{index=15}
• Vue d’ensemble 2026 (AWS/Azure/GCP) :contentReference[oaicite:16]{index=16}

Stratégie simple (qui marche)

1) Démarrer on-demand 2-4 semaines (mesure)
                    2) Identifier la "base stable" (socle)
                    3) Engager (CUD/SP/RI) uniquement sur le socle
                    4) Garder le burst en autoscaling/on-demand
                    => coût prévisible + flexibilité

Matrice de décision (score rapide)

Question clé (qui tranche vite)

Ton "cœur" c’est quoi ?
                    - Identité & enterprise MS ? -> Azure
                    - Data/analytics/ML comme différenciant ? -> GCP
                    - Plateforme généraliste avec 1000 services ? -> AWS

Patterns d’architecture (web / API / data) — équivalents

1) Web/API scalable (front-door + WAF)

AWS  : CloudFront + ALB + WAF -> ECS/EKS/EC2 -> RDS -> S3
                    GCP  : LB global + Armor      -> Run/GKE/CE  -> Cloud SQL -> GCS
                    Azure: Front Door + WAF       -> Apps/AKS/VM -> Azure SQL / PostgreSQL -> Blob

2) Data lake + query serverless

AWS  : S3 (data lake) -> Athena ($5/TB scanned) -> BI
                    GCP  : GCS -> BigQuery (bytes processed; 1 TiB free/mois) -> BI
                    Azure: ADLS/Blob -> Synapse Serverless ($5/TB processed) -> BI
                    Sources query pricing: :contentReference[oaicite:17]{index=17}

3) Event-driven (queue/pubsub)

AWS  : SNS/SQS/EventBridge -> Lambda -> DynamoDB
                    GCP  : Pub/Sub             -> Functions/Run -> Firestore
                    Azure: Event Grid/Service Bus -> Functions -> Cosmos DB

Pièges & anti-patterns (comparatif)

Conclusion “safe”

Le bon cloud = celui qui colle à ton ADN (data vs enterprise vs catalogue),
                    ET où tu sais mettre 4 garde-fous :
                    1) budgets/alertes, 2) WAF+rate-limit, 3) discipline data queries, 4) IAM strict.

Tableau comparatif (orientation décision)

Important : le coût dépend davantage de votre design (logs, egress, sizing, requêtes) que du fournisseur. Sans budgets/alertes, vous piloterez à l’aveugle.

Mapping des services (équivalences utiles)

Astuce : au lieu de “convertir service par service”, convertis plutôt les patterns : “front-door WAF+LB”, “private network”, “workload identity”, “central logs”, “budgets”.

Décision rapide (arbre de choix)

1) Votre entreprise est "Microsoft-first" (AD/M365/Windows/.NET partout) ?
                    -> Azure très souvent le meilleur fit

                    2) Vous voulez le plus grand catalogue + marketplace + options enterprise partout ?
                    -> AWS est souvent le choix "large"

                    3) Vous êtes data-centric (analytics/BI/ETL streaming) + microservices containers ?
                    -> GCP excellent (BigQuery + Pub/Sub/Dataflow + GKE/Run)

                    4) Vous voulez minimiser l'ops pour une API moderne (containers) ?
                    -> Cloud Run (GCP) est un candidat très fort

                    5) Vous faites du multi-région avec besoins réseau et LB global ?
                    -> GCP est très confortable (backbone + LB global)

Règle d’or

• Choisir un cloud “principal” pour les fondations (IAM/réseau/logs/budgets).
• Ensuite, utiliser les services qui apportent le plus de valeur (data, ML, serverless…), sans se disperser.

Patterns d’architecture (comparables)

Front-door : DNS -> LB + TLS + WAF
                            Compute    : (Kubernetes) ou (VM autoscaling) ou (serverless containers)
                            Data       : DB managée + cache + object storage
                            Ops        : logging + monitoring + alerting + CI/CD
                            Security   : IAM minimal + secrets + segmentation réseau

Ingestion  : bus/stream (Pub/Sub/Kinesis/Event Hubs)
                            Processing : ETL batch/stream (Dataflow/Glue/Data Factory)
                            Storage    : data lake (GCS/S3/Blob) + DWH (BigQuery/Redshift/Synapse)
                            BI         : dashboards + exports + governance
                            Security   : data perimeter + IAM + audit

Exemple “IDEO-Lab mindset”

Si priorité = vitesse + simplicité ops:
                    - Cloud Run (API Django) + Cloud SQL + GCS + LB/Armor + Monitoring
                    Si priorité = scale Kubernetes + workloads multiples:
                    - GKE + Ingress (LB) + Cloud SQL (private) + Secret Manager
                    Si priorité = analytics trafic/usage:
                    - Export logs -> BigQuery (requêtes partitionnées) + dashboards

Multi-cloud : quand ça a du sens (et quand non)

Recommandation pragmatique : mono-cloud au début, puis multi-cloud seulement si une contrainte business le justifie clairement.

Pièges & anti-biais (ce qui trompe tout le monde)

Conclusion (ultra simple)

• AWS : maximaliste (catalogue, enterprise, choix infinis)
• Azure : meilleur fit Microsoft & hybride entreprise
• GCP : réseau + containers + data/analytics (et vitesse PaaS)

IAM & héritage (Org → Folder → Project)

Service Accounts : identité “machine” (à structurer)

Pattern solide
                    - 1 service account par workload (api, worker, etl)
                    - rôles uniquement sur les ressources nécessaires (bucket/dataset/secret)
                    - éviter les clés statiques, préférer identité fédérée / Workload Identity

Billing, quotas & APIs : ce qui “vit” au niveau Project

APIs “classiques” selon stack (exemple)

Stack web simple (Run + SQL + GCS)
                    - Cloud Run API
                    - Cloud SQL Admin API
                    - Secret Manager API
                    - Cloud Storage API
                    - Cloud Logging / Monitoring APIs
                    - (Optionnel) Cloud Build API

Le “ça marche pas” le plus fréquent au début : API non activée ou permissions insuffisantes sur le project.

Landing Zone (template) : structure recommandée

Organization: ideolab.com
                    Folder: Shared
                    - Project: ideolab-shared-network   (VPC partagés, DNS, interco)
                    - Project: ideolab-shared-logging   (exports logs, sinks)
                    Folder: Prod
                    - Project: ideolab-web-prod        (GKE/Run/LB)
                    - Project: ideolab-data-prod       (BigQuery/Dataflow)
                    - Project: ideolab-sec-prod        (Armor/SCC/KMS policies)
                    Folder: Dev
                    - Project: ideolab-web-dev
                    - Project: ideolab-data-dev

Pour un “solo dev” (toi), on peut faire plus léger… mais garder la séparation Prod vs Dev reste une excellente habitude.

Nommage & labels : lisibilité + facturation + ops

Convention simple (recommandée)

Format projet : {org}-{domain}-{env}
                    - ideolab-web-prod
                    - ideolab-data-dev
                    - ideolab-sec-prod

Labels (tags) incontournables

Les labels sont la base d’une facturation “intelligente” : sans ça, tu ne sauras jamais ce qui coûte quoi.

Séparation Dev / Stage / Prod : pourquoi c’est non négociable

“Promotion” du code (pipeline mental)

dev -> staging -> prod
                    - mêmes templates IaC (Terraform)
                    - mêmes manifests (K8s/Run), variables différentes
                    - tests + validations avant prod
                    - rollback plan (run revisions / deploy tags / blue-green)

Exemple concret (IDEO-Lab) : découpage intelligent

Deux options “réalistes” pour toi

Option A (simple) : 2 folders (Dev/Prod) + 2 projects (web-dev/web-prod)
                    Option B (clean)  : + data-dev/data-prod + sec-prod (si Armor/exports/BigQuery)

Pièges & anti-patterns (ceux qui font perdre du temps)

Règle finale (ultra simple)

1. Projects = isolation (env, app, data).
2. Folders = gouvernance (prod/dev + politiques).
3. Org = guardrails (security/cost/audit).

Disques : performance, choix, pièges

Règles simples (prod)

• Boot disk séparé des données si tu veux restaurer/patcher sans toucher au data.
• Ne pas confondre “disque” et “backup” : un disque ≠ sauvegarde. Les snapshots sont la base DR.
• Si ta VM “rame” : vérifier IOPS/throughput avant d’augmenter CPU.

Pattern “data disk” propre

VM:
                    - boot disk (OS) : petit + patché
                    - data disk : séparé (postgres, medias, logs utiles)
                    Backup:
                    - snapshots planifiés du data disk
                    - éventuellement exports vers GCS (selon use-case)

Le meilleur gain perf vient souvent d’un bon choix disque + cache applicatif, avant même le CPU.

Images & snapshots : “golden image” + rollback

Pattern “Golden Image” (propre)

1) Créer une VM "builder"
                    2) Durcir + patcher + config baseline (agents monitoring/logging)
                    3) Créer une image "golden-YYYYMMDD"
                    4) Utiliser l'image dans un Instance Template
                    5) Déployer via MIG
                    => prod homogène, rollback simple (revenir à l'image précédente)

Snapshots (bonnes pratiques)

• Planifier (quotidien/heure) selon RPO souhaité.
• Tester la restauration (sinon c’est du “théorique”).
• Rétention : garder 7 jours + 4 semaines + 12 mois (à ajuster).

Le duo “golden image + MIG + snapshots” donne une prod robuste et facilement réversible.

Managed Instance Group (MIG) : autoscaling + self-healing

Le MIG est le moteur de scalabilité et résilience : il recrée une VM en cas de crash, scale selon la charge, et permet des déploiements propres (rolling update).

Architecture type

(Clients)
                    |
                    [HTTP(S) Load Balancer]   (TLS offload, WAF possible)
                    |
                    [Backend Service] -> [MIG]
                    -> instances identiques (template)
                    -> health checks

Étapes (le vrai workflow)

1. Créer une Image (optionnel mais recommandé) + config baseline.
2. Créer un Instance Template (machine type, disks, SA, metadata, startup script).
3. Créer un MIG (min/desired/max) + autohealing (health check).
4. Configurer autoscaling (CPU, LB utilization, métriques custom).
5. Brancher au Load Balancer (1.3) + règles firewall ciblées.

Autoscaling : règles simples

• Scale-out si CPU > 60–70% durable (ou RPS/latence via métriques custom).
• Scale-in plus lent (éviter oscillations).
• Prévoir un min stable en prod (ne pas descendre trop bas si warmup long).

Rolling update (déploiement propre)

Stratégie:
                    - Nouveau template (v2) -> rolling update du MIG
                    - Paramètres: max surge / max unavailable
                    - Validation health checks + logs
                    - Rollback: revenir au template v1

Sécurité : SSH, bastion, IAP, service accounts

VMs privées (pas d'IP publique)
                            - Private Google Access: ON
                            - Cloud NAT: ON (si sorties internet nécessaires)
                            Accès admin:
                            - Bastion OU IAP
                            Identité:
                            - SA "app-prod" (droits minimaux)
                            Secrets:
                            - Secret Manager (pas de secrets en dur)

Coûts & optimisation (Compute Engine)

Pièges coût (très fréquents)

• Disques persistants “oubliés” après suppression VM.
• Snapshots sans politique de rétention.
• Logs trop verbeux (surtout en debug) + rétention longue.

Le trio gagnant : budgets + tags/labels + dashboards.

Runbook prod (checklist courte mais carrée)

Template mental “prod solide”

LB -> MIG (VMs privées) -> App
                    \-> Cloud Armor (WAF/rate-limit) (option)
                    Data:
                    - Cloud SQL (si DB managée) ou disques + snapshots
                    Ops:
                    - Monitoring + Logging + alerting
                    Security:
                    - IAM minimal + SA dédiés + secrets manager

Subnets & IP plan : la base d’un réseau propre

Règles simples (qui marchent)

• Prévoir une marge (tu vas ajouter des services plus tard).
• Séparer public vs privé (même si tu évites le public en prod).
• Séparer apps vs data (ex: DB, caches, brokers) pour limiter le blast radius.

Exemple d’IP plan (lisible)

VPC: ideolab-vpc (10.20.0.0/16)

                    europe-westX:
                    - subnet-apps-euw : 10.20.10.0/24
                    - subnet-data-euw : 10.20.20.0/24

                    us-centralX:
                    - subnet-apps-usc : 10.20.30.0/24
                    - subnet-data-usc : 10.20.40.0/24

Même si tu ne mets pas tout de suite un “subnet data”, le prévoir te permet d’éviter des migrations réseau pénibles plus tard.

Firewall rules (stateful) : la sécurité réseau “de base”

Les règles firewall GCP sont stateful : si tu autorises une connexion sortante, le retour est permis. Le gros avantage GCP : cibler les règles par tags OU par service accounts (très propre).

Bonnes pratiques

• Deny by default (mental model) : n’ouvrir que le strict nécessaire.
• Règles par rôle : web, ssh-admin, db, monitoring.
• Éviter SSH public : préférer IAP ou bastion.

Exemples de règles (modèle)

Règles typiques
                    - allow-healthchecks-to-web : INGRESS tcp:80,443 depuis ranges LB/healthcheck (ciblé)
                    - allow-iap-ssh-to-admin    : INGRESS tcp:22 depuis IAP (ciblé)
                    - allow-app-to-db           : INGRESS tcp:5432 depuis subnet-apps -> subnet-data
                    - deny-all-ssh-public       : (principe) ne jamais ouvrir 22 au monde

Erreur classique

Ouvrir “0.0.0.0/0” sur SSH/DB “pour tester vite” puis oublier. → C’est souvent le début d’un incident.

Routes & egress : contrôler “où ça sort”

Egress : 2 patterns

Pattern A (simple dev):
                    - VM avec IP publique
                    => rapide mais moins safe

                    Pattern B (prod recommandé):
                    - VM privée (sans IP publique)
                    - Private Google Access = ON
                    - Cloud NAT = ON (si sorties internet nécessaires)
                    => egress maîtrisé, surface d’attaque réduite

Le pattern B est celui que tu veux pour des serveurs exposés (Idéo-Lab / API), surtout si tu subis du flood/bots.

Private Google Access : accès aux APIs Google sans IP publique

Private Google Access permet à des VMs/instances sans IP publique d’appeler des APIs Google (Storage, Artifact Registry, etc.) via le réseau Google, sans exposer la machine sur Internet.

Quand l’activer ?

• Workloads prod en subnet privé.
• VMs qui doivent accéder à GCS, logs, images, registries…
• Quand tu veux “zéro IP publique” mais garder la fonctionnalité.

Combo gagnant

Subnet privé:
                    - Private Google Access = ON
                    - Cloud NAT = ON (si apt/yum, pip, dépôts externes requis)
                    Résultat:
                    - machine non exposée
                    - accès aux APIs Google OK
                    - sorties internet contrôlées

Ça te permet une infra bien plus “enterprise” sans la complexité d’un proxy maison.

NAT / VPN / Interconnect : hybrid & connectivité

Choix rapide

Besoin ponctuel / démarrage hybride -> Cloud VPN
                    Besoin stable / gros volumes / latence maîtrisée -> Interconnect
                    Besoin uniquement egress internet sans IP publique -> Cloud NAT

Patterns prod (web/API) : “front-door” + subnets privés

Pattern recommandé (anti-bots / anti-flood)

(Internet)
                    |
                    [Global HTTP(S) Load Balancer]
                    |-- TLS offload
                    |-- (option) Cloud Armor : WAF + rate-limit + geo/ip rules
                    |
                    [Backends privés]
                    - MIG (Compute Engine) en subnet privé (pas d'IP publique)
                    - ou GKE (nodes privés) / Cloud Run (via NEG)
                    Egress:
                    - Cloud NAT (si besoin)
                    Ops:
                    - Logging/Monitoring + alerting

Segmentation minimale (utile)

• Subnet apps (web/API) : autoriser uniquement LB health checks + trafic interne nécessaire.
• Subnet data (DB/cache) : accessible uniquement depuis apps.
• Admin : accès via IAP/bastion, jamais SSH “public”.

Ce pattern colle parfaitement à ton contexte (sites exposés, bots, rate-limit) : tu déplaces la “bataille” au LB/WAF, et tu gardes les workloads privés.

Pièges & anti-patterns (réseau)

3 règles “golden”

1. Workloads privés (pas d’IP publique) dès que possible.
2. Entrée via LB (et WAF/rate-limit si besoin), pas en direct sur les VMs.
3. Firewall ciblé (tags/SA) + budgets/logs pour éviter surprise et incidents.

Architecture d’un HTTP(S) LB (mental model)

(Clients / Internet)
                    |
                    [Global HTTP(S) Load Balancer]
                    |-- TLS offload (certificat)
                    |-- URL maps (host/path routing)
                    |-- (option) Cloud Armor (WAF / rate-limit)
                    |-- (option) Cloud CDN (cache global)
                    |
                    [Backend Service]
                    |
                    [Backends] -> MIG (Compute Engine) / GKE Ingress / Cloud Run (via NEG)

Ce que ça t’apporte

• Un point d’entrée unique (TLS, sécurité, routage).
• Haute dispo + équilibre de charge + health checks.
• Évolutivité : tu scales derrière sans changer le DNS.
• Observabilité : métriques et logs sur le point névralgique.

Le LB est aussi un “pare-chocs” : il absorbe une partie des attaques/bots et stabilise ta prod (surtout combiné à Armor + rate-limit).

Backends : MIG / GKE / Cloud Run (via NEG)

Choix “pragmatique”

Si tu veux aller vite (API moderne) -> Cloud Run + LB
                    Si tu veux Kubernetes (multi-services) -> GKE + Ingress (et LB)
                    Si tu veux contrôle OS/legacy -> MIG + LB

Health checks : la clé du failover

Sans health checks, pas de failover fiable. Le LB a besoin d’un signal clair : “cet endpoint est OK / KO”. Un bon health check doit valider un minimum de logique applicative, sans être trop lourd.

Recommandation (HTTP)

/healthz  -> retourne 200 OK
                    - rapide (pas de DB lourde)
                    - vérifie process + routing basique
                    - idéalement vérifie que l'app est prête (readiness)

Self-healing (avec MIG)

• Le MIG peut recréer une VM si elle échoue aux checks (autohealing).
• Le LB retire un backend “unhealthy” du trafic.
• Résultat : résilience automatique sans intervention humaine (dans une certaine mesure).

Pièges health checks

• Endpoint trop lourd (tape la DB) → faux positifs sous charge.
• Endpoint trop faible (toujours OK) → LB envoie du trafic vers une app cassée.
• Firewall oublié : health checks bloqués → tout est “unhealthy”.

TLS / certificats : managé vs importé

TLS offload : pourquoi c’est bien

• Chiffrement géré au bord (LB) → backends simplifiés.
• Meilleure perf + gestion centralisée des certs.
• Tu peux garder backends privés, sans exposition directe.

En prod : LB termine TLS, puis trafic interne vers backends (possiblement re-chiffré selon design/contraintes).

Cloud CDN : cache global (statique + accélération)

Cloud CDN s’active sur le LB et met en cache des réponses (souvent statiques) au plus proche des utilisateurs. Idéal pour : images, CSS/JS, assets, downloads, contenus publics.

Quand activer ?

• Beaucoup de trafic sur /static ou assets lourds.
• Public international (latence).
• Tu veux réduire la charge sur backends (CPU, bande passante).

Pattern recommandé

LB + CDN
                    - /static -> bucket GCS (cacheable)
                    - /media  -> (selon besoin) GCS + signed URLs
                    - /api    -> backends (MIG/GKE/Run) non cache (ou cache contrôlé)

Cache : règles simples

• Cache agressif sur versionnés (ex: app.abc123.js) → TTL long.
• Cache prudent sur contenu “mutable” → TTL court + invalidations.
• Ne jamais “accidentellement” cacher des réponses sensibles (auth).

Patterns prod (contexte IDEO-Lab : bots, rate-limit, stabilité)

Pattern anti-flood (recommandé)

(Internet)
                    |
                    [HTTP(S) LB global]
                    |-- TLS offload
                    |-- Cloud Armor (WAF + rate-limit + IP rules)
                    |-- Cloud CDN (assets)
                    |
                    Backends privés:
                    - MIG (VMs privées)  OU  GKE nodes privés  OU  Cloud Run
                    Egress:
                    - Cloud NAT (si besoin)
                    Ops:
                    - Logging/Monitoring + alertes (4xx/5xx, latence, saturation)

Découpage URL utile

• /static : CDN + cache long (si versionné).
• /api : no-cache + Armor rate-limit (anti abuse).
• /admin : restrictions fortes (IP allowlist ou IAP, selon setup).
• /healthz : utilisé par health checks (simple, rapide).

Tu retrouves ton approche Nginx/rate-limit, mais déplacée au niveau “front-door” cloud, avant même d’atteindre tes VMs.

Pièges & anti-patterns (LB)

Checklist LB (prod)

1. LB HTTP(S) + cert managé (TLS).
2. Backends privés (MIG/GKE/Run) + health checks.
3. Firewall autorise health checks + trafic strict.
4. CDN sur /static (si pertinent) + cache safe.
5. Armor + rate-limit sur endpoints sensibles (/api, /login, /admin).
6. Monitoring : latence p95, 4xx/5xx, saturation.

Types de rôles : primitive vs predefined vs custom

Choix rapide

• Commencer avec des predefined roles (le plus safe).
• Passer à custom roles quand tu veux standardiser (et que tu sais exactement ce que tu fais).
• Limiter les rôles primitive à du dev/POC, jamais “Editor partout” en prod.

Exemples de rôles “courants” (pragmatiques)

Exemples (idées)
                    - Cloud Run invoker : appeler un service (sans l'admin)
                    - Storage objectViewer : lire des objets d'un bucket
                    - Secret Manager secretAccessor : lire un secret (pas lister tout)
                    - BigQuery jobUser + accès dataset ciblé : lancer des requêtes + lire des tables autorisées

Service Accounts (SA) : identité “machine”

Un Service Account est une identité utilisée par un workload (VM, GKE, Cloud Run, Dataflow…). C’est LA brique pour éviter les secrets en dur et rendre l’accès “traçable”.

Principes solides

• 1 SA par workload (api, worker, etl, cron…)
• Droits au niveau resource si possible (bucket/dataset/secret), pas “sur tout le project”.
• Nommer clairement : ideolab-api-prod, ideolab-worker-prod, etc.
• Éviter les “shared SA” à tout faire (ça finit toujours trop large).

Pattern concret (API Django → GCS + Secrets)

Créer SA : ideolab-api-prod

                    Accorder UNIQUEMENT:
                    - roles/secretmanager.secretAccessor sur les secrets nécessaires
                    - roles/storage.objectViewer (ou objectAdmin) sur le bucket précis
                    - (option) roles/logging.logWriter si besoin (souvent implicite via agents)

                    Attacher le SA au runtime:
                    - VM (Compute Engine) / MIG
                    - ou Cloud Run service
                    - ou GKE (via Workload Identity)

                    => aucune clé “hardcodée”, droits minimaux, audit propre

Bonus : dans certains designs, tu peux aussi cibler les firewall rules par service account (durcissement réseau très propre).

Niveaux d’application : Org → Folder → Project → Resource

L’IAM s’hérite “vers le bas”. Plus tu assignes haut, plus tu crées un accès large. Donc : mettre haut uniquement ce qui doit être global.

Règle simple

Accès humain:
                    - plutôt sur Folder/Project (via groupes)

                    Accès machine (workloads):
                    - plutôt sur Resource (bucket/dataset/secret) via SA

Patterns prod (web/API) — “ce qui marche dans la vraie vie”

Pattern équipes

Groupes (exemples)
                    - platform-admins : droits org (très restreints)
                    - prod-ops        : gérer LB/Run/GKE en prod (pas Owner)
                    - dev-team        : dev project (plus permissif)
                    - auditors        : lecture logs/audit

Pattern SA (workloads)

Principe “blast radius”

• Si un SA est compromis, il ne doit permettre d’accéder qu’à un petit périmètre.
• Donc : SA dédiés + droits ciblés = incident contenu.

Clés, identités et Workload Identity (objectif : 0 clés statiques)

Les clés de service account (JSON) sont le “vieux monde” : faciles à fuiter, difficiles à tracer/rotater. Le but en prod : ne pas en avoir.

Recommandation

• Pour GKE : préférer Workload Identity (Pods → SA GCP) plutôt que key files.
• Pour Cloud Run : attacher un SA au service (pas de clé).
• Pour VM : utiliser le SA attaché à la VM + scopes/permissions gérés par IAM.

Si tu dois utiliser une clé (exception)

• Stocker dans Secret Manager (pas dans le repo, pas sur disque “en clair”).
• Rotation planifiée + audit de l’usage.
• Limiter le SA à un périmètre minimal.

Une clé SA exposée = souvent compromission. Traite-la comme un mot de passe root.

Audit & ops : garder IAM sain dans le temps

Checklists (mensuelles)

1. Supprimer les accès non utilisés (users/SA).
2. Réduire progressivement Editor/Owner → roles prédéfinis.
3. Revoir les SAs “partagés” et découper si trop larges.
4. Vérifier les projets “orphelins” (dev) et leurs IAM.
5. Contrôler les accès aux données (buckets/datasets/secrets).

Principe de gouvernance

IAM doit être:
                    - lisible (groupes + nommage)
                    - minimal (least privilege)
                    - traçable (audit / logs)
                    - réversible (accès temporaire pour ops)

Le vrai risque n’est pas “une mauvaise règle” : c’est l’accumulation au fil des mois sans revue.

Pièges & anti-patterns IAM (très fréquents)

Mini-check “prod ready”

1. Pas de Owner/Editor large en prod.
2. SA dédiés + droits au niveau resource.
3. Pas de clés statiques (ou rotation/secret manager en exception).
4. Groupes pour humains, labels/naming cohérents.

Localisation : région vs multi-région (et pourquoi ça compte)

Static mondial -> souvent multi-région + CDN
                            Backups -> région (ou multi si DR strict)
                            Media -> région proche des workloads + CDN si public

Classes de stockage : Standard → (Nearline/Coldline/Archive)

Pattern gagnant

Backups:
                    - J0..J30   : Standard (restauration rapide)
                    - J30..J180 : Nearline/Coldline
                    - > 6 mois  : Archive (si besoin conformité)

Le bon design : tu restes en Standard pour ce qui sert “souvent”, puis tu automatises les transitions via lifecycle.

Accès & sécurité : IAM (recommandé) vs ACL (à éviter)

Rôles IAM utiles (idées)

Bucket privé (lecture seule)
                    - roles/storage.objectViewer sur bucket X

                    Upload/gestion objets (application)
                    - roles/storage.objectAdmin sur bucket X (ou plus fin selon besoin)

                    Administration bucket (rare)
                    - roles/storage.admin (à éviter pour l'app)

Règles d’or

• Bucket privé par défaut (public = exception volontaire et documentée).
• 1 service account par workload (api, worker, etl) + droits ciblés sur le bucket.
• Limiter les opérations de listing si non nécessaires (surface + coûts).

Versioning & retention : anti-effacement / anti-ransom

media/ : versioning selon besoin
                            backups/ : versioning OUI (quasi toujours)
                            static/ : inutile si assets versionnés (hash) + CDN

Pattern “safe backups”

Bucket ideolab-backups (private)
                    - Versioning: ON
                    - Lifecycle: transition vers cold storage
                    - (Option) Retention: 30j (anti-suppression)
                    - Accès: uniquement SA backup + auditors

Lifecycle rules : automatiser le ménage + réduire les coûts

Les règles de cycle de vie peuvent : supprimer, archiver (changer de classe), ou agir selon l’âge, la version, le préfixe, etc.

Exemples de règles (idéales)

Ex: backups/
                    - Après 30 jours -> Nearline
                    - Après 180 jours -> Coldline
                    - Après 365 jours -> Archive (ou delete si politique interne)

                    Ex: tmp-uploads/
                    - Supprimer après 7 jours

                    Ex: versions non courantes
                    - Supprimer versions anciennes après 30 jours (si versioning ON)

Checklist lifecycle

• Définir clairement : RPO/RTO et la durée de conservation.
• Ne pas oublier les versions non courantes (sinon tu stockes “en double” indéfiniment).
• Tester la restauration avant de “durcir” (retention/locks).

Signed URLs : bucket privé, accès temporaire (download + upload)

Les Signed URLs permettent de donner un accès temporaire à un objet sans rendre le bucket public. C’est le pattern moderne pour servir des fichiers aux utilisateurs.

Cas d’usage

• Download d’un fichier privé (factures, exports, docs).
• Upload direct browser vers GCS (évite de saturer ton serveur).
• Accès “one-shot” à des backups (admin ops) sans ouvrir IAM large.

Pattern “download Signed URL”

1) User -> demande /api/files/123/download
                    2) Backend (Django) vérifie droits applicatifs
                    3) Backend génère Signed URL (TTL 5-15 min)
                    4) Browser télécharge directement depuis GCS

Pattern “upload direct” (très puissant)

1) User -> demande /api/uploads/init
                    2) Backend génère une Signed URL (PUT) ou POST policy
                    3) Browser upload directement vers GCS
                    4) Backend enregistre la référence (object path) en DB
                    5) Option : job async (scan/resize/validation)

Point sécurité : TTL court + validation côté app + chemins contrôlés (pas de “../”, pas d’overwrite non voulu).

Static hosting + CDN : servir vite et encaisser

Option A (simple) : bucket “website”

• Possible pour du statique pur, mais attention aux exigences TLS/DNS.
• En prod, on préfère souvent : LB + CDN devant bucket (plus contrôlable).

Option B (prod recommandé) : LB + CDN + bucket privé

LB HTTP(S) global
                    - /static -> backend bucket GCS + Cloud CDN (cache long)
                    - /api    -> backends (MIG/GKE/Run) (pas cache)
                    Sécurité:
                    - bucket privé (IAM)
                    - pas d’objets publics
                    Perf:
                    - CDN absorbe la majorité des hits

Headers cache (règle d’or)

Assets versionnés (hash dans le nom) :
                    - Cache-Control: public, max-age=31536000, immutable

                    Assets non versionnés :
                    - max-age court + mécanisme d'invalidation

Pour ton site (beaucoup de pages, bots possibles), CDN sur static = moins de charge CPU + meilleure latence.

Coûts : ce qui fait vraiment “gonfler” la facture

Optimisations très rentables

1. Activer CDN sur /static public.
2. Lifecycles sur backups + versions non courantes.
3. Éviter les LIST : stocker l’index dans ta DB.
4. Nettoyer disques/exports “orphelins” (ops).

Patterns IDEO-Lab (concrets, réutilisables)

1) Static Django (collectstatic) + CDN

Bucket: ideolab-static (private)
                    - objets versionnés (ManifestStaticFilesStorage)
                    - served via LB + CDN
                    - cache long (immutable)
                    Bénéfice: CPU backend réduit + latence mondiale

2) Media utilisateur (uploads) via Signed URL

Bucket: ideolab-media (private)
                    Flow:
                    - Django génère Signed URL (upload)
                    - browser upload direct
                    - Django valide + enregistre path
                    Option:
                    - worker async (scan/resize) + tags/metadatas

3) Backups PostgreSQL + lifecycle

Bucket: ideolab-backups (private)
                    - versioning ON
                    - lifecycle: 30j -> nearline, 180j -> coldline, 365j -> archive
                    - accès: SA backup + auditors
                    - (option) retention 30j (anti-suppression)

4) Exports logs / analytics

Option A: Export logs -> BigQuery (requêtes direct)
                    Option B: Export logs -> GCS (data lake) -> Dataflow/BigQuery

Pièges & anti-patterns (GCS)

Checklist “prod ready”

1. Bucket privé + IAM (pas ACL).
2. SA dédié avec droits minimaux (objectViewer/objectAdmin sur bucket ciblé).
3. Versioning/retention selon criticité.
4. Lifecycle (transition + purge versions).
5. Signed URLs pour accès utilisateurs.
6. CDN pour static public.

HA (High Availability) : multi-zone + failover

En HA, tu as un primary + un standby (généralement dans une autre zone). En cas de panne, Cloud SQL bascule sur le standby (failover).

Points à retenir

• Failover ≠ “zéro coupure” : tu auras une courte période d’indisponibilité.
• Ton application doit gérer : retries, timeouts, reconnexion pool.
• Mettre en place des alertes : failover events, erreurs de connexions, saturation.

Design app “failover-friendly” (pattern)

Backend (Django / API)
                    - Connection pooling raisonnable
                    - timeouts courts + retries contrôlés
                    - transactions courtes (éviter locks longs)
                    - idempotence sur opérations critiques si possible

Le plus gros problème pendant un failover : pools de connexions “cassés” qui ne se reconstruisent pas correctement.

Backups & PITR (Point-In-Time Recovery)

Règles simples de rétention

Rétention type (à adapter)
                    - Quotidien : 7 à 14 jours
                    - Hebdo    : 4 à 8 semaines
                    - Mensuel  : 6 à 12 mois (si besoin)
                    + Tests restore réguliers (trimestriel minimum)

Test restore (obligatoire)

• Restaurer dans un projet/stage séparé.
• Lancer un set de requêtes de validation (schéma, data, indexes, perf basique).
• Documenter RTO réel (temps de restauration + remise en service).

Read replicas : scaler la lecture (et isoler du reporting)

Les read replicas répliquent le primary (asynchrone en général) et servent la lecture. Parfait pour : endpoints read-heavy, exports, reporting, dashboards.

Pattern routing (simple)

Writes -> primary
                    Reads  -> replica(s) (si acceptable)
                    Exceptions:
                    - lectures "juste après write" -> primary (éviter incohérence)

Réseau : Private IP (best practice) + PSA

En prod, on évite l’IP publique sur la DB. Le bon design : Cloud SQL en Private IP via VPC (souvent en utilisant Private Service Access), et tes workloads (MIG/GKE/Run) dans des subnets privés.

Patterns de connexion

Checklist réseau DB

• DB sans IP publique (si possible).
• Autoriser uniquement les subnets “apps” (ou SA ciblés) → port DB.
• Éviter d’exposer pgAdmin/outils admin au public (IAP/bastion).

Sécurité : comptes DB, IAM, secrets

3 couches à gérer

1. Réseau : private IP + firewall strict (socle).
2. Auth DB : users DB séparés (app, admin, readonly).
3. Secrets : stockés dans Secret Manager (rotation si possible).

Pattern “comptes DB” propre

Users DB:
                    - app_user    : droits minimaux (schema + CRUD nécessaires)
                    - ro_user     : read-only (reporting / exports)
                    - admin_user  : ops (migrations) -> accès très contrôlé

                    Secrets:
                    - secret/db/app_user_password
                    - secret/db/ro_user_password

Règles d’or

• Pas de mot de passe DB dans le repo.
• Pas de “superuser” pour l’app.
• Logs d’audit / alertes sur accès anormaux (si activés).

Performance : ce qui compte vraiment (PostgreSQL/MySQL)

Checklist perf (pragmatique)

• Index : sur colonnes filtrées / join / order by (sinon CPU brûle).
• Requêtes lentes : analyser et corriger (profiling).
• Connexions : limiter et pooler (Django + pgbouncer selon contexte).
• IO : surveiller disque/latence (souvent le vrai goulot).
• Autovacuum / bloat (Postgres) : surveiller et ajuster si besoin.

Pooling : point critique Cloud Run/GKE

Problème classique:
                    - scaling horizontal -> trop de connexions -> DB saturée

                    Solutions:
                    - limiter la concurrence par instance (Run)
                    - utiliser pooling (pgbouncer) si nécessaire
                    - séparer read replicas pour reporting
                    - monitorer "connections", "cpu", "disk latency"

Pour une app Django très concurrente, le “max_connections” est souvent le point de rupture avant même le CPU.

Migrations & cutover : passer en prod sans douleur

3 stratégies

Plan “cutover” (pratique)

1. Créer Cloud SQL (staging) + importer un snapshot/dump.
2. Tests perf + tests applicatifs (requêtes, migrations, index).
3. Mettre en place réplication ou plan de freeze writes.
4. Fenêtre de cutover : stop writes → sync final → switch DSN → smoke tests.
5. Rollback plan : revenir à l’ancienne DB si smoke tests KO.

Le rollback doit être “exécutable” (script/document) — pas juste une idée.

Runbook prod (checklist “prod ready”)

Observabilité minimale

Surveiller:
                    - cpu, memory
                    - disk latency / iops
                    - connections + errors
                    - replication lag (si replicas)
                    - slow queries (si activé)

Pièges & anti-patterns (Cloud SQL)

Conclusion (ultra pragmatique)

• Prod = Private IP + HA + backups/PITR + monitoring.
• Charge lecture = read replicas.
• Risque n°1 = connexions et requêtes lentes (pas “le cloud”).

Modèle de coût : “tu payes surtout ce que tu scannes”

Règle d’or “anti-facture”

Toujours:
                    - filtrer sur la partition (WHERE sur la date)
                    - sélectionner uniquement les colonnes nécessaires
                    - éviter SELECT * sur tables larges
                    => réduit coût + accélère p95

Le meilleur “tuning” BigQuery, c’est un bon design de tables (partition/cluster) + discipline SQL.

Schéma & types : faire simple et stable

Conseils pratiques

• Choisir un schéma évolutif : colonnes additionnelles OK, mais éviter de casser les noms/types.
• Pour événements/logs : un champ event_ts (TIMESTAMP) + event_date (DATE) est très utile.
• Utiliser des STRUCT/RECORD pour grouper (ex: user, http, geo).
• Ne pas “tout mettre en JSON string” : tu perds l’optimisation SQL.

Exemple de table d’événements (clean)

analytics.events
                    - event_ts      TIMESTAMP
                    - event_date    DATE
                    - event_type    STRING
                    - user_id       STRING
                    - http          STRUCT
                    - geo           STRUCT
                    - meta          STRUCT
                    - payload       STRING (option: JSON brut si besoin)

Pattern classique : colonnes “top-level” pour les filtres fréquents, STRUCT pour le reste.

Partitionnement : éviter de scanner “tout”

Le partitionnement découpe la table en “tranches” (souvent par date) pour que BigQuery ne lise que ce qui est nécessaire. C’est le meilleur levier perf + coût.

Types fréquents

• Partition par colonne DATE/TIMESTAMP (recommandé : event_date / event_ts).
• Partition par ingestion time (pratique mais moins sémantique).

Bon pattern (logs/events)

Table partitionnée sur event_date
                    - WHERE event_date BETWEEN '2026-02-01' AND '2026-02-07'
                    => scan limité aux partitions utiles

Règles simples

• Toutes les requêtes “standard” doivent filtrer la partition (sinon “full scan”).
• Mettre une politique de rétention : supprimer partitions anciennes (ou archiver ailleurs).
• Si tu fais du “temps réel”, partition par jour + clustering donne déjà de très bons résultats.

Clustering : accélérer les filtres fréquents

Le clustering organise les données dans la partition selon 1..N colonnes (ex: user_id, event_type), ce qui améliore le “pruning” sur ces colonnes.

Quand ça aide

• Filtres fréquents sur les mêmes colonnes (user_id, ip, event_type, status, path).
• Jointures répétées sur une clé.

Bon pattern

analytics.events
                    - Partition: event_date
                    - Cluster: user_id, event_type, http.status
                    => queries plus rapides + moins de bytes scannés

Erreurs classiques

• Cluster sur une colonne “unique” (peu d’intérêt).
• Cluster sur 10 colonnes (inutile) : rester sur les 2-4 plus fréquentes.
• Oublier que le partitionnement est souvent plus important que le clustering.

Performance SQL : discipline qui fait gagner (vraiment)

Top règles

1. Ne jamais faire SELECT * sur table large : choisir les colonnes.
2. Filtrer la partition systématiquement.
3. Préférer approx (si acceptable) pour certaines métriques volumineuses.
4. Éviter les JOIN inutiles : pré-agréger si possible.
5. Limiter les “explosions” (ex: UNNEST massif) sans filtre.

Exemples (bons réflexes)

OK (filtre partition + colonnes)
                    SELECT event_date, event_type, COUNT(*) AS n
                    FROM analytics.events
                    WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
                    GROUP BY event_date, event_type;

                    KO (full scan + SELECT *)
                    SELECT * FROM analytics.events;

Dans 90% des cas, le “tuning” = empêcher le full scan.

Ingestion : batch vs streaming (choisir intelligemment)

Pipeline type (logs web)

Option A (simple):
                    - Export logs -> GCS (par jour) -> Load BigQuery

                    Option B (temps réel):
                    - Pub/Sub -> Dataflow -> BigQuery (streaming)

Pour beaucoup de cas “ops/analytics”, un batch journalier suffit et coûte moins cher.

Exports & partage : GCS, BI, datasets

Exports

• Vers GCS : exports de tables ou résultats de requêtes (archivage, interchange).
• Vers BI : dashboards, data studio/Looker (selon stack).
• Snapshots : conserver un état “curated” avant transformation.

Bon pattern

Niveaux data:
                    - raw      : ingestion brute (partitionnée)
                    - curated  : nettoyée/normalisée (partition+cluster)
                    - marts    : tables métiers (KPI) -> BI
                    => exports BI depuis "marts", pas depuis "raw"

Si tu exposes les users/analystes directement au “raw”, tu perds le contrôle du coût (full scans à répétition).

Gouvernance & sécurité : IAM, séparation, guardrails

Bonnes pratiques

• Mettre BigQuery dans un project data dédié (ex: ideolab-data-prod).
• IAM par dataset : readers, writers, jobUsers séparés.
• Éviter “Editor” sur le project data.
• Budgets + alertes : le data peut exploser vite si mal utilisé.

Pattern groupes (exemple)

Groups:
                    - data-admins    : gestion datasets (restreint)
                    - data-engineers : écriture raw/curated
                    - analysts       : lecture marts + lancement requêtes
                    - auditors       : lecture logs/audit

Guardrail très utile : limiter qui peut lancer des queries sur le “raw” (sinon full scans).

Patterns IDEO-Lab : analytics trafic + anti-bots (très concret)

1) Table d’événements web (hits/logs)

analytics.web_hits
                    - Partition: hit_date
                    - Cluster: ip, path, status, ua_hash
                    But:
                    - détecter bursts, ranges IP agressifs
                    - mesurer latence, 4xx/5xx
                    - suivre top endpoints

2) KPI “ops” (marts)

marts.kpi_daily
                    - date, requests, unique_ips, errors_5xx, p95_latency
                    => dashboards rapides (tables petites, query cheap)

3) Exports

Exports vers GCS:
                    - rapport hebdo (CSV/JSON)
                    - snapshots mensuels (archivage / compliance)

Ton cas “NetGuard / flood” est parfait pour BigQuery : tu peux faire des group by sur IP ranges / ASN / pays et sortir des règles.

Pièges & anti-patterns (BigQuery)

Checklist “prod ready”

1. Project data séparé + IAM par dataset.
2. Tables “events/logs” partitionnées (DATE) + clustering (2–4 colonnes utiles).
3. Curated + marts pour BI (éviter raw direct).
4. Budgets + alertes + discipline SQL (pas de SELECT *).
5. Exports GCS planifiés uniquement sur tables petites/curated.

Autopilot : Kubernetes “PaaS” (le plus simple)

Autopilot enlève une grosse partie de l’ops : Google gère beaucoup plus (nodes, sizing, contraintes de sécurité), et tu raisonnes surtout en pods (resources). C’est souvent le meilleur choix pour démarrer vite et garder un cluster “propre”.

Bonnes pratiques Autopilot

• Définir requests/limits réalistes (sinon coût/perf partent n’importe où).
• Utiliser readiness/liveness probes (rollouts fiables).
• Éviter les manifests “exotiques” : rester dans le chemin standard.

Pour une app Django/API “classique”, Autopilot est souvent le meilleur ratio simplicité/robustesse.

Standard : contrôle total (et responsabilité totale)

Standard te donne la main sur node pools, types de machines, autoscaling nodes, GPU, spot/preemptible, taints/tolerations, etc. C’est plus flexible, mais aussi plus “ops heavy”.

Checklist Standard (à faire propre)

• Node pools par rôle : web / workers / ops.
• Activer node autoscaling (sinon HPA scale pods mais plus de place).
• Stratégie upgrades : canary, maintenance windows, rollback.

Erreur classique : HPA fonctionne mais le cluster n’a pas de nodes en plus → pods Pending → prod down.

Réseau & Ingress : l’entrée HTTP(S) “propre”

Deux patterns d’exposition

Ingress “prod” (mental model)

(Internet)
                    |
                    [HTTP(S) Load Balancer global]
                    |-- TLS / cert managé
                    |-- (option) Cloud Armor (WAF/rate-limit)
                    |
                    [GKE Ingress] -> Services -> Pods

Bonnes pratiques réseau

• Cluster “private” si possible (nodes sans IP publique).
• Limiter l’entrée à l’Ingress (pas d’accès direct aux nodes).
• Pour sortir sur Internet depuis workloads privés : Cloud NAT côté VPC.

Autoscaling : HPA + (node autoscaler)

HPA (pods)

• Scale le nombre de pods selon CPU/mémoire ou métriques custom.
• Indispensable : définir requests CPU (sinon HPA n’a pas de base fiable).
• Ajouter “stabilization” pour éviter oscillations.

Node autoscaler (nodes) — Standard

• Ajoute/retire des nodes selon pods Pending.
• Doit être dimensionné : max nodes, pools séparés, quotas.

Pattern complet

HPA:
                    - minReplicas: 2
                    - maxReplicas: 20
                    - targetCPUUtilization: 60%

                    Standard:
                    - node autoscaling ON (min/max nodes)
                    - pools séparés web/worker (option)

Pour un trafic bot/flood : tu veux scaler, mais aussi limiter (Armor/rate-limit) sinon tu “scales pour payer”.

Déploiement Django/API : pipeline clean

Étapes (pattern éprouvé)

1) Build image Docker -> Artifact Registry
                    2) Apply manifests:
                    - Deployment (web)
                    - Service (ClusterIP)
                    - Ingress (HTTP(S) LB + TLS)
                    3) Probes:
                    - readiness: /healthz
                    - liveness : /healthz (ou /live)
                    4) Autoscaling:
                    - HPA (CPU/RPS)
                    5) Config:
                    - ConfigMap + Secrets (ou Secret Manager)
                    6) Observabilité:
                    - logs/metrics + alerting + dashboards

Découpage recommandé (Django)

Alternative : si ton service est “simple API”, Cloud Run est souvent plus rapide à opérer (mais GKE brille en multi-services + contrôle).

Config & Secrets : éviter les secrets en dur

Options

• ConfigMap : variables non sensibles (flags, URLs).
• K8s Secrets : sensible, mais attention à la gouvernance.
• Secret Manager : option “enterprise” (rotation, audit) — idéal en GCP.

Pattern “best” GCP

- Secret Manager contient les secrets (DB, API keys)
                    - Workload identity (pod -> SA GCP) pour lire secrets
                    - Injection au runtime (env vars ou volume)
                    => pas de clés JSON, pas de secrets en repo

Anti-pattern : mettre un fichier key.json dans l’image Docker. À proscrire.

Observabilité : logs, métriques, traces

Minimum vital

• Logs applicatifs structurés (json si possible).
• Métriques : CPU, mémoire, pods restart, HPA events, latence HTTP (p95/p99).
• Alertes : 5xx, crash loops, pods Pending, saturation nodes.

Dashboards utiles

Dashboards (idées)
                    - Ingress: RPS, 4xx/5xx, latence
                    - Workloads: restarts, replicas, CPU/mem
                    - Cluster: nodes, saturation, pending pods
                    - DB: connections, latency, errors

En prod, tu veux savoir “ça tombe pourquoi” en 2 minutes : logs + métriques + traces.

Sécurité & durcissement : l’essentiel

Checklist sécurité (pragmatique)

• Cluster privé (si possible) + contrôle egress.
• RBAC Kubernetes : droits par namespace (pas cluster-admin partout).
• Workload Identity : pods → SA GCP, sans clés statiques.
• Network Policies (si utilisées) : limiter trafic inter-services.
• Pod security : éviter root, readOnlyRootFilesystem si possible.
• Images signées/scannées (pipeline CI).

Front-door sécurité

LB + Armor (option)
                    - WAF rules
                    - rate-limit sur /api et endpoints sensibles
                    - blocage IP/ranges si besoin
                    => tu arrêtes le bruit avant d’atteindre le cluster

Upgrades & ops : éviter la “maintenance surprise”

Stratégie recommandée

1. Maintenance windows (prod) + communication interne.
2. Upgrades par étapes : staging → canary → prod.
3. Rolling updates sur Deployments (avec readiness probes).
4. Rollback prêt : image précédente + manifests versionnés.

Hygiène cluster

• Limiter les add-ons “magiques” (complexité).
• Namespaces + conventions de labels.
• Nettoyage des ressources “orphelines” (jobs, old replicasets).

Patterns IDEO-Lab (hyper adaptés à ton contexte)

1) Déployer le moteur de traduction (workers séparés)

Workloads:
                    - api (Django)
                    - translate-worker (celery/async)
                    - scheduler (beat)
                    Scaling:
                    - HPA agressif sur worker (selon backlog)
                    - HPA modéré sur api
                    Sécurité:
                    - Workload Identity pour accéder GCS/Secret Manager
                    => scale indépendant, coût maîtrisé

2) Anti-bots / flood

LB -> Armor -> Ingress -> Services -> Pods
                    - rate-limit sur /api, /login, /admin
                    - logs vers BigQuery (analytics)
                    => tu analyses puis tu bloques intelligemment

3) Séparer “apps” et “data”

Namespaces:
                    - apps-prod
                    - data-prod (ou services internes)
                    RBAC:
                    - ops team admin namespace
                    - dev read-only prod
                    Network policies:
                    - apps -> data (ports stricts)

Pièges & anti-patterns (GKE/K8s)

Checklist “prod ready”

1. Choisir Autopilot (si possible) pour réduire l’ops.
2. Ingress + TLS + (option) Armor/rate-limit.
3. Probes + rollouts contrôlés + rollback prêt.
4. Requests/limits + HPA (et node autoscaling si Standard).
5. Secret Manager + Workload Identity (0 clés statiques).
6. Dashboards + alertes (restarts/pending/latence/5xx).

Repos & formats (Docker/OCI… et plus)

Règles de conception

• Un repo par domaine : ideolab-app, ideolab-workers, ideolab-tools.
• Choisir la région proche des workloads (éviter latence/egress).
• Ne pas mélanger prod/dev : repos ou projets séparés.

IAM & sécurité : qui peut push/pull ?

Le bon design : humains via groupes, machines via service accounts. Zéro “clé partout”.

Rôles (idées pragmatiques)

Humains:
                    - developers : lecture (pull) + éventuellement push en dev
                    - release-managers / platform-ops : push prod + gestion tags/releases

                    Machines:
                    - cloudbuild-sa : push images
                    - gke-nodes/runner-sa : pull images
                    - cloudrun-runtime-sa : pull images

Règles d’or

• Le runtime (GKE/Run) doit être pull-only (jamais push).
• La CI (Cloud Build) doit être push (et rien d’autre).
• Limiter les droits admin sur le repo (sinon suppression/retag non maîtrisés).

Le risque n°1 : donner “writer” trop largement. Tu perds la garantie “image = release”.

Tags & versioning : stable vs mutable

Règles simples (qui évitent les drames)

• Tag immutable recommandé : app:2026.02.01-1 ou app:gitsha.
• Tag mutable (ex: latest) : OK en dev, dangereux en prod.
• En prod, déployer idéalement par digest (immuable).

Convention de tags (exemple solide)

Tags:
                    - app:git-          (immutable)
                    - app:rel-2026.02.01-1   (immutable)
                    - app:staging            (mutable)
                    - app:latest             (dev only)

Pourquoi les digests sont “béton”

image: app@sha256:...
                    => garantit qu’on déploie EXACTEMENT l’image buildée
                    => rollback simple (digest précédent)

Policies de rétention & nettoyage

Sans politique, tu accumules des centaines d’images et tu payes du stockage… et surtout tu perds la lisibilité. Le but : conserver ce qui sert (releases) et purger le bruit (builds intermédiaires).

Politique typique (exemple)

Conserver:
                    - les 50 derniers tags "git-*" (dev/staging)
                    - toutes les releases "rel-*" pendant 6 à 12 mois
                    - (option) 1 release/mois pendant 2 ans (compliance)

                    Supprimer:
                    - images sans tag (dangling) après 7-14 jours
                    - anciens builds CI non référencés

Hygiène “release”

• Chaque release doit correspondre à un tag “rel-*” + digest.
• Documenter le mapping : release → commit → digest → déploiement.
• Le cleanup ne doit jamais casser le rollback : garder au moins N versions prod.

Vulnerability Scanning : ne pas pousser des bombes

Le scanning détecte des vulnérabilités dans les layers (OS libs, packages, etc.). C’est un garde-fou : tu vois le risque avant déploiement.

Bonnes pratiques

• Utiliser des base images slim (moins de surface).
• Mettre à jour régulièrement l’OS layer (rebuild planifié).
• Bloquer (policy CI) les images avec vulnérabilités critiques (selon tolérance).

Pipeline “propre”

CI:
                    - build
                    - scan
                    - if severity >= CRITICAL -> fail
                    - push (ou push puis gate avant deploy)
                    - deploy

Même sans gate automatique, le scanning apporte une visibilité énorme sur la dette sécurité.

Signatures & provenance : confiance dans la supply chain

Le but : prouver qu’une image vient bien de ta CI (et pas d’un push manuel). Selon ta stack : signatures, attestations, SBOM, et vérification à l’admission (cluster).

Pattern conceptuel

Cloud Build (seul) -> signe/atteste l’image
                    GKE -> n’accepte que les images signées par la CI
                    => empêche les pushes “sauvages” en prod

Quand c’est indispensable

• Prod sensible (banque/défense), exigences compliance.
• Équipes larges → risque d’erreur humaine.
• Supply chain : dépendances multiples.

Même sans enforcement total, documenter “CI-only push” + IAM strict couvre déjà beaucoup.

CI/CD avec Cloud Build : pipeline “référence”

Pipeline minimal (lisible)

git push -> Cloud Build Trigger
                    1) docker build
                    2) docker push Artifact Registry
                    3) deploy:
                    - Cloud Run: gcloud run deploy ...
                    - GKE: kubectl apply / helm upgrade

Bonnes pratiques CI

• Tagger l’image avec git sha + release tag (si prod).
• Build reproductible (Dockerfile propre, .dockerignore).
• Cache build (si dispo) pour accélérer.
• Promouvoir : dev → staging → prod (même digest, pas “rebuild différent”).

Gating “simple” (staging → prod)

- Build + deploy staging automatique
                    - Tests smoke (HTTP 200 /healthz)
                    - Promotion manuelle prod (sur tag rel-*)

Déploiement : Cloud Run vs GKE

Rollback (règle d’or)

Toujours pouvoir revenir:
                    - Cloud Run: revision précédente
                    - GKE: redeploy digest précédent (ou rollback deployment)

Patterns IDEO-Lab (très réutilisables)

1) Mono-repo, multi-images

Repos:
                    - ideolab-api
                    - ideolab-worker
                    - ideolab-tools

                    Tagging:
                    - git-
                    - rel-YYYY.MM.DD-N (prod)

2) Pipeline anti-bots / stabilité

Staging auto:
                    - déploiement
                    - smoke tests
                    - vérif /healthz + latence

                    Prod:
                    - promotion sur tag "rel-*"
                    - rollback prêt (digest précédent)

3) Séparation des identités

SAs:
                    - cloudbuild-sa : push
                    - gke-runtime-sa / run-runtime-sa : pull only
                    => évite qu’un runtime puisse publier des images

Pièges & anti-patterns (Artifact Registry)

Checklist “prod ready”

1. Repos séparés prod/dev (ou projets distincts) + région proche.
2. IAM : CI push, runtime pull-only, humains via groupes.
3. Tags immuables + déploiement par digest (prod).
4. Policies rétention + purge images sans tag.
5. Scanning vulnérabilités + rebuild planifié des base images.
6. Rollback documenté (Run revisions / GKE digests).

Autoscaling : 0 → N, concurrency, min instances

Ce qui pilote le scaling

• Requests : Cloud Run scale sur la demande.
• Concurrency : nombre de requêtes simultanées par instance (levier coût/perf).
• Min instances : éviter le “scale to zero” si tu veux latence stable (et réduire cold start).
• Max instances : garde-fou anti-facture / anti-flood.

Réglages pragmatiques (API web)

- concurrency: 20..80 (selon app)
                    - min instances: 0 (par défaut) / 1..2 si besoin latence stable
                    - max instances: limiter (ex: 50) pour éviter scaling infini en cas d'abus
                    - timeouts: adaptés (éviter 10min si pas nécessaire)

Si ton API peut être floodée : max instances + WAF/rate-limit (Armor via LB) évite de “scaler pour payer”.

Revisions : immuables, auditables, rollbackables

Chaque déploiement crée une révision immuable. Une révision = image + config (env vars, resources, concurrency…). Tu peux envoyer du trafic à plusieurs révisions à la fois.

Bonnes pratiques

• Tagger l’image (git sha / release) et déployer le même digest entre staging/prod.
• Nommer les révisions (convention) pour faciliter le rollback.
• Conserver quelques révisions “golden” (rollback instant).

Rollback (instantané)

Rollback = repointer le trafic vers la révision précédente (100%)
                    => pas besoin de rebuild, pas besoin de redeploy long

Le modèle “revisions + traffic” est une arme massive pour déployer sans stress.

IAM & accès : service privé par défaut (recommandé)

Deux modes

Pattern “prod clean”

Public (si besoin):
                    - Cloud Run public OU derrière un LB
                    - Auth applicative (JWT/session)
                    - (recommandé) WAF/rate-limit via Cloud Armor (devant)

                    Privé:
                    - Cloud Run privé
                    - appel via service account (workload identity)
                    - aucun endpoint public direct

Pour une API interne, IAM est ultra efficace : tu évites d’exposer inutilement.

Traffic split : canary / blue-green / safe deploy

Le traffic split permet d’envoyer X% du trafic vers une nouvelle révision pour tester en prod (canary), puis monter progressivement à 100%. Rollback = revenir instantanément.

Canary simple (recommandé)

Étape 1 : déployer nouvelle révision
                    Étape 2 : 5% trafic -> nouvelle révision, 95% -> ancienne
                    Étape 3 : observer (erreurs 5xx, latence p95, logs)
                    Étape 4 : 25% -> 50% -> 100%
                    Étape 5 : si souci, rollback en 10 secondes

Blue/Green

- Blue = révision stable
                    - Green = révision candidate (0% trafic)
                    - Switch 100% quand validé

Ne “promote” pas à 100% sans monitoring (5xx/latence). Cloud Run rend le rollback trop facile pour ne pas l’utiliser.

Réseau / VPC : accéder à des ressources privées

Si ton service doit accéder à des ressources privées (Cloud SQL private IP, services internes, etc.), tu utilises une intégration VPC (connectivité).

Cas typiques

• Accès à Cloud SQL en Private IP.
• Accès à un service interne sur VPC (ex: Redis managé, endpoint privé).
• Sortie internet contrôlée (egress) via NAT (selon design).

Bonnes pratiques réseau

• Limiter ce qui doit être privé : “private by default”.
• Surveiller l’egress (coûts) et les timeouts.
• Pour public : considérer Cloud Run derrière LB + Armor si tu veux un front-door robuste.

Cloud Run “simple” = public + IAM/app auth. Cloud Run “enterprise” = privé + VPC + front LB.

DB (Cloud SQL) : le point critique = connexions

Cloud Run scale horizontalement : si chaque instance ouvre trop de connexions DB, tu peux saturer Cloud SQL très vite. La discipline DB est le vrai sujet Cloud Run.

Règles pragmatiques

• Limiter la concurrency si la DB est fragile.
• Limiter le nombre de workers/threads qui ouvrent des connexions.
• Préférer des requêtes courtes, transactions courtes.
• Utiliser read replicas (si besoin) pour isoler reporting.

Pattern “API Django + Cloud SQL”

Cloud Run service:
                    - concurrency modérée (ex: 20)
                    - max instances limité (garde-fou)
                    - timeouts raisonnables
                    DB:
                    - user app minimal
                    - pool small (éviter 50 connexions par instance)
                    - monitoring connections + latency

Anti-pattern n°1 : “scale infini Cloud Run” + “pool DB énorme” = DB down.

Secrets & config : Secret Manager + service account runtime

Pattern recommandé

- Secrets dans Secret Manager (DB password, API keys)
                    - Cloud Run runtime service account (SA) a secretAccessor sur les secrets nécessaires
                    - Injection via env vars (ou au runtime)
                    => aucun secret dans l'image Docker, aucun secret dans Git

Config non sensible

• Variables d’environnement : flags, URLs, mode, niveaux logs.
• Conventions : préfixes (ex: IDEOLAB_*) pour lisibilité.

Cloud Run + Secret Manager = un combo extrêmement “propre” pour garder ton repo clean.

Observabilité & ops : rendre le serverless “opérable”

Monitoring minimal

• RPS, latence p95/p99, 4xx/5xx.
• Instance count (scaling), throttling.
• Erreurs applicatives (Error Reporting), traces (si activées).

Alertes recommandées

Alertes:
                    - 5xx > seuil (sur 5 min)
                    - latence p95 > seuil
                    - erreurs DB / timeouts
                    - scaling anormal (ex: instances > 80% du max)
                    - crash loops (si observé via logs)

Runbook “release safe”

1. Déployer nouvelle révision.
2. Traffic split 5% + observer.
3. Monter progressivement.
4. Si anomalies : rollback immédiat.
5. Post-mortem : corriger + redeployer.

Patterns IDEO-Lab (très adaptés à ton écosystème)

1) NetGuard API sur Cloud Run + Armor

Front:
                    - HTTP(S) LB + Cloud Armor (rate-limit, WAF)
                    Backend:
                    - Cloud Run (API)
                    Data:
                    - logs -> BigQuery (analyse ranges IP, ASN, pays)
                    => rapide, scalable, et tu contrôles le flood

2) Microservices “tools”

Services:
                    - unminify-api
                    - analyzer-api
                    - translation-api (si stateless)
                    Each:
                    - Cloud Run + Secret Manager
                    - Artifact Registry + CI/CD
                    => découplé, simple, rollback facile

3) Front public + back office privé

- Front public (Cloud Run public ou via LB)
                    - Admin/ops endpoints privés (IAM)
                    - Separate service accounts + least privilege

Pièges & anti-patterns (Cloud Run)

Checklist “prod ready”

1. Images immuables (digest) depuis Artifact Registry + CI/CD.
2. IAM : privé par défaut, public seulement si nécessaire.
3. Traffic split (canary) + rollback documenté.
4. Secrets via Secret Manager + runtime SA (least privilege).
5. Garde-fous : max instances + concurrency adaptée.
6. Si public : WAF/rate-limit (Armor via LB) + monitoring latence/5xx.

Triggers Git : automatiser “au bon moment”

Pattern recommandé (simple et solide)

- Trigger PR     : tests + lint (bloque merge si KO)
                    - Trigger main   : build + deploy staging + smoke tests
                    - Trigger tag rel-* : build (ou promote digest) + deploy prod (canary) + monitor

Tu peux garder “prod” sur un trigger tag uniquement : ça évite les “déploiements accidentels”.

Pipeline de base (lisible, efficace)

Étapes minimales (CI/CD containers)

1) Checkout (implicite via trigger)
                    2) Build image Docker
                    3) Tests (unit)
                    4) (Option) Lint / format / type check
                    5) Push Artifact Registry
                    6) Deploy (staging)
                    7) Smoke test (HTTP /healthz)
                    8) Promotion prod (si tag release)

Trois niveaux de maturité

Docker build “propre” : reproductible + rapide

Bonnes pratiques Dockerfile

• Multi-stage build : builder → runtime (image finale plus petite).
• Base image slim (surface + scan plus simple).
• .dockerignore : exclure caches, venv, node_modules, logs.
• Pin versions (deps) autant que possible.

Tagging “propre” (immuable)

Tagger:
                    - app:git-         (immutable)
                    - app:rel-YYYY.MM.DD-N  (immutable)
                    Déployer idéalement par digest:
                    - app@sha256:...

Le combo “tag immuable + digest” = rollback facile + déploiements reproductibles.

Tests & quality gates : empêcher la prod de casser

Gates recommandés

1. Unit tests (rapides, à chaque commit).
2. Lint (style + erreurs évidentes).
3. Smoke tests (après deploy staging : /healthz, DB connect, endpoint simple).
4. Migration check (si Django : détecter migrations non commitées).

Smoke test (pattern)

Après deploy staging:
                    - GET /healthz -> 200
                    - GET /version -> contient git sha
                    - (option) endpoint DB read-only -> OK
                    Si KO -> stop pipeline + rollback staging

Sans smoke tests, tu déplaces le test “en prod” sur tes utilisateurs. À éviter.

Push Artifact Registry : IAM & séparation des identités

Principes IAM (très importants)

• Le service account Cloud Build a le droit de push (writer) sur le repo.
• Les runtimes (GKE nodes / Cloud Run SA) ont le droit de pull-only.
• Les humains : plutôt pull-only en prod (push réservé CI).

Policy “CI-only push” (golden rule)

Artifact Registry:
                    - writers: cloudbuild-sa
                    - readers: gke-runtime-sa, cloudrun-runtime-sa, developers (option)
                    => aucun push manuel sur prod

Ce garde-fou réduit énormément les risques supply chain et les erreurs “à la main”.

Déploiement vers Cloud Run : simple, robuste, rollback facile

Pipeline type

Build -> Push -> Deploy Cloud Run (staging)
                    - définir env vars / secrets
                    - définir concurrency / max instances
                    - smoke test
                    Promotion prod:
                    - traffic split 5% -> 25% -> 100%
                    - rollback: repointer trafic vers révision précédente

Best practices Cloud Run en CI

• Déployer par digest (pas latest).
• Configurer max instances (anti-flood / anti-facture).
• Utiliser Secret Manager + runtime SA (pas de secrets dans l’image).

Déploiement vers GKE : contrôlé, versionné, “prod-grade”

Deux approches

Rollouts “safe”

GKE prod:
                    - readiness/liveness probes obligatoires
                    - rolling update (maxUnavailable contrôlé)
                    - HPA + requests/limits
                    - rollback prêt (deployment rollback ou digest précédent)

Sur GKE, le socle “probes + requests/limits + rollback” fait 80% de la stabilité.

Promotion staging → prod : éviter “ça marche chez moi”

Pattern recommandé : promouvoir le même digest

Staging:
                    - build image -> push -> deploy staging
                    - tests OK

                    Prod:
                    - promouvoir le même digest (pas rebuild différent)
                    - canary + monitoring
                    - rollback si anomalies

Stratégies de release

• Tag rel-* : déclenche promotion prod (simple).
• Manual approval : étape de validation avant prod (équipes + compliance).
• Canary : 5% trafic puis montée progressive.

Anti-pattern : rebuild en prod avec “mêmes sources” mais dépendances différentes → bugs non reproductibles.

Sécurité supply chain : scan, signatures, politique CI-only

Garde-fous utiles

• Scanner vulnérabilités (au moins visibilité).
• Bloquer (option) sur sévérité CRITICAL.
• Éviter secrets dans images (Secret Manager + runtime SA).
• Enforcer “CI-only push” sur Artifact Registry.
• Si exigences élevées : signatures/attestations (provenance) + admission control côté cluster.

Principe clé

Seule la CI produit les images “autorisées”.
                    Tout le reste = interdit (ou inutile).

Observabilité & runbook : CI/CD opérable

Logs & métriques pipeline

• Durée build, taux d’échec, étapes les plus lentes.
• Historique : commit → build → image digest → deploy.
• Alertes si échecs répétitifs (ex: tests cassés, quota).

Runbook “release safe” (ultra simple)

1. Déployer staging automatiquement.
2. Smoke tests OK.
3. Déployer prod en canary (ou 100% si service interne).
4. Monitor 10–15 min (5xx/latence/DB).
5. Si KO : rollback immédiat (Run revisions / GKE rollback).

Le runbook doit être exécutable en 2 minutes, pas un roman.

Pièges & anti-patterns (Cloud Build)

Checklist “prod ready”

1. Triggers : PR (tests), main (staging), tag rel-* (prod).
2. Build reproductible + tags immuables + déploiement par digest.
3. Tests (unit) + smoke tests après deploy.
4. Artifact Registry : CI push, runtime pull-only, humains via groupes.
5. Promotion staging → prod = même digest (pas rebuild).
6. Rollback documenté (Run revisions / GKE rollback).

Logging : centraliser, filtrer, requêter

Ce que tu veux obtenir

• Un endroit unique pour lire les logs (infra + app + LB).
• Des logs structurés (idéalement JSON) pour filtrer vite.
• Une séparation “humains vs bots” / “normal vs erreurs” (hyper utile en prod).

Log structure conseillé (API/web)

Fields utiles:
                    - severity (INFO/WARN/ERROR)
                    - service (api/worker)
                    - env (dev/stage/prod)
                    - request_id / trace_id
                    - http: method, path, status, latency_ms, user_agent, ip
                    - user_id (si applicable)
                    - msg + exception stack (si erreur)

Exports (option très puissant)

• Export vers BigQuery : analytics logs (ranges IP, endpoints, latence).
• Export vers GCS : archive/long terme.
• Attention : exporter “tout” sans filtrage = coûts + bruit.

Une observabilité “pro” = logs utiles, pas des gigas de bruit.

Alerting & SLO : alerter “utile”, pas “bruyant”

Deux types d’alertes

SLO (simple) : ce que tu mesures

SLO typiques (API):
                    - Disponibilité : % requêtes 2xx/3xx (ou inverse de 5xx)
                    - Latence : p95 < X ms
                    - Erreurs : 5xx < Y% sur 5 min

Notifications

• Email + webhook (Slack/Discord) + éventuellement SMS (incidents critiques).
• Routage : alertes “page” (nuit) vs alertes “ticket” (journée).

Anti-pattern : 50 alertes CPU → tu ignores tout. Toujours privilégier les alertes “symptôme”.

Error Reporting : le “signal prod” des exceptions

Error Reporting regroupe les exceptions identiques, te donne la fréquence, la régression (nouvelle version), et facilite la priorisation.

Bon usage

• Tagger par service/version (ex: api, rel-2026.02.01-1).
• Corréler avec un request_id / trace_id pour remonter au contexte.
• Créer une alerte si une erreur “nouvelle” apparaît en release.

Pattern “release gate”

Déploiement (canary 5%)
                    - si Error Reporting détecte nouvelles erreurs -> rollback automatique / manuel
                    => évite de pousser un bug à 100%

Trace : latence bout-en-bout (où ça bloque ?)

Ce que la trace te montre

• Temps total requête (edge → app → DB → services).
• Segments lents : DB query, appel externe, rendu, etc.
• Corrélation : latence p95 ↑ → quelle dépendance est responsable ?

Conseils APM (pragmatiques)

• Instrumenter d’abord les endpoints critiques (login, search, admin, API core).
• Ajouter des “spans” sur : DB, appels externes, tâches async.
• Conserver un trace_id dans les logs (corrélation immédiate).

Quand la latence explose, Trace t’empêche de “deviner”. Tu vois le goulot.

Profiler : hotspots CPU/mémoire sans tout casser

Le Profiler aide à trouver où le CPU est consommé (fonctions, libs, endpoints), et où la mémoire grimpe, avec un impact réduit (selon configuration).

Quand l’activer

• CPU trop élevé sans explication.
• Latence forte alors que la DB va bien (suspect code app).
• Fuites mémoire / usage mémoire qui monte avec le trafic.

Méthode (simple)

1) Activer sur staging (puis prod si OK)
                    2) Identifier 1-2 hotspots (top functions)
                    3) Corriger (cache, index, algo)
                    4) Mesurer avant/après (latence + CPU)
                    => itération courte

Dashboards “golden” : 1 écran pour piloter

Dashboard API (minimum)

API Dashboard
                    - RPS (global + top endpoints)
                    - Latence p50/p95/p99
                    - HTTP codes (2xx/4xx/5xx)
                    - Saturation (CPU/mem) + instances/pods
                    - DB connections + DB latency
                    - Top errors (Error Reporting)
                    - Top slow traces (Trace)

Dashboard “infra”

Infra Dashboard
                    - LB health checks (backends healthy/unhealthy)
                    - VMs/nodes: CPU/mem/disk latency
                    - Réseau: egress, spikes
                    - Incidents: alert history

Ton objectif : en 60 secondes, savoir si c’est “traffic”, “code”, “DB” ou “infra”.

Coûts & rétention : logs volumineux = facture

Principes anti-coût

• Filtrer les logs inutiles (health checks, bruit bots) ou les réduire.
• Échantillonnage (sampling) sur endpoints très “chatty”.
• Rétention : garder longtemps l’utile (erreurs), moins longtemps le bruit (debug).
• Exporter vers BigQuery seulement ce qui est exploitable (curated logs).

Politique type (exemple)

Rétention logs (idée):
                    - ERROR : 30-90 jours
                    - INFO  : 7-14 jours (selon volume)
                    - DEBUG : 1-3 jours (staging uniquement)
                    Exports:
                    - vers BigQuery : uniquement logs "requests" + "security events"

Anti-pattern : tout en DEBUG en prod + export BigQuery = explosion volume + coût + bruit.

Patterns IDEO-Lab (super adaptés à ton contexte)

1) Anti-flood / bots : “humains vs bots”

Logging:
                    - tagger user_agent + ip + path
                    - séparer logs "human" vs "bot"
                    Monitoring:
                    - alert si RPS bot > seuil
                    - latence p95 qui grimpe + 4xx/5xx
                    Export:
                    - logs security -> BigQuery (group by IP range/ASN/pays)

2) Django : health endpoints + release version

Endpoints:
                    - /healthz : 200 si app OK (option: DB check light)
                    - /version : git sha / release tag
                    => corrélation immédiate "incident <-> release"

3) Traduction engine (workers)

Métriques:
                    - queue depth / backlog
                    - throughput (items/min)
                    - erreurs par langue
                    Alertes:
                    - backlog > seuil (risque latence)
                    - erreurs GCP Translate / quotas

Pièges & anti-patterns (Observabilité)

Checklist “SRE-ready”

1. Dashboards golden signals (latence, trafic, erreurs, saturation).
2. Alertes symptôme + causes (DB connections/IO, pods pending, etc.).
3. Logs structurés + request_id/trace_id.
4. Error Reporting + Trace activés sur endpoints critiques.
5. Politique rétention/sampling pour maîtriser les coûts.
6. Runbook incident (quoi regarder, quoi faire, rollback).

Cloud Armor : WAF + rate limiting (la protection “front-door”)

Ce que tu obtiens

• WAF : règles managées + règles custom (patterns, paths, headers, IPs, geo, etc.).
• Rate limiting : limiter les abus sur endpoints sensibles (login, api, search, admin).
• Blocklists : IPs / ranges / ASN (selon ta stratégie) + géoblocage (si pertinent).
• Logs : visibilité (et export BigQuery si tu veux analyser à grande échelle).

Ruleset “starter” (très efficace)

Armor policies (idée)
                    1) Block obvious bad actors:
                    - IP/ranges connus
                    - paths de scan (/wp-admin, /phpmyadmin, etc.)
                    2) Rate-limit endpoints:
                    - /login, /admin, /api/*
                    3) Allowlist (si service interne):
                    - seulement corporate IP / IAP / SA caller
                    4) Default allow + monitoring

Rate limit : bonnes pratiques

• Limiter sur IP + éventuellement “key” applicative (token/user) si tu as.
• Ne pas casser /static (sinon tu te tires une balle dans le pied).
• Faire 2 niveaux : soft (challenge/throttle) puis hard (block).

Le meilleur ROI sécurité sur un service public, c’est Armor + règles simples.

IAP (Identity-Aware Proxy) : exposer une app interne sans VPN classique

IAP protège une application derrière une identité (Google Identity / SSO) : tu autorises des groupes (ops, dev, admin) et tu obtiens un accès sécurisé, MFA/SSO, audit, sans exposer l’app au public.

Use cases parfaits

• Backoffice admin / consoles internes.
• Outils ops (dashboards, endpoints maintenance).
• Accès temporaire pour support (audit + révocation facile).

Pattern “admin safe” (recommandé)

Internet -> LB HTTPS -> IAP -> service (Run / GKE / VM)
                    - seuls groupes autorisés passent
                    - MFA/SSO + audit
                    - pas d'admin exposé publiquement

Règles d’or IAP

• Autoriser par groupes, pas par utilisateurs “à la main”.
• Segmenter : admin ≠ dev ≠ read-only.
• Conserver un “break-glass” (procédure) mais ultra contrôlé.

KMS : clés, chiffrement, rotation, audit

Cloud KMS te permet de gérer les clés : création, rotation, contrôle d’accès fin, audit. En pratique : chiffrement de données sensibles, enveloppe de chiffrement, clés client-managed (selon besoin).

À quoi ça sert (concret)

• Chiffrer des données applicatives sensibles (tokens, secrets, payloads).
• Contrôler qui peut “decrypt” (ex: uniquement worker, pas l’API).
• Tracer l’usage des clés (audit).

Pattern “envelope encryption” (simple)

1) Générer une DEK (data key) pour chiffrer la donnée
                    2) Chiffrer la DEK avec KMS (KEK)
                    3) Stocker : data_encrypted + dek_encrypted
                    => rotation KEK possible, audit, contrôle decrypt

Rotation : stratégie

• Rotation régulière (selon exigences).
• Limiter l’accès au droit “decrypt” (c’est le plus sensible).
• Séparer clés par domaine : prod ≠ staging ≠ dev.

“KMS partout” n’est pas obligatoire, mais pour secrets applicatifs + données sensibles, c’est une base très solide.

VPC Service Controls : périmètre anti-exfiltration (data perimeter)

VPC-SC sert à réduire les risques d’exfiltration sur des services data (ex: Storage, BigQuery, etc.) : tu définis un périmètre et tu bloques certains accès “hors périmètre” même si une clé/identité est compromise.

Quand c’est pertinent

• Données sensibles / compliance.
• Grand projet multi-services : risque de misconfig IAM.
• Tu veux éviter “un token volé = exfiltration vers Internet”.

Mental model

Sans VPC-SC:
                    - si identité compromise -> accès data possible depuis n'importe où

                    Avec VPC-SC:
                    - accès data limité au périmètre (réseaux / projets / identités)
                    - exfiltration rendue beaucoup plus difficile

Attention (réalité terrain)

• VPC-SC peut casser des flux légitimes si non planifié (ex: CI, exports, intégrations).
• Ça se déploie en mode “design” : on cartographie les flux, puis on enferme.

Security Command Center (SCC) : posture + findings

SCC centralise la visibilité sécurité : ressources, vulnérabilités, misconfigurations, exposures. L’intérêt : passer d’un mode “on découvre quand ça brûle” à “on corrige en continu”.

Ce que tu veux faire avec SCC

• Avoir une vue centralisée des risques (par projet/env).
• Recevoir des findings actionnables (ex: ressource exposée, clé trop permissive).
• Routage : findings critiques → alert, le reste → backlog/ticket.

Workflow “sain”

SCC finding -> triage (critique / important / info)
                    - Critique : incident / page + action immédiate
                    - Important : ticket + correction sous X jours
                    - Info : backlog + revue mensuelle

Sans process de triage, SCC devient un “mur de bruit”. Avec un workflow, c’est très puissant.

Identity & IAM (rappel) : la base qui conditionne tout

Règles simples (mais non négociables)

• Least privilege : pas de “Editor” large, surtout en prod.
• Service Accounts dédiés par service (api, worker, ci).
• Humains : accès par groupes (ops/dev/audit), pas en direct.
• Séparer environnements : dev/stage/prod (projets distincts idéalement).

Pattern “identités” (propre)

Service Accounts:
                    - cloudbuild-sa     : push images + deploy (staging/prod selon)
                    - api-runtime-sa    : accès DB/Secrets strict
                    - worker-runtime-sa : accès queue/translate strict
                    - auditor-sa        : read-only logs/dashboards

80% des incidents cloud viennent d’IAM trop large + secrets mal gérés. C’est la fondation.

Sécurité “prod” : checklists rapides

Checklist Front-door (public)

1. LB HTTPS + cert managé.
2. Cloud Armor : règles managées + rate limit sur endpoints sensibles.
3. Logs LB + alerting sur 5xx/latence.
4. Max instances (Cloud Run) / HPA limites (GKE) pour garde-fou coût.

Checklist Admin / backoffice

1. IAP devant l’admin (idéal).
2. Groupes + MFA.
3. Audit logs + alert sur tentatives anormales.
4. Endpoints admin séparés des endpoints publics.

Checklist Data / secrets

1. Secrets dans Secret Manager, jamais dans l’image/repo.
2. KMS si données sensibles à chiffrer (domain keys, tokens).
3. Backups + restore tests (Cloud SQL, storage).
4. VPC-SC si data critique + risque exfiltration.

Pattern : NetGuard / IDEO-Lab (Run + Armor + BigQuery + Monitoring)

Public traffic
                    -> HTTP(S) Load Balancer (global)
                    -> Cloud Armor
                    - WAF rules (scans, injections basiques)
                    - rate-limit (/api, /login, /admin)
                    - blocklists (IP/ranges)
                    -> Cloud Run (NetGuard API / services)
                    - IAM strict (runtime SA)
                    - max instances (garde-fou)
                    -> Logging -> export BigQuery (security analytics)
                    -> Monitoring -> alerting (RPS bot, 4xx/5xx, latence)
                    -> (option) IAP pour consoles/admin

Pourquoi ce pattern est redoutable

• Tu bloques tôt (Armor) → CPU/app protégées.
• Tu scales (Run) mais avec garde-fous.
• Tu analyses (BigQuery) → rules plus intelligentes (ranges/ASN).
• Tu alertes (Monitoring) → réaction rapide.

Pièges & anti-patterns (sécurité GCP)

Checklist “enterprise-ready”

1. Armor en front-door (WAF + rate-limit) + logs.
2. IAP pour apps internes/backoffice + MFA.
3. Secret Manager + KMS (si données sensibles) + audit + rotation.
4. VPC-SC pour data critique (anti-exfiltration) après design.
5. SCC avec triage + alerting + backlog.

Always Free : utile… mais à cadrer

Bon usage

• Idéal pour dev/POC et tests d’intégration (sans charge).
• Le free tier n’est pas une stratégie prod : tu veux surtout des garde-fous (budgets/alertes).
• Ne pas confondre “gratuit” et “sans risque” : egress + logs + queries peuvent coûter vite.

Réflexes

1. Créer un project dev séparé (billing isolé).
2. Mettre un budget très bas + alerte agressive.
3. Déployer des quotas/limites (max instances, etc.).

SUD vs CUD : choisir intelligemment

Stratégie simple (FinOps)

1) Démarrer sans engagement : mesurer 2-4 semaines
                    2) Identifier la “base stable” (charge minimale)
                    3) CUD sur la base stable uniquement
                    4) Le reste en on-demand (autoscaling)
                    => tu évites de surpayer si trafic varie

CUD = excellent, mais uniquement si tu connais ton “socle” de consommation.

Budgets & alertes : anti-surprise (Jour 1 obligatoire)

Bon pattern

Budgets:
                    - dev  : petit budget (alerte tôt)
                    - stage: budget moyen
                    - prod : budget réaliste + alertes multi-seuils

                    Alertes:
                    - 50% / 80% / 95% (email + webhook si possible)
                    - alerte “spike” : hausse anormale jour/heure (si dispo via monitoring)

Garde-fous “tech” (complément budgets)

• Cloud Run : max instances + concurrency.
• GKE : HPA max + node autoscaling max (Standard).
• BigQuery : éviter full scans (discipline SQL + tables partitionnées).
• Logs : exclusions/filtrage + rétention courte pour INFO.

Un budget sans garde-fou technique = tu découvres l’incident après la dépense.

Labels & chargeback : savoir “qui coûte quoi”

Convention minimale (recommandée)

Labels (standard)
                    - env   : dev | stage | prod
                    - app   : ideolab | netguard | translate | unminify | ...
                    - owner : guillaume | ops | team-x
                    - cost_center : core | tools | data | security

Pourquoi c’est crucial

• Tu peux trier les coûts par app/service.
• Tu détectes vite “ce service a explosé”.
• Tu peux imposer des limites et optimiser la bonne zone.

Sans labels, l’optimisation devient une chasse au trésor.

Réseau & egress : la source #1 de surprises

Ce qui coûte typiquement

• Egress vers Internet (downloads, assets, API publiques volumineuses).
• Trafic inter-région (workloads non co-localisés).
• Exports data (BigQuery/GCS) vers des consommateurs externes.

Leviers

1. Co-localiser : app + DB + storage dans la même région si possible.
2. CDN : servir le statique via cache (réduit egress “chaud”).
3. Limiter exports massifs (curated, pas brut).
4. Surveiller le top talkers (services qui sortent beaucoup).

Si tu héberges beaucoup de statique, le CDN est souvent un ROI immédiat.

Optimiser Cloud Run : le trio gagnant

Les 3 réglages qui pilotent la facture

Pattern recommandé (API publique)

- concurrency : modérée (ex: 20..80)
                    - max instances : limiter (ex: 20..100) selon ton budget
                    - min instances : 0 (par défaut), ou 1 si besoin perf constante
                    + WAF/rate-limit devant (Armor via LB) si exposition Internet

Anti-pattern : pas de max instances + API floodable → tu scales pour payer.

Optimiser GKE : right-sizing + autoscaling + hygiène

Leviers principaux

• Requests/Limits : base du scheduling + HPA cohérent.
• HPA : scale pods selon CPU/métriques.
• Node autoscaling (Standard) : scale nodes selon pods Pending.
• Node pools : séparer web / workers / batch pour optimiser.
• Réduire le bruit logs (sinon coût ingestion + stockage).

Autopilot vs Standard (coût)

Si ton objectif est “ops minimal + coût maîtrisé”, Autopilot est souvent un excellent point de départ.

Optimiser BigQuery : coût = bytes scanned

Règles d’or

1. Tables “events/logs” partitionnées (DATE) + clustering (2-4 colonnes utiles).
2. Jamais SELECT * sur tables larges.
3. Filtrer toujours sur la partition (WHERE event_date …).
4. Créer des tables “marts” petites pour BI (éviter raw direct).

Pattern “curated” (anti-facture)

raw (partitionnée) -> curated (partition+cluster) -> marts (petites tables KPI)
                    BI/dashboard -> marts
                    Exploration -> curated (avec garde-fous IAM)

Anti-pattern : analystes sur raw + requêtes exploratoires = full scans = facture.

Optimiser Cloud Storage (GCS) : lifecycle & classes

Leviers

• Lifecycle rules : déplacer vers classes froides après X jours.
• Versioning : utile, mais à maîtriser (sinon stockage explose).
• Nettoyer les objets temporaires (exports, builds).
• Limiter egress : co-localiser + CDN si besoin.

Exemple de policy (simple)

- logs bruts : garder 14 jours en classe standard
                    - puis basculer en classe froide
                    - supprimer après 90 jours (ou archiver long-terme selon compliance)

En général, “lifecycle + purge” donne un ROI immédiat sur les buckets qui grossissent.

Check-list “Jour 1” (anti-surprise)

1. Créer 3 projets : dev / stage / prod (billing isolé).
2. Activer Budgets + alertes (50/80/95%) sur chaque projet.
3. Définir une convention labels (env/app/owner/cost_center) et l’appliquer partout.
4. Cloud Run : config max instances + concurrency par défaut.
5. GKE : requests/limits + HPA (et node autoscaling si Standard).
6. BigQuery : tables partitionnées + discipline SQL (pas de SELECT *).
7. Logs : rétention courte INFO + filtrage du bruit + pas de DEBUG en prod.
8. Dashboard “coûts” : top services + top egress + top logs + top BQ scanned.

Patterns IDEO-Lab : réduire coût sans perdre la perf

1) API publique (anti-flood) : coût maîtrisé

LB + Armor (rate-limit) -> Cloud Run (max instances)
                    - tu bloques tôt (évite scaling)
                    - tu plafonnes le scaling (anti-facture)
                    - tu observes (monitoring + alerting)

2) Traduction engine : coûts “contrôlés”

- Workers séparés (scale selon backlog)
                    - Budgets + alertes quota/API (GCP Translate)
                    - Logs: seulement erreurs + métriques (pas spam)
                    => throughput OK, coût prévisible

3) Logs de sécurité : exporter “curated” vers BigQuery

Logging -> filtre (security events) -> BigQuery (partition+cluster)
                    - analytics sur IP ranges / ASN / pays
                    - tables petites “marts” pour dashboards
                    => utile, pas ruineux

Pièges & anti-patterns (coûts GCP)

Checklist “FinOps-ready”

1. Budgets + alertes + dashboards coûts (top services).
2. Labels partout (env/app/owner/cost_center).
3. Garde-fous techniques (max instances, HPA max, quotas).
4. BigQuery : partition/cluster + guardrails IAM (raw vs marts).
5. Logs : filtrage + rétention + exports ciblés.
6. CUD uniquement sur la base stable mesurée.

Pré-requis (fondations) : si tu rates ça, la migration devient un cauchemar

Fondations à poser avant toute VM

1. Org / Folders / Projects : séparer dev/stage/prod (idéalement projets distincts).
2. Billing : budgets + alertes + labels (env/app/owner/cost_center).
3. IAM : groupes, least privilege, service accounts dédiés (CI, runtime, ops).
4. Réseau : VPC, subnets, firewall rules, Cloud NAT, stratégie IP.
5. Observabilité : Monitoring/Logging activés + dashboards “golden signals”.

Inventaire (à ne pas zapper)

• Applications : dépendances, endpoints, SLA/SLO, pics de charge.
• Data : DBs, volumes, RPO/RTO, contraintes conformité.
• Réseau : flux entrants/sortants, allowlists, IP fixes.
• Sécurité : secrets, clés, comptes techniques.

Anti-pattern : migrer “vite” sans IAM/réseau/budgets → tu paies en incidents + facture.

Migration VM : méthode “safe” (du rehost au replatform)

Trajectoire recommandée

On-prem VM
                    -> (1) Compute Engine (rehost)
                    -> (2) Managed services (replatform)
                    - Cloud SQL, managed LB, Secret Manager, etc.
                    -> (3) (option) GKE/Run (refactor)

Check VM avant move

• OS supporté, espace disque, drivers, dépendances système.
• Services : ports, reverse proxy, systemd, cron jobs.
• State : où sont les fichiers persistants (à externaliser si possible : GCS/DB).
• Observabilité : logs centralisés, healthcheck / endpoint /healthz.

Garde-fou

Objectif rehost = “ça tourne pareil”
                    Pas “optimiser tout” au premier déplacement.
                    Optimisation vient en Vague 2 (replatform).

DB : le vrai sujet (RPO/RTO, cutover, réplication)

Pour 80% des apps, la DB représente la vraie complexité : latence, cohérence, connexions, sauvegardes, reprise. La stratégie doit être explicite : downtime accepté ? sinon il faut une approche “sync / replicate / cutover”.

3 approches DB (du plus simple au plus robuste)

Cutover (pattern “propre”)

1) Préparer Cloud SQL + users + réseau privé
                    2) Synchroniser (replication / CDC si possible)
                    3) Freeze writes (courte fenêtre)
                    4) Final sync + switch DNS/app config
                    5) Smoke tests prod
                    6) Unfreeze + monitor
                    7) Garder rollback plan (retour DB source) pendant X heures

Anti-pattern : “on bascule la DB sans plan rollback” → tu perds ta marge de manœuvre.

Réseau hybride : VPN/Interconnect + “design des flux”

Pourquoi c’est crucial

• Pendant la migration, tu as souvent une phase hybride (app sur GCP, DB on-prem, ou inverse).
• La latence réseau devient un facteur majeur (DB queries + API calls).

Pattern hybride “sain”

On-prem <-> (VPN ou Interconnect) <-> VPC GCP
                    - routes claires
                    - firewall rules strictes
                    - NAT contrôlé (egress)
                    - monitoring de latence/packet loss

Conseils pragmatiques

• Co-localiser app + DB au plus vite (réduit latence + coûts réseau).
• Isoler “migration traffic” (réplication) et surveiller débit.
• Documenter les flux (ports, CIDR) → évite les ouvertures “trop larges”.

Plan par vagues : le meilleur compromis risque/valeur

Vague 0 — Préparer

• Fondations : org/projects, IAM, VPC, budgets, observabilité.
• Inventaire + classification : critique vs non-critique.
• Runbooks + rollback “papier” (avant le move).

Vague 1 — Quick wins (non critique)

• Un service stateless (API simple) vers Cloud Run.
• Une VM secondaire vers Compute Engine.
• Value rapide : logs export vers BigQuery (analytics sécurité/trafic).

Vague 2 — Cœur applicatif

• Replatform DB vers Cloud SQL (avec plan cutover).
• Déploiement stable (GKE Autopilot ou Run selon besoin).
• DRP de base (backups + restore tests).

Vague 3 — Optimisation & cloud-native

• Découper en services, jobs async (Pub/Sub), caching, etc.
• Cost optimization : SUD/CUD, lifecycle storage, BQ partitions.

Tests, canary, rollback : migration “sans panique”

Tests incontournables

• Smoke tests : /healthz, login, endpoint clé, DB read.
• Perf baseline : latence p95, throughput, CPU/IO (avant/après).
• Data checks : comptages, checksums (si possible), échantillons métier.

Canary (pattern)

1) Déployer nouvelle infra en parallèle
                    2) Router 1-5% du trafic vers GCP
                    3) Observer (5xx, latence, DB, logs)
                    4) Monter 25% -> 50% -> 100%
                    5) Conserver rollback facile (DNS/traffic/revision)

Rollback : ce que tu dois décider AVANT

• Rollback appli : repointer trafic vers ancienne infra.
• Rollback DB : possible uniquement si tu n’as pas “divergé” (d’où le freeze writes court).
• Durée de coexistence : X heures/jours selon criticité.

Sécurité & conformité pendant la migration

Règles simples

1. Secrets : Secret Manager, jamais dans images/repos.
2. IAM : service accounts dédiés, least privilege, groupes pour humains.
3. Front-door : WAF/rate-limit (Cloud Armor) si exposition Internet.
4. Logs/audit : activer et conserver assez longtemps pour investigations.
5. Accès admin : privilégier IAP ou accès privé, pas “ouverture large”.

La migration est une période où on ouvre “temporairement” trop de choses : documenter + refermer.

DR / Haute disponibilité : définir RPO/RTO (même simple)

Définitions (très concrètes)

• RPO : perte de données acceptable (ex: 5 min, 1h, 24h).
• RTO : temps de reprise acceptable (ex: 15 min, 1h).

Pattern minimal “DRP”

- Backups automatiques (DB + storage)
                    - Restore test mensuel (sinon backup = illusion)
                    - Multi-zone (au moins) pour workloads critiques
                    - Runbooks de reprise (qui fait quoi)

Si tu ne testes jamais un restore, tu ne sais pas si tu as une sauvegarde.

Patterns IDEO-Lab (concrets, ROI rapide)

1) Migration progressive du site (sans tout casser)

Vague 1:
                    - services “tools” stateless -> Cloud Run
                    - statique -> GCS + CDN
                    - logs -> BigQuery (analytics trafic/bots)

                    Vague 2:
                    - app principale (Django) -> GKE Autopilot ou Run
                    - DB -> Cloud SQL (cutover plan)

                    Vague 3:
                    - workers (traduction / cron) -> GKE/Run jobs + scaling
                    - Armor/IAP sur admin & endpoints sensibles

2) NetGuard : migration “secure by design”

LB + Armor -> Cloud Run API
                    - max instances (anti-facture)
                    - export logs sécurité -> BigQuery
                    - dashboard bots/ranges IP + alerting

3) Traduction engine : isoler compute & coûts

- API stable (Run/GKE)
                    - workers séparés (scale selon backlog)
                    - quotas/alertes (budgets) + logs “curated”
                    => performance + coût prévisible

Checklist Go/No-Go (avant cutover)

1. Budgets + alertes en place (dev/stage/prod).
2. IAM validé : SAs runtime, CI, ops (least privilege).
3. Réseau OK : firewall rules, NAT, DNS, monitoring latence.
4. Observabilité : dashboards + alertes (5xx/latence/DB connections).
5. Plan cutover écrit + fenêtre + responsables + rollback.
6. Smoke tests automatisés (au moins 5 endpoints clés).
7. Backups + restore test récent (DB).
8. Canary/traffic split prêt (si applicable).

Pièges & anti-patterns (migration)

Résumé “migration propre”

1) Fondations (IAM/VPC/Budgets/Observability)
                    2) Vagues progressives (non critique -> critique)
                    3) DB = plan cutover + rollback
                    4) Canary + smoke tests + monitoring
                    5) Refermer les ouvertures temporaires

Front-door & sécurité : LB + Armor + (option) IAP

Public : protéger contre bots/flood

• Cloud Armor en amont : règles managées + règles custom.
• Rate limit sur endpoints sensibles : /login, /admin, /api/*, /tools/*.
• Blocklists : IP/ranges agressifs (tu sais déjà que ça arrive chez toi).
• Garde-fous : Cloud Run max instances / GKE HPA max (anti-facture).

Interne : admin/ops “zéro exposition”

Option recommandée:
                    - /admin, /ops, endpoints sensibles -> derrière IAP
                    => accès par identité (groupes) + audit + MFA

Règles d’or

• Ne jamais “protéger” le statique comme l’app : /static doit rester performant.
• Armor d’abord, app ensuite : tu bloques tôt → CPU/DB protégées.
• Si public : prévoir un plan anti-scraping (rate-limit + tokens + analytics).

Data layer : Cloud SQL (PostgreSQL) + GCS (static/media)

Cloud SQL (PostgreSQL) : “prod basics”

• Mode HA + backups automatiques + tests de restore.
• Private IP (recommandé) + règles d’accès strictes.
• Monitoring : connections, IO latency, slow queries, replication lag.
• Users séparés : app runtime vs migrations vs read-only analytics.

GCS : static/media + lifecycle

Buckets:
                    - ideolab-static  (builds statiques, immutable)
                    - ideolab-media   (uploads, versioning si besoin)
                    Lifecycle:
                    - purge temp exports/build artifacts
                    - classes froides pour archives

Le duo Cloud SQL + GCS couvre 90% des besoins web. Le reste (cache, queue) se rajoute au fur et à mesure.

Moteur i18n / Weglot-like : jobs, dedup, quotas, perf

Composants typiques

Pattern “batch propre” (anti-latence / anti-coût)

Frontend -> enqueue (requests)
                    Workers -> batch translate (maxBatch) + dedup
                    DB -> store results
                    Dashboards -> throughput + errors + costs
                    => pas de traduction “bloquante” côté UX

Tu as déjà la mentalité “dedup hors chemin critique” : sur GCP, ça devient encore plus rentable (coût API).

NetGuard sur GCP : API, WAF, analytics sécurité (très puissant)

Architecture recommandée

Internet
                    -> Load Balancer
                    -> Cloud Armor (WAF + rate-limit + blocklists)
                    -> Cloud Run (NetGuard API)
                    Data/Analytics
                    -> Logging (security events) -> BigQuery
                    Ops
                    -> Dashboards + alerting (spikes, top ranges, 5xx)

Pourquoi ce pattern est ROI immédiat

• Armor réduit le bruit avant l’app → baisse CPU/latence.
• Cloud Run scale, mais tu gardes un cap (max instances).
• BigQuery te donne des stats sur ranges/ASN/pays → règles plus intelligentes.

Le “point dur” : ne pas exporter tous les logs. Exporter curated security events seulement.

BigQuery analytics (trafic, bots, perf, sécurité)

Pipeline recommandé

LB/Armor/App logs
                    -> Logging filters (requests + security)
                    -> BigQuery dataset (partition par date)
                    -> clustering (ip_range / path / status / user_agent_category)
                    -> tables “marts” (KPI quotidiens)
                    -> dashboards

KPI utiles (IDEO-Lab)

• Top endpoints (RPS) + latence p95.
• Ratio humains vs bots (user-agent categ + patterns).
• Top IP ranges / ASN / pays (si enrichissement).
• Top erreurs (5xx) corrélées à une release (sha/tag).
• Coût : bytes scanned / queries → discipline partition/clustering.

BigQuery devient ton “radar” anti-abus + perf, à condition de partitionner et d’éviter les full scans.

CI/CD & releases : Cloud Build + Artifact Registry + canary

Pipeline “prod ready”

Git push / tag rel-*
                    -> Cloud Build (tests + build)
                    -> push Artifact Registry (digest)
                    -> deploy staging
                    -> smoke tests (/healthz, /version)
                    -> promotion prod (Cloud Run traffic split / GKE rollout)
                    -> rollback prêt (revision/digest précédent)

Conventions (très pratiques)

• Tag image immuable : git-<sha> + rel-YYYY.MM.DD-N.
• Endpoint /version renvoie release tag + sha (corrélation logs/incident).
• Déploiement par digest en prod (pas latest).

Observabilité & SLO : rendre l’ensemble opérable

Golden dashboard (minimum)

- RPS global + top endpoints
                    - Latence p95/p99
                    - HTTP 4xx/5xx
                    - Saturation (CPU/RAM) + instances/pods
                    - DB connections + DB latency
                    - Top errors (Error Reporting)
                    - Top slow traces

Alertes (qui servent)

• 5xx > seuil (impact user direct).
• Latence p95 > seuil (dégradation).
• DB : connections/IO saturées.
• Scaling anormal (Run instances proche max, pods pending).

Si tu as ces alertes + un runbook rollback, tu gères 90% des incidents.

DR multi-région : backups, runbooks, tests (sans fantasme)

Définir RPO/RTO (exemples)

• RPO (perte acceptable) : 15 min / 1h / 24h selon criticité.
• RTO (temps reprise) : 15 min / 1h / 4h selon ton niveau.

DRP minimal (déjà très bon)

- Cloud SQL : backups planifiés + restore tests
                    - Exports vers GCS (bucket multi-région) si besoin long-terme
                    - Images/snapshots (si VMs)
                    - Runbook de bascule (DNS/traffic) + personnes responsables
                    - Monitoring du plan (alert si backup échoue)

DRP “plus sérieux” (progressif)

- Multi-zone partout (au minimum)
                    - Réplication / read-replica (selon DB)
                    - Infra as Code (Terraform) pour rebuild rapide
                    - Tests DR trimestriels (sinon DR = illusion)

Le DR n’existe pas tant que tu n’as pas fait au moins 1 test de restore/bascule.

Checklist “prod” (IDEO-Lab)

1. 3 projets : dev/stage/prod + budgets + alertes.
2. LB global + Armor (WAF + rate limit) pour tout service public.
3. Admin/backoffice derrière IAP (recommandé).
4. Cloud SQL private + HA + backups + restore tests.
5. GCS static/media + lifecycle rules.
6. CI/CD : Cloud Build + Artifact Registry + deploy digest + canary/rollback.
7. Observabilité : dashboards + alertes (5xx/latence/DB/scale).
8. Analytics : logs “curated” → BigQuery (partition+cluster).
9. DR : runbook + tests réguliers.

Pièges & anti-patterns (IDEO-Lab sur GCP)

Résumé “IDEO-Lab cloud-ready”

- Bloquer tôt (Armor)
                    - Déployer safe (revisions/canary + rollback)
                    - Data solide (Cloud SQL HA + backups testés)
                    - Logs utiles (curated -> BigQuery)
                    - DR réel (tests)