Trois mouvements de fond se dégagent parmi les nouveautés Snowflake d'aoùt.

D'abord, DCM Projects passe en disponibilité générale : lancé en preview en mars, l'Infrastructure-as-Code natif de Snowflake est désormais un produit assumé pour la production. Ensuite, Cortex Agents devient la porte d'entrée unique de l'IA analytique. Snowflake recommande officiellement d'abandonner Cortex Analyst en tant qu'API autonome, et enrichit les agents d'un agent de codage, d'une API asynchrone et d'un outil d'exécution de code. Enfin, la gouvernance se durcit sensiblement, avec des politiques de mouvement de données pour lutter contre l'exfiltration, des règles de politiques de fonctionnalités et l'approbation multi-parties en GA.

Point de vigilance : Cortex Analyst n'est plus la voie recommandée

Le 28 août, Snowflake a publié une recommandation officielle de transition de Cortex Analyst vers Cortex Agents. Les nouvelles capacités d'analytique en langage naturel arrivent désormais sur Cortex Agents, pas sur l'API Analyst
Si vous avez des applications qui appellent directement l'API Analyst, c'est le moment pour planifier la bascule dans votre roadmap.

DCM Projects : l'Infrastructure-as-Code native passe en Disponibilité Générale

C'est l'aboutissement du chantier suivi depuis notre newsletter de mars. Depuis le 7 août, DCM Projects est en disponibilité générale et sort officiellement de preview. Vous décrivez l'état cible de vos bases, tables, tâches et autres objets Snowflake dans des fichiers de définition, et Snowflake calcule puis applique les changements nécessaires pour y parvenir.

Les capacités désormais couvertes par la GA :

  • Définitions déclaratives : les instructions DEFINE dans des fichiers SQL décrivent l'état souhaité. Snowflake détermine seul les modifications à appliquer.
  • Templating Jinja : variables, boucles, conditions et macros pour paramétrer vos définitions et supporter des déploiements multi-environnements sans duplication.
  • Workflow plan-then-deploy : prévisualisation fiable des changements avant déploiement, pour intercepter les modifications non désirées.
  • Support étendu des objets : une large variété de types d'objets, couvrant l'infrastructure, les pipelines de données et la gouvernance.
  • Gestion de pipelines : construction, test et déploiement de pipelines via dynamic tables, tasks et data quality expectations.
  • Interfaces multiples : Snowsight, Snowflake CLI, SQL ou Cortex Code CLI. Les fichiers de définition peuvent vivre dans un Workspace Snowflake, un dépôt Git distant ou un répertoire local.

Attention toutefois, plusieurs briques annoncées en juillet restent en preview et ne bénéficient donc pas des engagements de la GA :

  • les commandes TEST et PREVIEW
  • les GitHub Actions pour DCM Projects
  • DEFINE PIPE, DEFINE STREAM, DEFINE MASKING POLICY, DEFINE ROW ACCESS POLICY
  • ATTACH TAG
  • les grants hérités (INHERITED) et le MANAGE GRANTS au niveau conteneur

Autrement dit : le socle de déploiement déclaratif est prêt pour la production, mais si votre cible inclut la gestion déclarative des politiques de masquage ou du RBAC hérité, prévoyez encore une part d'artisanat

Cortex Agents : agent de codage, API asynchrone et exécution de code

Coding Agent (GA, 26 août)

En ajoutant le type d'outil code_toolset_all à un agent Cortex, Snowflake provisionne et gère un sandbox adossé au même runtime que Snowflake CoCo. L'agent dispose alors de : bash, lecture/écriture/édition de fichiers, grep, glob, recherche web, exécution SQL et skills. Point important pour les architectes : Snowflake exécute les outils et vous renvoie les résultats en streaming, ce qui évite de construire et d'héberger vous-même une boucle d'agent

API asynchrone (GA, 30 août)

L'API asynchrone de Cortex Agents est en disponibilité générale sur AWS et Microsoft Azure. En positionnant le champ "background" à "true" dans une requête d'exécution d'agent, vous lancez un traitement long qui continue même après déconnexion du client, avec un timeout de 6 heures. Vous pouvez ensuite vous reconnecter au run via l'endpoint Stream Agent Run, ou interroger la fonction THREAD_MESSAGES en SQL.

