Snowflake Summit 2026 : ce qui a vraiment été livré, et ce que ça change

Snowflake a ouvert le bal avec deux changements de nom qui touchent presque toutes les autres annonces. Cortex Code s’appelle désormais Coco. Snowflake Intelligence devient Cowork. Coco s’adresse aux développeurs et aux builders. Cowork vise les utilisateurs métier qui veulent des réponses, pas du code.

Quasiment toutes les autres fonctionnalités de ce récapitulatif reposent sur Coco ou alimentent Cowork. C’est le fil conducteur de tout l’événement.

OpenFlow passe en mode headless. OpenFlow extrait et charge les données dans Snowflake, en concurrence directe avec des outils comme Fivetran et des orchestrateurs comme Dagster. Jeff a rappelé que l’interface d’OpenFlow a toujours été difficile à utiliser. La solution livrée par Snowflake est un modèle d’objets headless et programmable, pilotable entièrement via Coco : au lieu de cliquer dans une interface confuse, vous décrivez ce que vous voulez et un agent le construit.

Snowflake DataStream, c’est Kafka sur Snowflake. Il est compatible avec le protocole Kafka : en théorie, vous pointez vos producteurs Kafka existants vers une nouvelle URL Snowflake et les données arrivent directement dans vos tables, sans bucket intermédiaire. Pour Ian, c’est l’une des annonces majeures de l’événement : elle supprime toute une catégorie de dépendances à des fournisseurs externes pour l’ingestion en temps réel, et elle fonctionne aussi bien avec les tables natives Snowflake qu’avec les tables Iceberg.

Le miroir de données Postgres est peut-être l’annonce la plus importante pour les développeurs d’applications. Activez une option, et vos données Postgres apparaissent automatiquement dans Snowflake via la capture des changements (CDC), sans pipeline ETL. La BI traditionnelle est par définition en retard : les chargements par lots s’exécutent une fois par heure ou par jour, donc tout ce qui s’est passé dans votre système source depuis le dernier chargement n’apparaît pas encore. Cette fonctionnalité comble ce décalage pour les cas où Postgres est la base de données opérationnelle. Ian y voit la réponse de Snowflake au modèle hybride transactionnel-analytique pour lequel Unistore avait été conçu à l’origine, sans la complexité de monter cette architecture vous-même.

Snowflake Postgres est passé en disponibilité générale, avec la prise en charge du private link pour les comptes business-critical, les clés gérées par le client et une nouveauté baptisée PGLake : la possibilité d’utiliser Postgres lui-même comme catalogue Iceberg à la place d’un catalogue basé sur JSON. Jeff y voit une réponse directe à DuckLake, qui avait pris les devants avec une approche similaire de catalogue alternatif.

Les migrations assistées par IA revendiquent une réduction de 88 % du temps nécessaire. Ni Ian ni Jeff ne sont prêts à cautionner ce chiffre. L’avis d’Ian : "C’est du marketing à l’état pur, un chiffre sorti de nulle part pour faire bonne impression." Prenez-le comme un signal directionnel — la migration assistée par IA va plus vite — et non comme un chiffre sur lequel bâtir un budget.

Plusieurs annonces de cette catégorie se complètent plutôt qu’elles n’existent isolément :

• L’adaptive compute passe en disponibilité générale. C’est le pas de Snowflake vers un modèle plus proche de celui de BigQuery, où l’on se préoccupe moins du dimensionnement des warehouses. L’avis de Jeff, fondé sur le webinaire de SELECT consacré au sujet avant le Summit : il reste du dimensionnement à prendre en compte, mais c’est clairement la direction prise par Snowflake, et cette option deviendra probablement le compute par défaut d’ici quelques années. Ian a souligné une mise en garde importante : plusieurs clients ont supposé que l’adaptive compute était une fonctionnalité de réduction des coûts. Ce n’est pas le cas. Elle vise à améliorer les performances sans réglage manuel, pas à alléger votre facture.
• Interactive workloads s’appuie sur les tables et warehouses interactifs, conçus pour concurrencer ClickHouse sur l’analytique à faible latence. Cette version y ajoute le dimensionnement de clusters, la sélection de clés et des améliorations de précache.
• Le compilateur interactif revendique une compilation 40 fois plus rapide. Jeff a creusé le sujet et n’est toujours pas certain que cela s’applique uniquement aux workloads interactifs ou à toutes les requêtes exécutées sur des warehouses Snowflake standard. Les informations publiques sont suffisamment contradictoires pour que nous préférions signaler l’incertitude plutôt que de deviner.
• L’optimisation du moteur Unistore a été livrée en parallèle, avec peu de détails publics pour l’instant.

