PD-5 — Retour d'expérience¶
📚 Navigation User Story
| Document | | | ---------- | -- | | 📋 [Spécification](PD-5-specification.md) | | | 🛠️ [Plan d'implémentation](PD-5-plan.md) | | | ✅ [Critères d'acceptation](PD-5-acceptability.md) | | | 📝 **Retour d'expérience** | *(ce document)* | [← Retour à storage](../PD-198-epic.md) · [↑ Index User Story](index.md)1. Résumé exécutif¶
La User Story PD-5 visait à configurer AWS Glacier Deep Archive en région Paris avec Object Lock COMPLIANCE et Vault Lock pour l'archivage probatoire long terme (10-50 ans). L'implémentation fournit un module Terraform worm_glacier avec sous-modules (paris, frankfurt, monitoring), Object Lock COMPLIANCE, versioning, lifecycle transitions vers Deep Archive, et monitoring CloudWatch complet. Cependant, 1 écart MAJEUR est identifié : Vault Lock absent (seul Object Lock COMPLIANCE configuré), ainsi que 2 écarts MINEURS : transition à J+1 au lieu de J+90, et SSE-S3 au lieu de SSE-KMS dédié. Verdict : ACCEPTÉ AVEC RÉSERVES.
2. Points fluides¶
- Object Lock COMPLIANCE : mode COMPLIANCE correctement configuré avec rétention paramétrable
- Versioning activé : prérequis Object Lock respecté
- Lifecycle Deep Archive : transition automatique vers DEEP_ARCHIVE configurable via variable
- Noncurrent version transition : anciennes versions vers Deep Archive après 30 jours
- CloudWatch monitoring : alertes S3 errors (4xx), replication latency, failed/pending operations
- SNS notifications : topic dédié avec chiffrement KMS pour alertes
- CloudWatch Dashboard : vue consolidée CRR avec métriques Paris/Frankfurt
- Module modulaire : organisation paris/frankfurt/monitoring avec providers multi-région
- Variables validées : retention_years 1-100, lifecycle_transition_days 0-365
- abort_incomplete_multipart : nettoyage uploads incomplets après 7 jours
- prevent_destroy : protection Terraform contre suppression accidentelle
- Tags conformité : NF-Z42-013, ISO-14641, RetentionMax documentés
3. Points difficiles¶
| Difficulté | Contexte |
|---|---|
| Vault Lock absent | Spec demande Vault Lock "In Effect", seul Object Lock COMPLIANCE implémenté |
| Défaut transition J+1 | Variable lifecycle_transition_days défaut à 1, spec mentionne J+90 en tests |
| SSE-KMS non implémenté | SSE-S3 (AES256) utilisé au lieu de SSE-KMS avec clé dédiée Paris |
| Différence Object Lock vs Vault Lock | Object Lock = par objet, Vault Lock = policy immuable sur vault |
| Restoration time Glacier | 12-48h non testable automatiquement |
4. Hypothèses révélées tardivement¶
| Hypothèse initiale | Réalité découverte |
|---|---|
| Vault Lock = Object Lock | FAUX — Vault Lock est une ressource séparée (aws_glacier_vault_lock) |
| SSE-KMS obligatoire | FAUX — SSE-S3 suffisant car chiffrement client déjà appliqué |
| Transition J+90 par défaut | FAUX — Défaut J+1 pour optimiser coûts dev, override en prod |
| S3 Object Lock = Glacier Vault Lock | FAUX — Deux mécanismes distincts, spec demande les deux |
| CloudWatch metrics automatiques | VRAI — S3 publie automatiquement vers CloudWatch |
5. Invariants complexes à implémenter¶
| Invariant | Complexité |
|---|---|
| Vault Lock irréversible | complete_lock = true rend la policy permanente, aucun retour possible |
| Object Lock COMPLIANCE | Mode ne peut pas être réduit ou bypassé, même par root |
| Rétention 10-50 ans | Durées multi-décennales, coûts et gouvernance sur long terme |
| Deep Archive restoration | 12-48h délai, incompatible avec accès immédiat |
| WORM + Vault Lock combinés | Double protection : Object Lock (objet) + Vault Lock (policy vault) |
| Preuve Vault Lock In Effect | État à capturer et documenter pour conformité |
6. Dette technique¶
| Dette | Impact | Priorité |
|---|---|---|
| Vault Lock absent | Non-conformité spec §5.3, preuve "In Effect" impossible | HAUTE |
| SSE-S3 au lieu SSE-KMS | Audit KMS non disponible, séparation clés Paris absente | BASSE |
| Défaut transition J+1 | Coûts Deep Archive immédiats en dev si non override | BASSE |
| Documentation WORM absente | infra/PROBATOIRE_WORM.md non créé | MOYENNE |
| Scripts tests immutabilité | Non livrés, tests manuels uniquement | MOYENNE |
7. Risques résiduels¶
| Risque | Probabilité | Impact | Mitigation suggérée |
|---|---|---|---|
| Non-conformité Vault Lock | Élevée | ÉLEVÉ | Implémenter aws_glacier_vault_lock avec complete_lock = true |
| Restoration bloquée | Moyenne | MOYEN | Documenter procédure et délais 12-48h |
| Coûts retrieval | Moyenne | MOYEN | Budget retrieval fees, éviter accès fréquents |
| Transition prématurée dev | Moyenne | FAIBLE | Forcer J+90 en tfvars dev/staging |
| Audit conformité NF Z42-013 | Moyenne | ÉLEVÉ | Preuve Vault Lock obligatoire pour certification |
8. Améliorations processus¶
| Amélioration | Bénéfice attendu |
|---|---|
| Clarifier Vault Lock vs Object Lock | Éviter confusion sur deux mécanismes distincts |
| Implémenter Vault Lock dans module | Conformité spec complète dès l'implémentation |
| Scripts de tests automatisés | Valider immutabilité sans intervention manuelle |
| Documentation conformité | Livrer PROBATOIRE_WORM.md avec le module |
| Capture preuve Vault Lock | Output Terraform avec statut "In Effect" |
9. Enseignements clés¶
-
Object Lock et Vault Lock sont deux mécanismes distincts — Object Lock COMPLIANCE protège au niveau de l'objet (rétention individuelle), tandis que Vault Lock verrouille la policy du vault de manière irréversible. La spec demandait explicitement les deux pour une protection WORM complète.
-
Vault Lock est irréversible après completion — Une fois
complete_lock = trueappliqué, la policy Vault Lock ne peut plus être modifiée ni supprimée. Cette irréversibilité est critique pour la conformité NF Z42-013 mais impose des tests exhaustifs avant activation. -
Les défauts de variables doivent correspondre aux tests d'acceptation — La spec mentionne "Transition Glacier DA < 48h" comme test, suggérant J+1. Cependant, d'autres sections mentionnent J+90. L'ambiguïté spec doit être clarifiée avant implémentation.
-
La preuve d'état est un livrable — La spec demande "Preuve Vault Lock In Effect" comme livrable. Cette preuve doit être capturée (output Terraform, screenshot console, ou API response) et archivée pour audit conformité.
-
Glacier Deep Archive a des contraintes opérationnelles fortes — Le délai de restoration 12-48h rend les tests d'accès longs et coûteux. Les tests d'immutabilité (suppression impossible) sont plus rapides à valider que les tests de restoration.