Silicon · 9 juin 2026
Architecture data moderne : le socle avant l'IA
- architecture data
- composants
- définition
Avant de parler intelligence artificielle, encore faut-il que les données puissent circuler, être stockées et exploitées de façon fiable. C'est le sujet d'un article de fond de Silicon, qui retrace l'évolution des architectures data et détaille ce qu'implique une architecture « moderne ». Une lecture utile pour les dirigeants de PME qui entendent parler de data lake, de lakehouse ou de data mesh sans toujours savoir ce que ces mots recouvrent — ni s'ils les concernent.
Du data warehouse au lakehouse, une évolution par tâtonnements
Trois générations d'outils se sont succédé, sans que la précédente disparaisse totalement. Les premiers entrepôts de données, nés dans les années 1990, imposaient de tout ranger dans un format défini à l'avance — confortable pour des rapports stables, beaucoup moins pour des besoins qui évoluent ou des formats hétérogènes. Le data lake a inversé la logique en acceptant d'abord ce qui arrive, quitte à le structurer plus tard ; sans discipline de gouvernance, l'article note que ce pari se retourne souvent contre lui, l'entrepôt de bonnes intentions se changeant en ce qu'il nomme un « marécage de données inexploitables ». Le lakehouse cherche un compromis entre les deux, en s'appuyant sur des formats de table ouverts — Delta Lake, Apache Iceberg — pour retrouver de la fiabilité sans renoncer au faible coût du lac. Le data mesh, lui, change de logique plutôt que d'outil : ce n'est pas une brique technique supplémentaire mais une façon de répartir les responsabilités, en confiant à chaque équipe métier la charge de ses propres données plutôt que de tout faire remonter vers l'IT.
Quatre fonctions, une exigence transverse
Quelle que soit l'architecture retenue, l'article ramène le sujet à un enchaînement en quatre temps : faire entrer la donnée depuis ses sources — applications, API, capteurs —, la conserver sur une base qui n'enferme pas l'avenir, la nettoyer et la mettre en forme, puis la rendre disponible pour les usages qui en ont besoin, du tableau de bord classique jusqu'aux modèles de machine learning ou d'IA générative. Un fil de gouvernance — documentation, sécurité, contrôle qualité — doit courir sur ces quatre temps dès le départ, plutôt que d'être ajouté une fois le système déjà en place.
Un sujet qui concerne aussi les PME
Les petites structures n'ont évidemment pas vocation à déployer un lakehouse. Mais le principe reste transposable : savoir où vivent les données, comment elles circulent entre les outils, et si cette circulation est organisée ou livrée au hasard. C'est précisément ce que nous examinons dans les axes « accès à l'information » et « silos & shadow data » de l'Audit Data : repérer les points de friction avant d'envisager tout projet d'automatisation ou d'IA.