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_daysavait 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)