Snowflake Cortex : la plateforme IA du data cloud, comparée et chiffrée

Fonctionnalités, modèles disponibles, gouvernance, grille de décision face à Databricks, BigQuery ML et Azure AI Studio.

La question qui revient en comité de direction est rarement « quel modèle ? » mais « pourquoi ne pas appeler l'API du fournisseur directement ? ». Snowflake Cortex AI répond par l'argument du lieu : des modèles accessibles par appel SQL, une recherche vectorielle gérée, des agents, une console de supervision, tout cela à côté des données déjà présentes dans l'entrepôt. Face à lui, trois concurrents jouent la même carte depuis leur propre environnement.

La documentation publique et les démonstrations partenaires montrent que Snowflake Cortex fonctionne. Reste à savoir ce que ces fonctionnalités valent face à Databricks Mosaic AI, à BigQuery ML et à Azure AI Studio, sur un cas d'usage précis, dans une région européenne précise, avec un coût de sortie connu avant de signer.

On passe en revue la plateforme, on la confronte à ses concurrents, on démonte le coût réel au-delà du prix d'inférence, puis on ferme sur une méthode pour exiger des benchmarks reproductibles.

Snowflake Cortex AI : les briques à connaître

La plateforme se décompose en modules qui se combinent. Les connaître sépare un pilote utile d'une démonstration cosmétique.

Cortex LLM Functions

Les Snowflake AI Cortex Functions exposent des opérations de traitement de texte via SQL : COMPLETE pour la génération, SUMMARIZE pour le résumé, TRANSLATE, SENTIMENT, EXTRACT_ANSWER, CLASSIFY_TEXT. L'appel se fait depuis une requête SQL standard, le résultat revient en colonne. Côté modèles, la documentation publique recense des familles large language model Llama, Mistral, Claude, GPT et Snowflake Arctic, le modèle maison. Les modèles Anthropic Claude et OpenAI GPT figurent au catalogue des fonctions SQL, selon la région. Le Snowflake Cortex AI gateway est un point d'accès distinct, qui gouverne l'usage par des clients, des agents de code et des SDK (traces, budgets, quotas).

Cortex Search

Service de recherche hybride qui combine recherche par mot-clé et vector embeddings. Snowflake indexe le document, calcule les embeddings, et expose une API de requête. La base vectorielle ne quitte pas le Snowflake Data Cloud et les permissions de ligne restent appliquées. Sans ce point, un index externe exposerait des passages qu'un utilisateur ne devrait pas lire. Le mécanisme couvre donc à la fois la retrieval augmented generation et la recherche d'entreprise classique.

Cortex Analyst

Module de text-to-sql gouverné : l'utilisateur pose une question en langage naturel, Analyst produit une requête SQL contre un modèle sémantique déclaré par le data engineer. Pas de requête libre sur les tables. Le modèle sémantique fait office de contrat entre la question et le schéma physique. La différence avec un copilote généraliste tient à ce point exact : Analyst ne devine pas la structure, il lit un contrat écrit à la main.

Cortex Agents et interfaces

Un Snowflake Cortex Agent coordonne plusieurs outils : Cortex Search pour récupérer du contexte non structuré, Cortex Analyst pour interroger les tables, un modèle LLM pour synthétiser. L'orchestration est déclarative via la Snowflake Cortex API. On y définit les outils disponibles, les permissions, les prompts système. Pour les usages individuels, la solution Snowflake Intelligence, devenue Snowflake CoWork en juin 2026, offre une interface conversationnelle qui s'appuie sur ces briques sans développement.

Brique annexe mais utile : Cortex Guard, couche de filtrage anti-prompt-injection et anti-contenu sensible qu'on branche en aval d'un COMPLETE.

Snowflake Cortex AI vs Databricks Mosaic AI, BigQuery ML et Azure AI Studio

Ces plateformes s'adressent au même acheteur : l'équipe data qui veut appeler un LLM sans sortir de son environnement. Le reste se lit dans la documentation de chacune ; ce qui départage les offres tient en peu de points.

