Machine learning : à l’ère de l’IA agentique, Snowflake termine (enfin) ses fondations

Automatiser la modélisation sémantique (et faire de l’ombre à Tableau)

Du côté de Snowflake Intelligence, l’éditeur a présenté la disponibilité générale de Semantic View Autopilot. Cet agent doit servir à automatiser les modèles de données qui forment la couche sémantique nécessaire aux usages BI de l’assistant. SVA (pour les intimes) génère les vues sémantiques. Avec Cortex Analyst, il est possible de vérifier leur fonctionnement. C’était l’un des points saillants qui auraient pu freiner l’adoption de Snowflake Intelligence. La création de ces modèles sémantiques aurait pu sinon prendre des semaines, selon Snowflake.

Ce que ne précise pas les porte-parole, c’est que Semantic View Autopilot peut déjà convertir des modèles exportés depuis Tableau Desktop ou Online en vues sémantiques. L’intention de Snowflake et Databricks consistant à faire descendre d’un étage la couche sémantique de la suite BI vers le lakehouse était déjà limpide. L’objectif semble désormais très clair : se passer de Tableau, Looker ou de Power BI. Cette impression est renforcée par la préversion publique d’une fonctionnalité permettant de sauvegarder et de partager les visualisations créées par Snowflake Intelligence.

Le dernier en point notable en matière d’IA agentique est la disponibilité générale prochaine de Snowflake Postgres. Ce DBaaS né du rachat de Crunchy Data sert d’abord les cas d’usage agentique et le stockage de données applicatives à des fins analytiques. Pour autant, Snowflake ne semble pas encore avoir déterminé si elle veut remplacer Oracle et les autres bases de données relationnelles.

En outre, Snowflake Postgres chevauche Unistore, la fonctionnalité translytique lancée par l’éditeur il y a deux ans. « Si un client souhaite une compatibilité avec Postgres, la réponse est Snowflake Postgres. Si un client souhaite traiter une charge de travail de type OLTP en lecture/écriture à faible latence avec une compatibilité avec Snowflake, la réponse est Unistore », différencie Christian Klein « Les cas d’usage concrets se chevauchent quelque peu », confirme-t-il. « En fin de compte, il n’est pas rare qu’un agent ou une application agentique ou peut-être un pipeline stocke l’état dans Postgres ou Unistore, et que les deux soient exploités ultérieurement à des fins d’analyse ».

Machine learning : Snowflake se rapproche de Databricks

La situation paraît beaucoup plus claire en matière de machine learning. Enfin, Snowflake se rapproche de la parité fonctionnelle avec Databricks. Les notebooks Jupyter, l’ingérence de modèles ML et la gestion des features (paramètres) en temps réel (30 à 100 millisecondes, suivant les usages) depuis Snowflake Container Services entrent en disponibilité générale. Les notebooks Jupyter sont intégrés de longue date (au moins 2019) dans la plateforme du concurrent. L’inférence de modèles ML en temps réel a été lancée en disponibilité générale en 2023 chez Databricks.

« Ce sont les composants nécessaires pour créer des applications et des expériences réactives en temps quasi réel pour les clients », explique Christian Klein. Plus précisément, ces inférences servent entre autres à affiner la segmentation publicitaire, les recommandations de produits ou de contenus, prédire la conclusion d’un achat ou encore détecter des fraudes. L’année dernière, Snowflake avait lancé en disponibilité générale une fonctionnalité similaire pour des traitements en lot.

« Nous complétons nos capacités et nous faisons de Snowflake une plateforme crédible de machine learning », vante le dirigeant.

Une autre preuve de maturité tient dans la disponibilité des backups gérés par l’éditeur. Une fonctionnalité attendue de longue date.

L’interopérabilité open source est aussi (surtout ?) une affaire de relations commerciales

De même, l’éditeur renforce des fonctionnalités existantes, à commencer par le partage de données dit « zero ETL ». En sus des tables Snowflake, il est maintenant possible de partager des tables Apache Iceberg et Delta Lake à travers plusieurs régions et cloud.

Toutefois, l’une des capacités les plus déterminantes pour correspondre au discours d’ouverture de Snowflake tarde à sortir du bois. Si la lecture des tables Iceberg via Snowflake Horizon, l’API REST Catalog et Apache Polaris par des moteurs tiers (Flink, Spark, Trino, Python) entre enfin en disponibilité générale, l’écriture depuis ces engins tiers n'est qu'en préversion publique.

« Nous sommes toujours convaincus d’avoir un catalogue entièrement open source qui deviendra effectivement l’interface entre de nombreux éditeurs », affirme Christian Klein. « Nous continuerons à participer aux améliorations de Polaris en open source », assure-t-il.

Toutefois, cette ouverture est de plus en plus fonction des relations commerciales de Snowflake. Ce qui expliquerait le délai entre l’annonce de Polaris et son intégration.

« Pour les clients qui veulent déployer l’open source Polaris, nous les aiderons à le faire. Mais le scénario le plus courant que nous avons entendu est le suivant : “une fois que ces contrats ont été conclus entre vous, Microsoft, Amazon, Google et tous les autres, il faut que nous puissions les adopter facilement” », poursuit-il. « C’est ce que nous construisons, les interfaces et les contrats Polaris exacts dans Horizon. Il ne s’agit donc en aucun cas d’une réduction de la conviction et de la croyance en l’importance de l’interopérabilité. C’est plutôt au niveau de la mise en œuvre commerciale de ces interfaces que nous voulons réduire les frictions ».