En observant les annonces des dix-huit derniers mois, un constat s’impose. Éditeurs de cybersécurité, spécialistes de l’API Management, plateformes de données, fournisseurs cloud et acteurs nés avec l’IA développent des fonctions qui répondent aux mêmes problématiques. Leur objectif : contrôler les appels aux modèles de langage, appliquer des politiques de sécurité, maîtriser les coûts et gouverner les agents, tout en traçant leurs interactions et en limitant la dépendance à un fournisseur unique.

Tous cherchent, avec des approches différentes, à devenir le point de contrôle entre le système d’information et l’IA.

Dans l’histoire des infrastructures IT, ce type de convergence a souvent annoncé l’émergence d’une nouvelle catégorie de logiciels. Mais elle peut aussi annoncer autre chose : une course où chaque acteur tente d’imposer son propre control plane, au risque de recréer, autour de l’IA, la fragmentation que les AI Gateways sont précisément censés résoudre.

Les éditeurs cyber veulent protéger les agents

Les plateformes de cybersécurité ont été conçues pour protéger des utilisateurs, des postes de travail, des serveurs ou des applications. L’essor des agents IA introduit une nouvelle catégorie d’entités numériques : elles disposent de droits d’accès, utilisent des identités techniques, consultent des données et exécutent des actions de façon autonome. Elles deviennent donc elles-mêmes une nouvelle surface d’attaque.

Le cas de Palo Alto Networks illustre bien cette bascule, avec un calendrier resserré. En mars 2026, l’éditeur lance Prisma AIRS 3.0, avec un module « AI Agent Gateway » alors en accès limité. Fin avril, il annonce son intention de racheter Portkey, l’un des éditeurs d’AI Gateway les plus établis ; l’acquisition est finalisée le 29 mai. Six semaines plus tard, le 22 juillet, il annonce la disponibilité générale de Prisma AIRS AI Gateway, qui intègre directement la technologie de Portkey.

Dans sa communication, Palo Alto Networks avance un chiffre destiné à illustrer l’accélération du phénomène. Selon les données observées par l’éditeur, la part du trafic réseau d’entreprise liée au protocole MCP serait passée de 11 % fin 2025 à plus de 41 % à la mi-2026. Un chiffre fourni par l’éditeur, à considérer comme un indicateur de tendance plutôt que comme une mesure indépendante du marché.

CrowdStrike suit une trajectoire différente, centrée sur l’identité des agents. En juin dernier, l’éditeur lance « Continuous Identity for AI Agents », une fonctionnalité de Falcon issue de la technologie de SGNL, rachetée pour 740 millions $. Le principe est de réévaluer en permanence les droits d’un agent, action après action, plutôt que de lui accorder un accès permanent. CrowdStrike ne cherche toutefois pas à devenir lui-même une AI Gateway. L’éditeur mise sur une stratégie d’écosystème, avec des intégrations à plusieurs gateways, dont Kong, LiteLLM, Databricks, Microsoft Azure, TrueFoundry et Google Cloud

Cisco avance sur un terrain proche avec Duo, qui traite désormais l’agent comme un objet d’identité à part entière, avec ses propres règles d’authentification et son propre cycle de vie. Zscaler, enfin, a présenté en juin 2026 ce qu’il revendique comme la première plateforme Zero Trust complète pour l’IA agentique, avec un « AI Broker » pour l’accès aux agents et un « AI Access Graph » pour cartographier les liens entre identités, applications et données. Une extension directe de sa logique réseau historique aux flux agent-à-agent et aux appels MCP, plus difficiles à intercepter que du trafic utilisateur classique.

Ces trajectoires différentes traduisent une même logique : chaque cyberéditeur cherche à prolonger son point de contrôle historique jusqu’aux agents. L’AI Gateway devient ainsi l’une des nouvelles interfaces de la logique Zero Trust où l’on vérifie non seulement qui est autorisé à agir mais aussi ce que l’agent peut faire et dans quel contexte.

Les spécialistes des API veulent éviter d’être contournés

Pour les acteurs de l’API Management, la problématique est différente. Depuis quinze ans, les API Gateway occupent une place stratégique dans les systèmes d’information : une part importante des échanges applicatifs y transite, et les équipes d’architecture y définissent l’authentification, la limitation de débit, la supervision et le routage.