La facturation pèse le plus lourd. Snowflake agrège tout en crédits, par fonction et par modèle : c'est simple à budgéter, difficile à rapprocher d'un tarif au token chez un tiers. Databricks sépare les DBU et les tokens (pay-per-token ou provisioned throughput), ce qui se lit bien mais s'additionne à la main. Google cumule slots BigQuery et tokens Vertex. Azure facture les tokens Azure OpenAI ou réserve de la capacité en PTU. Sur Snowflake vs Databricks, le point de bascule se joue souvent là, avant même les capacités techniques. Le crédit unique est un atout pour une équipe qui veut un plafond de dépense lisible, et un piège pour celle qui doit prouver à sa direction financière ce que coûte un million de tokens.

La recherche vectorielle pose une question de territoire. Cortex Search reste dans le compte Snowflake et hérite des droits de ligne. Databricks Vector Search s'adosse aux Delta Tables sous Unity Catalog. Côté Google, on a le choix entre Vector Search BigQuery et Vertex AI Search. Azure AI Search tient dans un index séparé, mature mais à gouverner à part, avec Purview pour le catalogue. La gouvernance native suit la même ligne : Horizon chez Snowflake (masking, row access, lineage), Unity Catalog chez Databricks, Dataplex chez Google.

Pour l'orchestration, tout dépend de l'équipe. Les Cortex Agents se déclarent par API, ce qui accélère le prototype et limite la finesse du contrôle. Le AI Agent Framework de Databricks se code, Vertex AI Agent Builder et l'Azure AI Foundry Agent Service (avec Prompt Flow) se situent entre les deux. Côté modèles, Snowflake propose Arctic, Llama, Mistral, Claude et GPT selon la région, Databricks DBRX, Llama et Mistral, Google la famille Gemini, Azure les GPT-4o et o-series plus des modèles Hugging Face hébergés. Aucun catalogue ne l'emporte seul : la disponibilité régionale décide plus souvent que le nombre de modèles.

Snowflake Cortex et gouvernance : cloisons avant portes blindées

Les équipes sécurité ne demandent plus si l'IA est protégée. Elles demandent ce qui se passe quand une clé fuit, quand un prompt malicieux franchit le filtre, ou quand un modèle apprend ce qu'il ne devait pas apprendre. La bonne question ne porte pas sur la solidité de la porte d'entrée, mais sur le nombre de compartiments qui restent étanches quand l'eau entre.

Appliquée à Snowflake Cortex et à ses concurrents, cette grille de lecture produit des contrôles à mener séparément.

Le premier contrôle porte sur les données d'entraînement : le contrat doit dire noir sur blanc que prompts et complétions ne réentraînent pas un modèle partagé. Snowflake, Databricks, Google et Microsoft l'affirment pour leurs offres entreprise, mais les exceptions se cachent dans les conditions annexes, et seule la lecture ligne à ligne les trouve.

La région d'inférence est le deuxième point, et celui qui surprend le plus. Sur Cortex, la documentation liste les régions où chaque modèle est disponible ; si la vôtre n'est pas servie, l'option cross-region inference déplace la requête vers une autre juridiction, et elle doit être autorisée explicitement, jamais par défaut. Viennent ensuite les droits de ligne, que Cortex et Databricks appliquent aux fonctions LLM via Horizon et Unity Catalog, alors que BigQuery et Azure demandent une intégration supplémentaire. Reste la gestion des secrets d'un agent qui appelle des outils externes : stockés par le fournisseur, chiffrés avec la clé client, ou injectés à l'exécution ? Les réponses diffèrent, et le choix engage la sécurité plus que n'importe quel benchmark.

La différence entre une plateforme sûre et une plateforme solide tient à ce qu'elle a prévu pour l'incident, pas à la promesse qu'il n'arrivera pas. Un fournisseur sans plan de containment pour un prompt empoisonné n'a pas un produit plus sûr. Il a un produit moins honnête.

Snowflake Cortex : le prix affiché n'est pas le prix payé

Les grilles tarifaires publiques comparent le coût d'inférence : tant de crédits ou de dollars par million de tokens, par modèle, par région. Ce chiffre est utile pour l'exercice budgétaire mais incomplet pour la décision pluriannuelle.

D'autres coûts pèsent sur le TCO et apparaissent rarement dans la comparaison initiale :

