Histoire de l’ingénierie des données
Un problème ancien, des réponses techniques successives
Vers 3300 avant J.C., les premières formes d’écriture en Mésopotamie servent notamment à enregistrer des informations économiques : quantités de grain, rations, troupeaux ou échanges. La donnée apparaît déjà comme une réponse à un besoin de mémoire, de contrôle et de coordination.
Compter
à la main
Un scribe inscrit grain, rations et bétail sur une tablette d’argile. C’est déjà un registre de stocks.
Traiter
par ordinateur
Les banques et les compagnies aériennes passent les comptes à la machine. SABRE, chez American Airlines, réserve un siège en quelques secondes.
Distribuer
à très grande échelle
Les volumes générés par Internet dépassent la capacité d’une seule machine : c’est le big data. Le calcul se répartit sur des milliers d’ordinateurs, dans des data centers, puis dans le cloud.
Apprendre
à l’IA
Les modèles apprennent à partir de textes et d’images. Ils prennent en charge des tâches jadis réservées à l’humain : expliquer, dessiner, chanter, agir, etc.
Les outils changent, mais la même question revient : comment enregistrer, transformer et exploiter une quantité croissante d’informations ?
Un cycle récurrent
À chaque période, une architecture dominante finit par rencontrer ses limites. Le volume augmente, les utilisateurs exigent des réponses plus rapides, ou de nouveaux usages apparaissent. Une réponse technique ou organisationnelle émerge, se diffuse, puis révèle à son tour de nouvelles contraintes.
Cette lecture ne signifie pas que les technologies anciennes disparaissent. Les systèmes transactionnels, les data warehouses, les data lakes et les bases NoSQL coexistent encore aujourd’hui. L’enjeu consiste à comprendre pour quel problème chaque architecture a été conçue.
1960-1986 : la naissance du modèle relationnel
La première grande rupture consiste à séparer la structure logique des données de leur organisation physique sur le disque.
Dans les bases de données des années 1960, accéder à une donnée consiste à suivre un chemin physique sur le disque : le programme part d’un enregistrement, puis enchaîne des pointeurs jusqu’à l’information cherchée. Une modification de l’organisation physique peut donc imposer de réécrire les applications.
Le modèle relationnel répond à cette rigidité : on décrit le résultat recherché, plus le chemin sur le disque. La frise retrace cette bascule, de l’article de Codd à la normalisation de SQL.
Modèle relationnel
E. F. Codd, IBM
- Données représentées par des tables et des relations.
- Séparation entre modèle logique et stockage physique.
SEQUEL, puis SQL
Chamberlin et Boyce
- Langage déclaratif fondé sur le modèle relationnel.
- L’utilisateur exprime le résultat recherché.
Premiers produits SQL
Commercialisation
- Oracle V2 est commercialisé.
- Les SGBDR se diffusent durant les années 1980.
Garanties ACID
Härder et Reuter
- Atomicité, cohérence, isolation et durabilité.
- Cadre de référence pour les transactions.
Normalisation de SQL
ANSI, puis ISO en 1987
- Un langage commun s’impose.
1980-1999 : séparer le transactionnel de l’analytique
Les systèmes transactionnel OLTP (Online Transaction Processing) doivent traiter rapidement un grand nombre de transactions courtes et concurrentes. Les usages analytiques OLAP (Online Analytical Processing) parcourent au contraire de grands volumes historiques, effectuent des jointures et calculent des agrégations. Exécuter ces charges sur la même base peut ralentir les opérations métier.
Le data warehouse sépare alors l’environnement décisionnel du système de production. Des pipelines ETL extraient, transforment et chargent les données. Bill Inmon formalise une approche intégrée à l’échelle de l’entreprise, tandis que Ralph Kimball popularise la modélisation dimensionnelle, les tables de faits et les dimensions.
Data warehouse
Les requêtes décisionnelles ne doivent pas perturber les opérations courantes.
- Les systèmes OLTP enregistrent rapidement les transactions.
- Les systèmes OLAP agrègent l’historique pour analyser et décider.
- Teradata (1984) est l’un des premiers data warehouses : une machine dédiée à l’analyse, séparée de la production.
- Bill Inmon formalise l’approche du data warehouse d’entreprise.
Modélisation dimensionnelle
Le décideur a besoin d’indicateurs stables, pas du schéma opérationnel brut.
- Les pipelines ETL alimentent les environnements décisionnels.
- Ralph Kimball popularise la modélisation dimensionnelle.
- Les tables de faits et de dimensions structurent les analyses.
- La business intelligence diffuse tableaux de bord et reporting.
2000-2006 : le big data et le calcul distribué
L’essor du web au début des années 2000 fait émerger le big data : journaux, clics, pages et vidéos s’accumulent plus vite que ne le permettent SGBDR et data warehouses dédiés. YouTube annonce plus de 65 000 téléversements par jour dès 2006 (chiffres historiques repris par Wikipedia). La frise retrace cette saturation, puis le passage au stockage et au calcul répartis sur des machines ordinaires.
Scale-up des SGBDR très coûteux
Le volume des plateformes web dépasse ce que SGBDR et data warehouses dédiés absorbent encore.
- Montée en charge souvent verticale : renforcer un serveur devient progressivement plus coûteux.
- Calcul distribué spécialisé : les systèmes parallèles et MPP existent déjà, notamment Teradata, mais avec un coût très élevé.
- Nouveau besoin : répartir stockage et calcul sur de nombreuses machines ordinaires, avec reprise sur panne.
Stocker et calculer en distribué
Le système répartit les données et le travail sur un grand nombre de machines ordinaires.
- Google File System (2003) organise un stockage distribué tolérant aux pannes.
- MapReduce (2004) automatise la parallélisation et l’agrégation des calculs.
- Apache Hadoop (2006) propose une implémentation open source inspirée de ces travaux.
- AWS S3 et EC2 (2006) rendent stockage et calcul accessibles à la demande sur le cloud.
2005-2012 : bases distribuées, NoSQL et théorème CAP
Hadoop et GFS couvrent le stockage de fichiers et le calcul par lots. Les applications en ligne, elles, doivent encore servir des lectures et des écritures rapides sur un cluster. Le volume dépasse ce qu’un serveur relationnel absorbe encore ; les données web, souvent imbriquées ou incomplètes, collent mal à un schéma tabulaire figé. NoSQL désigne les bases conçues pour ces charges. Elles ne remplacent pas universellement le relationnel.
Le terme regroupe plusieurs formes de données : clé-valeur, document, colonnes larges ou graphe. Ils proposent d’autres compromis pour répondre à des charges précises.
Le théorème CAP s’applique aux bases de données distribuées. Lors d’une partition réseau, certains nœuds ne peuvent plus communiquer : on ne peut alors plus garantir à la fois la cohérence et la disponibilité.
L’arbitrage CAP conduit les bases de données à se positionner différemment, chacune pour un besoin précis. Dynamo (Amazon, 2007), par exemple, accepte les écritures même pendant une panne pour ne pas bloquer le panier client, quitte à réconcilier plus tard des versions divergentes ; tandis que MongoDB, avec un nœud primaire, refuse en général d’écrire si ce primaire n’est plus joignable : une seule vérité compte plus qu’une réponse immédiate.
Servir des applications distribuées
Les grandes plateformes recherchent disponibilité, faible latence et montée en charge horizontale.
- Répliquer les données entre plusieurs machines et régions.
- Accepter des structures plus flexibles que les schémas transactionnels traditionnels.
- Adapter le modèle de stockage aux accès dominants : clé-valeur, document, colonnes larges ou graphe.
- Choisir explicitement les garanties de cohérence nécessaires.
Une famille de systèmes, pas un modèle unique
NoSQL regroupe des architectures répondant à des compromis différents.
- Google Bigtable (2006) gère des données structurées à l’échelle de milliers de serveurs.
- Amazon Dynamo (2007) privilégie une haute disponibilité pour certains services.
- Apache Cassandra combine plusieurs idées de Dynamo et Bigtable, avec une cohérence réglable par opération.
- MongoDB et Redis contribuent à diffuser les modèles document et clé-valeur.
2010-2020 : cloud et services managés
Avant le cloud, une équipe devait installer et maintenir son propre cluster : acheter ou louer des machines, prévoir la capacité et résoudre les incidents. Cela demandait du temps avant même de produire de la valeur métier.
Avec le cloud, une partie de ce travail est assurée par le fournisseur. L’équipe peut alors se concentrer sur les données et les usages : construire les pipelines, écrire les requêtes et contrôler les accès.
Le data lake stocke les données brutes à faible coût. Des services comme BigQuery, Redshift ou Snowflake permettent ensuite de les analyser en SQL sans administrer directement les serveurs.
Gérer son propre cluster
L’équipe exploite aussi l’infrastructure.
- Prévoir le nombre de machines nécessaire.
- Installer, mettre à jour et surveiller le cluster.
- Résoudre les incidents et absorber les pics d’activité.
Utiliser des services managés
Le fournisseur exploite l’infrastructure.
- Un data lake stocke les données brutes.
- BigQuery, Redshift et Snowflake permettent l’analyse SQL.
- L’équipe se concentre sur les pipelines, les accès et les coûts.
Comment traiter 1 TB de données ?
2006, Hadoop
Ressources
- 100 machines
- Mise en place en plusieurs mois
- 10 ingénieurs
Comment ?
- Cluster HDFS configuré manuellement
- ~150 lignes de Java pour un job simple
- Exécution en 2 h si le cluster tient
Coût
- ~$1 M pour démarrer
2026, BigQuery
Ressources
- 0 machine
- 0 configuration
- 1 ingénieur
Comment ?
- Zéro configuration et scale automatique
- ~15 lignes de SQL
- Résultats disponibles en quelques secondes
Coût
- ~$6 pour 1 TB
Depuis 2020 : convergence des architectures, lakehouse et data mesh
Le cloud n’a pas unifié les architectures : data lake, data warehouse et outils spécialisés coexistent, et les mêmes données y sont souvent recopiées. Cette duplication, avec ses délais et ses gouvernances distinctes, est la contrainte à laquelle répondent le lakehouse et le data mesh.
Une première réponse est le lakehouse. Des formats de table comme Delta Lake, Apache Iceberg ou Apache Hudi ajoutent aux fichiers d’un data lake des métadonnées, des transactions, une évolution de schéma et un suivi des versions. Ils cherchent à rapprocher la souplesse du stockage objet et les garanties attendues d’une table analytique.
Une seconde réponse est organisationnelle. Le data mesh propose de rapprocher la responsabilité des données des domaines qui les produisent, de traiter la donnée comme un produit et de mettre en place une gouvernance fédérée. Ce n’est pas un outil, mais une organisation sociotechnique qui suppose une plateforme commune.
| Saturation | Réponse proposée | Conséquence |
|---|---|---|
| Duplication entre data lake, data warehouse et outils spécialisés | Lakehouse et formats de table ouverts | On interroge les mêmes fichiers Parquet, mais il faut choisir un format de table (Iceberg, Delta Lake, Hudi), un catalogue et un moteur (Spark, BigQuery, Trino) |
| Responsabilité des données dispersée entre de nombreuses équipes | Data mesh et donnée traitée comme un produit de domaine | Propriétaires, contrats et responsabilités plus explicites |
Depuis 2023 : ingénierie des données multimodales, LLM, RAG et bases vectorielles
L’intelligence artificielle a fait naître une nouvelle branche du métier : l’ingénierie des données multimodales. Elle consiste à rendre exploitables pour l’IA des images, des vidéos, de l’audio ou des documents, par le prétraitement et les embeddings.
Ces données préparées alimentent surtout deux usages. Le premier passe par des architectures RAG, qui combinent la recherche vectorielle avec un modèle de langage. La qualité du système dépend du découpage des documents, des métadonnées, du modèle d’embedding, de la stratégie de recherche et de l’évaluation des réponses.
Le second concerne les tables. Le text-to-SQL traduit une question en langage naturel, mais une formulation en français ne garantit pas une requête correcte : le modèle doit s’appuyer sur un schéma documenté, une couche sémantique, des règles métier et des contrôles d’accès.
| Saturation | Réponse proposée | Conséquence |
|---|---|---|
| Volumes croissants de documents, d’images et d’audio difficiles à explorer | Parsing, OCR, embeddings, recherche vectorielle et hybride | Recherche par contenu, avec de nouvelles exigences d’évaluation et de gouvernance |
| Interroger les tables reste réservé aux développeurs | Interfaces en langage naturel, couche sémantique et text-to-SQL | Accès simplifié, mais nécessité de valider les requêtes et les réponses générées |
- Les architectures de données évoluent lorsque le volume, la vitesse, la variété ou les exigences de fiabilité changent.
- Depuis 1974, SQL reste le langage commun ; les moteurs changent. Distinguez le paradigme (requête déclarative sur des tables) de l’outil du moment (Oracle hier, BigQuery ou Spark SQL aujourd’hui).
- Le calcul distribué apporte la montée en charge, mais introduit des compromis de cohérence, de disponibilité et d’exploitation.
- Le cloud réduit la gestion directe de l’infrastructure, tout en renforçant l’importance de l’architecture, de la sécurité, de la qualité et des coûts.
- L’ingénieur des données classique évolue vers une ingénierie multimodale : préparer PDF, images, audio et documents scannés pour alimenter les pipelines IA (embeddings, RAG, bases vectorielles).