L’IA pourrait remettre en cause cette position. Si les développeurs appellent directement les modèles de langage sans passer par l’infrastructure existante, une partie croissante des échanges risque d’échapper aux plateformes de gouvernance déjà en place. Les spécialistes des API cherchent donc à étendre leur périmètre plutôt qu’à laisser une infrastructure parallèle émerger.

L’exemple de Kong est représentatif : l’éditeur présente son AI Gateway comme une extension de plugins sur sa plateforme Kong Konnect existante. Les flux applicatifs continuent de transiter par la même infrastructure, mais sont désormais aussi dirigés vers des modèles de langage, avec les mêmes mécanismes d’authentification et de quotas déjà en place pour les API classiques.

Google fait évoluer Apigee dans une direction similaire, en l’articulant à la nouvelle plateforme d’agents que le groupe a lancée en avril 2026 en rebaptisant Vertex AI en Gemini Enterprise Agent Platform. Un changement qui va au-delà du nom, puisqu’il absorbe aussi Agentspace et repositionne l’ensemble autour de la construction, du déploiement et de la gouvernance d’agents plutôt que du seul entraînement de modèles.

D’autres éditeurs d’API Management plus spécialisés, comme Gravitee, Tyk ou WSO2, suivent une trajectoire comparable en ajoutant des fonctions de routage LLM, de gouvernance MCP et de suivi des coûts d’inférence à leurs plateformes existantes.

Le principe reste le même dans tous les cas : réutiliser les mécanismes déjà déployés pour les API ( authentification, quotas, journalisation, observabilité ) plutôt que de les faire reconstruire par chaque équipe projet pour l’IA. L’IA ne crée pas une infrastructure parallèle ; elle prolonge l’architecture existante.

Les plateformes de données veulent rapprocher les agents des données

Une troisième famille avance avec une approche différente : les plateformes de données. La conviction est que la valeur de l’IA ne réside pas uniquement dans le modèle, mais surtout dans les données auxquelles il accède.

Snowflake en fournit une première illustration. Fin mai 2026, l’éditeur annonce l’acquisition de Natoma, spécialiste de la gouvernance du protocole MCP. Deux mois plus tard, il lance Cortex AI Gateway pour contrôler les interactions des agents avec les modèles, les outils, les serveurs MCP et les données de l’entreprise.

La solution s’adresse aussi bien aux agents natifs de Snowflake qu’à ceux développés sur des plateformes tierces comme Claude Code ou Cursor, et s’intègre notamment avec Okta, SailPoint et 1Password pour la gestion des identités.

Databricks suit une trajectoire comparable avec Unity AI Gateway. Construit sur Unity Catalog, le service transpose aux modèles et aux agents les mécanismes de gouvernance déjà appliqués aux données : permissions, traçabilité et audit. Il ajoute des fonctions spécifiques à l’IA, comme le contrôle des dépenses, le routage entre fournisseurs et la prévention des fuites de données personnelles.

Databricks revendique déjà plusieurs milliers de clients utilisant Unity AI Gateway, dont Rivian, Asana et Edmunds. Selon l’éditeur, plus d’un quadrillion de tokens ont transité par la gateway au cours des douze derniers mois.

L’éditeur a par ailleurs choisi une approche ouverte en intégrant à Unity AI Gateway des spécialistes de la sécurité, dont CrowdStrike, Palo Alto Networks et Zscaler. L’objectif est de permettre aux entreprises de conserver leurs outils de sécurité existants tout en les appliquant aux interactions avec les modèles, les agents et les outils. Une logique d’écosystème qui contraste avec les plateformes cherchant à intégrer l’ensemble des fonctions de sécurité en interne.

Les annonces successives de Snowflake et Databricks montrent que la gouvernance des agents est en train de devenir un nouveau terrain de concurrence pour les plateformes Data & IA. Leur avantage est de pouvoir prolonger vers les modèles et les agents les politiques de contrôle déjà appliquées aux données, sans nécessairement ajouter une couche de gouvernance indépendante.

Les hyperscalers avancent en ordre dispersé

Une quatrième famille d’acteurs, les hyperscalers, aborde le problème sous un angle différent : intégrer les fonctions de gouvernance de l’IA à leur propre environnement plutôt que de les vendre comme un produit autonome.