1. Le stockage des embeddings. Une recherche vectorielle correcte sur un corpus documentaire conséquent produit des millions de vecteurs qu'il faut stocker, indexer, et reconstruire quand le modèle d'embedding change. Ce coût se cumule au coût d'inférence du chatbot au-dessus.
2. Le coût de sortie. Les vecteurs produits dans Cortex sont utilisables dans Cortex. Portés ailleurs, ils imposent un recalcul avec le modèle de destination. De même, faites confirmer par écrit si un modèle fine-tuné via Cortex est exportable vers un autre runtime ; la documentation Snowflake annonce par ailleurs l'arrêt du fine-tuning au premier trimestre 2027, au profit de Cortex Training. Changer de fournisseur dans trois ans coûte le prix du ré-embedding plus celui du ré-entraînement — jamais nul.
3. La capacité réservée. Pour tenir une latence prévisible en production, les quatre plateformes proposent une réservation payante : PTU chez Azure, provisioned throughput chez Databricks, capacité allouée chez Snowflake. Cette réservation se paie même quand elle n'est pas consommée.

Une méthode utile consiste à ne pas accepter le cadre proposé par le commercial sans poser une question qui force la révélation des contraintes réelles. Face à un prix affiché, une question calibrée produit souvent une remise annoncée nulle part : « Comment serais-je censé tenir ce budget si mon volume de requêtes double en six mois ? » Ce qui remonte alors — crédits non consommés reportables, remise par engagement pluriannuel, passage à PTU préférentiel — n'est presque jamais dans la grille publique.

Quelques questions ouvrent plus de portes que les autres. Quels sont les frais exacts pour exporter les embeddings et les modèles fine-tunés en cas de résiliation à l'échéance ? Il faut obtenir la formule, pas un « on en parle ». Quelle remise sur les crédits à l'engagement d'un an ou de trois ans, avec ou sans minimum de consommation ? Et si un modèle utilisé est retiré, quel préavis contractuel et quel modèle de remplacement, sans révision tarifaire ?

Choisir Snowflake Cortex par cas d'usage : grille de décision

La plateforme adaptée dépend du cas d'usage dominant. Voici les cas qui reviennent le plus souvent en pilotage IA, et la recommandation argumentée pour chacun.

Text-to-SQL interne pour analystes métiers

Ce cas d'usage échoue d'abord par manque d'entretien, pas par manque de technologie. L'objectif est de remplacer les tickets « peux-tu me sortir ce chiffre » adressés à l'équipe data. Cortex Analyst se distingue par son modèle sémantique déclaré — l'analyste décrit dimensions et métriques, le LLM se limite à ce contrat. Azure n'a pas d'équivalent natif à ce niveau : on y assemble Prompt Flow et des connecteurs sur mesure. BigQuery mise sur l'intégration Gemini avec les colonnes documentées, et Databricks propose Genie, équivalent fonctionnel.

Si les données vivent déjà dans Snowflake, Cortex Analyst est le plus direct. Il échoue quand personne n'est désigné pour tenir le modèle sémantique à jour : une métrique renommée dans le schéma physique et les réponses dérivent sans alerte. Sans propriétaire nommé pour ce fichier, mieux vaut ne pas démarrer.

RAG documentaire sur base de connaissances interne

Sur ce cas, Azure AI Search est souvent le concurrent le plus sérieux, et il gagne nettement dans un parc Microsoft 365. Cortex Search plus un COMPLETE en aval fait pourtant le travail sans quitter l'enceinte. La gouvernance par ligne est un argument décisif quand les documents sont sensibles. Databricks Vector Search tient le même rôle sur l'environnement Delta. Azure AI Search est mature et intégré à Azure OpenAI, mais l'index vit dans un service séparé. BigQuery propose Vertex AI Search, très abouti sur la recherche d'entreprise.

Cortex se justifie si les documents sont déjà dans Snowflake, Azure AI Search si le parc applicatif tourne surtout sur Microsoft 365, Vertex AI Search si le corpus mélange Google Drive et BigQuery. Le cas perdant est le corpus éparpillé sur plusieurs stockages : le coût de rapatriement des documents dépasse alors le bénéfice de la gouvernance par ligne.

Agents multi-outils pour assistance opérationnelle

Les Cortex Agents orchestrent recherche et SQL de manière déclarative — simple à prototyper, moins souple qu'un framework code-first. Azure AI Foundry Agent Service est l'offre la plus ouverte sur la coordination inter-outils externes, Vertex AI Agent Builder couvre le même terrain côté Google, et le AI Agent Framework de Databricks offre plus de contrôle à condition d'écrire le code.

