Dans la collecte des données, on a fait atterrir le dataset e-commerce dans le bucket 's3://ibdata-datalake-formation'. Mais pour l'instant, c'est du vrac. Et un data lake en vrac c'est un bazar, personne ne sait ce qui est brut, ce qui est nettoyé, ce qui est fiable.

Dans cet article, on va bien structurer le bucket avec trois choses. Une structure médaillon pour savoir où en est chaque donnée, le versioning pour se protéger des écrasements, et une règle de cycle de vie pour que la facture ne gonfle pas avec le temps.

Les trois zones du data lake

Le principe est simple, la donnée traverse le lake en trois étapes, et chaque étape a sa zone.

1 - raw, la donnée brute, exactement comme elle est arrivée. On n'y touche jamais, c'est le filet de sécurité. Si un traitement se passe mal, on repart toujours de raw.

2 - clean, la donnée nettoyée. Doublons supprimés, types corrigés, formats standardisés (souvent en Parquet, on verra ça bientôt). C'est la zone de travail des data eng.

3 - curated, la donnée prête pour le métier. Agrégée, croisée, modélisée. C'est ce que consomment les dashboards et les data analystes.

C'est la même logique que l'architecture médaillon (bronze, silver, gold), seuls les noms changent. Et si tu as suivi ma formation dbt, tu reconnais aussi la logique staging puis marts, appliquée au stockage.

Un bucket ou trois ?

Il y a en réalité deux écoles. Un bucket par zone (isolation des permissions, et c'est courant dans les grands groupes), ou un seul bucket avec un préfixe par zone (plus simple à gérer). Pour la série, on garde notre bucket unique avec des préfixes, et on verra dans le module Lake Formation comment gérer finement les droits même dans ce cas.

Petit point vocabulaire au passage, S3 n'a pas de vrais dossiers. Donc par exemple raw/commandes/fichier.csv est juste un nom d'objet qui contient des slashs, et la console affiche ça comme une arborescence. Un préfixe n'existe que si au moins un objet l'utilise.

Ranger le dataset dans la zone raw

On range les fichiers de l'article précédent dans une vraie structure, un préfixe par source, puis la date d'arrivée.

s3://ibdata-datalake-formation/
└── raw/
    ├── commandes/2026-08-16/commandes.csv
    ├── clients/2026-08-16/clients.csv
    ├── produits/2026-08-16/produits.csv
    └── evenements_web/2026-08-16/evenements_web.json

En CLI, depuis le dossier local du dataset.

$date = "2026-08-16"
aws s3 cp commandes.csv s3://ibdata-datalake-formation/raw/commandes/$date/
aws s3 cp clients.csv s3://ibdata-datalake-formation/raw/clients/$date/
aws s3 cp produits.csv s3://ibdata-datalake-formation/raw/produits/$date/
aws s3 cp evenements_web.json s3://ibdata-datalake-formation/raw/evenements_web/$date/

Et on nettoie les tests de l'article précédent, les fichiers en vrac à la racine et le préfixe exports.

aws s3 rm s3://ibdata-datalake-formation/exports/ --recursive
aws s3 rm s3://ibdata-datalake-formation/commandes.csv
aws s3 rm s3://ibdata-datalake-formation/clients.csv
aws s3 rm s3://ibdata-datalake-formation/produits.csv
aws s3 rm s3://ibdata-datalake-formation/evenements_web.json

Activer le versioning

Le scénario classique, un script bugué réécrit commandes.csv avec un fichier vide, et sans versioning la donnée d'origine est perdue. Le versioning garde chaque version de chaque objet, l'écrasement devient réversible.

  1. Ouvre le bucket, onglet "Properties".
  2. Section "Bucket Versioning", clique sur "Edit" puis "Enable".
Versioning aws

Pour tester, réuploade clients.csv au même emplacement, puis active l'interrupteur "Show versions" dans la vue du bucket. Les deux versions apparaissent, avec leur date. Supprimer la version récente restaure l'ancienne.

Avec le versioning, une suppression ne détruit rien, elle pose un "delete marker" et l'objet disparaît de la vue par défaut. Les versions restent stockées, et facturées.

Classes de stockage et cycle de vie

S3 propose plusieurs classes de stockage, du plus rapide au plus froid. Trois à retenir :

  • Standard, l'accès immédiat, environ 0,023 $/Go/mois. La zone de travail par default.
  • Standard-IA (Infrequent Access), moitié moins cher au stockage, mais chaque lecture est facturée. Pour la donnée qu'on garde et qu'on lit rarement.
  • Glacier, l'archivage à moins de 0,004 $/Go/mois, avec des minutes ou des heures pour restaurer. Pour la conformité et l'historique profond.

On ne déplace pas les fichiers à la main entre les classes, on pose une règle de lifecycle et S3 s'en charge. Pour notre lake, une règle simple, la zone raw bascule en Standard-IA après 90 jours, et les anciennes versions créées par le versioning sont purgées après 30 jours.

cycle de vie aws
  1. Ouvre le bucket, onglet "Management", clique sur "Create lifecycle rule".
  2. Nomme la règle archivage-raw et limite-la au préfixe raw/.
  3. Coche "Transition current versions" avec Standard-IA après 90 jours.
  4. Coche "Permanently delete noncurrent versions" avec 30 jours.
cycle de vie aws

La règle tourne ensuite toute seule, chaque nuit et c'est le premier réflexe FinOps de la série.

La checklist finale

  • [ ] Structure raw/source/date/ en place pour les 4 sources.
  • [ ] Les fichiers de test de l'article précédent supprimés.
  • [ ] Versioning activé, testé avec un réupload et Show versions.
  • [ ] Lifecycle rule posée sur raw/ (IA à 90 jours, purge des anciennes versions à 30 jours).

Combien ça coûte ?

0 €. Le versioning et les règles de lifecycle sont gratuits, on ne paye que le stockage des versions conservées. Avec notre dataset, on reste à des fractions de centime.

La suite ?

Le lake est maintenant structuré, mais AWS ne sait pas encore ce qu'il contient. Pour lui, commandes.csv est un fichier d'octets comme un autre. Dans le prochain article, on branche le Glue Data Catalog et son crawler, et le lake devient requêtable en SQL.

Aller plus loin

Le programme complet du parcours est sur la page de la formation AWS.

Tu prépares la certification AWS Certified Data Engineer Associate (DEA-C01) ? Les classes de stockage S3, le versioning et les lifecycle rules tombent à quasiment chaque session. Pour t'entraîner, j'ai créé des questions d'examen blanc en français.

👉 S'entraîner sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (AWS, Snowflake, dbt, modélisation, coûts) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes

C'est quoi les zones raw, clean et curated d'un data lake ?

raw contient la donnée brute telle qu'elle arrive, jamais modifiée. clean contient la donnée nettoyée et typée. curated contient la donnée modélisée et agrégée pour le métier. Chaque transformation lit une zone et écrit dans la suivante. (voir l'article médaillon)

