Nouveautés Snowflake : été 2025

Nouvelle barre latérale (Preview, déploiement en cours)

Snowflake déploie une barre de navigation latérale réorganisée. Certains comptes en bénéficient déjà, d'autres basculeront par phases. D'après ce que j'ai pu constater, la plupart des comptes en disposent désormais. Les groupes de menus sont plus clairs et collent mieux à la façon dont les équipes travaillent. Personnellement, il m'a fallu un petit temps d'adaptation. J'ai mis quelques secondes à retrouver *databases* et *query history*, mais dans l'ensemble j'adore la nouvelle disposition !

Disposition :

• Shortcuts : épinglez jusqu'à trois pages pour un accès rapide. Glissez-déposez pour les réorganiser.
• Work with data : Projects, Ingestion, Transformation (dbt, Task History, Dynamic Tables), AI & ML, Monitoring (query history ! La vue GUI de votre event table s'y trouve aussi), Marketplace.
• Horizon Catalog : Catalog (les databases sont ici !), Data sharing, Governance & security.
• Manage : Compute et Admin.

Voici comment épingler et désépingler des raccourcis :

Cette capture, tirée de la documentation Snowflake, présente la nouvelle et l'ancienne barre latérale côte à côte.

Au passage, si vous n'avez pas encore essayé la nouvelle recherche globale, foncez ! Elle parcourt les databases, le marketplace, la documentation, et en réalité à peu près tout ce que contient Snowflake pour retrouver vos mots-clés. Je la trouve très efficace pour mettre la main rapidement sur ce que je cherche.

Créer une Semantic View depuis Snowsight (Public Preview)

Vous pouvez créer et gérer des Semantic Views directement dans Snowsight via l'explorateur d'objets de la database ou la page Cortex Analyst. À vous de choisir entre l'assistant ou l'import d'un YAML.

• Points de départ :
  • Ancienne barre latérale : Data → Databases → Sélectionner un schéma → Create → Semantic View, ou AI & ML → Cortex Analyst → Create / Upload YAML.
  • Nouvelle barre latérale : Horizon Catalog → Catalog → Database → sélectionner un schéma → create, Semantic View
  • Ou via AI & ML → Cortex Analyst

Créer une nouvelle Semantic View s'est avéré très simple. Les captures d'écran ci-dessous illustrent la démarche.

Étape 1 : ouvrez un schéma et cliquez sur *Create*. Ci-dessous, la nouvelle barre latérale : les databases et schémas se trouvent désormais dans *Horizon Catalog*.

Étape 2 : remplissez les pages du formulaire

Voici comment procéder à l'identique depuis le menu Cortex Analyst :

À noter : l'interrogation des Semantic Views en SQL est également en Preview. Consultez la documentation pour en savoir plus.

Dynamic Tables : lecture depuis Iceberg géré en externe (GA)

Les Dynamic Tables peuvent désormais lire directement depuis des tables Iceberg gérées par un catalogue externe. Voilà une avancée majeure des capacités de pipeline de données de Snowflake pour les clients qui exploitent Iceberg. Plus d'informations dans la documentation.

Types structurés pour les tables standard (GA)

D'autres plateformes de données comme BigQuery et Databricks proposent depuis longtemps des types de données structurés (struct, array, record), alors que Snowflake se contentait du type variant pour couvrir ces cas d'usage.

Vous pouvez maintenant définir ARRAY, OBJECT et MAP comme colonnes structurées dans des tables Snowflake classiques, avec jusqu'à 1 000 sous-colonnes par colonne. Pour l'instant, les types structurés ne sont pas pris en charge sur les tables dynamiques, hybrides ou externes. Consultez la documentation pour en savoir plus.

Pre-clustering pour Snowpipe Streaming (Preview)

Snowpipe Streaming peut pré-clusteriser les lignes dès l'ingestion, de sorte que les données arrivent triées selon vos clés de clustering. À la clé : de meilleures performances de requête sur les tables actives et une charge réduite sur le clustering automatique. Nous n'avons pas encore testé la fonctionnalité, mais ce sera probablement un levier d'économies pour les clients dont les dépenses en clustering automatique sont élevées.

Activez le pre-clustering dans la définition du COPY avec CLUSTER_AT_INGEST_TIME=TRUE ; votre table cible doit déjà disposer de clés de clustering.

CREATE OR REPLACE PIPE TEST_PRECLUSTERED_PIPE
AS
    COPY INTO TEST_PRECLUSTERED_TABLE (num) FROM (
            SELECT $1:num::number as num FROM TABLE(
                DATA_SOURCE(
                    TYPE => 'STREAMING')
        ))
        CLUSTER_AT_INGEST_TIME=TRUE;

Commande COPY FILES (GA)

COPY FILES déplace des objets d'un stage à un autre. Un cas d'usage concret : faire passer des fichiers d'un dossier *unprocessed* vers un dossier *processed*.

Dans ce scénario, vous pouvez définir des politiques de bucket (en dehors de Snowflake) pour vous assurer que votre dossier unprocessed est nettoyé après un certain délai, sans avoir à écrire de code supplémentaire pour gérer le cycle de vie des données.

Par exemple, vous pourriez supprimer les données du dossier unprocessed après 30 jours, et archiver celles du dossier processed vers Glacier après 60 jours. Ce type de stratégie réduit la duplication des données et les coûts de stockage en dehors de Snowflake.

Exécuter des tasks au nom d'un autre utilisateur : EXECUTE AS USER + IMPERSONATE (GA)

Les tasks peuvent s'exécuter avec les privilèges d'un utilisateur spécifique grâce à EXECUTE AS USER, à condition que le rôle propriétaire de la task dispose de IMPERSONATE sur cet utilisateur. C'est utile lorsque des politiques ou systèmes en aval s'appuient sur l'identité de l'utilisateur, par exemple pour l'accès par ligne ou le masquage, et cela permet de voir bien plus facilement au nom de qui une task a réellement agi en consultant les logs.

Voici un exemple simplifié pour illustrer la nouvelle fonctionnalité. Il suppose que les utilisateurs et les rôles existent déjà. Consultez la documentation Snowflake pour un exemple complet, incluant la création des utilisateurs, rôles, warehouses, l'octroi de privilèges, etc.

-- accorder impersonate. Nouvelle fonctionnalité !
GRANT IMPERSONATE ON USER task_user TO ROLE task_role;

USE ROLE task_owner;

-- exécuter la task au nom d'un autre utilisateur
CREATE TASK team_task
  SCHEDULE='12 HOURS'
  EXECUTE AS USER task_user
  AS SELECT 1;

La nouvelle tarification Snowpipe annoncée au Summit : désormais GA pour Business Critical et VPS

Dans notre récapitulatif du Summit, nous avons déjà évoqué les bénéfices du nouveau modèle de tarification Snowpipe pour les clients. L'ancienne tarification reposait sur deux composantes : par seconde et par cœur, plus un coût par tranche de 1 000 fichiers. La nouvelle est simplifiée : un montant fixe de crédits par Go ingéré.

Elle passe désormais du concept à la GA pour les clients Business Critical et VPS, et sera bientôt déployée pour les clients Standard et Enterprise.

Pour en saisir tous les détails, consultez le tableau de consommation des crédits ainsi que la documentation des coûts Snowpipe.

Snowpark Connect for Spark et Snowpark Submit (Preview)

En résumé : vous pouvez désormais exécuter des jobs Apache Spark directement dans Snowflake sans réécrire la moindre ligne de code. Cela couvre Spark DataFrame, SQL et UDFs. Vous pouvez également soumettre des jobs non interactifs en mode asynchrone via Snowpark Submit.

Ces fonctionnalités constituent un pont pragmatique pour les équipes Spark qui migrent vers Snowflake et ne souhaitent pas réécrire leur code Spark en API Snowpark.

Vous pouvez développer dans des outils familiers comme Jupyter Notebooks ou Snowflake Notebooks. Voir la documentation pour en savoir plus.

UDF Snowflake Scripting (GA)

Vous pouvez désormais utiliser la logique Scripting de Snowflake dans des UDF SQL et les appeler en ligne depuis vos requêtes, et plus uniquement via CALL comme pour les stored procedures. Idéal pour de petits utilitaires procéduraux ou des fonctions SQL personnalisées que vous souhaitez réutiliser dans des instructions SELECT/INSERT.

Snowflake Scripting est un langage de scripting SQL puissant. Tous les détails sur la nouvelle fonctionnalité UDF sont disponibles ici.

À noter : cela ne fonctionnera pas avec les curseurs (declare … c1 cursor for select foo from bar). Cette limitation joue probablement en faveur des utilisateurs, car une logique ligne à ligne comme celle des curseurs n'est pas une bonne idée dans des fonctions SQL.

Dynamic Tables : UNION dans le rafraîchissement incrémental (GA)

À mesure que les clients adoptent les capacités natives de pipeline de données de Snowflake, l'éditeur comble une lacune aussi évidente qu'agaçante : les Dynamic Tables incrémentales prennent désormais en charge UNION (distinct) dans les requêtes de rafraîchissement, élargissant l'éventail des fusions multi-sources réalisables sans repasser par un rafraîchissement complet. Les autres opérateurs ensemblistes (par exemple minus, except, intersect) restent non pris en charge en mode incrémental.

CREATE DYNAMIC TABLE my_dynamic_table
 TARGET_LAG = DOWNSTREAM
 AS
 SELECT * from foo
 -- plus besoin de union all
 union
 select * from bar;

Petit conseil pour les débutants en SQL : il est considéré comme une bonne pratique de privilégier union all à union, car union force un distinct qui ralentit l'exécution de la requête. N'utilisez donc cette nouvelle fonctionnalité que si vous avez réellement besoin que l'union soit distinct.

À ce jour, la documentation Snowflake n'a pas été mise à jour pour mentionner la prise en charge de l'opérateur union, mais celle-ci est bel et bien disponible. 🧐

Événements de monitoring pour Snowpipe, plus événements d'auto-refresh Iceberg (GA)

Snowpipe publie désormais des événements d'ingestion détaillés dans l'Event Table active. Vous pouvez suivre les changements d'état d'un pipe, la progression fichier par fichier, et consulter des résumés périodiques qui synthétisent l'activité d'ingestion. En complément, Snowflake émet également des événements à chaque fois qu'une table Iceberg gérée en externe est automatiquement rafraîchie.

Résultat : vous observez l'intégralité du cycle de vie de l'ingestion, depuis l'arrivée des fichiers en staging dans Snowpipe jusqu'à la mise à jour des tables Iceberg en aval, le tout au même endroit. Voilà qui comble une lacune de visibilité de longue date. En pratique, cela devrait grandement simplifier le diagnostic des fichiers bloqués ou des rafraîchissements en retard, et ouvrir la voie à des alertes plus fines sur les SLA des pipelines de données. C'est selon moi l'une de ces fonctionnalités de "confort d'utilisation" qui peuvent paraître discrètes au premier abord, mais que les équipes exploitant des pipelines d'ingestion en production sauront immédiatement apprécier.

Voici plus d'informations sur la fonctionnalité.

Définir une taille de fichier cible pour les tables Iceberg (Preview)

Vous pouvez désormais définir une taille de fichier Parquet cible lors de la création ou de la modification d'une table Iceberg. Vous gagnez ainsi en contrôle sur la manière dont les données sont écrites et pouvez améliorer les performances lorsque ces fichiers sont lus par des moteurs comme Spark ou Trino.

C'est particulièrement utile dans les configurations multi-moteurs où la taille des fichiers peut faire toute la différence sur l'efficacité des requêtes. Les petits fichiers conviennent bien aux requêtes rapides et granulaires, tandis que les plus volumineux réduisent la surcharge des scans massifs. J'y vois une avancée concrète qui rend Snowflake plus flexible pour les usages hybrides de type lakehouse.

Voici un exemple de création ou de modification d'une table Iceberg avec cette nouvelle fonctionnalité :

CREATE ICEBERG TABLE my_iceberg_table (
  amount INT,
  name STRING
)
  CATALOG = 'SNOWFLAKE'
  EXTERNAL_VOLUME = 'my_external_volume'
  BASE_LOCATION = 'my_iceberg_table'
  TARGET_FILE_SIZE = '64MB'; -- NOUVEAU !

ALTER ICEBERG TABLE my_iceberg_table
SET TARGET_FILE_SIZE = '128MB';

ALTER LISTING : ajout/suppression de cibles simplifiés (GA)

Les fournisseurs Marketplace peuvent désormais ajouter ou retirer des cibles de listing avec un manifeste partiel, sans avoir à resoumettre l'ensemble complet des cibles. De quoi alléger la complexité d'automatisation lors de la gestion de nombreux comptes, rôles ou organisations.

Facts et metrics privés dans les Semantic Views (General Availability)

Vous pouvez marquer des facts et metrics comme PRIVATE lors de la définition d'une Semantic View. Les éléments privés sont autorisés dans les calculs au sein de la vue, mais ne peuvent être ni interrogés directement, ni utilisés dans des filtres. Ils restent visibles dans DESCRIBE SEMANTIC VIEW et GET_DDL, ce qui facilite la découverte et les audits. Pratique lorsque vous souhaitez exposer en surface des metrics propres et prêtes à l'emploi tout en gardant en coulisses des facts utilitaires et des metrics intermédiaires. Mon avis : c'est une lacune dont je n'avais jamais soupçonné l'existence, mais elle rend les Semantic Views plus adaptées à l'analytique gouvernée en production.

CREATE SEMANTIC VIEW my_sales_view
  TABLES (
    orders AS my_db.my_schema.orders PRIMARY KEY (order_id)
  )
  FACTS (
	  -- Nouvelle fonctionnalité
    PRIVATE adjustment_factor AS AVG(orders.adjustment)
  )
  METRICS (
    total_revenue AS SUM(orders.revenue),
    -- nouvelle fonctionnalité
    PRIVATE adjusted_revenue AS SUM(orders.revenue + adjustment_factor)
  );

Fonction AI_EXTRACT (Preview)

AI_EXTRACT extrait des champs structurés à partir d'entrées non structurées. La fonction accepte des chaînes de caractères ou des entrées FILE, et vous définissez le format de réponse avec des prompts simples ou des paires nom-prompt. Pensez aux factures, contrats, notes patients ou PDF marketing, le tout extrait directement dans Snowflake. À la clé : moins d'allers-retours vers des services externes et un chemin plus direct vers des données structurées exploitables. C'est prometteur pour les équipes qui centralisent déjà leurs données dans Snowflake, mais traitez-la comme n'importe quelle fonctionnalité IA en preview. Mon approche : démarrer avec un jeu de test labellisé pour évaluer son comportement. Réfléchissez aux garde-fous à mettre en place avant de l'intégrer à des pipelines critiques !

Exemples :

-- Syntaxe :
AI_EXTRACT( <text>, <responseFormat> )

-- exemple spécifiant une sortie structurée
AI_EXTRACT( <'colonne sql contenant du texte non structuré'>,
['address': 'City, street, ZIP', 'name': 'First and last name'] )

-- autre exemple où la sortie est en langage naturel
-- ici on extrait depuis un fichier au lieu d'une colonne
AI_EXTRACT( <'un fichier pdf dans un Snowflake Stage'>,
['give me address and first and last name' );\
```\
\
### Mode layout d'AI Parse Document (GA)\
\
Le mode layout d'[`AI_PARSE_DOCUMENT`](https://docs.snowflake.com/en/user-guide/snowflake-cortex/parse-document#ai-parse-document) est une nouvelle fonctionnalité GA qui remplace la fonction `SNOWFLAKE.CORTEX.PARSE_DOCUMENT`. Elle extrait la mise en page d'un document en Markdown en préservant le flux du texte, les tableaux et la structure. En clair : du PDF (ou similaire) vers du Markdown ! 🥳 Vous obtenez ainsi une forme intermédiaire propre, idéale pour le chunking, le RAG ou tout traitement en aval. Ce parsing conscient de la mise en page semble bien constituer la fondation d'une IA documentaire fiable. J'imagine aussi très bien l'associer à `AI_EXTRACT` pour passer de fichiers bruts à des lignes structurées en moins d'étapes.\
\

\

Traitement distribué dans Snowflake ML : Many Model Training et Distributed Partition Function (General Availability)\

Snowflake ML prend désormais en charge deux schémas distribués. Many Model Training (MMT) entraîne en parallèle des modèles distincts par partition d'un Snowpark DataFrame. Distributed Partition Function (DPF) exécute votre fonction Python sur des partitions réparties sur un ou plusieurs nœuds d'un compute pool, avec stockage des artefacts et suivi de la progression pris en charge pour vous. Cela élimine une grande partie du travail d'orchestration tout en passant à l'échelle sur la plateforme que vous utilisez déjà.

Si vous souhaitez creuser le sujet, Train models across data partitions et Process data with custom logic across partitions sont documentés en détail.
\

\

Data Metric Function : ACCEPTED_VALUES (GA)\

ACCEPTED_VALUES est une DMF système qui vérifie si les valeurs d'une colonne satisfont une expression booléenne et renvoie le nombre de lignes qui ne la satisfont pas. Vous l'associez à une table ou une vue selon une planification, ou vous l'exécutez ponctuellement avec SYSTEM$DATA_METRIC_SCAN.

C'est un moyen peu coûteux et à forte valeur ajoutée pour détecter des problèmes de conformité simples comme les enums et jeux de codes, sans écrire de SQL personnalisé.
\

1-- syntaxe\
\
2SNOWFLAKE.CORE.ACCEPTED_VALUES ON ( <column>, <lambda-expression> )\
\
3\
\
4-- exemple\
\
5ALTER TABLE orders\
\
6  ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ACCEPTED_VALUES\
\
7    ON (\
\
8      order_status,\
\
9      order_status -> order_status IN ('Pending', 'Shipped', 'Delivered', 'Returned')\
\
10    );\
\
11\
\
12 CALL SYSTEM$DATA_METRIC_SCAN('orders');\
\
13 -- ceci renverra toutes les DMF de la table orders\
```\
\
### Mises à jour Snowflake Data Clean Rooms (GA)\
\
Une data clean room est un environnement sécurisé où plusieurs parties peuvent analyser des jeux de données combinés sans accéder directement aux données brutes les unes des autres. Cela passe par des contrôles de requêtes stricts et des politiques qui n'autorisent que des sorties approuvées comme des agrégats ou des résultats anonymisés, jamais des données au niveau ligne.\
\
Snowflake a déployé 4 mises à jour des data clean rooms le mois dernier. Il s'agit essentiellement d'améliorations de confort qui réduisent les frictions à l'usage.\
\
- **Flux simplifié pour le partage inter-régions** : les fournisseurs n'ont plus besoin d'appeler à la fois `request_laf_cleanroom_requests` et `mount_laf_cleanroom_requests_share` pour accepter les requêtes de consommateurs venant d'une autre région. Ils peuvent désormais se contenter de `provider.mount_request_logs_for_all_consumers`. Le [guide développeur](https://docs.snowflake.com/en/user-guide/cleanrooms/activation?utm_source=chatgpt.com) le détaille sous "Implementing activation in your clean room".\
- **Installation simplifiée** : Snowflake crée et vérifie désormais automatiquement le service user nécessaire aux clean rooms, ou en réutilise un existant, plutôt que d'imposer une création manuelle aux utilisateurs. Conséquence : moins d'étapes de configuration avant de pouvoir réellement utiliser les clean rooms.\
- **Tests sur un compte unique** : vous pouvez désormais utiliser un seul compte Snowflake pour jouer à la fois le rôle de fournisseur et de consommateur dans une clean room de test. Parfait pour les environnements dev/test : vous pouvez construire et valider des templates de clean room sans avoir à provisionner des comptes séparés. La page tutoriels et exemples le montre en action ("[Basic UI tutorial, single account](https://docs.snowflake.com/en/user-guide/cleanrooms/tutorials-and-samples?utm_source=chatgpt.com)"). Voir la [documentation](https://docs.snowflake.com/en/user-guide/cleanrooms/developer-introduction#label-dcr-self-share-for-developers) pour une lecture plus rapide.\
- **Fréquences de rafraîchissement configurables pour Cross-Cloud Auto-Fulfillment** : par défaut, le rafraîchissement des données entre comptes fournisseurs et consommateurs sur des clouds ou régions différents est désormais effectué toutes les 30 minutes (contre 24 heures auparavant). Et cette fréquence est configurable. [Voir la documentation](https://docs.snowflake.com/en/user-guide/cleanrooms/provider.html#dcr-provider-set-laf-dcr-refresh-schedule).\
\
### Snapshots Write Once, Read Many (WORM) (Preview)\
\
Les [Snapshots](https://docs.snowflake.com/en/user-guide/snapshots) WORM sont des sauvegardes ponctuelles et **immuables** de tables, schémas ou databases. Ils s'appuient sur des snapshot sets et des snapshot policies optionnelles pour la planification et l'expiration. Le **verrouillage de rétention** et les **legal holds** ajoutent une protection contre la suppression, le verrouillage de rétention étant conçu pour offrir de solides garanties de conformité. Même un accountadmin ne peut pas supprimer ces tables, ce qui offre une protection solide contre les identifiants compromis et les ransomwares. Les Snapshots WORM sont disponibles dans toutes les éditions, tandis que le verrouillage de rétention et les legal holds sont réservés à Business Critical et au-delà.\
\
Voilà un contrôle concret pour la résilience face aux ransomwares et la rétention réglementaire, qui va au-delà du Time Travel. La fonctionnalité semble prometteuse pour l'hygiène des sauvegardes, mais elle est encore en preview : testez donc les chemins de restauration et planifiez le stockage avant de vous reposer sur le verrouillage de rétention.\
\

\

Profils d'organisation (General Availability)\

Vous pouvez désormais créer et gérer des profils d'organisation dans Snowsight, définir quels comptes et rôles peuvent publier sous un profil, et personnaliser les listings internes avec un avatar de profil et une référence URL. Cela renforce la confiance au sein de l'Internal Marketplace et supprime beaucoup de SQL ad hoc pour la configuration. Les grandes organisations gagnent en cohérence et les consommateurs disposent d'une provenance plus claire pour les produits de données internes.

\

Activation en self-service de Tri-Secret Secure (General Availability)\

Petit rappel de votre formation Snowflake : Tri-Secret Secure est l'approche du chiffrement de Snowflake reposant sur trois clés : la clé propre à Snowflake, celle du fournisseur cloud et une clé gérée par le client. Les données ne peuvent être déchiffrées que si les trois clés sont disponibles, ce qui permet aux clients de suspendre l'accès directement en désactivant leur propre clé. La fonctionnalité est disponible pour Business Critical et VPS.

Grâce à la nouvelle fonctionnalité Self Service Activation, les ACCOUNTADMIN peuvent activer Tri-Secret Secure eux-mêmes via des fonctions système, gérer la clé client et même la désactiver si nécessaire. Fini la boucle de support : les contrôles de chiffrement forts deviennent une composante standard de l'hygiène du compte, et non plus un projet spécial impliquant le support client.
\

Query Insights : performance des jointures et optimisation (Public Preview)\

Contexte :

Query Insights est une fonctionnalité intégrée relativement récente qui fait remonter automatiquement des observations sur vos requêtes : jointures inefficaces, filtres manquants, etc. Au lieu de fouiller dans des profils bruts, vous recevez des indications lisibles qui pointent vers des correctifs améliorant les performances et réduisant les coûts.

Les insights se trouvent dans Snowsight Query History → Query Profile, ou en interrogeant la vue snowflake.account_usage.query_insights. Un outil tiers comme SELECT offre aux utilisateurs une bien meilleure observabilité des query insights dans une UI dédiée.


Nouvelle fonctionnalité :

Query Insights ajoute de nouvelles observations sur les erreurs de jointure et les gains d'optimisation possibles, consultables dans Snowsight ou en interrogeant la vue QUERY_INSIGHTS. Les indications mettent en évidence des patterns comme les conditions de jointure manquantes, les jointures explosives, l'absence de filtres, l'usage de la search optimization et le spillage, pour vous permettre de corriger la cause racine plus vite. Très utile pour le triage, même si vous continuez à vous appuyer sur Query Profile pour les analyses plus poussées.
\

Semantic Views : lister dimensions et metrics à n'importe quelle portée (GA)\

Vous pouvez inventorier votre couche sémantique avec SHOW SEMANTIC DIMENSIONS et SHOW SEMANTIC METRICS à n'importe quelle portée : vue, schéma, database ou compte, et même lister les dimensions valides pour une metric donnée. Pratique pour auditer les modèles, vérifier la granularité et les relations, et garder les équipes lucides sur ce qui est réellement disponible. C'est une petite fonctionnalité, mais elle sera très appréciée des profils admin qui s'appuient sur les commandes show pour comprendre la gouvernance.
\

Voici une liste rapide d'autres mises à jour à signaler :
\

• Jobs ML multi-nœuds - Preview\
• Create Index prend en charge "Include Columns" - GA\
• Consistency Secret désormais optionnel dans generate_synthetic_data - GA\
• Interrogation des Semantic Views passe de Preview à GA\
• La fonction SEARCH_IP prend en charge la recherche d'adresses IPv6 - GA\
• Les e-mails Trust Center passent de Preview à GA Nouveau Stage Volume pour Snowpark Container Services - Preview\
• Connecteur Microsoft Power Apps - GA
  \

Et voilà, beaucoup de fonctionnalités en seulement deux mois ! Faites-nous signe si vous avez besoin d'un coup de main sur l'une d'entre elles.



Jeff est consultant Data et Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des insights et l'exploitation des données pour piloter les processus métier. Côté technologies, il est spécialisé en Snowflake + dbt + Tableau. Côté métiers, il a travaillé dans les services publics, les essais cliniques, l'édition, les biens de grande consommation et l'industrie manufacturière. N'hésitez pas à le contacter à tout moment : [email protected].\