Nous n'avons pas pu vérifier en production les limites de concurrence des agents Cortex sur des scénarios à fort trafic : les retours publics restent rares fin 2025. Un assistant exposé à plusieurs centaines d'utilisateurs simultanés doit passer par un pilote chronométré avant tout engagement d'infrastructure ; sinon, le framework code-first de Databricks reste la valeur sûre.

Génération de contenu structuré à grande échelle

Le batch est le seul cas où Cortex l'emporte presque sans discussion, tant que les données sont déjà chez Snowflake. Pour du traitement batch — résumés d'appels, extraction d'entités sur un corpus, classification de tickets — les fonctions SQL de Cortex (COMPLETE, EXTRACT_ANSWER, SUMMARIZE) sont imbattables côté intégration. Une requête SQL, une colonne de sortie. BigQuery ML offre le même confort avec ML.GENERATE_TEXT sur Gemini. Databricks et Azure demandent plus d'orchestration pour atteindre la même fluidité.

Pour le batch, mieux vaut calculer là où les données sont déjà : les déplacer coûte souvent plus cher que l'inférence. Cette logique s'inverse si le corpus est ponctuel et ne justifie pas de l'ingérer dans Snowflake, auquel cas un appel direct à l'API du modèle revient moins cher.

Exiger des benchmarks reproductibles avant engagement

Chaque éditeur présente des benchmarks favorables. Les slides montrent des scores, des temps de latence, des accuracies. Rien n'empêche de les contester sur le fond, et tout empêche d'arbitrer entre quatre démonstrations qui prétendent chacune être la meilleure.

Méthode qui tient : ne pas discuter les résultats, discuter la procédure. Demander à chaque fournisseur de livrer, avant toute signature :

Concrètement : le jeu de données exact utilisé, téléchargeable, le prompt système complet plutôt qu'un extrait choisi, les paramètres du modèle (température, top-p, max tokens), la version exacte du modèle à la date du test avec son numéro de build, et une procédure d'exécution qu'un tiers peut rejouer sans aide du fournisseur. Le prompt système est celui qu'on obtient le plus rarement, et c'est lui qui révèle le plus de choses.

La condition d'acceptation n'est pas que le benchmark soit flatteur. Elle est qu'un ingénieur de votre équipe, ou un cabinet mandaté, puisse rejouer les tests sur sa propre infrastructure et retrouver, à écart près, les mêmes chiffres. Un fournisseur qui refuse de livrer ce kit vend une performance, pas une capacité.

Cette exigence coûte un mois de travail en amont du choix. Elle économise souvent le double sur la phase de pilote, et donne un argument solide pour renégocier le prix quand les chiffres reproduits sont moins beaux que ceux de la plaquette.

Par où commencer sur Snowflake Cortex

La plupart des entrées sur Snowflake Cortex qui tournent mal ont la même origine : un POC ouvert, sans tâche précise derrière. Mieux vaut choisir une corvée qu'une équipe subit chaque jour, du type « sors-moi ce chiffre », et mesurer le temps qu'elle coûte avant de toucher à l'outil. Reste à vérifier que le modèle visé est disponible dans la région du compte, avec la trajectoire officielle sur douze mois, parce qu'un modèle absent de la région impose l'inférence cross-region et ses conséquences de résidence.

Le pilote dure trois mois, avec un seuil de bascule écrit avant le premier appel : au-dessus, on industrialise, en dessous, on s'arrête sans débat. Le piège habituel est de repousser ce seuil quand les premiers résultats déçoivent. Un critère d'arrêt modifié en cours de route n'en est plus un.

Que le choix final se porte sur Snowflake Cortex AI, sur l'arbitrage Snowflake vs Databricks, sur Azure OpenAI ou sur BigQuery ML, la plateforme n'est pas la décision la plus dure. Ce qui l'est, c'est de refuser une signature qui ne garantit pas par écrit la reproductibilité des benchmarks, le plan de containment et le coût de sortie. Pour préparer cela : un environnement d'essai avec Cortex activé dans la région cible, le cahier de conditions reproductibles, et la même épreuve soumise à deux fournisseurs. La taille de l'équipe change la manière de faire : à trois personnes, on teste un seul cas d'usage de bout en bout ; avec un centre d'excellence plus large, on peut comparer deux fournisseurs en parallèle.

FAQ : questions fréquentes

Six réponses courtes, tirées des questions que posent les directions informatiques en phase de choix.