Aller au contenu

PD-4 — Rétrospective

1. Contexte

Champ Valeur
Story ID PD-4
Titre Buckets OVH S3 avec Object Lock WORM
Domaine storage
Projet infra
Date complétion 2025-01-XX
Verdict ACCEPTÉ AVEC RÉSERVES

2. Métriques

Métrique Valeur
Écarts majeurs 0
Écarts mineurs 5
Points fluides 12
Points difficiles 5

3. Learnings clés

  • Les défauts de variables Terraform peuvent diverger de la spec : La variable lifecycle_transition_days avait un défaut de 1 jour alors que la spec demandait 90 jours. Les défauts doivent être alignés sur la spec.

  • SSE-S3 peut suffire avec chiffrement client : Le choix SSE-S3 au lieu de SSE-KMS est justifiable car le backend applique déjà un chiffrement client-side (AES-256-GCM avec K_doc).

  • Object Lock COMPLIANCE est irréversible : Une fois configuré, impossible de le désactiver ou réduire la rétention. Tests en dev avec rétention courte critiques.

  • La purge post-rétention nécessite procédure manuelle : Object Lock empêche toute expiration automatique. S3 Batch Operations requis même après expiration rétention.

  • Le module doit couvrir tous les buckets de la spec : L'absence du bucket backups GOVERNANCE crée une dette technique.

4. Patterns applicables

Nouveau pattern : Module Terraform WORM complet

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

  # Sous-modules par région
  paris     = module.paris
  frankfurt = module.frankfurt

  # Object Lock COMPLIANCE obligatoire
  object_lock_enabled       = true
  object_lock_mode          = "COMPLIANCE"
  object_lock_retention     = var.retention_years

  # Protections critiques
  prevent_destroy           = true
  versioning_enabled        = true
  block_public_access       = true
  bucket_owner_enforced     = true
}

Pattern confirmé : Bucket policies WORM

# DenyAllDeletes + HTTPSOnly = standard WORM
statement {
  sid       = "DenyAllDeletes"
  effect    = "Deny"
  actions   = ["s3:DeleteObject", "s3:DeleteObjectVersion"]
  resources = ["${aws_s3_bucket.this.arn}/*"]
  principals { type = "*" identifiers = ["*"] }
}

5. Signal CLAUDE.md

Priorité moyenne : Aligner défauts variables Terraform sur spec.

### Terraform — Défauts de variables (2026-02-XX)

**RÈGLE** : Les défauts de variables DOIVENT correspondre aux valeurs spec, pas aux valeurs dev.

**Exemple PD-4** :
- Spec : transition Glacier à J+90
- Variable : `lifecycle_transition_days` défaut = 1 (dev)
- Problème : Prod sans override → coûts Glacier immédiats

**Solution** :
```hcl
variable "lifecycle_transition_days" {
  type        = number
  default     = 90  # Valeur SPEC, pas dev
  description = "Jours avant transition vers Glacier (spec: 90)"
}
```

6. Conclusion

PD-4 a livré l'infrastructure S3 WORM avec Object Lock COMPLIANCE, versioning, bucket policies restrictives et monitoring. Les 5 écarts mineurs (SSE-S3 vs KMS, défaut J+1, bucket backups absent, rétention fixe, IAM roles) illustrent l'importance d'aligner variables Terraform sur spec et de couvrir tous les composants spécifiés. Le pattern module WORM est réutilisable pour PD-5 (Glacier) et PD-6 (CRR).


Rétrospective générée 2026-02-19 (Étape 10 batch storage)