Snowflake Cortex AI en production : ce que personne ne vous dit

Snowflake vend Cortex AI comme un écosystème complet pour industrialiser l'IA générative dans le Data Cloud. La promesse : pas besoin de sortir de Snowflake, pas besoin de copier des données ailleurs, pas besoin de gérer une infra LLM. En 2026, l'écosystème est mature : AI Functions, Cortex Search, Cortex Code (GA en mars), Cortex Agents, AI Function Studio, CoWork. Ça ressemble à une solution miracle.

En production, c'est plus nuancé. Le pricing déroute, le modèle de gouvernance est mal compris, et certains choix d'architecture faits au départ coûtent cher six mois plus tard. Cet article est un retour d'expérience sur ce qui marche, ce qui piége, et comment éviter les trois erreurs que je vois le plus souvent.

Le modèle de pricing : les crédits Snowflake, pas les tokens

Premier choc pour qui vient d'OpenAI : Cortex AI ne facture pas au token, mais au crédit Snowflake. Un crédit correspond grossièrement à un token de sortie, mais le ratio dépend du modèle et du mode d'inférence.

-- Exemple : résumé d'un texte de 5000 mots avec llama-3.3-70b
SELECT SNOWFLAKE.CORTEX.SUMMARIZE(
  'Extraction des insights clés du rapport Q3 2026...'
) AS summary;

-- Coût : ~0.05 crédit par appel (modèle 70B, ~1000 tokens output)

Le tableau qu'il faut avoir en tête

Le piège classique : comparer au prix OpenAI brut en oubliant que Cortex AI est sur Snowflake, et que les crédits Snowflake sont déjà dans ton contrat entreprise. Si tu as 10 000 crédits/mois non utilisés, Cortex AI devient quasi gratuit. Sinon, additionne.

Cross-region inference : gratuit mais lent

Snowflake permet d'inférer hors de ta région principale si le modèle n'y est pas déployé. C'est gratuit (pas de surcoût cross-region) mais ça ajoute 200-500ms de latence.

-- Forcer le routage interrégional
ALTER SESSION SET CORTEX_MODEL_REGION = 'AUTO';
-- ou explicitement
ALTER SESSION SET CORTEX_MODEL_REGION = 'CROSS_REGION';

Règle pragmatique : utilise cross-region pour les batchs nocturnes (ETL de classification), jamais pour du temps réel utilisateur.

AI Functions vs Cortex Code vs Cortex Agents : le bon outil

L'écosystème Cortex AI a grandi, et il est facile de se tromper d'outil. Voici l'arbre de décision.

AI Functions (SQL) : 90% des cas d'usage

COMPLETE, SUMMARIZE, TRANSLATE, EXTRACT_ANSWER, SENTIMENT, CLASSIFY_TEXT, PARSE_DOCUMENT. C'est le mode "SQL natif", idéal pour :

-- Classification de tickets support en batch
SELECT
  ticket_id,
  SNOWFLAKE.CORTEX.CLASSIFY_TEXT(
    content,
    ['bug', 'feature_request', 'billing', 'other']
  ) AS category
FROM support_tickets
WHERE created_at >= DATEADD('day', -7, CURRENT_DATE());

Quand l'utiliser : tout ce qui peut s'exprimer en SQL, batch ou temps réel, sans boucle d'agent.

Cortex Code (Python) : GA depuis le 9 mars 2026

C'est l'assistant agentic intégré à Snowsight. Il fait du SQL/Python auto-généré, exploration de données, et même du ML end-to-end.

Quand l'utiliser : exploration ad-hoc par un analyst, prototypage rapide. Pas pour de la prod batch.

Cortex Agents : orchestration multi-step

Pour les workflows complexes qui combinent retrieval + tool calling + raisonnement, Cortex Agents orchestre les étapes.

from snowflake.cortex import Agent