AWS a lancé Amazon Bedrock AgentCore Gateway, qui fournit un point d’accès unique aux agents pour accéder à des outils, des serveurs MCP et d’autres agents via A2A. La plateforme peut également router les requêtes vers différents fournisseurs de modèles et connecter des services comme Salesforce, Slack, Jira ou Asana.

Microsoft combine deux briques complémentaires. Azure API Management fournit les fonctions d’AI Gateway, tandis qu’Entra Agent ID, disponible généralement depuis mai 2026, attribue une identité propre aux agents et permet d’en contrôler les accès, y compris lorsqu’ils sont construits sur des plateformes tierces.

Google a choisi une approche plus intégrée. Avec le lancement de Gemini Enterprise Agent Platform, qui succède à Vertex AI, l’éditeur regroupe dans une même plateforme la construction, le déploiement et la gouvernance des agents, plutôt que de présenter l’AI Gateway comme une brique autonome.

L’avantage de cette approche est net pour une DSI déjà engagée sur un cloud donné : l’identité, la facturation et une partie de l’observabilité restent dans le même environnement, sans couche supplémentaire à opérer. La contrepartie l’est tout autant : dans un contexte multicloud, ces trois approches ne se substituent pas les unes aux autres, et une entreprise utilisant AWS, Azure et Google Cloud simultanément peut se retrouver avec trois mécanismes de gouvernance de l’IA distincts plutôt qu’une couche transverse unique.

Les acteurs AI-native : les pionniers de la gateway IA

Une dernière catégorie est née directement avec les applications d’IA. Des acteurs comme LiteLLM, Helicone, OpenRouter ou Portkey ont construit leurs offres autour de besoins apparus avec les LLM : router les requêtes entre plusieurs modèles et fournisseurs, suivre la consommation, gérer les clés et les coûts ou observer les interactions des agents.

Portkey illustre toutefois la difficulté pour ces spécialistes de conserver leur indépendance lorsque le marché se structure. Racheté par Palo Alto Networks en mai 2026, l’éditeur montre comment les fonctions développées par les acteurs AI-native peuvent être progressivement intégrées à des plateformes plus larges de cybersécurité, d’API Management, de données ou de cloud.

Ce que révèle cette convergence

Le rapprochement de ces cinq familles d’acteurs montre que l’AI Gateway devient une couche stratégique de contrôle de l’IA. Mais cette convergence ne conduira pas forcément à une gateway unique : le marché pourrait plutôt voir coexister plusieurs briques capables de coopérer.

Pour les DSI, la question sera donc de savoir où placer le point de contrôle principal et comment faire interagir les autres briques avec lui. Faute de coordination, la multiplication des offres pourrait paradoxalement recréer une nouvelle fragmentation de la gouvernance de l’IA.

The post AI Gateway : la bataille pour le contrôle de l’IA appeared first on Silicon.fr.

En dix ans, la gestion des données d’entreprise a radicalement changé. L’explosion des volumes exige désormais des infrastructures informatiques très performantes. Ces nouveaux systèmes doivent allier puissance de calcul et stockage flexible. Sur ce marché compétitif, Snowflake et Databricks s’imposent parmi les leaders mondiaux.

L’année 2026 consacre une convergence technique marquée entre ces deux géants. Snowflake dépasse le cadre de l’entrepôt classique et Databricks optimise son lac de données. Les deux solutions s’affrontent désormais directement sur les mêmes cas d’usage. Cette étude analyse leurs architectures, leurs performances et leurs coûts réels.

L’état actuel du marché des plateformes de données

Longtemps, le choix d’une architecture de données était binaire. Les entreprises achetaient un entrepôt pour le décisionnel ou un lac pour les données brutes. Aujourd’hui, cette frontière s’est atténuée grâce à l’unification des plateformes. Le stockage de masse permet désormais d’exécuter des requêtes rapides sur tous les formats.

Cette fusion complexifie le choix des décideurs face à des outils en apparence identiques. La différence ne se fait plus sur le stockage, mais sur la philosophie d’exécution. De plus, l’essor de l’IA générative exige que la plateforme serve de moteur aux grands modèles de langage. Enfin, les enjeux de souveraineté imposent un contrôle fort de l’hébergement.

