⚙️DevOps – Terraform, State, GitLab CI/CD & Gestion d'incidents (Part 1)

Typical production stack

Users
                            │
                            ▼
                            DNS / CDN / WAF
                            │
                            ▼
                            Load Balancer
                            │
                            ▼
                            Application Tier
                            ├── container platform / VMs
                            ├── autoscaling
                            └── background workers
                            │
                            ▼
                            Data Tier
                            ├── relational database
                            ├── cache
                            ├── object storage
                            └── search / analytics
                            │
                            ▼
                            Observability Layer
                            ├── metrics
                            ├── logs
                            ├── tracing
                            └── alerting

Production constraints

Concrete production scenario

Terraform in real production

Terraform is used to describe cloud infrastructure as code. In a professional setup, code is organized into reusable modules, state is stored remotely, environments are clearly separated, and applies are done through controlled pipelines.

Typical module breakdown

live/
                            prod/
                            network/
                            security/
                            app/
                            data/
                            staging/
                            network/
                            security/
                            app/
                            data/
                            modules/
                            vpc/
                            security_group/
                            ecs_service/
                            rds_postgres/
                            iam_role/
                            dns_record/

What modules should achieve

Remote state and locking

Terraform code
                            │
                            ▼
                            Backend configuration
                            │
                            ├── remote state storage
                            ├── state version history
                            └── state lock
                            │
                            ▼
                            Plan / Apply
                            │
                            ▼
                            State updated safely

Standard infra pipeline

Stages
                            1. lint
                            2. validate
                            3. security_scan
                            4. plan
                            5. review / approval
                            6. apply
                            7. post_deploy_checks

Critical CI/CD controls

SEV-1 incident flow

Alert fires
                            │
                            ▼
                            Triage
                            │
                            ├── confirm impact
                            ├── identify affected scope
                            └── assign incident lead
                            │
                            ▼
                            Mitigation
                            ├── rollback
                            ├── disable bad change
                            ├── failover
                            └── traffic control
                            │
                            ▼
                            Recovery validation
                            ├── health checks
                            ├── logs
                            ├── metrics
                            └── business KPI
                            │
                            ▼
                            Postmortem
                            ├── timeline
                            ├── root cause
                            ├── corrective actions
                            └── prevention

Example incident in production

Incident response roles

Postmortem quality checklist

• Precise timeline with timestamps.
• Customer impact and internal impact.
• Triggering change or trigger event.
• Root cause, not only the symptom.
• What worked well during response.
• Corrective actions with owners and deadlines.

SLA / SLO / Error budget

Architecture recommandée

infra/
                            ├── modules/
                            │   ├── network/
                            │   │   ├── main.tf
                            │   │   ├── variables.tf
                            │   │   ├── outputs.tf
                            │   │   └── README.md
                            │   ├── security_group/
                            │   ├── compute_service/
                            │   ├── database/
                            │   ├── dns/
                            │   └── monitoring/
                            │
                            ├── live/
                            │   ├── dev/
                            │   │   ├── network/
                            │   │   ├── app/
                            │   │   └── data/
                            │   ├── staging/
                            │   │   ├── network/
                            │   │   ├── app/
                            │   │   └── data/
                            │   └── prod/
                            │       ├── network/
                            │       ├── app/
                            │       └── data/
                            │
                            └── global/
                            ├── iam/
                            ├── dns/
                            └── shared-services/

Découpage par domaine

Diagramme d’organisation

modules/
                            │
                            ├── composants réutilisables
                            │
                            ▼
                            live/dev
                            live/staging
                            live/prod
                            │
                            ├── appellent les modules
                            ├── passent les variables
                            ├── utilisent un backend state dédié
                            └── exposent les outputs utiles

Structure minimale propre

terraform/
                            ├── providers.tf
                            ├── versions.tf
                            ├── backend.tf
                            ├── variables.tf
                            ├── main.tf
                            ├── outputs.tf
                            ├── locals.tf
                            ├── terraform.tfvars
                            └── README.md

Exemple : versions.tf

terraform {
                            required_version = ">= 1.6.0"

                            required_providers {
                            aws = {
                            source  = "hashicorp/aws"
                            version = "~> 5.0"
                            }
                            }
                            }

Exemple : providers.tf

provider "aws" {
                            region = var.aws_region

                            default_tags {
                            tags = local.common_tags
                            }
                            }

Exemple : locals.tf

locals {
                            name_prefix = "${var.project}-${var.environment}"

                            common_tags = {
                            Project     = var.project
                            Environment = var.environment
                            ManagedBy   = "terraform"
                            Owner       = var.owner
                            }
                            }

Providers fréquents en production

Exemple multi-provider

provider "aws" {
                            region = var.aws_region
                            }

                            provider "cloudflare" {
                            api_token = var.cloudflare_api_token
                            }

                            provider "gitlab" {
                            token = var.gitlab_token
                            }

Risques liés aux providers

Bon réflexe professionnel

Avant upgrade provider
                            │
                            ├── lire changelog
                            ├── lancer terraform init -upgrade en dev
                            ├── vérifier terraform plan
                            ├── tester en staging
                            └── appliquer en prod uniquement après validation

Resource : Terraform gère l’objet

Une resource représente un objet que Terraform doit créer, modifier ou supprimer. Exemple : une instance, un bucket, une règle réseau, une base de données.

resource "aws_security_group" "web" {
                            name        = "${local.name_prefix}-web-sg"
                            description = "Security group for web traffic"
                            vpc_id      = var.vpc_id

                            ingress {
                            description = "HTTPS from internet"
                            from_port   = 443
                            to_port     = 443
                            protocol    = "tcp"
                            cidr_blocks = ["0.0.0.0/0"]
                            }

                            egress {
                            description = "Outbound traffic"
                            from_port   = 0
                            to_port     = 0
                            protocol    = "-1"
                            cidr_blocks = ["0.0.0.0/0"]
                            }
                            }

Data source : Terraform lit l’existant

Une data source permet de récupérer une information existante sans en devenir propriétaire. C’est utile pour référencer une AMI, un VPC existant, un secret, une zone DNS, etc.

data "aws_ami" "ubuntu" {
                            most_recent = true
                            owners      = ["099720109477"]

                            filter {
                            name   = "name"
                            values = ["ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"]
                            }
                            }

Resource vs Data source

Cycle de dépendances

data source
                            │
                            ▼
                            récupère une information existante
                            │
                            ▼
                            resource
                            │
                            ▼
                            utilise cette information pour créer un objet

Variables d’entrée

Les variables permettent de rendre le code Terraform paramétrable. Elles évitent de dupliquer le même code pour dev, staging et production.

variable "project" {
                            description = "Project name"
                            type        = string
                            }

                            variable "environment" {
                            description = "Deployment environment"
                            type        = string

                            validation {
                            condition     = contains(["dev", "staging", "prod"], var.environment)
                            error_message = "Environment must be dev, staging, or prod."
                            }
                            }

                            variable "instance_type" {
                            description = "EC2 instance type"
                            type        = string
                            default     = "t3.micro"
                            }

Exemple terraform.tfvars

project       = "ideo-platform"
                            environment   = "prod"
                            aws_region    = "eu-west-3"
                            owner         = "platform-team"
                            instance_type = "t3.medium"

Outputs utiles

Les outputs exposent des valeurs générées par Terraform : endpoint de base de données, DNS du load balancer, ID du VPC, ARN d’un rôle IAM, etc.

output "load_balancer_dns_name" {
                            description = "Public DNS name of the load balancer"
                            value       = aws_lb.main.dns_name
                            }

                            output "security_group_id" {
                            description = "Web security group ID"
                            value       = aws_security_group.web.id
                            }

Variables sensibles

variable "database_password" {
                            description = "Database password"
                            type        = string
                            sensitive   = true
                            }

Cycle standard

terraform init
                            terraform fmt -check -recursive
                            terraform validate
                            terraform plan -var-file="prod.tfvars" -out="tfplan"
                            terraform apply "tfplan"

Rôle de chaque commande

Lire un plan Terraform

Diagramme du cycle

Code modifié
                            │
                            ▼
                            terraform fmt
                            │
                            ▼
                            terraform validate
                            │
                            ▼
                            terraform plan
                            │
                            ├── aucun changement : OK
                            ├── création : vérifier nommage / tags / coût
                            ├── modification : vérifier impact
                            └── destruction : analyse obligatoire
                            │
                            ▼
                            review humaine
                            │
                            ▼
                            terraform apply
                            │
                            ▼
                            contrôles post-apply

Pourquoi le state est sensible

Exemple backend S3

