La course à la plateforme de données IA pousse simultanément les fournisseurs d’infrastructure vers le haut de la pile et les éditeurs de bases de données et de lacs de données vers le bas. Les uns intègrent nativement l’orchestration, la vectorisation et la gouvernance des données dans leurs couches de stockage ; les autres, les éditeurs, descendent vers l’infrastructure transactionnelle. Une recomposition dont les implications pour la stratégie d’achat, la gouvernance et la souveraineté des données méritent une analyse.
L’intégration verticale de la pile de données IA s’effectue par les deux extrémités du modèle. D’un côté, les fournisseurs d’infrastructure remontent vers les couches hautes, l’orchestration, la vectorisation et la gouvernance des données. De l’autre, les plateformes de données descendent vers l’infrastructure transactionnelle et absorbent les outils spécialisés qui constituaient jusqu’ici des composants autonomes. Les organisations qui avaient construit des architectures modulaires en assemblant des briques indépendantes se retrouvent prises en étau entre ces deux mouvements. Ce n’est pas une évolution graduelle, c’est une recomposition qui redéfinit la stratégie d’achat, la gouvernance et la souveraineté des données.
Pendant plusieurs années, la doctrine dominante en matière d’architecture de données reposait sur la modularité : choisir le meilleur outil pour chaque fonction, assembler les composants via des API standardisées, et conserver la flexibilité de substituer l’un d’eux sans tout reconstruire. Un entrepôt de données pour l’analytique SQL, un lac de données pour les flux non structurés, une base vectorielle pour le RAG, un orchestrateur de pipeline pour l’ingestion, un outil de gouvernance pour le catalogage. Cette approche permettait d’adopter les meilleures solutions du marché sans s’enfermer dans un écosystème propriétaire unique.
Cette doctrine est aujourd’hui sous pression de deux côtés du pipeline simultanément. Les fournisseurs d’infrastructure ont franchi la frontière du stockage pour intégrer nativement les fonctions de préparation, de vectorisation et d’orchestration des données. Au même moment, les plateformes de données ont franchi la leur en sens inverse : Databricks a racheté Neon, une base de données PostgreSQL serverless, pour étendre sa présence sur les charges OLTP, pendant que Snowflake rachetait Crunchy Data pour le même motif. Les deux acquisitions, annoncées à quelques semaines d’intervalle en 2025, matérialisent leur intention d’occuper la pile de bout en bout.
Du lac de données à la plateforme d’intelligence
La trajectoire de Databricks illustre la logique de la compression par le haut. Née sur Apache Spark, la société a progressivement étendu sa plateforme vers l’entrepôt de données avec Databricks SQL et le moteur Photon, vers l’ingestion avec Lakeflow — qui a atteint la disponibilité générale en 2025 en couvrant l’ingestion, la transformation ETL et l’orchestration en un seul composant — et vers l’IA avec la suite Mosaic AI, qui intègre la recherche vectorielle, le service de modèles et les Agent Bricks pour l’orchestration d’agents IA en production. L’acquisition de MosaicML pour 1,3 milliard de dollars, puis celle de Neon, ont comblé les deux derniers angles morts, la couche de calcul GPU et la base de données transactionnelle.
Snowflake suit une trajectoire parallèle depuis une position de départ différente. Conçu comme un entrepôt de données cloud-natif, il a étendu son périmètre vers les formats ouverts avec Apache Iceberg, vers l’IA avec Cortex AI — qui dépasse 9 100 comptes actifs en fin 2025 — et vers le développement d’applications avec Streamlit et Snowpark. Comme Databricks, il a absorbé PostgreSQL via l’acquisition de Crunchy Data pour couvrir les charges transactionnelles. Les deux plateformes convergent vers le même positionnement : une fondation de données unifiée et gouvernée sur laquelle peuvent s’exécuter l’analytique, l’IA et les applications. Le résultat est sans équivoque : après les sommets Databricks et Snowflake de 2025, de nombreux éditeurs de solutions spécialisées ont vu leurs fonctionnalités absorbées et rebaptisées en simples « fonctionnalités » des grandes plateformes.
Quand l’infrastructure absorbe la gouvernance des données
Le mouvement inverse est tout aussi structurel. Everpure lance Data Stream, un pipeline automatisé d’ingestion jusqu’à l’inférence, développé avec Supermicro sur la base de l’architecture de référence Nvidia AI Data Platform. NetApp lance AI Data Engine, qui enrichit les métadonnées sur place sans déplacer les données, couvrant la sélection, la transformation et la mise à disposition pour les agents. Vast Data, fondée en 2016 comme spécialiste du stockage flash pour le calcul intensif, revendique désormais le titre d’AI Operating System avec une pile unifiée — DataStore, DataBase, DataEngine, InsightEngine, AgentEngine — qui prétend couvrir du stockage jusqu’au déploiement d’agents en production.
Ces fournisseurs ne remontent pas dans la pile par hasard, Ils répondent à un verrou opérationnel persistant dans les entreprises : les projets IA échouent à passer en production non pas faute de modèles performants, mais faute de données correctement préparées et acheminées. La couche de gouvernance, catalogage, classification, vectorisation, politique d’accès, est le maillon que leurs clients assemblaient manuellement, à coût élevé. En l’intégrant nativement dans la couche de stockage, ils se substituent à des outils qui auraient autrement été achetés séparément. Ce faisant, ils s’installent dans un nœud incontournable de la chaîne de traitement de l’IA.
L’étau : ce que les organisations modulaires ont à perdre
Pour les entreprises qui ont construit des architectures en assemblant des composants indépendants, la situation produit une forme de compression inédite. Les outils sélectionnés pour leurs qualités spécifiques — une base vectorielle performante, un orchestrateur de pipeline précis, un catalogue de métadonnées ouvert — sont désormais des fonctionnalités intégrées dans des plateformes plus larges. Continuer à les opérer séparément implique de maintenir des intégrations avec des plateformes qui ne les considèrent plus comme des partenaires, mais comme des concurrents sur leur propre terrain.
La question posée aux équipes d’architecture n’est donc plus « quel est le meilleur outil pour cette fonction ? », mais « quelle plateforme intégrée suis-je prêt à accepter comme point de gravité de mon architecture de données ? ». Ce glissement est fondamental : il transforme une décision technique en décision stratégique, avec des implications sur la dépendance au fournisseur, la portabilité des données et la capacité de négociation à long terme. Les DSI qui ne posent pas explicitement la question de la portabilité des métadonnées et de la transférabilité des pipelines dans leurs appels d’offres actuels risquent de se retrouver dans dix-huit mois avec un enfermement dont ils n’auront pas mesuré les termes au moment de la signature.
Souveraineté et Cloud Act : la couche sémantique comme angle mort
Cette recomposition soulève aussi des questions de souveraineté, que ni les fournisseurs d’infrastructure ni les plateformes de données n’abordent dans leurs communications. Everpure, NetApp, Vast Data, Databricks et Snowflake sont tous des acteurs américains, soumis au Cloud Act. Lorsque la couche sémantique — métadonnées enrichies, catalogues, politiques de classification, vecteurs représentant le contenu des données d’entreprise — est hébergée et opérée par l’un de ces acteurs, l’exposition à une injonction extraterritoriale porte désormais sur bien plus que les données brutes. Elle porte sur la description structurée de ce que valent ces données, de ce qu’elles contiennent et de la façon dont elles alimentent les décisions de l’organisation.
Pour les organisations soumises au RGPD, à NIS2 ou à DORA, trois clauses méritent une attention systématique dans tout appel d’offres portant sur ces plateformes intégrées : la portabilité des métadonnées et des catalogues dans un format ouvert et documenté, les conditions d’hébergement de la couche sémantique et son isolation des systèmes exposés au Cloud Act, et les modalités de réversibilité en cas de changement de plateforme. La séparation architecturale explicite entre la couche de stockage et la couche d’orchestration — même au prix d’une complexité opérationnelle accrue — reste la seule option qui préserve une flexibilité réelle. Ce choix a un coût. Il représente une assurance de gouvernance dont la valeur se mesure sur la durée du cycle de vie de l’infrastructure.
