
GreenFarm dispose désormais de deux environnements fonctionnels :
un Data Lake cloud sur AWS S3,
et son équivalent open source sur MinIO, pour expérimenter et tester les pipelines localement.
Mais un Data Lake, même performant, peut rapidement se transformer en Data Swamp — un marécage de données ingérables — si rien n’est fait pour structurer, gouverner et hiérarchiser les informations.
GreenFarm veut donc passer à l’étape suivante : structurer son Data Lake pour en faire une véritable plateforme de données.
L’objectif :
améliorer la performance des analyses,
maîtriser les coûts de stockage,
et poser les bases d’une gouvernance claire avant d’évoluer vers une.
Pour GreenFarm, la première étape consiste à organiser les données selon leur maturité et leur usage.
Le modèle retenu s’appuie sur trois grandes zones :
Zone | Description | Exemple de contenu | Accès |
Raw | Données brutes, directement issues des sources (IoT, API, ERP, etc.) | JSON, CSV, logs bruts | Restreint (Data Engineers |
Processed | Données nettoyées et enrichies, prêtes pour l’analyse | Fichiers Parquet, tables nettoyées | Restreint (Data Engineers / Analysts) |
Curated | Données validées, standardisées et prêtes pour la consommation métier | Tables agrégées, jeux de données BI | Large (Analystes / Outils BI) |
Ce modèle permet :
d’isoler les traitements,
de suivre le cycle de vie des données,
et de gérer les droits d’accès selon la qualité et la sensibilité des jeux de données.
Une structure cohérente évite les erreurs, facilite la navigation et prépare l’automatisation.
GreenFarm a adopté la convention suivante :
/raw/<source>/<année>/<mois>/<jour>/
/processed/<domaine>//
/curated/<usage>/<projet>/</projet></usage><table></table></domaine></jour></mois></année>Exemple :
/raw/iot/2025/10/12/
/processed/production/mesures_temp/
/curated/analyse/performance_agricole/Ces conventions peuvent être intégrées dans les scripts d’ingestion (Airbyte, Redpanda, Spark) pour garantir la cohérence à long terme.
GreenFarm définit des rôles clairs :
Data Engineers → lecture/écriture dans raw et processed,
Data Analysts → lecture dans processed et curated,
Applications métiers / BI → lecture seule dans curated.
Cette hiérarchisation garantit la qualité, la traçabilité et la sécurité du Data Lake.
Un Data Lake se conçoit à deux niveaux :
L’architecture logique définit les zones fonctionnelles, la gouvernance et les règles de nommage.
L’architecture physique décrit où et comment ces zones sont hébergées:
sur AWS → buckets S3, préfixes et politiques IAM,
sur Azure → comptes de stockage et containers Blob,
sur GCP → buckets Cloud Storage.
Cette distinction permet de raisonner de façon multi-cloud : les concepts restent identiques, même si les technologies changent.
Toutes les données n’ont pas la même valeur ni la même fréquence d’accès.
Le tiering consiste à placer chaque donnée sur le bon niveau de stockage selon son usage.
Tier | Type de données | Exemple | Coût | Accès |
Hot | Données récentes, souvent utilisées | IoT du mois en cours | 💰💰 | Très rapide |
Warm | Données d’analyse intermédiaire | Historique des 6 derniers mois | 💰 | Rapide |
Cold | Données d’archives ou rarement consultées | Logs anciens, audits | 💸 | Lent |
 Sur AWS S3, ces niveaux correspondent à des classes de stockage :
S3 Standard (hot)
S3 Infrequent Access (warm)
S3 Glacier / Deep Archive (cold)
Sur MinIO, on peut simuler ce comportement grâce aux règles de lifecycle management (suppression, archivage ou déplacement automatique).
Chez GreenFarm, les données processed n’ont d’intérêt que pendant quelques mois.
Pour réduire les coûts, l’équipe met en place une règle de cycle de vie :
déplacer automatiquement les fichiers de plus de 90 jours vers S3 Glacier,
supprimer les fichiers de plus d’un an.
Accédez à votre bucket S3.
Onglet “Management” → “Lifecycle rules” → “Create lifecycle rule”.
Donnez un nom (ex. move-old-processed-files).
Choisissez le préfixe processed/.
Configurez la transition vers Glacier après 90 jours.
Ajoutez une règle de suppression après 365 jours.
Résultat : les données “vieillissent” automatiquement dans un stockage moins coûteux, sans intervention manuelle.
aws s3api put-bucket-lifecycle-configuration \
--bucket greenfarm-datalake-demo \
--lifecycle-configuration '{
"Rules": [{
"ID": "ProcessedDataLifecycle",
"Filter": { "Prefix": "processed/" },
"Status": "Enabled",
"Transitions": [{
"Days": 90,
"StorageClass": "GLACIER"
}],
"Expiration": { "Days": 365 }
}]
}'Ces politiques automatisent la gestion du cycle de vie, tout en assurant l’équilibre entre coût et performance.
Structurer un Data Lake, c’est aussi penser à son écosystème.
GreenFarm s’appuie sur plusieurs principes pour en assurer la cohérence et la pérennité :
Standardisation : formats optimisés (Parquet, Avro), conventions de nommage uniformes.
Documentation : chaque dataset possède un README décrivant son origine, ses transformations et son usage.
Séparation des rôles : Data Engineers, Data Stewards et Analysts interviennent chacun sur des zones définies.
Automatisation : CI/CD pour les déploiements, la création de buckets, et les règles de lifecycle.
GreenFarm met en place une distinction claire entre :
Dev → jeux de données échantillonnés, accès large, expérimentations.
Test → validations des pipelines, intégration continue.
Prod → données réelles, accès restreint, sécurité maximale.
Chaque environnement possède ses propres buckets et credentials.
Les configurations sont automatisées via pipelines CI/CD, garantissant la cohérence d’un environnement à l’autre.
Un Data Lake bien structuré ne se limite pas aux fichiers : il repose sur un catalogue de métadonnées.
Chez GreenFarm, chaque dataset contient des informations essentielles :
source d’origine,
transformations appliquées,
propriétaire de la donnée,
qualité et niveau de validation.
Ces métadonnées peuvent être stockées dans un fichier YAML, une base interne ou un outil de Data Catalog (AWS Glue, Azure Purview, DataHub, DataGalaxy).
Elles facilitent la traçabilité et la découvrabilité des données.
Structurer un Data Lake, c’est séparer les données en zones (raw, processed, curated) selon leur maturité.
Le tiering et les règles de cycle de vie optimisent les coûts et la performance.
Les bonnes pratiques d’urbanisation (gouvernance, standardisation, CI/CD, documentation) assurent la durabilité du système.
L’architecture proposée n’est qu’un modèle parmi d’autres.
GreenFarm dispose maintenant d’un Data Lake solide, structuré et gouverné. Mais très vite, l’entreprise réalise que le stockage et la qualité ne suffisent plus : les équipes métiers veulent analyser les données en temps réel, les data scientists ont besoin d’entraîner leurs modèles directement sur les fichiers du Data Lake, et la direction souhaite un accès unifié et fiable à tous les indicateurs. C’est le moment pour GreenFarm de franchir une nouvelle étape : transformer son Data Lake en une architecture Lakehouse, alliant la souplesse du stockage objet à la puissance de l’analyse avancée.