C'est la brique qui manquait pour industrialiser des agents sur des traitements longs (analyses de fond, agents batch) sans maintenir une connexion ouverte

Et aussi :

  • Versioning des évaluations d'agents (GA, 21 août) : les évaluations Cortex Agent et Cortex Analyst peuvent cibler une version précise, ce qui rend les comparaisons reproductibles dans une chaîne CI/CD.
  • Références Cortex Extension dans les skills d'agents (GA, 26 août).
  • Cortex Agents et serveurs MCP dans les Native Apps (GA, 7 août) : les éditeurs peuvent embarquer agents et serveurs MCP dans leurs applications natives.

Gouvernance : les politiques de mouvement de données arrivent en GA

Le sujet le plus structurant du mois pour les DSI et les RSSI.

Data movement policies (GA, 19 août)

Disponibles à partir de l'édition Enterprise, ces politiques font partie de l'arsenal de protection contre l'exfiltration de données de Snowflake. Ce sont des politiques conditionnelles de style SQL qui permettent de limiter, alerter ou bloquer des opérations de sortie de données selon leur type.

Les types de mouvements couverts :

Type de mouvement périmètre
COPY_INTO_EXTERNAL_STAGE Export ou COPY INTO vers un stage externe
COPY_INTO_INTERNAL_STAGE COPY INTO vers un stage interne géré par Snowflake
SNOWSIGHT_UI Accès aux données depuis Snowsight
AGENT_ACCESS Accès via un agent ou un client de type MCP
UI_DOWNLOAD Téléchargement de résultats de requête depuis Snowsight (le bouton est désactivé au franchissement du seuil)
PROGRAMMATIC_FETCH Accès programmatique via driver, connecteur, SnowSQL, CLI, API SQL ou procédure stockée

Les politiques s'attachent à des tags au niveau colonne, table, schéma ou base, ou directement au compte comme politique de référence. Le type AGENT_ACCESS est particulièrement révélateur de l'époque : il devient possible d'encadrer spécifiquement ce que les agents IA peuvent faire sortir de la plateforme.

Multi-party Approval (GA, 4 août)

Le principe du "quatre yeux" appliqué aux opérations critiques du compte. Quand une politique MPA est attachée, aucun administrateur ne peut exécuter seul une opération protégée : au moins un approbateur autorisé supplémentaire doit valider.

Trois groupes d'opérations sont couverts :

  • Opérations d'administration : modification de la configuration MPA, désactivation du MFA, gestion des clés Tri-Secret Secure, attribution ou révocation de rôles administratifs, gestion des guardrails Cortex AI, modification des paramètres de rétention de données
  • Opérations de politiques : politiques réseau, de session, d'authentification et de mots de passe
  • Opérations d'intégrations de sécurité : OAuth, External OAuth, SCIM

Feature policy rules (GA, 16 août)

Une politique de fonctionnalité peut désormais embarquer un corps YAML qui bloque conditionnellement la création d'objets selon les attributs de la requête.

Exemples concrets : autoriser les tables mais interdire les tables temporaires, ou autoriser les tasks mais bloquer les tasks serverless (sans warehouse).

La commande DESCRIBE FEATURE POLICY passe également en GA et permet d'inspecter le corps YAML d'une politique via la propriété policy_definition.

