Les outils d’IA d’entreprise évoluent bien plus vite que la plupart des architectures de données. Un lakehouse qui fonctionne bien pour les projets actuels d’analytique et de machine learning peut devenir plus difficile à adapter si ses tables, ses catalogues, sa gouvernance ou ses choix de calcul sont trop étroitement liés à une seule plateforme.
Personne ne peut savoir quels modèles, agents, moteurs d’analytique ou services cloud seront importants dans plusieurs années. Les organisations peuvent néanmoins garder le contrôle de la fondation de données dont dépendent ces outils. Les formats de tables ouverts, des métadonnées interopérables, une gouvernance cohérente et un déploiement flexible peuvent faciliter l’adoption de nouveaux outils d’analytique et d’IA sans déplacer ou reconstruire à répétition les données sous-jacentes.
- Les formats ouverts assurent la portabilité de la couche de données
- L’interopérabilité ne dépend pas uniquement d’Iceberg
- La flexibilité de l’IA commence par les données
- Les environnements hybrides font du placement des charges de travail un choix d’architecture
- Les choix opérationnels peuvent néanmoins limiter la flexibilité
Les formats ouverts assurent la portabilité de la couche de données
Le format de table d’un lakehouse influe sur bien plus que l’organisation des fichiers. Il détermine également la manière dont différents moteurs interprètent les changements de données, gèrent les transactions et localisent les informations nécessaires à l’exécution d’une requête.
Apache Iceberg fournit une méthode ouverte pour gérer de grandes tables analytiques, avec la prise en charge des transactions ACID, de l’évolution des schémas et des partitions, des instantanés et du voyage dans le temps. guide de migration Iceberg de Cloudera décrivait également la prise en charge de Spark, Hive, Flink, Impala, Trino et Presto. Différents moteurs peuvent donc travailler avec les mêmes tables sous-jacentes, au lieu de nécessiter une copie dédiée pour chaque charge de travail.
Le Market Guide for Data Lakehouse Platforms de Gartner identifiait les formats de tables ouverts, le stockage objet, la séparation du calcul et du stockage, ainsi que l’unification des métadonnées et de la gouvernance comme des caractéristiques fondamentales des lakehouses. Le cabinet recommandait de vérifier que la plupart des données du lakehouse sont stockées dans un format ouvert et partageable, plutôt que principalement dans un stockage propriétaire.
Les data lakehouses combinent la flexibilité et l’évolutivité d’un data lake avec des fonctionnalités traditionnellement associées aux entrepôts de données. Un format de table ouvert peut rendre ces données partagées moins dépendantes du moteur de traitement qui les utilise aujourd’hui.
L’interopérabilité ne dépend pas uniquement d’Iceberg
La prise en charge d’Iceberg ne rend pas automatiquement chaque composant d’un lakehouse portable. Les catalogues, les services de métadonnées, les contrôles de sécurité, les API et les outils opérationnels peuvent eux aussi créer des dépendances.
Le catalogue REST Iceberg peut réduire une autre source de friction en standardisant la manière dont les moteurs se connectent à un catalogue. Grâce à une interface partagée, différents outils peuvent découvrir et utiliser les mêmes tables sans nécessiter une connexion personnalisée au catalogue pour chaque plateforme.
Le partage de fichiers ne garantit pas que différents moteurs utiliseront les données de manière cohérente. Chaque moteur a également besoin d’une vue cohérente des instantanés et des métadonnées des tables, de contrôles de sécurité appropriés et d’un moyen fiable de coordonner les changements lorsque plusieurs charges de travail utilisent les mêmes tables.
Gartner conseillait de même aux acheteurs de vérifier si les interfaces du lakehouse suivent des standards ouverts afin que les données restent partageables entre les outils.
Une plateforme peut prendre en charge Iceberg tout en introduisant des dépendances ailleurs dans la pile. Si l’ajout d’un autre moteur nécessite une nouvelle copie des données, un pipeline personnalisé ou un modèle de gouvernance distinct, changer d’outils par la suite peut malgré tout devenir difficile.
L’interopérabilité dépend également d’une gouvernance qui reste cohérente entre les outils et les environnements. Les métadonnées, la traçabilité, les politiques et les contrôles d’accès doivent rester utiles à mesure que de nouveaux moteurs et de nouvelles charges de travail d’IA sont ajoutés, plutôt que de créer un nouvel ensemble de règles déconnectées pour chaque plateforme.
La flexibilité de l’IA commence par les données
À mesure que les organisations ajoutent de nouvelles charges de travail d’IA, les différents cas d’usage peuvent nécessiter des modèles, des outils de recherche, des systèmes vectoriels, des frameworks d’agents et des moteurs de traitement différents. Un lakehouse capable d’accueillir ces choix sans reconstruire la couche de données laisse aux équipes davantage de marge pour changer d’outils à mesure que leurs besoins évoluent.
Le Q3 2026 Data Lakehouses Wave de Forrester identifiait les formats de tables ouverts, les standards de métadonnées interopérables, le partage de données sans copie et les API extensibles comme des fonctionnalités clés des lakehouses prenant en charge l’IA agentique. Le rapport soulignait que les modèles, les outils et les workflows continuent d’évoluer, ce qui renforce la valeur d’une architecture capable de se connecter à différentes technologies.
L’aptitude à l’IA dépend également de la qualité, du contexte et de la gouvernance des données sous-jacentes. Dans une étude d’IDC parrainée par Cloudera, 51,6 % des 353 organisations donnant la priorité à la préparation des données pour l’IA ont cité l’intelligence des données, qui englobe la qualité des données, la catalogage, la traçabilité, les métadonnées et les données de référence, parmi leurs deux principaux domaines d’intérêt. Une autre proportion de 37,9 % a cité la modernisation des données dans les data lakes, lakehouses, entrepôts et bases de données hybrides ou cloud.
La série de Cloudera sur les données prêtes pour les agents soulignait que les applications d’IA ont besoin de plus qu’un simple accès aux données. Une utilisation efficace dépend également de données disponibles en temps voulu, d’une visibilité sur leur provenance et leur utilisation, ainsi que du contexte et des garde-fous appropriés.
Lorsque des données gouvernées sont déjà disponibles via des systèmes interopérables, l’ajout d’une charge de travail d’IA ne doit pas nécessairement commencer par une nouvelle copie isolée du jeu de données. Les équipes disposent de davantage de latitude pour appliquer différents outils aux données lorsque les exigences évoluent.
Les environnements hybrides font du placement des charges de travail un choix d’architecture
La flexibilité d’un lakehouse dépend également de l’emplacement d’exécution nécessaire des données et des charges de travail. Les exigences réglementaires, la souveraineté des données, l’infrastructure existante, les impératifs de performance et les coûts du cloud peuvent tous maintenir certaines parties du patrimoine de données dans différents environnements.
IDC indiquait que 53 % des référentiels de données analytiques étaient stockés dans des environnements de cloud public, de cloud hybride ou multicloud, tandis que 47 % restaient exclusivement sur site ou dans des clouds privés. Le rapport citait notamment la réglementation, la souveraineté, l’optimisation des coûts et les besoins en calcul parmi les raisons de cette répartition.
Une conception qui suppose que chaque jeu de données finira par être déplacé vers un environnement unique peut être difficile à appliquer dans une grande organisation. Déplacer les données simplement pour prendre en charge un autre outil de traitement peut également ajouter un pipeline à gérer et une copie supplémentaire à gouverner.
La séparation du calcul et du stockage, associée à l’utilisation de formats ouverts, donne aux équipes davantage de liberté pour choisir où exécuter une charge de travail tout en continuant à utiliser des données gouvernées. Les données sensibles peuvent par exemple rester sur site ou dans un environnement privé, tandis que d’autres charges de travail utilisent des ressources de cloud public lorsque cette organisation est plus pertinente.
Cloudera applique cette approche dans les environnements hybrides. L’évaluation des lakehouses de Forrester en 2026 décrivait la plateforme comme prenant en charge les déploiements sur site, dans un cloud privé et dans un cloud public, avec un accès multidé moteur à Spark, Hive, Impala et Trino, ainsi que la gouvernance, la traçabilité, la sécurité et la gestion des métadonnées.
Le rapport mettait également en avant l’architecture ouverte de Cloudera et son interopérabilité avec les moteurs non-Cloudera, permettant aux organisations de conserver les plateformes existantes lorsqu’elles conviennent plutôt que de déplacer chaque charge de travail vers une pile unique.
Les choix opérationnels peuvent néanmoins limiter la flexibilité
Les standards ouverts ne suppriment pas le travail nécessaire à l’exploitation d’un lakehouse à grande échelle. Les équipes doivent toujours prendre en compte la concurrence, la maintenance des tables, la croissance des métadonnées, les performances des charges de travail, la sécurité et la fiabilité.
Les recommandations de Cloudera pour la mise en production d’Iceberg soulignaient que les stratégies de partitionnement, la planification des tâches, les politiques de conservation et la fréquence des validations influent sur le comportement des tables en situation de concurrence et de changement continu. L’exécution de l’ingestion, de la maintenance et des requêtes sur les mêmes tables rend cette coordination particulièrement importante.
Gartner recommandait également d’évaluer les performances, la fiabilité, la capacité, la maintenabilité, la gestion des charges de travail et le cycle de vie global des données, plutôt que de choisir un lakehouse sur la seule base de ses fonctionnalités. Le cabinet notait aussi que des entrepôts de données dédiés peuvent rester plus performants pour certaines charges de travail optimisées d’entrepôt.
Éviter le verrouillage propriétaire demande donc davantage que le choix d’un format de table open source. Les architectes doivent examiner la manière dont le format de table, le catalogue, la couche de gouvernance, les moteurs de calcul, les interfaces et le modèle de déploiement fonctionnent ensemble, ainsi que les éléments qu’il faudrait modifier si l’un de ces composants était remplacé.
Les futurs projets d’IA introduiront de nouvelles exigences, mais le coût de leur prise en charge dépendra largement de l’architecture de données sous-jacente. Les formats ouverts, les interfaces interopérables, une gouvernance cohérente et un placement flexible des charges de travail peuvent faciliter l’adoption de nouveaux outils sans transformer chaque évolution technologique en une nouvelle migration de données.
Vous recherchez la plateforme de gouvernance de l’IA adaptée à vos besoins ? Consultez le guide d’eWeek consacré aux meilleurs outils de gouvernance de l’IA pour comparer les principales options et leurs points forts.