Cette intégration cloud s’accompagne d’une surveillance budgétaire accrue pour éviter les dérives financières. L’optimisation des coûts dicte désormais les choix architecturaux. Les entreprises refusent le verrouillage technologique qui rend les migrations futures trop complexes. L’interopérabilité des formats ouverts devient ainsi une exigence incontournable.

L’évolution de l’architecture Cloud native propre à Snowflake

Snowflake s’est imposé grâce à une innovation clé : la séparation du stockage et du calcul. Cette architecture met fin aux contraintes des systèmes traditionnels. Les entreprises ajustent leur puissance informatique indépendamment du volume de données stockées. Ce découplage offre une grande flexibilité dans la gestion du cloud.

Les données sont logées dans des micro-partitions optimisées et indexées automatiquement. Plusieurs clusters de calcul peuvent interroger simultanément les mêmes tables sans conflit. La puissance informatique démarre très vite et s’arrête à la fin des calculs. Cette mise en veille automatique réduit le gaspillage lié aux serveurs inactifs.

Pour éviter la duplication des fichiers, la plateforme prend aussi en charge les formats ouverts. Le moteur interroge directement les données brutes situées dans vos propres espaces cloud. L’intégration native d’Apache Iceberg améliore l’interopérabilité avec le stockage interne. Les entreprises maintiennent une gouvernance stricte sans subir un verrouillage propriétaire trop fort.

La puissance du traitement de masse standardisée par Databricks

Databricks est né d’Apache Spark, le moteur de calcul en mémoire développé à l’université de Berkeley. Ce moteur traite les données en mémoire avec une rapidité élevée. Pour le stockage, la plateforme utilise le format ouvert Delta Lake. Ce format apporte des transactions ACID pour sécuriser les fichiers.

Son moteur d’exécution moderne, développé en C++, pousse encore plus loin les performances de calcul. Il optimise l’usage des processeurs pour traiter des pétaoctets d’informations en un temps record. L’architecture intègre nativement le traitement par lots et la gestion des flux en temps réel. Les pipelines associent ainsi vitesse brute et stabilité opérationnelle.

L’environnement propose des notebooks collaboratifs adaptés à Python, SQL, Scala ou R. La plateforme orchestre automatiquement les tâches et déploie l’infrastructure nécessaire à leur exécution. En cas d’erreur, un mécanisme de reprise automatique limite les interventions manuelles. Enfin, une traçabilité de bout en bout cartographie le parcours précis de la donnée.

La fusion des modèles analytiques à travers le Lakehouse

Pendant des années, les entreprises ont maintenu deux infrastructures informatiques parallèles. Elles séparaient le lac pour les données brutes et l’entrepôt pour le décisionnel. Cette duplication entraînait des coûts massifs et de fréquents problèmes de synchronisation. Le concept architectural de Lakehouse est né pour unifier ces deux mondes.

Ce modèle moderne rapproche les fonctionnalités de l’entrepôt et du lac. Une seule copie de la donnée sert désormais à tous les besoins d’analyse. Les scientifiques et les experts métiers travaillent ainsi sur le même référentiel unifié. Cela élimine les transferts complexes et accélère la prise de décision stratégique.

La standardisation s’organise désormais autour du format ouvert Apache Iceberg. Ce protocole de table permet à différents moteurs de coexister avec peu de barrières. Les équipes lisent et modifient les fichiers sans opération de conversion technique. Cette interopérabilité réduit le verrouillage technologique et libère enfin le stockage.

Performance en Business Intelligence et vitesse du moteur SQL

La vitesse des tableaux de bord reste essentielle pour les équipes métiers. Le moteur de requêtes de Snowflake excelle grâce à son optimisation automatique. L’architecture gère la concurrence en lançant des clusters de calcul supplémentaires. Chaque utilisateur bénéficie d’une performance stable sans ralentissement majeur.

Les tests de performance valident l’efficacité de ses micro-partitions. Un système de cache intelligent évite aussi de recalculer les mêmes requêtes. De son côté, Databricks progresse avec son offre SQL serverless. Les analystes n’attendent plus le démarrage de serveurs complexes pour travailler.

Cette puissance de calcul instantanée rivalise avec les meilleurs entrepôts du marché. Le moteur accélère grandement les jointures complexes sur le format Delta Lake. Des connecteurs natifs réduisent la latence vers les outils de Business Intelligence. Les utilisateurs profitent d’une interface familière connectée au Big Data.

