Guide : construire les fondations data de votre organisation

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.

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.

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.

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.

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.

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.

• ☐ 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)