terraform {
                            backend "s3" {
                            bucket         = "company-terraform-state-prod"
                            key            = "prod/network/terraform.tfstate"
                            region         = "eu-west-3"
                            dynamodb_table = "terraform-locks"
                            encrypt        = true
                            }
                            }

State locking

Pipeline A lance terraform apply
                            │
                            ▼
                            verrouillage du state
                            │
                            ├── Pipeline A peut écrire
                            └── Pipeline B doit attendre
                            │
                            ▼
                            fin du apply
                            │
                            ▼
                            déverrouillage du state

Commandes liées au state

Exemple : plateforme web sur AWS

Route53 / DNS
                            │
                            ▼
                            Application Load Balancer
                            │
                            ▼
                            ECS / EC2 / Kubernetes
                            │
                            ├── service web
                            ├── workers
                            └── autoscaling
                            │
                            ▼
                            RDS PostgreSQL
                            │
                            ├── backups
                            ├── monitoring
                            └── security groups
                            │
                            ▼
                            CloudWatch / Grafana / Alerting

Ce que Terraform peut gérer

Processus professionnel de changement

Besoin métier
                            │
                            ▼
                            ticket ou demande de changement
                            │
                            ▼
                            branche Git
                            │
                            ▼
                            modification Terraform
                            │
                            ▼
                            merge request
                            │
                            ├── fmt
                            ├── validate
                            ├── security scan
                            └── plan
                            │
                            ▼
                            review du plan
                            │
                            ▼
                            approval production
                            │
                            ▼
                            apply contrôlé
                            │
                            ▼
                            vérifications post-changement
                            │
                            ├── logs
                            ├── métriques
                            ├── health checks
                            └── coût / sécurité

Contrôles indispensables

Avant merge request

Avant apply production

Arborescence professionnelle

infra/
                            ├── modules/
                            │   ├── network/
                            │   │   ├── main.tf
                            │   │   ├── variables.tf
                            │   │   ├── outputs.tf
                            │   │   ├── locals.tf
                            │   │   ├── versions.tf
                            │   │   └── README.md
                            │   │
                            │   ├── security-group/
                            │   ├── load-balancer/
                            │   ├── compute-service/
                            │   ├── database-postgres/
                            │   ├── redis-cache/
                            │   ├── dns-record/
                            │   └── monitoring-alarm/
                            │
                            ├── live/
                            │   ├── dev/
                            │   │   ├── network/
                            │   │   ├── app/
                            │   │   └── data/
                            │   ├── staging/
                            │   │   ├── network/
                            │   │   ├── app/
                            │   │   └── data/
                            │   └── prod/
                            │       ├── network/
                            │       ├── app/
                            │       └── data/
                            │
                            └── global/
                            ├── iam/
                            ├── dns/
                            └── shared-services/

Root module vs child module

Flux d’instanciation

live/prod/app
                            │
                            ├── définit les variables prod
                            ├── configure le backend state prod
                            ├── appelle les modules nécessaires
                            └── expose les outputs utiles
                            │
                            ▼
                            modules/
                            ├── network
                            ├── security
                            ├── compute
                            └── database

Exemple d’appel module

module "web_service" {
                            source = "../../modules/compute-service"

                            project       = var.project
                            environment   = var.environment
                            vpc_id        = module.network.vpc_id
                            subnet_ids    = module.network.private_subnet_ids
                            instance_type = var.web_instance_type

                            tags = local.common_tags
                            }

Inputs : variables propres et typées

variable "project" {
                            description = "Project name used for naming and tags."
                            type        = string
                            }

                            variable "environment" {
                            description = "Environment name."
                            type        = string

                            validation {
                            condition     = contains(["dev", "staging", "prod"], var.environment)
                            error_message = "Environment must be dev, staging, or prod."
                            }
                            }

                            variable "subnet_ids" {
                            description = "Private subnet IDs used by the service."
                            type        = list(string)
                            }

                            variable "enable_public_access" {
                            description = "Whether the service is publicly exposed."
                            type        = bool
                            default     = false
                            }

Outputs : exposer seulement l’utile

output "service_name" {
                            description = "Name of the created service."
                            value       = aws_ecs_service.main.name
                            }

                            output "security_group_id" {
                            description = "Security group attached to the service."
                            value       = aws_security_group.service.id
                            }

                            output "load_balancer_dns_name" {
                            description = "Public DNS name of the load balancer."
                            value       = aws_lb.main.dns_name
                            }

Qualité du contrat

Responsabilités du module network

Exemple d’appel

module "network" {
                            source = "../../modules/network"

                            project           = var.project
                            environment       = var.environment
                            vpc_cidr          = "10.20.0.0/16"
                            public_subnets    = ["10.20.1.0/24", "10.20.2.0/24"]
                            private_subnets   = ["10.20.11.0/24", "10.20.12.0/24"]
                            availability_zones = ["eu-west-3a", "eu-west-3b"]

                            tags = local.common_tags
                            }

Diagramme réseau type

VPC 10.20.0.0/16
                            │
                            ├── Public Subnet A
                            │     ├── Load Balancer
                            │     └── NAT Gateway
                            │
                            ├── Public Subnet B
                            │     ├── Load Balancer
                            │     └── NAT Gateway
                            │
                            ├── Private App Subnet A
                            │     └── Web / API / Workers
                            │
                            ├── Private App Subnet B
                            │     └── Web / API / Workers
                            │
                            └── Private Data Subnets
                            ├── PostgreSQL
                            ├── Redis
                            └── Search

Outputs réseau

output "vpc_id" {
                            value = aws_vpc.main.id
                            }

                            output "private_subnet_ids" {
                            value = aws_subnet.private[*].id
                            }

                            output "public_subnet_ids" {
                            value = aws_subnet.public[*].id
                            }

Responsabilités possibles

Exemple d’appel

module "api_service" {
                            source = "../../modules/compute-service"

                            project        = var.project
                            environment    = var.environment
                            vpc_id         = module.network.vpc_id
                            subnet_ids     = module.network.private_subnet_ids
                            image          = var.api_image
                            desired_count  = 3
                            min_capacity   = 2
                            max_capacity   = 8

                            enable_public_load_balancer = true
                            health_check_path           = "/health/"

                            tags = local.common_tags
                            }

Diagramme applicatif

Internet
                            │
                            ▼
                            Load Balancer
                            │
                            ├── health check /health/
                            │
                            ▼
                            Compute Service
                            ├── task / instance 1
                            ├── task / instance 2
                            └── task / instance 3
                            │
                            ├── logs
                            ├── metrics
                            └── autoscaling policy
                            │
                            ▼
                            Database / Cache / APIs internes

Outputs utiles

output "service_name" {
                            value = aws_ecs_service.main.name
                            }

                            output "load_balancer_dns_name" {
                            value = aws_lb.main.dns_name
                            }

                            output "service_security_group_id" {
                            value = aws_security_group.service.id
                            }

Paramètres essentiels

Exemple d’appel

module "postgres" {
                            source = "../../modules/database-postgres"

                            project               = var.project
                            environment           = var.environment
                            subnet_ids            = module.network.private_subnet_ids
                            allowed_sg_ids        = [module.api_service.service_security_group_id]

                            engine_version        = "15"
                            instance_class        = "db.t3.medium"
                            allocated_storage_gb  = 100
                            backup_retention_days = 14
                            multi_az              = true
                            deletion_protection   = true

                            tags = local.common_tags
                            }

Diagramme database sécurisé

Application Security Group
                            │
                            ▼
                            Database Security Group
                            │
                            ├── autorise seulement le port DB
                            ├── refuse accès public
                            └── limite aux subnets privés
                            │
                            ▼
                            Managed Database
                            ├── backups automatiques
                            ├── monitoring
                            ├── maintenance window
                            ├── encryption
                            └── deletion protection

Protections recommandées

Règles de sécurité module

Exemple validation sécurité

variable "allowed_cidr_blocks" {
                            description = "CIDR blocks allowed to access the service."
                            type        = list(string)
                            default     = []

                            validation {
                            condition     = length(var.allowed_cidr_blocks) > 0
                            error_message = "At least one allowed CIDR block must be provided."
                            }
                            }

Secrets : ce qu’il ne faut pas faire

# Mauvais exemple
                            variable "database_password" {
                            default = "SuperPassword123"
                            }

Approche préférable

variable "database_password" {
                            description = "Database password provided by CI/CD or secret manager."
                            type        = string
                            sensitive   = true
                            }

Outils liés à la sécurité

Source module : local vs Git

Exemple module local

module "network" {
                            source = "../../modules/network"

