Gestion des coûts Snowflake : le point en 2026 (récap du webinar)

• La plateforme Snowflake s'est étendue bien au-delà du compute et du stockage, et chaque nouveau service est un nouvel endroit où les coûts peuvent se cacher.
• Les fonctions Cortex AI de Snowflake sont puissantes, mais aussi le moyen le plus simple de dilapider des milliers de dollars par inadvertance. Un client a dépensé 60 000 $ en trois jours à cause d'une requête censée tourner en QA qui s'est exécutée en production.
• La visibilité doit précéder l'optimisation. Des équipes découvrent régulièrement des workloads coûtant des centaines de milliers de dollars par an dont personne ne connaissait l'existence.
• Les optimisations au meilleur ROI sont souvent simples : exécuter les jobs moins souvent et appliquer le right-sizing aux warehouses, plutôt que réécrire des requêtes.
• Pour passer la gestion des coûts à l'échelle d'une organisation en croissance, il faut donner à chaque équipe sa propre visibilité, au lieu de faire transiter chaque question de coût par une équipe centrale.

Snowflake, c'était avant tout du compute et du stockage. Mais ce n'est plus qu'une partie du tableau. Ian et Dave ont passé en revue la liste croissante de services que les clients exécutent désormais sur la plateforme : applications natives, applications Streamlit, modèles de machine learning déployés sur des compute pools, un éventail de capacités IA en pleine expansion, et même des workloads Postgres depuis le rachat de Crunchy Data par Snowflake.

Chacun de ces services apparaît comme une nouvelle ligne sur la facture. Cela crée un vrai problème de suivi : si votre dispositif de monitoring ignore l'existence d'un nouveau service, vous ne verrez tout simplement pas ce qu'il coûte. SELECT maintient une équipe de près de 30 ingénieurs dont la mission est uniquement d'anticiper les releases de Snowflake, afin que les nouvelles sources de coûts soient prises en charge dès leur lancement, et non des mois plus tard.

Dave a ajouté qu'il ne s'agit pas d'une simple contrariété technique. Les directions prennent de plus en plus de décisions sur l'endroit où les workloads doivent s'exécuter, et elles ne peuvent pas le faire sans une vraie transparence des coûts pour les étayer.

Les fonctions Cortex de Snowflake (désormais appelées AI SQL) permettent d'exécuter de l'IA directement sur les données stockées dans Snowflake. L'exemple de Dave : filtrer les avis produits pour ne garder que ceux où le client exprime de la frustration, en une seule requête. Il y a quelques années, cela impliquait des humains qui relisaient et étiquetaient chaque enregistrement à la main.

Cette facilité s'accompagne d'un vrai risque. Dave a partagé l'exemple d'un client : une requête intégrant une fonction Cortex devait tourner en QA. Elle s'est exécutée en production sur l'ensemble du dataset, et a consommé 60 000 $ de tokens en trois jours, sans rien d'exploitable à la clé.

Ian a expliqué pourquoi cela arrive si facilement. L'usage de l'IA est facturé aux tokens entrants et sortants. Les tokens en entrée sont à peu près prévisibles à l'avance, puisque vous pouvez estimer la taille de ce que vous donnez au modèle. Les tokens en sortie ne le sont pas, car la quantité générée dépend de la question elle-même. C'est cette asymétrie qui rend les coûts IA si difficiles à prévoir avant d'exécuter quoi que ce soit.

Comment obtenir de la visibilité sur les dépenses IA dans Snowflake ?

Le schéma account usage de Snowflake inclut plusieurs vues dédiées à l'IA. La plupart fonctionnent comme les autres vues account usage, avec un usage horaire ventilé par modèle. La vue AI SQL usage est au niveau de la requête : vous voyez le modèle utilisé et le texte de la requête, mais pas le prompt lui-même. L'option la plus granulaire est la table d'événements AI observability. On y accède via une fonction de table plutôt qu'une vue standard, et elle peut montrer les prompts à l'origine de l'usage. Elle est en général plus lente à interroger et, d'après ce qu'en comprend Ian, n'est pas persistante, ce qui complique les analyses sur de longues périodes.

Les budgets et quotas IA de Snowflake stoppent-ils vraiment les dérapages de dépenses ?

