Architectures data modernes : data warehouse, data lake et data lakehouse, quelle approche adopter ?

11 juillet 20233 octobre 2025

0 commentaires

Dans un monde moderne qui produit sans cesse des données qui nourrissent en continu ses économies, faire le bon choix en terme d’architecture est essentiel pour capter, gérer, analyser et exploiter les données. Les architectures de données ont beaucoup évolué pour répondre à ces nouveaux besoins sur des volumétries jamais atteintes jusqu’alors et des systèmes qui demandent de plus en plus de traitement temps réel. Voici un selon nous les architectures data les plus modernes en 2024.

La réponse ne peut plus reposer sur une seule approche. Les architectures data modernes doivent être modulaires, évolutives et capables d’intégrer des logiques d’automatisation via l’AIOps.

Dans ce contexte, l’architecte data joue un rôle central : il articule vision métier, contraintes techniques et exigences de gouvernance. Architectures Data Modernes & AIOps : Data Mesh, Lakehouse, Data Fabric, quelle architecture choisir en 2024 ?

Choix en architectures de données modernes

Le Data Lake, le socle historique, à repenser

Le Data Lake a longtemps été la solution privilégiée pour centraliser les données brutes. Il répond à un besoin de volume et de stockage low cost.
Mais sans gouvernance, il devient rapidement un « data swamp », difficile à exploiter.

• Avantages : souplesse, stockage massif, coût faible
• Limites : qualité, sécurité, complexité d’exploitation

Le Lakehouse, un compromis entre performance et gouvernance

L’architecture Lakehouse combine les atouts du Data Lake et du Data Warehouse. Elle permet de traiter à la fois des workloads analytiques et des pipelines data intensifs. En termes de technologies, nous utilisons chez Smartpoint Delta Lake, Apache Iceberg, Snowflake, etc.

• Avantages : unification, gouvernance, performance
• Limites : encore jeune, nécessite une montée en compétences

Le Data Mesh, vers une architecture orientée data products

Le Data Mesh rompt radicalement avec le modèle centralisé et nos experts misent tout sur cette architecture de nouvelle génération ! Vous pouvez lire notre artciles sur le Data Mesh et ses fondamentaux ici. Chaque domaine métier devient responsable de ses “data products”. L’approche repose sur quatre piliers :

1. Domain Ownership
2. Data as a Product
3. Self-serve Platform
4. Federated Governance

• Avantages : scalabilité organisationnelle, ownership
• Limites : transformation culturelle, gouvernance plus complexe

L’AIOps Architecture, vers une automatisation intelligente !

L’architecture AIOps intègre des techniques d’intelligence artificielle pour automatiser l’observabilité, la détection d’incidents, la remédiation et le monitoring temps réel des infrastructures et des flux de données.

Nul doute qu’elle va s’imposer comme un complément indispensable des architectures data modernes, en particulier dans des environnements SI hybrides et cloud-native.

• Avantages : fiabilité, anticipation des incidents, scalabilité automatique
• Limites : complexité d’implémentation, dépendance à des modèles

Quels critères pour choisir la bonne architecture Data IA ?

Aligner stratégie d’architecture avec cas d’usages

Nos architectes data le constatent tous les jours dans la réalité des SI Data de nos clients. Le bon choix d’architecture de données repose sur une analyse des cas d’usage, des contraintes techniques, de votre SI Data et de la maturité Data globale de votre organisation.

Pour schématiser en fonction des priorités :

• Gouvernance renforcée → Lakehouse ou Data Mesh
• Cas d’usage IA → AIOps + Lakehouse
• Organisation distribuée → Data Mesh

L’architecte data : un rôle clé pour 2024

Le data architecte n’est plus là pour faire des schémas directeurs, il intervient beaucoup plus en amont sur votre chantier de modernisation de votre architecture de données. Il traduit les enjeux métiers en modèles data, intègre la durabilité dans ses choix d’architecture, pilote les interactions entre cloud / IA / data et gouvernance et enfin il intègre les principes d’AIOps pour fiabiliser les environnements.

