Pourquoi les fondations data sont critiques
Toutes les organisations veulent être « data-driven ». Peu y parviennent réellement. La raison est simple : l'analyse de données ne peut pas se faire sur des données mal organisées.
Les symptômes d'une organisation sans fondations data :
Chaque service calcule ses chiffres différemment
Les rapports prennent des jours à produire
Les projets IA échouent faute de données propres
Les décisions se prennent à l'intuition, faute de données fiables
Les données historiques sont perdues ou inexploitables
Le data engineering est l'ensemble des pratiques qui permettent de collecter, transformer, stocker et rendre accessibles les données. C'est l'infrastructure invisible sur laquelle reposent la BI, l'analyse et l'IA.
Les 4 responsabilités du data engineering
1. Collecte
Récupérer les données depuis leurs sources : bases applicatives, APIs, fichiers, logs. Les outils modernes (Airbyte, Fivetran, Meltano) automatisent cette étape, mais la complexité reste dans les cas particuliers.
2. Transformation
Nettoyer, normaliser, enrichir, agréger. C'est là que les règles métier sont traduites en transformations techniques. Les outils modernes (dbt, SQLMesh) permettent de gérer ces transformations comme du code.
3. Stockage
Organiser les données dans un entrepôt (BigQuery, Snowflake, PostgreSQL) ou un lac (S3, Azure Blob) selon les besoins. Le choix dépend du volume, de la latence et des compétences.
4. Exposition
Rendre les données accessibles : vues, APIs, catalogues. C'est ce qui permet aux analystes, data scientists et applications de travailler.
Batch ou streaming ?
Un choix structurant : traite-t-on les données par lots (batch) ou en temps réel (streaming) ?
Batch — la norme
Traitement à intervalles réguliers (horaire, quotidien). Simple, robuste, économique. Convient à la majorité des cas : reporting, analyses, alimentation d'un entrepôt.
Streaming — pour des cas spécifiques
Traitement en continu. Nécessaire quand les décisions dépendent de données très fraîches (moins de quelques minutes). Exemples : détection de fraude, supervision industrielle, alerting temps réel.
Notre recommandation
Commencer par du batch. Le streaming introduit une complexité opérationnelle importante. Ne l'adopter que quand un cas d'usage le justifie réellement.
ELT plutôt qu'ETL
La pratique moderne privilégie ELT (Extract, Load, Transform) plutôt que ETL (Extract, Transform, Load).
ETL — l'ancienne école
On transforme les données avant de les charger dans l'entrepôt. Avantage : l'entrepôt ne contient que des données propres. Inconvénient : impossible de refaire les transformations sans recharger.
ELT — l'approche moderne
On charge d'abord les données brutes, on transforme ensuite dans l'entrepôt. Avantages :
Historique complet conservé
Possibilité de refaire les transformations à tout moment
Découplage entre ingestion et transformation
Utilisation de la puissance de calcul de l'entrepôt
C'est l'approche que nous recommandons dans la majorité des cas.
Les données comme produit
Le principe le plus structurant du data engineering moderne : traiter les données comme un produit.
Ce que ça implique
Chaque table, chaque dataset a :
Un propriétaire — une personne responsable
Un contrat — schéma, fréquence, qualité attendue
Une documentation — à jour et accessible
Un cycle de vie — création, évolution, archivage
Pourquoi c'est important
Sans cette discipline, les données deviennent un chaos :
Tables orphelines que personne ne maintient
Chiffres contradictoires entre services
Coûts de stockage qui explosent
Projets bloqués faute de données fiables
Le principe « data as a product » transforme la donnée en actif maîtrisé, pas en sous-produit.
Combien de temps pour construire les fondations
Pour une organisation de taille moyenne avec 5 à 10 sources :
Cadrage et architecture : 2 à 3 semaines
Première collecte : 3 à 4 semaines
Transformations principales : 2 à 3 mois
Documentation et catalogue : 2 à 3 semaines
Total : 4 à 6 mois pour une fondation solide.
Ce temps est-il justifié ?
Oui. Les organisations qui sautent cette étape se retrouvent avec des projets BI ou IA qui échouent en production, puis recommencent — en ayant perdu plus de temps.
Les fondations data sont un investissement. Ce n'est pas un coût.
Checklist fondations data
☐ Inventaire des sources de données identifiées
☐ Architecture cible définie (entrepôt, lac, hybride)
☐ Outils choisis (collecte, transformation, orchestration)
☐ Premiers pipelines en production
☐ Transformations versionnées dans un dépôt Git
☐ Catalogue de données en place
☐ Propriétaires nommés pour chaque dataset
☐ Règles de qualité définies et mesurées
☐ Documentation accessible aux utilisateurs
☐ Surveillance des pipelines (alertes en cas d'échec)