                            project     = var.project
                            environment = var.environment
                            }

Exemple module Git versionné

module "network" {
                            source = "git::ssh://git@gitlab.com/company/terraform-modules.git//network?ref=v1.4.2"

                            project     = var.project
                            environment = var.environment
                            }

Stratégie de release module

Modification module
                            │
                            ▼
                            tests / terraform validate
                            │
                            ▼
                            merge request
                            │
                            ▼
                            release tag v1.4.2
                            │
                            ▼
                            environnement dev utilise v1.4.2
                            │
                            ▼
                            staging valide v1.4.2
                            │
                            ▼
                            production adopte v1.4.2

Compatibilité

Pipeline de validation module

Commit module
                            │
                            ▼
                            terraform fmt -check
                            │
                            ▼
                            terraform validate
                            │
                            ▼
                            security scan
                            ├── checkov
                            ├── tfsec
                            └── trivy config
                            │
                            ▼
                            example plan
                            │
                            ▼
                            review humaine
                            │
                            ▼
                            tag de release

Exemple GitLab CI

stages:
                            - lint
                            - validate
                            - security

                            terraform_fmt:
                            stage: lint
                            script:
                            - terraform fmt -check -recursive

                            terraform_validate:
                            stage: validate
                            script:
                            - terraform init -backend=false
                            - terraform validate

                            checkov_scan:
                            stage: security
                            script:
                            - checkov -d .
                            allow_failure: false

Tests pratiques de module

Outils liés

Checklist technique

Checklist production

Local state vs remote state

Exemple backend S3 + lock DynamoDB

terraform {
                            backend "s3" {
                            bucket         = "company-terraform-state-prod"
                            key            = "prod/network/terraform.tfstate"
                            region         = "eu-west-3"
                            dynamodb_table = "terraform-locks"
                            encrypt        = true
                            }
                            }

Ce que doit garantir le backend

Architecture backend

GitLab CI/CD ou poste autorisé
                            │
                            ▼
                            terraform init
                            │
                            ▼
                            Backend distant
                            ├── state chiffré
                            ├── versioning
                            ├── accès IAM restreint
                            └── mécanisme de lock
                            │
                            ▼
                            terraform plan / apply
                            │
                            ▼
                            State mis à jour proprement

Diagramme de verrouillage

Pipeline A démarre terraform apply
                            │
                            ▼
                            Lock du state obtenu
                            │
                            ├── Pipeline A peut lire / écrire
                            │
                            └── Pipeline B doit attendre
                            │
                            ▼
                            erreur ou attente selon backend
                            │
                            ▼
                            Pipeline A termine
                            │
                            ▼
                            Lock libéré
                            │
                            ▼
                            Pipeline B peut relancer proprement

Sans locking

Que faire en cas de state lock ?

Commande de dernier recours

terraform force-unlock LOCK_ID

Règle CI/CD

Un environnement = un state = une file d'exécution contrôlée

                            prod/network apply
                            │
                            └── un seul job actif à la fois

Mauvaise approche

Un seul state global
                            │
                            ├── dev
                            ├── staging
                            ├── prod
                            ├── network
                            ├── compute
                            ├── database
                            ├── IAM
                            └── monitoring

Bonne approche

States séparés
                            │
                            ├── dev/network
                            ├── dev/app
                            ├── dev/data
                            │
                            ├── staging/network
                            ├── staging/app
                            ├── staging/data
                            │
                            ├── prod/network
                            ├── prod/app
                            └── prod/data

Découpage recommandé

Partager des valeurs entre states

data "terraform_remote_state" "network" {
                            backend = "s3"

                            config = {
                            bucket = "company-terraform-state-prod"
                            key    = "prod/network/terraform.tfstate"
                            region = "eu-west-3"
                            }
                            }

                            locals {
                            vpc_id = data.terraform_remote_state.network.outputs.vpc_id
                            }

Risques principaux

.gitignore minimal

.terraform/
                            *.tfstate
                            *.tfstate.*
                            crash.log
                            crash.*.log
                            *.tfvars
                            *.tfvars.json
                            override.tf
                            override.tf.json
                            *_override.tf
                            *_override.tf.json

Contrôles de sécurité recommandés

Secrets et state

Variable sensitive
                            │
                            ├── masque l'affichage CLI
                            └── ne garantit pas l'absence dans le state
                            │
                            ▼
                            Secret manager préférable
                            ├── Vault
                            ├── AWS Secrets Manager
                            ├── SSM Parameter Store
                            └── GitLab protected variables

Diagramme du drift

Code Terraform
                            instance_type = "t3.small"

                            State Terraform
                            instance_type = "t3.small"

                            Cloud réel
                            instance_type = "t3.medium"

                            Résultat :
                            terraform plan détecte un écart
                            et propose de revenir à t3.small

Causes fréquentes

Réaction professionnelle au drift

Drift détecté
                            │
                            ▼
                            Ne pas appliquer automatiquement
                            │
                            ▼
                            Comprendre l'écart
                            │
                            ├── changement manuel légitime ?
                            ├── incident ou hotfix ?
                            ├── bug provider ?
                            └── ressource supprimée ?
                            │
                            ▼
                            Décision
                            ├── intégrer le changement dans le code
                            ├── restaurer l'état attendu
                            ├── importer correctement
                            └── documenter la décision

Commandes utiles

terraform plan
                            terraform plan -refresh-only
                            terraform apply -refresh-only
                            terraform state list
                            terraform state show RESOURCE_NAME

Politique anti-drift

Commandes principales

Exemple import

# 1. Écrire d'abord le bloc resource correspondant
                            resource "aws_security_group" "web" {
                            name   = "prod-web-sg"
                            vpc_id = var.vpc_id
                            }

                            # 2. Importer la ressource existante
                            terraform import aws_security_group.web sg-0123456789abcdef0

                            # 3. Lancer un plan pour aligner code et réalité
                            terraform plan

Renommer une ressource sans recréation

# Ancien nom dans le state
                            aws_instance.web

                            # Nouveau nom dans le code
                            aws_instance.application

                            # Déplacement dans le state
                            terraform state mv aws_instance.web aws_instance.application

Processus sécurisé

Avant manipulation state
                            │
                            ├── sauvegarder state
                            ├── comprendre mapping actuel
                            ├── préparer commande exacte
                            ├── faire revue par un pair
                            └── exécuter hors période critique
                            │
                            ▼
                            Après manipulation
                            ├── terraform plan
                            ├── vérifier zéro destruction inattendue
                            └── documenter l'opération

Scénario 1 : state local commité dans Git

Scénario 2 : lock bloqué

Pipeline échoue brutalement
                            │
                            ▼
                            Lock reste présent
                            │
                            ▼
                            Nouveau plan/apply impossible
                            │
                            ▼
                            Vérifier qu'aucun apply ne tourne
                            │
                            ▼
                            force-unlock uniquement si lock orphelin
                            │
                            ▼
                            relancer terraform plan

Scénario 3 : mauvais state utilisé

Scénario 4 : state corrompu ou perdu

1. Stopper les applies immédiatement.
2. Récupérer une version précédente du backend.
3. Comparer avec l’infrastructure réelle.
4. Restaurer le state si possible.
5. Importer manuellement les ressources si nécessaire.
6. Documenter la cause et renforcer les protections.

Outils Terraform natifs

Commandes utiles

terraform state list
                            terraform state show aws_instance.web
                            terraform plan -refresh-only
                            terraform apply -refresh-only
                            terraform output
                            terraform state pull > state-backup.json

Outils complémentaires

Checklist backend

Checklist isolation

Checklist avant apply production

Mini-cheat-sheet

terraform init
                            terraform state list
                            terraform state show RESOURCE_NAME
                            terraform plan -refresh-only
                            terraform apply -refresh-only
                            terraform import RESOURCE_NAME PROVIDER_ID
                            terraform state mv OLD_NAME NEW_NAME
                            terraform state rm RESOURCE_NAME
                            terraform force-unlock LOCK_ID

Chaîne complète

Commit / Merge Request
                            │
                            ▼
                            lint
                            ├── terraform fmt
                            └── tflint
                            │
                            ▼
                            validate
                            ├── terraform init
                            └── terraform validate
                            │
                            ▼
                            security
                            ├── checkov
                            ├── tfsec / trivy config
                            └── secret detection
                            │
                            ▼
                            plan
                            ├── terraform plan
                            ├── plan lisible
                            └── artefact conservé
                            │
                            ▼
                            review
                            ├── revue du diff
                            ├── revue des destructions
                            └── approval
                            │
                            ▼
                            apply
                            ├── manuel en production
                            ├── environnement protégé
                            └── state verrouillé
                            │
                            ▼
                            post-checks
                            ├── smoke tests
                            ├── logs
                            ├── métriques
                            └── alertes