Dans l'ensemble, oui, avec une lacune importante. Les budgets IA permettent de fixer une limite mensuelle de crédits pour un compte ou un groupe d'objets taggés, couvrant les agents Cortex, Cortex search et les fonctions IA, et vous alertent quand la limite est dépassée. Les quotas par utilisateur vont plus loin et bloquent réellement l'usage, même si l'application prend quelques minutes à s'enclencher au lieu d'arrêter une requête instantanément.

La lacune : une seule requête volumineuse peut encore pulvériser la limite avant que le système ne réagisse. L'exemple d'Ian : lancer une fonction d'analyse de sentiment sur une table massive d'avis en une seule passe. Vous pouvez dépenser 10 000 $, et seule la requête suivante est bloquée. Les quotas permettent tout de même de bloquer les cas répétés ou qui tournent tout un week-end, et Ian a décrit leur mise en place comme la chose à retenir absolument de la session. Mais ils ne remplacent pas les bonnes pratiques, comme tester en QA sur des datasets limités avant de toucher à la production.

Comment mesurer le ROI des dépenses IA ?

Il n'existe pas de formule universelle. Commencez par le volet que vous pouvez mesurer précisément : le coût. Pour la valeur, tout dépend du cas d'usage. Si l'IA remplace quelque chose qui existait déjà, comme une équipe qui classifiait le sentiment manuellement, comparez l'ancien coût en temps et en compute avec le nouveau. Si elle rend possible quelque chose de nouveau, vous travaillez le plus souvent avec des indicateurs indirects : temps gagné, vélocité des tickets ou des stories dans un système comme Jira, ou chiffre d'affaires récupéré. Quand rien de tout cela ne donne de réponse claire, la suggestion d'Ian était sans détour : coupez la fonctionnalité et voyez qui se plaint.

Avant tout travail d'optimisation, vous devez savoir ce que les choses coûtent réellement. Ian a partagé l'exemple d'un client qui, lors de sa première connexion à SELECT, a trouvé en tête de liste un workload coûtant 850 000 $ par an, porté en grande partie par une fonction IA tournant dans ce qui s'est révélé être un job de QA. Ils l'ont désactivé. Aucune investigation poussée nécessaire : la visibilité a suffi à faire émerger le correctif.

Dave a illustré la même leçon avec un autre cas : un client qui dépensait 10 000 $ par an uniquement pour envoyer un e-mail depuis Snowflake. Un seul coup d'œil au coût réel a suffi pour déplacer ce workload vers une solution moins chère. Il entend aussi tout le temps "je pensais avoir désactivé ça il y a trois mois" dès que les clients découvrent pour la première fois les coûts requête par requête et workload par workload.

Une fois la visibilité en place, la question suivante est de savoir si une optimisation vaut votre temps. Passer une journée d'ingénierie pour économiser 500 $ de stockage est un mauvais calcul. Passer quelques heures pour économiser 20 000 $ est un oui évident. Le conseil d'Ian : vérifiez ce calcul avant de commencer, et attaquez les gains rapides avant de réécrire le moindre SQL.

Quelles sont les optimisations au meilleur ROI une fois que vous savez où regarder ?

1. Exécutez les jobs moins souvent. Un job qui tourne toutes les heures et coûte 10 000 $ par an tombe sous les 500 $ par an s'il suffit de l'exécuter quotidiennement, soit une réduction de 96 % pour un simple changement de configuration. Même passer d'une exécution horaire à une exécution toutes les trois heures économise environ les deux tiers du coût.
2. Appliquez le right-sizing à vos warehouses. Chaque taille supplémentaire double le compute et le coût ; un warehouse plus grand n'est donc rentable que si le temps de requête est lui aussi divisé par deux. L'exemple d'Ian : passer un warehouse d'ingestion de Large à Extra Small a fait grimper le temps moyen de requête d'environ cinq secondes à environ vingt, un délai que personne n'a remarqué, et a économisé 50 000 $ par an. Une heuristique utile : environ 125 partitions scannées par cœur CPU (un warehouse Large compte 64 cœurs) ; une requête qui ne scanne que 500 partitions a donc rarement besoin de plus qu'un Extra Small.
3. Gare au pattern Snowflake utilisé comme file de messages. Dave a vu des équipes utiliser Snowflake comme une file Kafka, en exécutant des millions de micro-opérations au lieu des opérations batch plus volumineuses pour lesquelles la plateforme est conçue. Résultat : des warehouses qui tournent sans interruption, et une facture qui grimpe. Faites correspondre le workload à la bonne technologie.
4. Pensez à la scalabilité horizontale, pas seulement verticale. Dave a souligné qu'on choisit souvent une taille de warehouse en négligeant le nombre de clusters. Augmenter le nombre de clusters peut donner de meilleurs résultats qu'augmenter simplement la taille du warehouse, selon le workload.
5. Utilisez des agents de codage IA pour les réécritures plus complexes. L'exemple interne de SELECT partagé par Ian : un dataset entièrement recréé à chaque exécution coûtait plus de 8 000 $ par an, et quelques heures passées à rendre la requête incrémentale ont supprimé cette dépense. Il a ajouté que des agents de codage comme Coco rendent désormais ce type de réécriture possible en quelques heures, là où il fallait auparavant des jours.