Le résumé d’Ian : interactive workloads et Unistore visent directement les équipes qui construisent des expériences rapides, de type applicatif, sur Snowflake. L’adaptive compute cible des workloads ETL et BI plus traditionnels, et il s’agit de performance, pas de coût.

AI Complete lit désormais l’audio et la vidéo, et plus seulement le texte et les images.

Cortex AI Function Studio (preview publique) vous permet de créer vos propres fonctions Cortex personnalisées. Pointez-le vers des lignes contenant des images, demandez-lui de repérer celles qui présentent un attribut spécifique, et il renvoie une fonction que vous pouvez appeler comme n’importe quelle autre. Les équipes plateforme peuvent valider la fonction avant son déploiement à grande échelle.

xAI rejoint le catalogue de modèles, aux côtés d’Anthropic, OpenAI, Google, Meta, Mistral et DeepSeek. L’important n’est pas tant Grok en soi que le signal envoyé : Snowflake se positionne comme une couche d’agrégation sécurisée pour le LLM de votre choix, gouvernée via vos identifiants Snowflake existants au lieu de gérer des clés API distinctes pour chaque fournisseur.

L’agentic search se confond facilement avec le Cortex Search existant. La distinction : Cortex Search renvoie des extraits de texte et des réponses verbeuses issues de documents non structurés. L’agentic search est conçue pour renvoyer une réponse unique et déterministe : une question comme "combien de contrats sont datés de 2025" retourne un chiffre plutôt qu’une pile d’extraits de contrats.

Les code bundles permettent d’exécuter du Python comme un simple fichier .py. Jusqu’ici, exécuter du Python dans Snowflake impliquait de l’encapsuler dans une procédure stockée SQL ou de travailler dans un notebook, deux options incompatibles avec un workflow de débogage classique. Désormais, vous chargez un fichier Python dans un stage et le planifiez directement. Ian a souligné le temps que cela a pris : "Je dois l’encapsuler dans un autre langage pour le définir ? Ce n’est pas ce que je voulais." L’obligation de passer par une procédure stockée était un vrai point de friction de l’expérience développeur, et sa suppression compte pour convaincre les équipes qui veulent simplement écrire du Python.

Côté ML : Cortex Training (preview privée) permet d’affiner des modèles ouverts comme Qwen et Mistral sur vos propres données ; un modèle beaucoup plus petit surpasserait ainsi un modèle bien plus grand une fois entraîné sur votre jeu de données spécifique. Le Snowflake Pipeline Builder ajoute une interface en glisser-déposer pour construire des pipelines ML, dans l’esprit d’outils comme Alteryx, avec Coco disponible pour en poser les bases. Les extensions VS Code et Cursor pour le ML, ainsi que les tests A/B en ligne, sont également passés en preview publique.

Streamlit sur Snowflake est passé en disponibilité générale, et s’exécute désormais sur un runtime de conteneurs plutôt que sur des warehouses Streamlit dédiés. Les pools de conteneurs sont facturés à une fraction du crédit horaire d’un warehouse complet, ce qui devrait réduire sensiblement le coût d’exécution des applications Streamlit.

App Runtime résout un vrai problème : la découvrabilité. Jeff l’a testé directement en déployant la même application dans Snowpark Container Services et dans App Runtime. La différence fonctionnelle : les applications App Runtime apparaissent dans un onglet Apps au sein de Snowsight, si bien que les collaborateurs de toute l’entreprise peuvent réellement les trouver. Les applications construites directement dans Container Services exigent que quelqu’un ait déjà l’URL en favori, sans quoi personne ne les trouve.

Snap and Ask permet de sélectionner un graphique généré par Cowork et de lui poser directement des questions complémentaires. Snowflake ne l’a pas montré en démo live, il n’y a donc pas grand-chose à ajouter pour l’instant, si ce n’est le guetter dans les prochaines versions.

Iceberg v3 a atteint la disponibilité générale, et Snowflake revendique la prise en charge v3 la plus complète de tous les fournisseurs Iceberg, y compris le support intégral des insertions, mises à jour, suppressions et fusions atomiques. Le catalogue REST Iceberg rend aussi possibles les workflows multi-moteurs : transformez des données dans DuckDB, et les changements apparaissent dans Snowflake via le catalogue partagé.

Le stockage Iceberg géré par Snowflake est en disponibilité générale sur AWS, Azure et GCP suivront bientôt. Un changement structurel à connaître même s’il n’a pas fait la une : la mise en place et la gestion de votre propre catalogue Polaris disparaissent entièrement. Tout passe désormais par défaut par le catalogue Horizon, qui fait tourner Polaris en sous-jacent sans jamais exposer ce concept à l’utilisateur. Créez une table de type Iceberg, et elle apparaît automatiquement dans Horizon.