Stages typiques

Politique par environnement

Types de runners

Tags runner

terraform_apply_prod:
                            stage: apply
                            tags:
                            - terraform
                            - prod
                            - protected
                            script:
                            - terraform apply -auto-approve tfplan

Architecture runner sécurisée

GitLab
                            │
                            ▼
                            Protected Runner
                            │
                            ├── exécute seulement branches protégées
                            ├── utilise credentials limités
                            ├── accès réseau contrôlé
                            ├── logs surveillés
                            └── isolation Docker / VM
                            │
                            ▼
                            Terraform
                            │
                            ├── remote state
                            ├── cloud provider
                            └── environnement prod

Risques runner

Types de variables

Exemple TF_VAR

# Variable GitLab CI/CD
                            TF_VAR_project=ideo-platform
                            TF_VAR_environment=prod
                            TF_VAR_aws_region=eu-west-3

                            # Terraform la récupère automatiquement :
                            variable "project" {
                            type = string
                            }

Masked, protected, scoped

Flux sécurisé

GitLab protected variables
                            │
                            ├── accessibles uniquement sur main/protected
                            ├── masquées dans les logs
                            ├── scopées à production
                            └── injectées au job apply
                            │
                            ▼
                            Terraform
                            ├── utilise credentials temporaires si possible
                            └── évite secrets en clair dans Git

Ce qu’il faut relire

Lecture du plan

Diagramme review

Plan généré
                            │
                            ▼
                            Revue automatique
                            ├── fmt
                            ├── validate
                            ├── security
                            └── policy
                            │
                            ▼
                            Revue humaine
                            ├── scope
                            ├── destroy / replace
                            ├── réseau / IAM
                            ├── database
                            └── rollback
                            │
                            ▼
                            Approval ou rejet

Commentaire MR recommandé

Résumé infra :
                            - Environnement : production
                            - Domaine : app
                            - Ressources créées : 2
                            - Ressources modifiées : 1
                            - Ressources détruites : 0
                            - Risque : faible
                            - Rollback : revenir au commit précédent + plan/apply
                            - Vérification : health check /metrics + logs applicatifs

Garde-fous GitLab

Exemple job apply prod

terraform_apply_prod:
                            stage: apply
                            environment:
                            name: production
                            script:
                            - terraform apply -auto-approve "$TF_PLAN_FILE"
                            dependencies:
                            - terraform_plan
                            when: manual
                            allow_failure: false
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'
                            tags:
                            - terraform
                            - prod
                            - protected

Apply contrôlé : flux opérationnel

Merge sur main
                            │
                            ▼
                            Pipeline prod
                            │
                            ├── validate
                            ├── security
                            └── plan
                            │
                            ▼
                            Plan relu
                            │
                            ▼
                            Approval environnement production
                            │
                            ▼
                            Job apply manuel
                            │
                            ▼
                            State lock
                            │
                            ▼
                            terraform apply
                            │
                            ▼
                            post-checks

Avant de cliquer Apply

Rollback : cas possibles

Rollback par commit précédent

Incident après apply
                            │
                            ▼
                            Identifier commit fautif
                            │
                            ▼
                            Créer revert commit
                            │
                            ▼
                            Pipeline terraform plan
                            │
                            ▼
                            Relire plan de rollback
                            │
                            ▼
                            Apply contrôlé
                            │
                            ▼
                            Vérifier service

Mitigation vs rollback

Runbook rollback minimal

1. Déclarer l'incident.
                            2. Identifier le dernier apply Terraform.
                            3. Lire le plan appliqué et le commit associé.
                            4. Vérifier l'impact : réseau, IAM, DB, compute.
                            5. Choisir : rollback commit, hotfix Terraform ou mitigation.
                            6. Générer un nouveau plan.
                            7. Faire relire le plan.
                            8. Appliquer.
                            9. Vérifier santé service.
                            10. Documenter postmortem.

Contrôles indispensables

Exemple de sécurité job

terraform_apply_prod:
                            stage: apply
                            when: manual
                            protected: true
                            environment:
                            name: production
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'
                            tags:
                            - protected
                            - prod

Threat model simple

Risque
                            │
                            ├── MR malveillante
                            ├── variable exposée
                            ├── runner compromis
                            ├── image CI compromise
                            ├── plan non relu
                            └── accès cloud trop large
                            │
                            ▼
                            Contrôles
                            ├── protected branches
                            ├── approvals
                            ├── masked variables
                            ├── least privilege IAM
                            ├── runner dédié
                            ├── scan IaC
                            └── audit logs

Outils sécurité liés

Problèmes fréquents

Commandes utiles

# Runner
                            gitlab-runner verify
                            gitlab-runner list

                            # Terraform
                            terraform --version
                            terraform providers
                            terraform init
                            terraform validate
                            terraform plan -refresh-only
                            terraform state list

                            # Lock, uniquement après analyse
                            terraform force-unlock LOCK_ID

Méthode de debug

Pipeline échoue
                            │
                            ▼
                            Identifier le job exact
                            │
                            ▼
                            Lire logs du haut vers le bas
                            │
                            ├── image utilisée
                            ├── variables disponibles
                            ├── dossier courant
                            ├── terraform init
                            ├── backend
                            └── provider error
                            │
                            ▼
                            Corriger la cause minimale
                            │
                            ▼
                            Relancer uniquement le job nécessaire

Checklist pipeline

Checklist avant apply production

Mini-cheat-sheet

terraform fmt -check -recursive
                            terraform init
                            terraform validate
                            terraform plan -out=tfplan
                            terraform show -no-color tfplan > plan.txt
                            terraform apply tfplan
                            terraform plan -refresh-only
                            terraform state list

Tableau de maturité

Nommage recommandé

project     = "ideo-platform"
                            environment = "prod"
                            region      = "eu-west-3"

                            name_prefix = "${project}-${environment}"

                            Exemples :
                            ideo-platform-dev-api
                            ideo-platform-staging-api
                            ideo-platform-prod-api

Architecture cible

Organisation Cloud / GitLab
                            │
                            ├── Dev
                            │     ├── compte/projet ou namespace dédié
                            │     ├── credentials dev
                            │     ├── state dev
                            │     └── budget limité
                            │
                            ├── Staging
                            │     ├── credentials staging
                            │     ├── state staging
                            │     ├── données anonymisées
                            │     └── pipeline contrôlé
                            │
                            └── Production
                            ├── credentials prod
                            ├── state prod
                            ├── variables protégées
                            ├── runner protégé
                            ├── approvals
                            ├── monitoring complet
                            └── runbooks incidents

Stratégie cloud

Mapping recommandé

Exemple rules GitLab

terraform_plan_prod:
                            stage: plan
                            environment:
                            name: production
                            script:
                            - terraform plan -var-file="prod.tfvars"
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'

                            terraform_apply_prod:
                            stage: apply
                            environment:
                            name: production
                            when: manual
                            script:
                            - terraform apply tfplan
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'

Flux GitLab recommandé