Comment construire une architecture data pérenne ?

Chez Smartpoint, nous accompagnons les DSI, les directions Data et les architectes dans la conception, l’implémentation et l’évolution de leurs architectures de données, en veillant à aligner les besoins des métier, les contraintes techniques, la stack existante et les impératifs de gouvernance.

Après un diagnostic de l’existant afin d’évaluer la maturité de l’organisation, les performances des environnements en place et le niveau de structuration de la gouvernance des données ; nous vous recommandons une architecture Data sur mesure, adaptées aux cas d’usage et à l’écosystème IT. Ces recommandations s’appuient sur des approches comme le Data Lakehouse, le Data Mesh ou des architectures intégrant des principes d’AIOps.

Une fois l’architecture cible définie, nous assurons sa mise en production en respectant les impératifs de performance, d’évolutivité et de scalabilité. Nous accompagnons également les équipes internes, data owners, architectes, DevOps, afin de nous assurer de l’appropriation des modèles mis en place et leur adoption durable dans les pratiques de l’entreprise.

Concevoir des architectures de données modernes, évolutives, gouvernées et automatisées, capables de soutenir durablement la performance et la création de valeur à l’échelle de l’organisation; c’est notre métier en tant qu’ESN spécialisée en ingénierie des données.

Vers des architectures intelligentes, au service de la valeur

Les architectures data modernes doivent répondre à aux maitres mots que sont l’agilité et la maîtrise.

Intégrer des logiques d’AIOps, favoriser des approches domain-centric comme le Data Mesh, ou unifier les flux via un Lakehouse sont autant de ressors pour créer de la valeur à l’échelle.

En 2024, l’architecte data devient un stratège : il conçoit des environnements data solides, adaptés aux enjeux métiers comme technologiques, dans une logique cloud-native, automatisée et gouvernée.

Data Warehouse, Data Lake et Data Lakehouse : comment choisir l’architecture adaptée ?

Les entreprises doivent aujourd’hui gérer une grande diversité de types de données : structurées, semi-structurées et non structurées. Le choix de l’architecture data moderne conditionne directement la qualité des données, leur exploitation en data science et les usages analytiques tels que la business intelligence (BI).

• Le data warehouse cloud reste privilégié pour l’analytique et le reporting, grâce à sa capacité à organiser et fiabiliser les données structurées.
• Le data lake (ou lac de données) se démarque par sa flexibilité et sa capacité de stockage de données massives, mais requiert une gouvernance rigoureuse pour éviter l’effet “data swamp”.
• Le data lakehouse émerge comme une alternative hybride, combinant la puissance transactionnelle (transactions ACID) et analytique du warehouse avec la souplesse du data lake.

Le choix dépendra de plusieurs facteurs :

• La prise en charge des données non structurées,
• Les besoins en scalabilité et performance analytique,
• La nécessité de garantir la traçabilité et la conformité réglementaire,
• L’intégration avec les pratiques de data governance et les outils de traitement cloud-native.

Quelle architecture data adopter ?

La question n’est plus de savoir si un data warehouse ou un data lake est meilleur, mais de déterminer quelle combinaison d’architectures permet de répondre aux besoins spécifiques de l’entreprise.

Le data warehouse continue de jouer un rôle central dans la business intelligence (BI) et la fiabilité des rapports. Le data lake, de son côté, facilite la gestion des données non structurées et alimente les projets de data science. Enfin, le data lakehouse s’impose comme un modèle innovant, capable de concilier stockage de données, analytique avancée et qualité des données grâce à des mécanismes robustes comme les transactions ACID.

Pour les DSI et responsables data, la clé est de bâtir une stratégie d’architecture data moderne flexible, intégrant ces briques de manière cohérente, afin de soutenir la transformation numérique, l’innovation et la prise de décision.

Pour aller plus loin