Modèle économique et optimisation des coûts des plateformes

Le modèle financier de Snowflake repose sur la consommation de crédits virtuels. Chaque taille de cluster informatique correspond à un tarif horaire clair et transparent. La facturation s’ajuste à la seconde selon l’utilisation réelle des serveurs. La configuration de la mise en veille automatique reste le levier de contrôle principal.

Cette flexibilité par département offre une bonne prévisibilité budgétaire globale. Cependant, l’élasticité automatique du système peut engendrer des surprises financières rapides. Une requête mal optimisée lancée sur un entrepôt géant consomme immédiatement d’importantes ressources. Une surveillance stricte des quotas de calcul et des droits d’accès s’avère indispensable.

Quant à Databricks, il facture son service via des unités de calcul spécifiques. S’y ajoute le coût brut de l’infrastructure prélevé par votre fournisseur cloud. Ce modèle devient particulièrement rentable pour certains traitements industriels de grande ampleur. L’absence de marge sur le stockage brut réduit ainsi le coût total de possession.

L’intégration de l’intelligence artificielle générative par Snowflake

Snowpark permet à Snowflake de dépasser le cadre du langage SQL traditionnel. Cette fonctionnalité exécute du code Python ou Scala directement au sein de l’infrastructure. Les développeurs n’ont plus besoin d’extraire de gros volumes vers des serveurs externes. Les scripts s’exécutent ainsi en toute sécurité dans des environnements isolés.

Cette architecture renforce la stabilité du système avec les bibliothèques de science des données. Les ingénieurs encapsulent ensuite ces traitements complexes dans des fonctions stockées en base. Les analystes métiers appellent alors ces scripts via de simples requêtes SQL. Cette intégration native simplifie grandement le déploiement de vos applications.

En 2026, la suite managée Cortex AI intègre directement de grands modèles de langage. L’environnement propose des fonctions SQL natives pour résumer, traduire ou classifier vos textes. Ces outils avancés d’analyse ne requièrent aucune expertise en infrastructure d’intelligence artificielle. L’hébergement sécurisé protège les informations confidentielles au sein de l’entreprise.

La maturité opérationnelle du Machine Learning chez Databricks

Databricks utilise le projet open-source MLflow pour gérer le cycle de vie des modèles. Cet outil suit précisément leurs paramètres, leurs versions et leurs performances. Son intégration avec Unity Catalog centralise la gouvernance des données et du code. Les équipes tracent ainsi l’origine exacte des informations utilisées pour entraîner chaque IA.

Ce suivi rigoureux facilite le passage des modèles en production. Les ingénieurs déploient des API sécurisées en quelques clics. Un système de monitoring intégré surveille ensuite l’évolution de leurs performances dans le temps. La plateforme intègre aussi une recherche vectorielle native, essentielle pour les architectures RAG.

Le réentraînement des LLM open-source profite pleinement du calcul distribué. Les entreprises affinent ces modèles généraux sur leurs propres bases de connaissances. L’infrastructure répartit automatiquement la charge de travail sur des clusters de GPU. Cette maturité technique en fait un environnement très apprécié des ingénieurs en Deep Learning.

Gouvernance des données et sécurité des partages natifs

Snowflake et Databricks proposent des mécanismes stricts pour contrôler l’accès aux informations. Les politiques de sécurité s’appliquent de manière fine jusqu’au niveau de la ligne ou de la colonne. Le masquage dynamique protège les données sensibles selon le niveau d’habilitation de l’utilisateur. De plus, le chiffrement est activé par défaut, que les fichiers soient au repos ou en transit.

La traçabilité de l’origine de la donnée est largement automatisée par les deux systèmes. Les auditeurs visualisent ainsi l’historique complet d’une information depuis sa collecte jusqu’à ses transformations. Cette transparence technique simplifie grandement la mise en conformité réglementaire. Elle permet de répondre efficacement aux exigences strictes du RGPD ou de la norme HIPAA.

Pour le partage externe, Snowflake évite la copie de fichiers grâce à un mécanisme natif de tables partagées. Les données restent chez le producteur et le consommateur les interroge en temps réel. De son côté, Databricks utilise le protocole open-source Delta Sharing pour offrir une approche similaire. Ce standard sécurise les échanges même si le destinataire utilise une plateforme différente.