La lecture d’Ian sur l’adoption d’Iceberg plus largement, d’après la base clients de SELECT : elle reste concentrée dans deux groupes. Les entreprises digital-native dotées de très gros volumes de données et d’équipes d’ingénierie solides (pensez à Coinbase ou Shopify), et les grandes entreprises disposant des effectifs d’ingénierie nécessaires pour gérer la complexité. L’investissement continu de Snowflake vise à abaisser cette barrière à l’entrée.

Lors du webinaire, Paul Horan a demandé si le RBAC à granularité fine (filtrage de lignes, masquage de colonnes) s’étendait au catalogue REST Iceberg lui-même, de sorte que les consommateurs utilisant par exemple Athena soient gouvernés de la même manière que les utilisateurs Snowflake. Ni Ian ni Jeff n’avaient de réponse ferme. L’expérience de Jeff consiste à garder la gouvernance dans la couche Snowflake et à n’utiliser l’API REST que pour le déplacement de données, ce qui contourne la question plutôt que d’y répondre. Cela ressemble à un véritable problème ouvert pour quiconque cherche à construire une architecture réellement multi-moteurs sans dupliquer une couche de gouvernance sur chaque moteur.

Autres nouveautés côté partage de données :

• Le repartage de données inclut désormais un paramètre permettant aux fournisseurs de décider si leurs consommateurs peuvent repartager les données en aval.
• L’open sharing permet d’exposer des données à des clients non Snowflake via une API REST, sans compte Snowflake ni compte reader de leur côté.
• Les clean rooms ont aussi reçu des mises à jour, même si ni Ian ni Jeff ne se sentaient en mesure d’en parler en détail.
• L’écosystème zero-copy s’est élargi à SAP, Workday et IBM watsonx.data (orthographié ainsi, ce n’est pas une coquille), rejoignant l’intégration Salesforce existante.

Sur ce dernier point, Ian et Jeff ont tous deux nuancé le discours. Déployer un Salesforce Data Cloud ou un SAP Business Cloud pour obtenir un accès zero-copy coûte souvent plus cher que de simplement charger ces données dans Snowflake via un ETL classique. L’avis de Jeff : ce n’est pas vraiment une démarche d’économie, mais de simplicité, et c’est sur ce terrain qu’il faut l’évaluer plutôt que de supposer qu’elle fait économiser de l’argent par défaut.

Cowork a aussi gagné des connecteurs vers Redshift, Postgres et d’autres services externes, fonctionnant à la manière de serveurs MCP. Snowflake l’a montré en direct : un agent a extrait des données de Snowflake et des données d’enrichissement de Redshift dans la même conversation pour répondre à une seule question.

Coco (anciennement Cortex Code) apparaît désormais dans tout Snowsight, dans le catalogue Horizon et au sein des Workspaces, représenté par une icône scintillante bleue. Quelques surfaces spécifiques à connaître :

• Coco for Desktop est un fork complet de VS Code avec un mode agent (interface de type chat) et un mode éditeur qui ressemble au VS Code standard. Jeff le teste et le trouve vraiment bien construit, même s’il utilise toujours principalement VS Code avec le plugin Claude Code comme configuration de référence. Il estime être investi à environ 15 % dans l’écosystème Coco, pour les cas où celui-ci gère clairement mieux les tâches spécifiques à Snowflake.
• L’extension VS Code principale de Snowflake inclut désormais un accès direct à Cortex Code, via une icône scintillante dans le coin supérieur.
• Un catalogue public de skills existe en dehors de l’interface Coco elle-même, et Coco dispose aussi d’un plugin pour Claude.
• Les agents cloud peuvent désormais s’exécuter dans des environnements sandbox isolés au sein de Snowsight, afin que les modifications pilotées par des agents ne risquent pas de détruire des ressources auxquelles ils ne devraient pas toucher.

Cowork n’exige plus de choisir le bon agent avant de poser une question. Un orchestrateur détermine désormais quel agent sous-jacent doit traiter la requête, supprimant une étape qui en demandait beaucoup aux utilisateurs non techniques.

La mémoire par utilisateur fait aussi son apparition, à la manière dont Claude conserve le contexte au fil d’une conversation. Cowork peut désormais se constituer des skills et une mémoire propres à chaque utilisateur, liées à ce sur quoi il travaille.

L’écosystème de connecteurs est plus large que ne le laissait penser la slide : les intégrations Slack, Teams et calendrier alimentent désormais Cowork. L’exemple montré par Snowflake : demandez à Cowork "à quoi ressemble ma journée", et il consulte votre calendrier, repère un rendez-vous commercial, récupère les notes du compte Salesforce concerné, vérifie l’historique Slack pour les mentions associées et extrait les données Snowflake les plus pertinentes, puis renvoie un véritable résumé de préparation pour cette réunion.