• Data Mesh : https://en.wikipedia.org/wiki/Data_mesh
• TechTarget – Benefits of data mesh might not be worth the cost
• Les stratégies clés autour du Data Mesh

Le choix de la bonne architecture de données dépend de vos besoins spécifiques. Que ce soit le Data Mesh, la Data Fabric ou le Lakehouse, chaque option a ses propres intérêts qui peuvent servir votre stratégie d’exploitation des données. Chez Smartpoint, nos architectes vous conseillent car être en capacités de comprendre les différentes architectures de données est primordial afin de concevoir et mettre en œuvre des systèmes data efficaces : traitement par lots, traitement en flux, architecture Lambda, entrepôt de données, le lac de données, microservices, (…)

Data Mesh, architecture miracle pour libérer enfin la valeur promise des data ?

17 mai 202317 mai 2023

0 commentaires

Au-delà du concept et des principes d’architecture, est-ce que le Data Mesh est viable à l’épreuve de réalité des organisations et des SI data ? Est-ce que cette architecture décentralisée et orientée domaine fonctionnel, qui permet une exploitation des données en libre-service, est la hauteur des promesses ?

Voici les principaux écueils à anticiper.

En tant que pure-player de la Data, nous en avons connu chez Smartpoint des architectures de données … Et nous savons à quel point il est complexe de trouver, de concevoir, de mettre en œuvre la bonne solution et de briser enfin les silos. On sait aujourd’hui qu’environ 80% des projets de Data Warehouses ont échoué et il y a déjà presque 10 ans, Gartner prédisait que 90% des Data Lakes seraient finalement inutiles. Il est vrai aussi que l’on sait qu’une équipe Data centralisée est souvent débordée et manque d’expertises par domaines métiers, ce qui nuit invariablement à la découverte et à la création de valeur data.

Revenons sur les principes fondamentaux qui caractérisent le Data Mesh ou Maillage de données tel que promus par Zhamak Dehghani(ThoughtWorks) en alternative aux structures de données centralisées et monolithiques :

1. Domain-driven ownership of data : Les données sont considérées comme des actifs appartenant à des domaines spécifiques au sein de l’organisation. Chaque domaine est responsable de la production, de l’amélioration de la qualité des données et de la gestion. Cette approche permet de créer des équipes spécialisées, composées d’experts métier et techniques, qui travaillent en étroite collaboration pour définir les normes et les règles spécifiques à leur domaine. Leur objectif est de répondre aux besoins de leur domaine fonctionnel en terme d’exploitation des données, tout en favorisant la réutilisation et l’interopérabilité entre les différents domaines métiers.

2. Data as a product : Les données sont destinées à être consommées par les utilisateurs au sein de l’organisation. Les équipes data doivent se recentrer sur le client pour fournir des data sets de qualité, fiables et bien documentés. Elles créent des interfaces claires (API) et définissent des contrats pour la consommation des données. Ainsi, les utilisateurs peuvent découvrir, accéder et utiliser les données de manière autonome, comme un produit prêt à l’emploi. On est dans la même logique que les architectures microservices.

3. Self-service data platform : Les équipes data fournissent une plateforme de données en libre-service, qui facilite la découverte, l’accès et l’exploitation des données. Cette plateforme fournit des outils, des services et des interfaces qui permettent aux utilisateurs de trouver intuitivement et de consommer les données de manière autonome. Elle favorise l’automatisation et l’orchestration des flux de données, permettant ainsi aux équipes data de se concentrer sur la qualité et l’enrichissement des données plutôt que sur des tâches opérationnelles chronophages et à faible valeur ajoutée.

4. Federated computational governance : La gouvernance des données est décentralisée et répartie entre les différentes équipes. Chaque équipe a la responsabilité de définir et d’appliquer les règles et les normes spécifiques à son domaine. La gouvernance fédérée consiste à mettre en place des processus et des outils qui permettent de gérer et de contrôler les données de manière distribuée. Cela inclut la gouvernance des métadonnées, la sécurité, la conformité réglementaire, ainsi que la prise de décision collective et transparente sur les évolutions de l’architecture et des pratiques liées aux données.