feature/*
                            │
                            ├── fmt
                            ├── validate
                            └── plan dev
                            │
                            ▼
                            Merge Request
                            │
                            ├── review code
                            ├── review plan
                            └── scan sécurité
                            │
                            ▼
                            release/*
                            │
                            └── apply staging manuel
                            │
                            ▼
                            main
                            │
                            ├── plan production
                            ├── approval
                            └── apply production manuel

Environnements protégés GitLab

Organisation recommandée

Exemple de variables par env

# dev.tfvars
                            environment   = "dev"
                            instance_type = "t3.micro"
                            min_capacity  = 1
                            max_capacity  = 2

                            # staging.tfvars
                            environment   = "staging"
                            instance_type = "t3.small"
                            min_capacity  = 1
                            max_capacity  = 3

                            # prod.tfvars
                            environment   = "prod"
                            instance_type = "t3.medium"
                            min_capacity  = 2
                            max_capacity  = 8

Diagramme secrets

GitLab variables
                            │
                            ├── DEV credentials
                            │     └── accessibles jobs dev
                            │
                            ├── STAGING credentials
                            │     └── accessibles jobs staging
                            │
                            └── PROD credentials
                            ├── masked
                            ├── protected
                            ├── scoped production
                            └── utilisables uniquement par runner protégé

Règles de sécurité

Backend keys recommandées

# Dev
                            key = "dev/network/terraform.tfstate"
                            key = "dev/app/terraform.tfstate"
                            key = "dev/data/terraform.tfstate"

                            # Staging
                            key = "staging/network/terraform.tfstate"
                            key = "staging/app/terraform.tfstate"
                            key = "staging/data/terraform.tfstate"

                            # Production
                            key = "prod/network/terraform.tfstate"
                            key = "prod/app/terraform.tfstate"
                            key = "prod/data/terraform.tfstate"

Pourquoi découper aussi par domaine ?

Mauvais vs bon modèle

Mauvais :
                            state-global.tfstate
                            ├── dev
                            ├── staging
                            ├── prod
                            ├── network
                            ├── app
                            └── data

                            Bon :
                            prod/network/terraform.tfstate
                            prod/app/terraform.tfstate
                            prod/data/terraform.tfstate

                            staging/network/terraform.tfstate
                            staging/app/terraform.tfstate
                            staging/data/terraform.tfstate

Remote state entre environnements

Éviter autant que possible que dev lise prod. Si un state doit lire un autre state, le couplage doit être volontaire, documenté et limité à des outputs non sensibles.

data "terraform_remote_state" "network" {
                            backend = "s3"

                            config = {
                            bucket = "company-terraform-state-prod"
                            key    = "prod/network/terraform.tfstate"
                            region = "eu-west-3"
                            }
                            }

Politique d’approbation

Exemple de règles pratiques

• Changement d’instance type en dev : validation légère.
• Ouverture de port en staging : review sécurité.
• Modification IAM prod : approval obligatoire.
• Modification database prod : fenêtre de changement + rollback.
• Suppression/recréation prod : justification écrite obligatoire.

Flux approval production

Merge Request
                            │
                            ▼
                            Pipeline plan production
                            │
                            ▼
                            Plan lisible en artifact
                            │
                            ▼
                            Review technique
                            ├── ressources créées
                            ├── ressources modifiées
                            ├── destroy / replace
                            ├── sécurité
                            └── rollback
                            │
                            ▼
                            Approval
                            │
                            ▼
                            Job apply manuel
                            │
                            ▼
                            Post-checks

Critères Go / No-Go

Flux de promotion

Feature branch
                            │
                            ├── fmt / validate / plan dev
                            │
                            ▼
                            Merge Request
                            │
                            ├── review code
                            ├── scan sécurité
                            └── review plan
                            │
                            ▼
                            Dev apply
                            │
                            ▼
                            Staging apply
                            │
                            ├── tests fonctionnels
                            ├── tests infra
                            ├── smoke tests
                            └── métriques
                            │
                            ▼
                            Production plan
                            │
                            ▼
                            Approval
                            │
                            ▼
                            Production apply
                            │
                            ▼
                            Post-checks

Pourquoi promouvoir progressivement ?

Exemple de stratégie de branches

feature/network-private-subnets
                            -> plan dev

                            develop
                            -> apply dev

                            release/2026-04-network
                            -> apply staging

                            main
                            -> plan production
                            -> approval
                            -> apply production

Artefacts utiles à chaque étape

Politique de données

Anonymisation : exemples

email:
                            john.smith@example.com -> user_12345@example.test

                            phone:
                            +33612345678 -> +33000000000

                            name:
                            John Smith -> User 12345

                            address:
                            10 Real Street -> 1 Test Street

                            free text:
                            supprimer ou remplacer si contient données personnelles

Flux de données sécurisé

Production database
                            │
                            ▼
                            Export contrôlé
                            │
                            ▼
                            Anonymisation / masking
                            │
                            ▼
                            Validation sécurité
                            │
                            ▼
                            Import staging
                            │
                            ▼
                            Tests fonctionnels et performance

Règles professionnelles

Scénarios réels

Réaction en cas d’erreur d’environnement

Erreur détectée
                            │
                            ▼
                            Stopper pipeline si encore actif
                            │
                            ▼
                            Identifier environnement réellement touché
                            │
                            ├── state utilisé
                            ├── credentials utilisés
                            ├── backend key
                            ├── branch / commit
                            └── runner
                            │
                            ▼
                            Évaluer impact
                            ├── ressources modifiées
                            ├── données touchées
                            ├── sécurité
                            └── disponibilité
                            │
                            ▼
                            Mitigation / rollback
                            │
                            ▼
                            Postmortem et correction garde-fous

Garde-fou simple dans pipeline

echo "Target environment: $CI_ENVIRONMENT_NAME"
                            echo "Terraform root: $TF_ROOT"
                            echo "Backend key: $TF_STATE_KEY"

                            if [ "$CI_ENVIRONMENT_NAME" = "production" ] && [ "$CI_COMMIT_BRANCH" != "main" ]; then
                            echo "Production deploy is only allowed from main."
                            exit 1
                            fi

Checklist structure

Checklist production

Mini-cheat-sheet

feature/*  -> dev / review
                            develop    -> dev partagé
                            release/*  -> staging
                            main       -> production

                            dev:
                            apply rapide, droits limités

                            staging:
                            plan + review + tests

                            prod:
                            plan archivé + approval + apply manuel + post-checks

Options importantes

Exemples de noms

# Dev
                            AWS_ACCESS_KEY_ID_DEV
                            AWS_SECRET_ACCESS_KEY_DEV

                            # Staging
                            AWS_ACCESS_KEY_ID_STAGING
                            AWS_SECRET_ACCESS_KEY_STAGING

                            # Production
                            AWS_ACCESS_KEY_ID_PROD
                            AWS_SECRET_ACCESS_KEY_PROD

                            # Terraform variables
                            TF_VAR_project
                            TF_VAR_environment
                            TF_VAR_db_password

Bon usage dans un job

terraform_plan_prod:
                            stage: plan
                            environment:
                            name: production
                            script:
                            - terraform init
                            - terraform plan -var-file="prod.tfvars"
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'

Mauvais usage

# Mauvais : secret dans le YAML
                            variables:
                            AWS_SECRET_ACCESS_KEY: "my-secret-value"

                            # Mauvais : affichage dans les logs
                            script:
                            - echo "$AWS_SECRET_ACCESS_KEY"

Règles concrètes

Mapping recommandé

Séparation branche / environnement

feature/*
                            │
                            └── pas de secrets prod

                            develop
                            │
                            └── secrets dev

                            release/*
                            │
                            └── secrets staging

                            main
                            │
                            └── secrets production
                            ├── masked
                            ├── protected
                            └── environment scoped

Garde-fou dans le pipeline

check_environment_safety:
                            stage: validate
                            script:
                            - echo "Branch: $CI_COMMIT_BRANCH"
                            - echo "Environment: $CI_ENVIRONMENT_NAME"
                            - |
                            if [ "$CI_ENVIRONMENT_NAME" = "production" ] && [ "$CI_COMMIT_BRANCH" != "main" ]; then
                            echo "Production jobs are only allowed from main."
                            exit 1
                            fi

Erreur classique

Variable globale :
                            AWS_SECRET_ACCESS_KEY_PROD

                            Disponible dans :
                            ├── feature/*
                            ├── develop
                            ├── release/*
                            └── main

                            Résultat :
                            une MR ou un job non protégé peut exposer ou utiliser le secret prod.

Pourquoi OIDC est préférable

Flux OIDC

GitLab job
                            │
                            ▼
                            Demande un ID token OIDC
                            │
                            ▼
                            Cloud IAM vérifie :
                            ├── projet GitLab
                            ├── branche
                            ├── environnement
                            ├── audience
                            └── claims autorisés
                            │
                            ▼
                            Cloud émet credentials temporaires
                            │
                            ▼
                            Terraform plan/apply
                            │
                            ▼
                            Credentials expirent automatiquement

Exemple conceptuel AWS STS

assume_role_with_web_identity:
                            stage: validate
                            id_tokens:
                            GITLAB_OIDC_TOKEN:
                            aud: https://gitlab.com
                            script:
                            - echo "Exchange OIDC token for temporary cloud credentials"
                            - echo "Run terraform with short-lived credentials"

Contrôles à mettre dans la trust policy

Stratégie de rôles

Least privilege : principes

• Séparer dev, staging et production.
• Séparer plan et apply si possible.
• Limiter les actions aux services réellement utilisés.
• Limiter les ressources par nom, tags, région ou compte.
• Éviter les wildcards * sauf justification.
• Auditer régulièrement les permissions inutilisées.

IAM trop large : mauvais exemple

{
                            "Effect": "Allow",
                            "Action": "*",
                            "Resource": "*"
                            }

Approche plus contrôlée

{
                            "Effect": "Allow",
                            "Action": [
                            "ec2:Describe*",
                            "ec2:CreateTags",
                            "elasticloadbalancing:Describe*",
                            "rds:Describe*"
                            ],
                            "Resource": "*"
                            }

Blast radius

Credential CI compromis
                            │
                            ▼
                            Si IAM large :
                            └── impact compte cloud complet

                            Si IAM limité :
                            ├── actions limitées
                            ├── ressources limitées
                            ├── environnement limité
                            └── durée limitée si OIDC/STS

Solutions fréquentes

Quand sortir de GitLab variables ?

• Beaucoup de secrets ou beaucoup de projets.
• Besoin d’audit centralisé.
• Besoin de rotation automatique.
• Besoin de credentials dynamiques et temporaires.
• Exigences conformité ou séparation forte des responsabilités.

Flux Secret Manager

GitLab Runner
                            │
                            ├── s'authentifie via OIDC / rôle court
                            │
                            ▼
                            Secret Manager / Vault
                            │
                            ├── vérifie identité
                            ├── vérifie policy
                            ├── journalise l'accès
                            └── retourne secret ou credential temporaire
                            │
                            ▼
                            Job CI/CD
                            │
                            └── utilise le secret sans le stocker dans Git

Rotation

Mauvais exemples

# Mauvais : affiche le secret
                            script:
                            - echo "$AWS_SECRET_ACCESS_KEY"

                            # Mauvais : debug shell trop bavard
                            script:
                            - set -x
                            - terraform plan

                            # Mauvais : dump d'environnement
                            script:
                            - env
                            - printenv

Meilleure approche

script:
                            - echo "Terraform plan started"
                            - terraform plan -var-file="prod.tfvars"
                            - echo "Terraform plan completed"

Risques logs

Commande de debug plus sûre

# Vérifier seulement la présence
                            if [ -z "$AWS_ACCESS_KEY_ID" ]; then
                            echo "AWS_ACCESS_KEY_ID is missing"
                            exit 1
                            else
                            echo "AWS_ACCESS_KEY_ID is present"
                            fi

Variable sensible

variable "database_password" {
                            description = "Database password."
                            type        = string
                            sensitive   = true
                            }

Output sensible

output "database_password" {
                            value     = var.database_password
                            sensitive = true
                            }

Ce qu’il faut protéger

Flux recommandé

Secret Manager
                            │
                            ▼
                            Application runtime
                            │
                            └── récupère secret au démarrage
                            ou via injection sécurisée

                            Terraform
                            │
                            ├── crée l'infrastructure
                            ├── crée éventuellement la référence au secret
                            └── évite de manipuler la valeur brute

Exemple : référence plutôt que valeur

variable "database_password_secret_name" {
                            description = "Name of the secret storing DB password."
                            type        = string
                            }

                            # Terraform configure l'application avec le nom du secret,
                            # pas forcément avec sa valeur brute.

Checklist Terraform secrets

Scénarios classiques

Réponse incident

Fuite suspectée
                            │
                            ▼
                            Stopper exposition
                            ├── supprimer variable/log/artifact si possible
                            ├── bloquer pipeline compromis
                            └── désactiver credential
                            │
                            ▼
                            Rotation
                            ├── créer nouveau secret
                            ├── mettre à jour CI/CD
                            ├── invalider ancien secret
                            └── vérifier services
                            │
                            ▼
                            Investigation
                            ├── qui a eu accès ?
                            ├── depuis quand ?
                            ├── quelles actions cloud ?
                            └── quels logs/audits ?
                            │
                            ▼
                            Postmortem et prévention

Runbook de rotation rapide

1. Identifier le secret exposé.
                            2. Déterminer son périmètre : dev, staging, prod.
                            3. Révoquer ou désactiver l’ancien secret.
                            4. Créer un nouveau secret avec droits minimaux.
                            5. Mettre à jour GitLab/Vault/Secret Manager.
                            6. Relancer pipeline de validation.
                            7. Vérifier que les services fonctionnent.
                            8. Auditer les logs d’utilisation.
                            9. Nettoyer logs/artifacts si possible.
                            10. Documenter cause et prévention.

Priorité selon criticité

Checklist GitLab

Checklist IAM

Checklist Terraform

Mini-cheat-sheet

# À faire
                            - masked variables
                            - protected variables
                            - environment scopes
                            - runner protégé
                            - IAM least privilege
                            - OIDC / credentials temporaires
                            - secret detection
                            - rotation documentée

                            # À éviter
                            - secrets dans Git
                            - echo $SECRET
                            - env / printenv en CI
                            - IAM admin
                            - variables prod globales
                            - artifacts contenant .tfstate ou .env

Workflow standard production

1. Créer une demande de changement ou ticket technique.
2. Décrire le besoin, le périmètre et le risque.
3. Créer une branche Git dédiée.
4. Modifier le code Terraform ou la configuration CI/CD.
5. Lancer terraform fmt, validate, scan sécurité et plan.
6. Relire le plan en merge request.
7. Identifier destructions, remplacements, ouvertures réseau, IAM, database.
8. Obtenir approval selon criticité.
9. Appliquer dans une fenêtre adaptée.
10. Vérifier santé cloud, applicative, logs, métriques et alertes.
11. Documenter résultat, anomalies et suites éventuelles.

Pipeline type

MR pipeline
                            │
                            ├── lint
                            ├── validate
                            ├── security
                            └── plan
                            │
                            ▼
                            Review humaine
                            │
                            ▼
                            Merge vers main
                            │
                            ▼
                            Production pipeline
                            │
                            ├── plan final
                            ├── approval
                            ├── apply manuel
                            └── post-checks

Responsabilités

Template de change request

Titre :
                            Ajouter un nouveau target group pour l'API publique

                            Objectif :
                            Préparer le routage vers la nouvelle version API.

                            Environnement :
                            production

                            Périmètre :
                            Load balancer, listener rule, target group, health check.

                            Risque :
                            Mauvais routage ou health check incorrect.

                            Plan de validation :
                            - terraform plan relu
                            - health check /health/
                            - test HTTP 200 sur endpoint API
                            - logs 5xx surveillés

                            Rollback / mitigation :
                            - désactiver nouvelle listener rule
                            - revenir au commit précédent
                            - appliquer plan de rollback validé

                            Fenêtre :
                            Hors pic trafic, présence DevOps + backend engineer.

Classification du risque

Questions à poser avant de coder

Commandes recommandées

terraform fmt -check -recursive
                            terraform validate
                            terraform plan -var-file="prod.tfvars" -out="tfplan"
                            terraform show -no-color tfplan > plan.txt

Lecture du plan

Checklist de review du plan

Diagramme décisionnel

Plan généré
                            │
                            ▼
                            Contient destroy / replace ?
                            │
                            ├── Oui : justification + approval renforcé
                            └── Non
                            │
                            ▼
                            Touche réseau / IAM / DB ?
                            │
                            ├── Oui : review senior / sécurité
                            └── Non
                            │
                            ▼
                            Plan cohérent ?
                            │
                            ├── Oui : apply contrôlé
                            └── Non : correction avant merge

Quand prévoir une fenêtre ?

Préparation fenêtre

• Plan validé et archivé.
• Rollback ou mitigation écrit.
• Personnes clés disponibles.
• Monitoring ouvert avant apply.
• Canal de communication prêt.
• Pas de changement concurrent critique.

Timeline type

T-30 min
                            ├── vérifier pipeline vert
                            ├── ouvrir dashboards
                            ├── confirmer présence équipe
                            └── annoncer début fenêtre

                            T0
                            ├── déclencher apply
                            └── surveiller logs Terraform

                            T+5 min
                            ├── vérifier cloud resources
                            ├── health checks
                            └── métriques initiales

                            T+15 min
                            ├── vérifier erreurs 5xx
                            ├── vérifier latence
                            └── confirmer absence alertes

                            T+30 min
                            ├── clôturer changement
                            └── documenter résultat

Communication minimale

Début :
                            Changement infra PROD démarré.
                            Périmètre : Load balancer API.
                            Risque : routage HTTP.
                            Rollback : listener rule précédente.

                            Fin :
                            Changement terminé.
                            Health checks OK.
                            5xx stable.
                            Aucune alerte critique.
                            Surveillance prolongée 30 minutes.

Commande recommandée

terraform plan -out="tfplan" -var-file="prod.tfvars"
                            terraform apply "tfplan"

Appliquer le fichier tfplan évite qu’un plan différent soit recalculé au moment de l’apply.

Job GitLab apply protégé

terraform_apply_prod:
                            stage: apply
                            environment:
                            name: production
                            script:
                            - terraform apply "tfplan"
                            dependencies:
                            - terraform_plan_prod
                            when: manual
                            allow_failure: false
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'
                            tags:
                            - terraform
                            - prod
                            - protected

Avant de lancer Apply

Pendant l’apply

• Surveiller les ressources modifiées.
• Ne pas interrompre brutalement sauf nécessité.
• Noter toute erreur, timeout ou ressource partielle.
• Ne pas relancer plusieurs applies en parallèle.
• En cas de lock, comprendre avant de déverrouiller.

Ce qu’il faut regarder après apply

Commandes exemples

curl -fsS https://example.com/health/
                            curl -fsS https://example.com/api/status/

                            terraform output
                            terraform state list

                            # Exemples Linux
                            journalctl -u app.service -n 100 --no-pager
                            tail -n 100 /var/log/nginx/error.log

Diagramme vérification

Apply terminé
                            │
                            ▼
                            Contrôle cloud
                            │
                            ▼
                            Contrôle applicatif
                            │
                            ├── healthcheck
                            ├── endpoint critique
                            └── parcours métier
                            │
                            ▼
                            Contrôle observabilité
                            ├── logs
                            ├── metrics
                            ├── traces
                            └── alertes
                            │
                            ▼
                            Décision
                            ├── OK : clôture changement
                            └── KO : mitigation / rollback

Post-check GitLab

post_deploy_checks:
                            stage: post_check
                            image: alpine:latest
                            before_script:
                            - apk add --no-cache curl
                            script:
                            - curl -fsS https://example.com/health/
                            - curl -fsS https://example.com/api/status/
                            needs:
                            - terraform_apply_prod
                            rules:
                            - if: '$CI_COMMIT_BRANCH == "main"'

Rollback possible selon changement

Rollback par revert Git

git revert <commit_id>
                            git push origin main

                            # Pipeline :
                            terraform plan -out=tfplan
                            # Review du plan de rollback
                            terraform apply tfplan

Runbook rollback minimal

Incident post-apply
                            │
                            ▼
                            Déclarer l'incident
                            │
                            ▼
                            Identifier impact
                            ├── utilisateurs
                            ├── services
                            ├── réseau
                            ├── données
                            └── sécurité
                            │
                            ▼
                            Choisir action
                            ├── rollback Git/Terraform
                            ├── hotfix Terraform
                            ├── mitigation manuelle contrôlée
                            └── restore backup
                            │
                            ▼
                            Planifier action
                            │
                            ▼
                            Appliquer correction
                            │
                            ▼
                            Vérifier récupération
                            │
                            ▼
                            Postmortem

Mitigation d’urgence

Cas 1 : changement security group DB

Cas 2 : ajout autoscaling

Cas 3 : changement DNS

Cas 4 : modification RDS

Avant merge

Avant apply production

Après apply

Logs à collecter

Bon log structuré

{
                            "level": "error",
                            "service": "api",
                            "environment": "prod",
                            "request_id": "req-8f31",
                            "trace_id": "tr-91ab",
                            "user_id": "u_12345",
                            "route": "/api/orders",
                            "status_code": 500,
                            "duration_ms": 842,
                            "error": "database_timeout"
                            }

Bonnes pratiques logs

Commandes utiles Linux

journalctl -u nginx -n 100 --no-pager
                            journalctl -u app.service -f
                            tail -f /var/log/nginx/access.log
                            tail -f /var/log/nginx/error.log
                            grep " 500 " /var/log/nginx/access.log

Golden signals

Métriques système

Métriques applicatives et DB

Diagramme métriques → décision

Métrique collectée
                            │
                            ▼
                            Dashboard
                            │
                            ├── tendance normale
                            ├── pic temporaire
                            └── anomalie durable
                            │
                            ▼
                            Alerte si seuil + durée + impact
                            │
                            ▼
                            Investigation logs / traces
                            │
                            ▼
                            Action : scale, rollback, fix, mitigation

Exemple de trace

Request: POST /api/orders
                            │
                            ├── API Gateway               12 ms
                            ├── Auth service              28 ms
                            ├── Order API                120 ms
                            │     ├── PostgreSQL query    85 ms
                            │     ├── Redis cache          4 ms
                            │     └── Payment API        410 ms
                            └── Response total           590 ms

Ce qu’une trace révèle

Outils de tracing

Traces + logs

trace_id = tr-91ab
                            │
                            ├── visible dans la trace APM
                            ├── présent dans les logs API
                            ├── présent dans les logs worker
                            └── utilisé pour rechercher l'incident complet

Tableau d’alertes production

Niveaux d’alerte

Diagramme anti-bruit

Signal brut
                            │
                            ▼
                            Seuil + durée
                            │
                            ▼
                            Impact utilisateur ?
                            │
                            ├── Non : dashboard / warning
                            └── Oui : alerte critique
                            │
                            ▼
                            Runbook associé
                            │
                            ▼
                            Action humaine claire

Exemple règle Prometheus

- alert: HighHttp5xxRate
                            expr: rate(http_requests_total{status=~"5.."}[5m]) 
                            / rate(http_requests_total[5m]) > 0.02
                            for: 5m
                            labels:
                            severity: critical
                            annotations:
                            summary: "High HTTP 5xx rate"
                            runbook: "https://runbooks.example.com/http-5xx"

Dashboard minimal production

Organisation recommandée

Dashboard global
                            │
                            ├── Service health
                            ├── Errors / latency
                            ├── Traffic
                            └── Recent changes

                            Dashboards spécialisés
                            ├── API
                            ├── Database
                            ├── Workers
                            ├── Infrastructure
                            ├── CI/CD
                            └── Security / Audit

Bon design de dashboard

Exemple de panneaux

Production Overview
                            - Availability
                            - Requests per second
                            - HTTP 5xx rate
                            - Latency p95 / p99
                            - Top slow endpoints
                            - Database connections
                            - Queue backlog
                            - Last deployment
                            - Active critical alerts

Cas 1 : hausse des erreurs 5xx après déploiement

Cas 2 : saturation disque

Cas 3 : base de données lente

Cas 4 : pipeline Terraform échoué

Stack open source fréquente

Stack SaaS fréquente

Architecture type

Applications / Infra
                            │
                            ├── exporters
                            ├── agents
                            ├── SDK OpenTelemetry
                            └── log shippers
                            │
                            ▼
                            Collecte
                            ├── Prometheus
                            ├── Fluent Bit / Vector
                            ├── OpenTelemetry Collector
                            └── Cloud agents
                            │
                            ▼
                            Stockage / plateforme
                            ├── Grafana stack
                            ├── ELK / OpenSearch
                            ├── Datadog
                            └── Cloud native monitoring
                            │
                            ▼
                            Dashboards + Alerts + Incident response

Choix rapide

Checklist minimale avant go-live

Checklist après déploiement

Mini-cheat-sheet

# Logs
                            journalctl -u app.service -f
                            tail -f /var/log/nginx/error.log

                            # HTTP
                            curl -fsS https://example.com/health/

                            # Métriques clés
                            HTTP 5xx rate
                            Latency p95 / p99
                            CPU / RAM / Disk
                            DB connections / slow queries
                            Queue backlog
                            Pipeline failures

                            # Alertes minimales
                            Service down
                            5xx high
                            Disk > 85%
                            DB connections high
                            Queue backlog high
                            Prod pipeline failed

Table de sévérité

Critères de qualification

Décision rapide

Incident détecté
                            │
                            ▼
                            Impact utilisateur réel ?
                            │
                            ├── Non : SEV-3 / SEV-4 possible
                            └── Oui
                            │
                            ▼
                            Service critique touché ?
                            │
                            ├── Oui : SEV-1 ou SEV-2
                            └── Non : SEV-2 ou SEV-3
                            │
                            ▼
                            Données ou sécurité impliquées ?
                            │
                            ├── Oui : escalade immédiate
                            └── Non : mitigation standard

Rôles recommandés

Organisation du canal incident

#incident-sev1-api
                            │
                            ├── Incident Commander
                            ├── DevOps
                            ├── Backend engineer
                            ├── Database expert
                            ├── Communications lead
                            └── Scribe
                            │
                            ▼
                            Messages courts :
                            ├── observation
                            ├── hypothèse
                            ├── action proposée
                            ├── décision
                            └── résultat

Règles de canal

Méthode en 6 étapes

1. Qualifier : identifier qui est impacté, quel service est touché, depuis quand, avec quelle gravité.
2. Stabiliser : stopper les déploiements, éviter les changements concurrents, empêcher l’incident de s’étendre.
3. Mitiger : rollback, restart contrôlé, scale, bypass, désactivation feature flag, correction minimale.
4. Communiquer : envoyer des messages courts, factuels, réguliers, sans spéculation excessive.
5. Restaurer : vérifier retour au nominal par métriques, logs, health checks, parcours métier.
6. Analyser : cause racine, facteurs contributifs, actions préventives, suivi post-mortem.

Actions rapides possibles

Flux opérationnel

Détection
                            │
                            ▼
                            Triage rapide
                            ├── impact
                            ├── gravité
                            ├── service
                            └── changement récent
                            │
                            ▼
                            Hypothèse principale
                            │
                            ├── app release ?
                            ├── Terraform apply ?
                            ├── DB saturation ?
                            ├── provider externe ?
                            └── réseau / IAM ?
                            │
                            ▼
                            Action réversible
                            │
                            ▼
                            Mesure du résultat
                            │
                            ├── amélioration : continuer stabilisation
                            └── pas d'effet : nouvelle hypothèse
                            │
                            ▼
                            Retour nominal
                            │
                            ▼
                            RCA et prévention

Commandes utiles en première analyse

# HTTP
                            curl -fsS https://example.com/health/

                            # Linux services
                            systemctl status app.service
                            journalctl -u app.service -n 100 --no-pager

                            # Nginx
                            tail -n 100 /var/log/nginx/error.log
                            grep " 500 " /var/log/nginx/access.log | tail

                            # Terraform
                            terraform plan -refresh-only
                            terraform state list

                            # Disk / system
                            df -h
                            free -m
                            top

Exemple de chronologie SEV-1

Format de note chronologique

[21:04] Alerte HighHttp5xxRate déclenchée.
                            [21:06] Dashboard API confirme 5xx à 4.8%.
                            [21:08] Incident SEV-1 déclaré. IC: Alice.
                            [21:10] Dernier deploy API identifié : commit abc123.
                            [21:12] Décision : rollback API vers version précédente.
                            [21:16] Rollback terminé.
                            [21:20] 5xx revenus sous 0.2%.
                            [21:25] Health checks OK.
                            [21:35] Communication : service stabilisé.
                            [22:00] Début RCA.

À noter systématiquement

Catalogue de mitigations

Diagramme de décision mitigation

Incident actif
                            │
                            ▼
                            Cause probable liée à un changement récent ?
                            │
                            ├── Oui
                            │     ├── rollback app
                            │     ├── revert Terraform
                            │     └── désactiver feature flag
                            │
                            └── Non
                            ├── scale temporaire
                            ├── bypass dépendance
                            ├── redémarrage contrôlé
                            ├── restauration connectivité
                            └── mode dégradé
                            │
                            ▼
                            Mesurer impact
                            │
                            ├── amélioration : stabiliser
                            └── pas d'amélioration : nouvelle hypothèse

Actions à éviter en urgence

Règles de communication

Message initial interne

Incident SEV-2 en cours sur API production.
                            Impact confirmé : hausse des erreurs 5xx sur /api/orders.
                            Début estimé : 14:06.
                            Action en cours : analyse dernier déploiement et logs applicatifs.
                            Prochain update : dans 10 minutes.

Messages de suivi

Update 14:20 :
                            Cause probable identifiée : release API 2026.04.29-3.
                            Action : rollback vers version précédente en cours.
                            Les erreurs 5xx restent élevées mais stables.
                            Prochain update : 14:30.

                            Update 14:32 :
                            Rollback terminé.
                            Les 5xx sont revenus sous le seuil normal.
                            Surveillance prolongée pendant 30 minutes.
                            Post-mortem suivra.

Communication externe éventuelle

Nous observons actuellement une dégradation sur une partie des appels API.
                            Notre équipe a identifié le problème et applique une mesure de mitigation.
                            Nous publierons une mise à jour dès que le service sera pleinement stabilisé.

Symptôme vs cause racine

Méthode des 5 pourquoi

Pourquoi l'API était lente ?
                            -> PostgreSQL répondait lentement.

                            Pourquoi PostgreSQL répondait lentement ?
                            -> Une requête faisait un scan complet.

                            Pourquoi la requête faisait un scan complet ?
                            -> Un index manquait sur une colonne filtrée.

                            Pourquoi l'index manquait ?
                            -> La migration n'a pas été revue côté performance.

                            Pourquoi ce risque n'a pas été détecté ?
                            -> Pas de test sur volume représentatif en staging.

Facteurs contributifs

Diagramme RCA

Incident
                            │
                            ▼
                            Impact utilisateur
                            │
                            ▼
                            Symptôme visible
                            │
                            ▼
                            Cause technique immédiate
                            │
                            ▼
                            Cause technique profonde
                            │
                            ▼
                            Facteurs contributifs
                            ├── tests absents
                            ├── alerte absente
                            ├── review insuffisante
                            └── runbook manquant
                            │
                            ▼
                            Actions préventives vérifiables

Template post-mortem

# Incident : titre court

                            ## Résumé
                            - Date :
                            - Durée :
                            - Gravité :
                            - Services concernés :
                            - Statut final :

                            ## Impact
                            - Utilisateurs touchés :
                            - Fonctionnalités touchées :
                            - Impact métier :
                            - Données impactées :
                            - Impact sécurité :

                            ## Chronologie
                            - HH:MM Détection
                            - HH:MM Qualification
                            - HH:MM Première mitigation
                            - HH:MM Retour partiel
                            - HH:MM Retour nominal
                            - HH:MM Fin surveillance

                            ## Cause racine
                            - Cause technique :
                            - Cause process :
                            - Facteurs contributifs :

                            ## Ce qui a bien fonctionné
                            - ...

                            ## Ce qui doit être amélioré
                            - ...

                            ## Actions préventives
                            - [ ] Action 1 - Owner - Date
                            - [ ] Action 2 - Owner - Date
                            - [ ] Action 3 - Owner - Date

Qualité des actions post-mortem

Actions préventives typiques

• Ajouter une alerte plus précoce.
• Ajouter un test de pipeline ou smoke test.
• Renforcer la review Terraform sur réseau/IAM/DB.
• Ajouter un garde-fou policy-as-code.
• Documenter le rollback.
• Réduire le blast radius.
• Ajouter dashboard spécifique.
• Automatiser une vérification manuelle répétitive.

Tableau de cas fréquents

Cas détaillé : security group trop restrictif

Changement Terraform
                            │
                            ▼
                            Security group DB modifié
                            │
                            ▼
                            API ne peut plus joindre PostgreSQL
                            │
                            ▼
                            Symptômes
                            ├── 500 API
                            ├── logs database connection refused
                            ├── healthcheck KO
                            └── hausse latence
                            │
                            ▼
                            Mitigation
                            ├── restaurer règle SG précédente
                            ├── apply correctif minimal
                            └── vérifier connexion API → DB
                            │
                            ▼
                            Prévention
                            ├── review plan réseau
                            ├── test connectivité post-apply
                            ├── policy anti-ouverture/fermeture critique
                            └── runbook rollback SG

Cas détaillé : disque saturé

Symptômes :
                            - Erreurs écriture logs
                            - Service instable
                            - DB ou app ne peut plus créer fichiers temporaires

                            Commandes :
                            df -h
                            du -sh /var/log/*
                            journalctl --disk-usage

                            Mitigation :
                            - Nettoyage contrôlé
                            - Rotation logs
                            - Extension volume
                            - Restart uniquement si nécessaire

                            Prévention :
                            - Alerte disque 75/85/95%
                            - logrotate
                            - quotas/rétention
                            - dashboard stockage

Checklist pendant incident

Checklist technique rapide

[ ] Healthcheck KO ou OK ?
                            [ ] 5xx / 4xx anormaux ?
                            [ ] Latence p95 / p99 ?
                            [ ] Dernier déploiement ?
                            [ ] Dernier Terraform apply ?
                            [ ] DB connexions / locks / slow queries ?
                            [ ] Disque / CPU / RAM ?
                            [ ] Queue backlog ?
                            [ ] Provider externe ?
                            [ ] DNS / certificat / load balancer ?
                            [ ] Security group / IAM ?

Checklist après incident

Mini-cheat-sheet incident

1. Déclarer incident + gravité.
                            2. Nommer Incident Commander.
                            3. Qualifier impact.
                            4. Chercher changement récent.
                            5. Mitiger avec action réversible.
                            6. Mesurer effet.
                            7. Communiquer régulièrement.
                            8. Confirmer retour nominal.
                            9. Écrire post-mortem.
                            10. Fermer actions préventives.