Les tâches planifiées et les automatisations permettent de configurer des vérifications récurrentes, comme demander à Cowork de consulter chaque semaine une page de release produit pour une fonctionnalité que vous attendez. Jeff s’en sert lui-même pour suivre le moment où Snowflake livrera la possibilité de combiner plusieurs artefacts épinglés (graphiques enregistrés depuis les réponses de Cowork) sur un seul dashboard.

Cortex Sense construit du contexte à partir de l’historique des requêtes, des dashboards et des métadonnées pour améliorer la précision. Ni Ian ni Jeff n’avaient encore une idée claire de la façon d’interagir directement avec cette fonctionnalité.

La gouvernance pilotée par l’intention est peut-être l’annonce la plus intéressante de cette section. Au lieu d’écrire des politiques à la main, vous décrivez une intention en langage naturel, par exemple garantir qu’aucun numéro de sécurité sociale n’est exposé, et Snowflake analyse le compte à la recherche de violations et vous aide à les corriger.

Les quotas IA par utilisateur permettent de plafonner les dépenses par personne et par jour plutôt que de s’appuyer sur un budget unique à l’échelle du compte. L’approche pratique de Jeff avec ses clients : faire de Claude Sonnet 4.6 quasiment le seul modèle activé sur certains comptes, car il est efficace et bien positionné en prix maintenant que des modèles plus récents comme Opus et Fable existent. Ainsi, personne n’interroge accidentellement un modèle bien plus coûteux et ne fait grimper une facture imprévue.

Si la maîtrise des dépenses IA sur Snowflake est un sujet sur lequel vous travaillez activement, The Unofficial AI Cost Optimization Manual for Snowflake approfondit les quotas, le choix des modèles et l’origine réelle des coûts.

La réplication de compte nouvelle génération utilise la capture des changements basée sur les logs pour le basculement inter-régions, avec des sauvegardes 20 fois plus rapides et de meilleurs SLA. Snowflake a partagé un chiffre concret sur scène : lors d’une panne cloud majeure l’an dernier, 300 clients ont basculé automatiquement vers une région de secours sans intervention manuelle.

Observe by Snowflake est un produit de monitoring façon Datadog, mais il n’en est qu’à ses débuts. Il est issu de l’acquisition d’Observe par Snowflake, et ni Ian ni Jeff n’ont encore vu de démo fonctionnelle ou de captures d’écran. Vu le temps qu’ont mis certains éléments de l’acquisition précédente de Select Star à aboutir pleinement, ne vous attendez pas à ce qu’Observe arrive plus vite.

Natoma semble être un moyen de connecter Cowork en toute sécurité au reste de votre écosystème métier (Slack, Salesforce et outils similaires) via votre fournisseur SSO existant, qu’il s’agisse d’Okta ou de Microsoft. Un chiffre partagé par Snowflake : plus de 225 cas d’usage non autorisé de "shadow AI" détectés en moyenne par organisation, c’est-à-dire des employés utilisant des outils comme ChatGPT ou des assistants de code non approuvés, sans validation officielle. Pour Jeff, Natoma est probablement le mécanisme par lequel Snowflake branchera Cowork sur l’ensemble de la stack métier en toute sécurité, même si les documents publics ne le précisent pas encore explicitement.

Les dynamic tables ont gagné une fonctionnalité de "frozen period" peu après le Summit : elle permet d’indiquer à une dynamic table de ne jamais tenter de rafraîchir des données antérieures à un horodatage donné, y compris via des expressions relatives comme "aujourd’hui moins 30 jours". Utile si certains enregistrements historiques doivent rester intacts quelles que soient les modifications en amont.

Deux tendances traversent presque tout ce récapitulatif. D’abord, Snowflake continue d’investir pour rendre l’entrée et la sortie des données moins chères et plus simples, sans dépendre de fournisseurs externes : OpenFlow, DataStream, le miroir Postgres et les intégrations zero-copy vont tous dans le même sens. Ensuite, presque tout passe désormais par Coco ou Cowork, ce qui indique clairement la direction prise par la plateforme dans son ensemble.

Si vous gérez des coûts au-delà de Snowflake, SELECT prend désormais en charge Databricks en plus de Snowflake, et la prise en charge de BigQuery arrivera plus tard ce trimestre.

Si la maîtrise des coûts IA sur Snowflake fait partie de vos priorités, surtout maintenant que les quotas par utilisateur et le choix des modèles entrent en jeu, téléchargez The Unofficial AI Cost Optimization Manual for Snowflake. Jeff l’a rédigé, et il va bien au-delà de ce que nous avons pu couvrir ici.