Voici pourquoi une architecture data mesh pourrait se révéler être un échec dans certaines organisations où les notions de produit data ou de propriété de domaines sont difficilement applicables.

• Toutes les données n’ont pas forcément une valeur, c’est même le contraire. La plupart des données collectées sont inutiles et brouillent l’information car elles ne sont pas pertinentes. Dans les faits, c’est compliqué d’identifier dans la masse celles qui sont réellement précieuses et potentiellement génératrice de valeur. C’est un véritable chantier en soi, complexe et laborieux. Un travail de chercheur d’or !
• Produire des données est une charge supplémentaire ! Certes le concept de data product est séduisant et facile à appréhender mais dans la réalité du terrain, les ingénieurs data doivent déjà les créer … Et les transformer en plus par domaine nécessite d’élargir encore leurs compétences. Certes les avancées en IA, automatisation, et autres Low Code promettent de leur faciliter la tâche mais c’est encore une promesse qui reste à éprouver.
• On en vient naturellement à la troisième difficulté : le manque de compétences data disponibles. Le Data Engineering, c’est un métier de spécialiste de la gestion des données et nous savons qu’il est rare de trouver des professionnels qui en maîtrise toute la palette ! Déléguer la responsabilité à des équipes par domaine, sans compétences spécialisées en data, peut générer des problèmes sans aucun doute.
• La gouvernance fédérée est aussi une évidence sur le papier. Dans les faits, ce n’est pas applicable sans de fortes contraintes avec un véritable régime central très autoritaire qui encadre les comportements et contrôle régulièrement les usages. En effet, si la gouvernance des données est détenue par une guilde fédérée composées de représentants de différents domaines, cela risque fortement d’être inefficace car chaque département a ses propres règles et priorités.
• Une plateforme centralisée en libre-service fait rêver mais dans les faits, mettre en place ce type de solution se révèle très complexe car on est confronté à une variété vertigineuse de formats de données, une pluralité de systèmes et d’applications différents, de différentes versions voire de générations. Certes, nous disposons aujourd’hui de nombreux outils pour ingérer massivement les données et de larges bibliothèques de connecteurs … mais on peut rapidement retomber dans les travers du data warehouse.

Pour conclure, une architecture Data Mesh est très intéressante, mais au là du concept, il faut en mesurer les risques, les écueils et ses limites.

Voici les principaux avantages qui méritent qu’on étudie sa faisabilité et sa mise en pratique dans votre SI Data :

1. Démocratisation de l’exploitation des données par un plus grand nombre (au delà des data scientist) via les applications en libre service
2. Réduction des coûts car cette architecture distribuée est davantage #Cloud native avec des pipeline de collecte des données en temps réel (paiement à la consommation en terme de stockage)
3. Interopérabilité car les données sont normalisées indépendamment du domaine et les consommateurs s’interfacent par APIs.
4. Renforcement de la sécurité et de la gouvernance des données car les normes sont appliquées au-delà du domaines ainsi que la gestion des droits et des accès (journalisation, observabilité).

Sources :

• L’échec des projets de datawarehouses : https://www.dbta.com/Editorial/Think-About-It/Why-a-Majority-of-Data-Warehouse-Projects-Fail-and-What-Businesses-Can-Do-145910.aspx
• Dès 2014, Gartner prévoyait qu’en 2018, 90% des data lakes déployés seraient inutiles car ils seront submergés d’informations capturées pour des cas d’utilisation incertains. Relire les prédictions de l’époque : https://blogs.gartner.com/merv-adrian/2014/12/30/prediction-is-hard-especially-about-the-future/
• 6 raisons pourquoi le Data Mesh va échouer : https://medium.com/@hannes.rollin/six-reasons-why-data-mesh-will-fail-195886c89bdd