Opposition entre l’expérience SaaS et l’approche PaaS de Databricks

Snowflake fonctionne comme un SaaS clé en main. L’éditeur gère toute l’administration des serveurs, du partitionnement aux mises à jour logicielles. Cette automatisation forte libère les équipes des tâches de maintenance quotidiennes. Les entreprises exploitent ainsi leurs données sans avoir à recruter des experts en infrastructure.

À l’inverse, Databricks adopte un modèle PaaS axé sur le contrôle des ressources cloud. Les moteurs de calcul s’exécutent directement dans le réseau cloud privé de l’entreprise. Les ingénieurs configurent précisément la mémoire, les processeurs et le stockage requis. Cette flexibilité s’avère indispensable pour optimiser les calculs de masse les plus spécifiques.

Ces deux philosophies dictent vos besoins en compétences et votre gestion des risques. Snowflake accélère le lancement des projets grâce à sa simplicité opérationnelle immédiate. Databricks exige des profils pointus pour piloter, optimiser et sécuriser les ressources. Dans ce second modèle, une erreur de configuration peut vite provoquer des dérives budgétaires.

Critères de sélection selon les compétences et objectifs de l’entreprise

Privilégiez la Business Intelligence si votre activité dépend du décisionnel classique. Cette option est idéale pour les équipes d’analystes maîtrisant le langage SQL. Elle s’adresse aux entreprises qui exigent une simplicité opérationnelle et refusent la gestion d’infrastructure. Je vous conseille de valoriser les compétences internes tout en visant un retour sur investissement rapide.

À l’inverse, le Lakehouse ouvert convient mieux aux projets centrés sur l’ingénierie et l’intelligence artificielle. Ce choix cible les Data Scientists et les ingénieurs qui programment en Python ou en Scala. Il devient utile pour transformer d’immenses volumes de données brutes via des pipelines complexes. Ce modèle permet aussi de développer des applications d’IA générative sur mesure.

L’arbitrage dépend de vos besoins de partage et de votre vision technologique. Snowflake excelle dans la diffusion de tableaux de bord interactifs et sécurisés vers des utilisateurs externes. Databricks mise sur les formats open-source pour réduire le risque de verrouillage propriétaire. En 2026, la réussite de votre projet repose sur l’alignement de la plateforme avec les compétences de vos équipes.

Cet article Snowflake vs Databricks : quel est le meilleur outil de traitement de données en 2026 ? a été publié sur LEBIGDATA.FR.

Prenez Neon. Ajoutez-y Mooncake. Vous obtenez LTAP (Lake Transactional/Analytical Processing).

Databricks compte intégrer cette architecture au sein de son offre Lakebase (Postgres serverless) « dans les prochaines semaines ». La promesse : pouvoir mêler OLTP et OLAP sans pipelines ni extensions… et en évitant le compromis de performance qu’implique HTAP. Le moyen : unifier non pas les back-ends, mais les formats de données.

LTAP exploite le surplus CPU de Neon

Lakebase découle de l’acquisition de Neon. Databricks avait finalisé l’opération en mai 2025 pour environ 1 milliard de dollars. Elle lui a apporté une brique transactionnelle sur stockage objet.

Acquis en octobre 2025, Mooncake a procuré le substrat de LTAP : un mécanisme de conversion « à la volée » de Postgres à Parquet. Il exploite deux composants de la couche de stockage de Neon. D’un côté, les safekeepers, qui assurent la réplication des enregistrements générés à partir des lignes. De l’autre, le pagekeeper, qui reconstruit les pages de manière asynchrone.

L’architecture LTAP tire parti de la faible consommation CPU de ces services. Elle utilise les cycles disponibles pour effectuer le transcodage Postgres-Parquet au moment du dépôt sur le stockage objet (latence annoncée : 1 minute). Le pagekeeper fait office de cache conservant le format Postgres. On est donc sur une forme de mise en miroir qui permet à Databricks de revendiquer un format unifié, sans copie.

À consulter en complément :

Bases de données coud : l’abondance de l’offre devient un défi
IBM secoue l’édifice Db2 pour y intégrer l’IA agentique
Face aux bases de données vectorielles, pgvector atteint-il ses limites ?
Injection de prompt et injection SQL : même concept ?