Faut-il un bucket par zone ou un seul bucket ?

Les deux se font. Un bucket par zone isole mieux les permissions et se voit souvent en entreprise. Un bucket unique avec un préfixe par zone reste plus simple et suffit pour la plupart des projets, les droits fins pouvant être gérés avec Lake Formation.

Les dossiers existent-ils vraiment dans S3 ?

Non. S3 stocke des objets à plat, et les slashs dans les noms créent une arborescence visuelle dans la console. Un préfixe n'existe que si au moins un objet l'utilise.

À quoi sert le versioning S3 ?

À rendre les écrasements et suppressions réversibles. Chaque écriture crée une nouvelle version, l'ancienne reste accessible. Indispensable sur la zone raw, où la donnée d'origine est irremplaçable. À coupler avec une règle de purge des anciennes versions pour contenir le coût.

Quelle classe de stockage S3 choisir pour un data lake ?

Standard pour la donnée de travail, Standard-IA pour la donnée conservée mais rarement lue, Glacier pour l'archivage long terme. Le bon réflexe, ne rien déplacer à la main et laisser une lifecycle rule faire les transitions.

Combien coûte le stockage S3 ?

Environ 0,023 $/Go/mois en Standard, deux fois moins en Standard-IA, et moins de 0,004 $/Go/mois en Glacier. Pour donner un ordre de grandeur, 100 Go en Standard coûtent environ 2,30 $ par mois.