Autres nouveautés Snowflake 

  • Organization Hub en GA (3 août) : la page Insights offre des tuiles interactives sur l'ensemble de l'organisation ,coûts (coût total, par type de service, stockage, utilisation du contrat), sécurité (violations Trust Center, progression de l'authentification forte, échecs de connexion, utilisateurs dormants) et santé des requêtes (requêtes en échec, congestion des warehouses, requêtes les plus coûteuses). Les organisations peuvent aussi analyser ces signaux via la skill /organization-management dans Cortex Code. Accès via le rôle GLOBALORGADMIN ou les rôles applicatifs ORGANIZATION_USAGE appropriés. Les types d'utilisateurs au niveau organisation sont passés en GA le 26 août.
  • Quotas par utilisateur en GA : annoncés en preview en juillet, ils sont désormais généralisés, avec des notifications configurables, des seuils ciblables mensuellement ou quotidiennement, une nouvelle vue ACCOUNT_USAGE.QUOTA_ACCESS_BLOCK_HISTORY et une propagation des changements ramenée à 5-10 minutes
  • Anomaly monitors pour les anomalies de coûts (Preview) : Un anomaly monitor permet de définir son propre périmètre via des tags et des types de service, avec sa propre liste de notification. Jusqu'à 20 monitors par compte.
  • Ingestion Power BI pour Semantic View Autopilot (GA, 18 août) : vous pouvez charger un fichier .pbit ou .pbix et générer automatiquement une semantic view depuis votre modèle Power BI existant, en préservant les mesures DAX, les relations entre tables et les descriptions de colonnes
  • Openflow seconde génération (Preview, 31 août) : les déploiements, runtimes et connecteurs Openflow deviennent des objets SQL Snowflake de plein droit, avec RBAC standard, gestion de cycle de vie en SQL (CREATE, ALTER, DROP, SHOW, DESCRIBE), configuration versionnée sous forme de File Based Entities (commit, rollback, promotion entre environnements via Git) et un assistant de configuration. Connecteurs supportés en preview : PostgreSQL CDC et MySQL/MariaDB CDC. Les ressources gen 1 continuent de fonctionner et peuvent coexister
  • Tags multi-valeurs (GA, 25 août) : un même tag peut porter plusieurs valeurs, utile quand un objet relève de plusieurs classifications non exclusives (plusieurs sources de données, plusieurs exigences de conformité). Création avec MULTI_VALUE = TRUE, puis ADD VALUE / DROP VALUE ; vérification avec SYSTEM$TAG_VALUE_CONTAINS. Les tags fournis par Snowflake sont arrivés en preview publique le 31 août
  • Automations dans Snowflake CoWork (Preview, 6 août) : transforme un rapport ponctuel en rapport récurrent. CoWork rejoue votre question avec des données fraîches selon la planification choisie et vous envoie les résultats par e-mail (résumé, métriques clés, lien vers le rapport complet). Configurable conversationnellement ou depuis l'onglet Automations.
  • CoCo dans l'extension Visual Studio Code (GA, 27 août), complété par le développement distant en preview le 25 août ,l'agent Snowflake s'installe durablement dans l'IDE des équipes.
  • Mode IA pour la classification des données sensibles (Preview, 17 août) et remédiation des violations Trust Center (GA, 14 août).
  • Inline Stored Procedures pour les hybrid tables (Preview, 3 août) : un nouveau type de procédure dont le corps entier s'exécute comme une unité atomique poussée directement dans la couche de traitement des requêtes, réduisant la surcharge par instruction pour des charges OLTP à faible latence.
  • AI_MULTI_EMBED pour les gros fichiers vidéo (GA, 10 août) : recherche vidéo sémantique jusqu'à 6 Go par fichier via le modèle TwelveLabs Marengo Embed 3.0.
  • Intégration au catalogue REST Amazon S3 Tables (GA, 10 août) et accès aux tables Iceberg gérées en externe via Horizon Catalog (Preview, 18 août) : la stratégie d'interopérabilité Iceberg se poursuit.
  • Nouvelle colonne agents_info dans ACCESS_HISTORY (3 août) : dans la continuité de la colonne agent_type de juillet, elle détaille les agents ayant accédé aux données pour le compte d'un utilisateur. L'inventaire des agents IA dans le Trust Center est aussi passé en preview le 3 août, et l'onglet AI Security du Trust Center en GA.

Agenda Snowflake : Les prochains rendez-vous

15 Octobre 2026 : Snowflake World Tour Paris (Palais des Congrès, Porte Maillot ,8h30-18h30) Keynote d'ouverture, sessions thématiques, démos live et témoignages clients sur le déploiement d'agents IA à grande échelle
L'équipe Next Decision sera présente tout au long de la journée ! Venez échanger avec nos experts sur vos projets et partager vos retours d'expérience. Réservez votre place ! 

Vous souhaitez bénéficier d'experts, de développeurs, ou d'une formation sur Snowflake ? Rendez-vous sur la page Contact.