Illustration générée par IA

The post Databricks joue l’alternative à HTAP pour unifier transactionnel et analytique appeared first on Silicon.fr.

Databricks s’attaque au marché de la cybersécurité avec Lakewatch. Jusqu’ici positionné comme « the Data and AI company », l’éditeur franchit une nouvelle étape.

Ce SIEM (Security Information and Event Management) de nouvelle génération, bâti directement sur son socle analytique et IA, promet une réduction du coût total de possession (TCO) pouvant atteindre 80 % par rapport aux solutions historiques.

Un SIEM pensé pour l’ère des agents d’IA

Le positionnement de Lakewatch stipule que face à des attaquants qui recourent désormais à des agents d’IA capables d’opérer à vitesse machine et à grande échelle, les outils de sécurité traditionnels montrent leurs limites. Pour y répondre, Databricks adopte une philosophie qu’elle résume ainsi : « fight agents with agents ».

Lakewatch unifie logs, événements, données IT et métier dans un environnement gouverné, reposant sur des formats ouverts. Les données restent stockées dans les objets cloud du client
( S3, ADLS ou GCS ) et sont exploitées directement dans le lakehouse, sans duplication. L’outil intègre des agents d’IA ainsi que l’assistant « Genie » pour automatiser la détection, le tri, le threat hunting en langage naturel et la réponse aux incidents.

La rupture avec les SIEM classiques

traditionnels. D’une part, leur incapacité à ingérer l’intégralité de la télémétrie pour des raisons de coût : la facturation à « l’ingest » (ingestion-based billing ) ou au volume indexé contraint les équipes de sécurité à opérer avec une visibilité partielle. D’autre part, la fragmentation entre données de sécurité et données métier, qui impose copies et duplications coûteuses.

Lakewatch inverse ce modèle en faisant « tourner la sécurité sur le lakehouse ». Au lieu de déplacer les données vers un entrepôt SIEM, la sécurité opère directement sur le lakehouse gouverné via Unity Catalog, où coexistent données IT, sécurité et métier. La tarification est indexée sur l’utilisation logicielle plutôt que sur le volume de données stockées — une rupture économique majeure qui met sous pression les acteurs historiques.

L’outil est par ailleurs construit sur l’Open Cybersecurity Schema Framework (OCSF), réduisant le verrouillage propriétaire sur les schémas et les données, là où nombre de SIEM imposent encore leurs formats internes et leurs langages de requête spécifiques.

Un écosystème déjà structuré

Pour accompagner ce lancement, Databricks annonce un « Open Security Lakehouse Ecosystem » réunissant des partenaires de premier plan : Okta, Palo Alto Networks, 1Password, Wiz (intégré à Google Cloud), Zscaler ou encore Slack.

Côté clients, Adobe, Dropbox et la National Australia Bank figurent parmi les premiers adoptants. Anthropic, de son côté, contribue à alimenter les capacités de cybersécurité de la plateforme via ses modèles intégrés.

Des conséquences profondes pour le marché

L’arrivée de Lakewatch exerce une pression directe sur le modèle économique et l’architecture des SIEM établis. En proposant un socle data/IA déjà massivement déployé dans les entreprises, Databricks facilite les stratégies de remplacement ou de déport de charges analytiques vers le lakehouse, menaçant des acteurs comme Splunk ou Elastic sur leur terrain.

À moyen terme, Lakewatch accélère la convergence entre plateformes data, IA et sécurité, et pourrait redéfinir la place des SIEM historiques, reléguant certains au rang de simples sources de logs plutôt que de systèmes centraux d’opérations de sécurité.

Un lancement stratégique avant l’IPO

Ce virage vers la cybersécurité s’inscrit dans un contexte particulier pour Databricks. Valorisée autour de 134 milliards $ la société prépare une introduction en Bourse qui pourrait intervenir dès 2026. S’implanter sur un marché SIEM en pleine recomposition renforce considérablement son récit de croissance à l’attention des investisseurs, en ajoutant un nouveau relais à une plateforme déjà bien implantée dans les grandes entreprises mondiales.

The post Databricks s’attaque au marché de la cybersécurité avec Lakewatch appeared first on Silicon.fr.