agent = Agent(
    name="support_triage",
    model="claude-sonnet-4",
    tools=[
        cortex_search_tool("ticket_kb"),
        sql_tool("SELECT * FROM support_tickets WHERE ..."),
    ],
    system_prompt="Tu tries les tickets de niveau 2..."
)

Quand l'utiliser : assistants conversationnels avancés, workflows avec plusieurs sources de données, tool calling.

Cortex AI Function Studio (public preview depuis mai 2026)

Pour les data scientists qui veulent évaluer et optimiser leurs prompts avant de passer en prod : Function Studio permet de comparer les modèles, benchmarker les prompts, et déployer la version gagnante comme AI Function custom.

Quand l'utiliser : phase d'expérimentation avant industrialisation.

Cortex Search : le RAG managé

Cortex Search est le service de retrieval de Snowflake, qui combine BM25 (keyword) et vector search, plus reranking. GA en mars 2026 avec une nouveauté importante : tu peux maintenant utiliser tes propres embeddings au lieu de ceux générés par Snowflake.

-- Créer un service de recherche sur des documents
CREATE CORTEX SEARCH SERVICE support_kb
  ON content
  ATTRIBUTES product, severity
  WAREHOUSE = compute_wh
  TARGET_LAG = '1 hour'
  AS (
    SELECT
      doc_id,
      content,
      product,
      severity
    FROM knowledge_base
    WHERE updated_at >= DATEADD('month', -6, CURRENT_DATE())
  );

Le piège de l'ingestion

Cortex Search est bon. Mais il ne pardonne pas une mauvaise ingestion. Les trois erreurs classiques :

1. Chunking trop petit (< 200 chars) → trop de bruit dans le retrieval
2. Pas de metadata (attributs mal définis) → filtres impossibles
3. Pas de filtre temporel dans la source → le LLM répond avec des données obsolètes

-- Mauvais : tout le KB indexé
SELECT * FROM knowledge_base;

-- Bon : filtre temporel + metadata exploitables
SELECT
  doc_id, content, product, severity, updated_at
FROM knowledge_base
WHERE updated_at >= DATEADD('month', -6, CURRENT_DATE());

Gouvernance : le vrai sujet en production

C'est ici que Cortex AI se distingue positivement d'OpenAI direct — à condition de configurer correctement.

Data exfiltration : le risque sous-estimé

Quand tu appelles SNOWFLAKE.CORTEX.COMPLETE avec un prompt qui contient des données sensibles, elles transitent vers le fournisseur du modèle (Anthropic, OpenAI, Meta, etc.). Si tu es sur un compte entreprise avec des données RGPD ou bancaires, c'est potentiellement un incident de conformité.

Trois solutions dans l'ordre de préférence :

1. Modèles Snowflake-hosted uniquement : llama-3.3-70b, mistral-large-2 — hébergés par Snowflake, pas de transit tiers
2. Network policies : restreindre Cortex AI à des modèles hébergés dans des régions spécifiques
3. Cortex Private Preview : modèles déployés dans ton VPC, isolation totale (programme bêta, à demander à Snowflake)

-- Vérifier quel modèle va traiter ta donnée
-- (un appel COMPLETE_LOG retourne le fournisseur)
SELECT
  PARSE_JSON(SNOWFLAKE.CORTEX.COMPLETE(
    'llama-3.3-70b',
    'Concatène ce nom : Dupont'
  )) AS result;

AI Cost Management : le budget partagé

Snowflake a ajouté en 2026 un système de budget partagé par équipe/centre de coût pour les features IA. C'est crucial pour éviter les dérives.

-- Créer un budget IA pour l'équipe data science
CREATE RESOURCE MONITOR cortex_ai_ds_budget
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = 'MONTHLY'
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND_IMMEDIATE;

-- Attacher le budget à un warehouse utilisé par les features Cortex
ALTER WAREHOUSE compute_wh SET RESOURCE_MONITOR = cortex_ai_ds_budget;

RLS + Cortex AI : ce qui marche, ce qui ne marche pas