Concernant l'ingestion en particulier, Ian a indiqué qu'elle représente généralement 10 à 20 % des dépenses de compute, une part en baisse tendancielle. Snowpipe Streaming a divisé les coûts d'ingestion par environ 10 pour certains clients, et l'adoption d'Iceberg y contribue aussi. Les deux économies d'ingestion les plus simples selon Dave : n'importer que les tables et colonnes dont vous avez réellement besoin, et aligner la fréquence de rafraîchissement sur le vrai besoin métier plutôt que de viser par défaut le quasi-temps réel.

Les équipes migrent-elles leurs workloads vers des moteurs moins chers comme DuckDB, ou adoptent-elles Iceberg pour économiser ?

À petite échelle, parfois. Un ingénieur seul dans une petite entreprise peut raisonnablement router certains workloads vers un moteur comme DuckDB. À grande échelle, avec des milliers d'utilisateurs qui ont besoin de contrôles d'accès centralisés, c'est rare, car trop difficile à gérer. Dave a dit qu'il n'avait jamais vraiment considéré Iceberg comme une mesure d'économie. Son attrait, c'est l'interopérabilité : réutiliser les mêmes données depuis de nombreux endroits sans dépenser davantage de compute. Ian a ajouté qu'Iceberg peut réduire les coûts d'ingestion et évite de payer deux fois le stockage, mais qu'il voit rarement plusieurs moteurs de compute tourner par-dessus. Ce que Dave observe plus souvent, ce sont des clients qui déplacent des workloads entiers entre plateformes, par exemple de Snowflake vers Databricks ou de Postgres vers Snowflake et inversement, selon la pertinence. Pour lui, il s'agit d'économiser du compute plutôt que d'optimiser le stockage.

Une seule équipe data centrale qui répond à toutes les questions de coûts ne passe pas à l'échelle. Dave, qui a été cette personne, a décrit comment une petite équipe devient un goulot d'étranglement dès que chaque demande data transite par elle. La solution consiste à donner aux utilisateurs finaux la visibilité sur les coûts qu'ils génèrent, pour que chacun puisse agir en acteur responsable de ses dépenses.

Cela commence par l'allocation des coûts : rattacher les dépenses aux équipes qui en sont responsables, afin que l'attention de chacun reste sur ce qu'il peut contrôler. Des audiences différentes ont aussi besoin de vues différentes. Les dirigeants veulent en général des dashboards de haut niveau présentant les coûts par groupe, à la journée, à la semaine ou au mois. Les praticiens veulent voir précisément ce que leur propre équipe exécute.

Rendre cette information facile d'accès compte autant que de la posséder. Dave a suggéré de construire des dashboards pertinents pour chaque audience, ou de donner aux utilisateurs l'accès à un serveur MCP pour qu'ils puissent poser les bonnes questions à Claude. Ian a ajouté que les utilisateurs ont parfois simplement besoin d'informations organisées dans une interface facile à utiliser : servez-les-moi, ne m'obligez pas à aller les chercher.

Un centre d'excellence a un vrai rôle à jouer, mais un rôle restreint. L'équipe centrale doit conseiller les utilisateurs sur la manière d'améliorer leurs coûts et diffuser ce savoir dans toute l'organisation, et non assumer elle-même chaque optimisation. Comme l'a formulé Ian, faire ces optimisations une à une pour le compte de toute l'organisation atteint vite ses limites.