Le Row-Level Security Snowflake s'applique sur les données envoyées au prompt, pas sur la sortie du LLM. Concrètement :

• ✅ Si ta fonction SQL fait SELECT ... WHERE row_filter_col = X avec RLS, le prompt ne contient que les lignes autorisées
• ❌ Mais si tu passes le résultat d'un JOIN qui révèle des données hors RLS dans le contexte, le LLM peut le regurgiter

Règle : teste systématiquement tes pipelines IA avec un user RLS-strict pour valider ce qui sort vraiment.

Pattern de prod : RAG complet

Voici un pattern end-to-end que j'ai vu fonctionner en prod, sur des cas d'usage réels.

-- 1. Ingestion : préparer les documents (batch quotidien)
INSERT INTO kb_chunks (chunk_id, content, source_id, product, indexed_at)
SELECT
  SHA1(content) AS chunk_id,
  content,
  source_id,
  product,
  CURRENT_TIMESTAMP()
FROM raw_kb_documents
WHERE LENGTH(content) BETWEEN 200 AND 4000;  -- chunking raisonnable

-- 2. Indexation Cortex Search (auto, toutes les heures)
CREATE OR REPLACE CORTEX SEARCH SERVICE kb_search
  ON content
  ATTRIBUTES product
  WAREHOUSE = compute_wh
  TARGET_LAG = '1 hour'
  AS SELECT chunk_id, content, product FROM kb_chunks;

-- 3. Retrieval (SQL direct, pas besoin de Python)
WITH search_results AS (
  SELECT content, product,
    VECTOR_COSINE_SIMILARITY(embedding, :query_embedding) AS score
  FROM TABLE(
    CORTEX_SEARCH('kb_search', :user_query, 10, {'product': :product_filter})
  )
)
SELECT
  sr.content,
  SNOWFLAKE.CORTEX.COMPLETE(
    'claude-sonnet-4',
    CONCAT(
      'Contexte : ', STRING_AGG(sr.content, '\n---\n'),
      '\n\nQuestion : ', :user_query
    )
  ) AS answer
FROM search_results sr
WHERE score > 0.7
GROUP BY ALL;

# 4. Monitoring des coûts (à brancher sur Snowflake Account Usage)
import snowflake.connector
conn = snowflake.connector.connect(...)
cur = conn.cursor()
cur.execute("""
  SELECT
    DATE_TRUNC('day', start_time) AS day,
    model_name,
    SUM(credits_used) AS credits
  FROM snowflake.account_usage.cortex_functions_usage_history
  WHERE start_time >= DATEADD('day', -30, CURRENT_DATE())
  GROUP BY 1, 2
  ORDER BY 1 DESC, 3 DESC
""")

Verdict : quand Cortex AI est le bon choix

Cortex AI est le bon choix si :

• Tu es déjà sur Snowflake et tu veux éviter la duplication des données
• Tes volumes sont prévisibles et rentrent dans le budget crédits
• Tes contraintes de gouvernance exigent que la donnée reste dans Snowflake
• Tu fais du SQL-first et tu veux industrialiser l'IA sans monter une équipe ML

Cortex AI n'est pas le bon choix si :

• Tu as besoin du dernier modèle (Cortex a 3-6 mois de retard sur OpenAI/Anthropic)
• Tu fais du fine-tuning custom (Cortex ne supporte que les modèles pré-entraînés)
• Tu as des workloads temps réel sub-100ms (latence cross-region)
• Tu veux un contrôle fin sur le prompt engineering (Cortex a moins de knobs qu'une API directe)

Ma recommandation : commence par Cortex AI pour 80% de tes cas (classification, summarization, search). Garde une API directe (OpenAI, Anthropic, Bedrock) pour les 20% qui ont besoin du top tier ou de flexibilité. Les deux peuvent coexister dans la même architecture.

Et surtout : configure ton budget AI avant de déployer le premier pipeline. Une boucle d'agent mal calibrée peut consommer 10 000 crédits en une nuit.