La COF-C02 sera retirée le 14 mai 2026 en anglais et le 31 juillet 2026 en français.

J'ai déjà écrit un guide complet de SnowPro Core qui couvre tous les fondamentaux. La bonne nouvelle c'est que tout ce qui est dedans reste valable pour la COF-C03 car Snowflake n'a rien retiré, il a juste ajouté des sujets par-dessus.

Cet article couvre uniquement ce qui est nouveau ou renforcé. C'est le complément de mon guide, pas un doublon.

Ce qui change dans la structure de l'examen

Le format ne bouge pas : 100 questions, 115 minutes, 750/1000.

Ce qui change c'est que les 6 domaines de la COF-C02 passent à 5 dans la COF-C03. Snowflake a fusionné "Performance & Coûts" et "Transformations" en un seul domaine, et a redistribué les poids.

Domaine COF-C03 Poids
1. Snowflake AI Data Cloud Features & Architecture 31%
2. Account Management & Data Governance 20%
3. Data Loading, Unloading & Connectivity 18%
4. Performance Optimization, Querying & Transformation 21%
5. Data Collaboration 10%

La gouvernance et la collaboration prennent plus de place. Et surtout, l'IA fait son entrée dans le Domaine 1.

Snowflake Cortex

C'est le plus gros ajout de la COF-C03.

Cortex c'est un ensemble de services d'IA/ML qui tournent directement dans Snowflake. Les données ne quittent jamais la plateforme. C'est le point clé.

L'objectif est de bien comprendre ce que Cortex fait et où il se positionne, et dans quel use case on peut l'utiliser donc pas besoin d'apprendre les API ou la syntaxe exacte des fonctions.

a - Les fonctions AI SQL

Des fonctions IA que tu appelles directement en SQL, comme n'importe quelle fonction Snowflake. Elles utilisent des LLMs hébergés par Snowflake (Llama, Mistral, Claude, etc...).

Les principales fonctions à connaitre COMPLETE (génère du texte à partir d'un prompt, le couteau suisse), SUMMARIZE (résume un texte), TRANSLATE (traduit), SENTIMENT (score entre -1 et 1), AI_CLASSIFY (classe du texte dans des catégories), AI_EMBED (génère un vecteur d'embedding pour la recherche sémantique).

Voici quelques exemples :

SELECT SNOWFLAKE.CORTEX.SUMMARIZE(review_text) FROM reviews;
SELECT SNOWFLAKE.CORTEX.SENTIMENT(comment) FROM feedback;
SELECT SNOWFLAKE.CORTEX.COMPLETE('llama3.1-70b', 'Classifie ce ticket: ' || ticket_text) FROM support_tickets;
💡
Nb : pour utiliser ces fonctions, le rôle doit avoir le role SNOWFLAKE.CORTEX_USER (granté à PUBLIC par défaut, donc accessible à tous sauf si un admin l'a révoqué) et il faut aussi le privilège de compte USE AI FUNCTIONS. La facturation est par token (input + output), et le coût varie selon le modèle choisi.

b - Cortex Search vs Cortex Analyst

C'est la distinction à retenir pour l'examen.

Cortex Search : c'est de la recherche sémantique (RAG) sur des documents et textes (non structuré). Il combine embeddings et mots-clés, crée un index automatiquement.

Cortex Analyst : permet de faire la traduction de langage naturel vers SQL sur des tables (structuré). L'utilisateur pose une question comme "Quel est le CA par région ce trimestre ?" et Cortex Analyst génère le SQL.

Dans l'exam, si la question parle de documents/PDF, c'est Cortex Search. Si la question parle de tables relationnelles, c'est plutôt Cortex Analyst.

c - Cortex Agents

Les Agents combinent Search et Analyst dans une seule conversation. Ils routent vers le bon outil selon la question. Il faut retenir qu'ils mélangent structuré et non structuré, c'est leur raison d'être.

d - Snowflake ML

Les principales fonctions ML pré-entraînées, accessibles sans expertise ML : FORECAST (prévisions de séries temporelles), ANOMALY_DETECTION (détection des anomalies), CLASSIFICATION (supervisée).

-- Entraîner un modèle de forecast
CREATE SNOWFLAKE.ML.FORECAST mon_exemple_forecast(
  INPUT_DATA => TABLE(SELECT date, revenue FROM sales),
  TIMESTAMP_COLNAME => 'DATE',
  TARGET_COLNAME => 'REVENUE'
);

-- Générer les prévisions
CALL mon_exemple_forecast!FORECAST(FORECASTING_PERIODS => 30);
⚠️
Pas besoin de devenir data scientist. Personnellement, je ne le suis pas. Pour la certif, il faut seulement savoir dans quels cas on utilise ces fonctions, pas les implémenter de A à Z.

Apache Iceberg Tables

Voir l'article dédié sur le sujet Iceberg Tables Snowflake.

Le concept est simple, c'est des tables au format ouvert de Apache Iceberg, stockées dans ton propre cloud storage (AWS, GCP, Azure) en Parquet. N'importe quel moteur compatible Iceberg (Spark, Flink, Trino...) peut lire ces données.

On trouve deux principaux modes "Snowflake-managed catalog" (Snowflake gère tout, DML complet : INSERT, UPDATE, DELETE, MERGE) et "External catalog" comme Polaris ou AWS Glue etc...

CREATE ICEBERG TABLE iceberg_table (
  id INT, name STRING, amount NUMBER
)
CATALOG = 'SNOWFLAKE'
EXTERNAL_VOLUME = 'ext_volume'
BASE_LOCATION = 'iceberg/my_table';

Ce que les Iceberg Tables n'ont pas par rapport aux tables natives est que y'a pas de Time Travel Snowflake, pas de Fail-safe, pas de clustering keys. (Le versionning existe mais il passe par les snapshots Iceberg, pas par le mécanisme Time Travel de Snowflake.)

Pour la certif, il faut surtout retenir la logique : Natif Snowflake si tu veux l'expérience Snowflake la plus simple et la plus intégrée et Iceberg si tu veux garder un format ouvert et partager les mêmes données avec d’autres moteurs.

Snowflake Notebooks

Environnement de développement interactif dans Snowsight, organisé en cellules (SQL, Python, Markdown). Comme Jupyter que les data scientists adorent, mais dans Snowflake. Les données ne bougent pas, le compute est un warehouse ou un container pool.

Ce qui est intéressant c'est le référencement inter-cellules car le résultat d'une cellule SQL est accessible en Python via le nom de la cellule. Et les variables Python sont utilisables en SQL.

-- Cellule SQL
SELECT product_id, SUM(revenue) AS total FROM sales GROUP BY 1;

# Cellule Python : référencer le résultat SQL précedent
df = cell1.to_pandas()
df.plot.bar(x='PRODUCT_ID', y='TOTAL')

-- Utiliser une variable Python
SELECT * FROM products WHERE category = '{{selected_category}}';

Un Notebook peut tourner de deux façons : "Warehouse Runtime" (les warehouse classique) ou "Container Runtime" (CPU/GPU, les packages custom pour le ML et le deep learning).

Les Notebooks peuvent être planifiés via Tasks ou EXECUTE NOTEBOOK, comme n'importe quel job.

⚠️
Même logique que pour ML. Pour la certif, il faut connaître le positionnement et les cas d'usage, pas l'implémentation.

Native App Framework

Le Native App Framework existait avant, mais la COF-C03 lui donne beaucoup plus de poids.

Le principe est simple : un provider package une application (stored procedures, UDFs, Streamlit UI, données de référence) et la publie sur le Marketplace. Un consumer l'installe dans son propre compte. L'app tourne chez le consumer, avec ses données donc les données du consumer ne quittent jamais son compte, et le code de l'app est masqué pour protéger la propriété intellectuelle du provider.

Ne pas confondre avec le data sharing car le sharing partage uniquement des données brutes. Les Native Apps partagent plutôt une application donc du code, de la logique, une interface...

Gouvernance renforcée

La COF-C03 pousse plus loin la gouvernance. Voici les notions qui sont nouvelles ou renforcées par rapport à ce que j'ai mentionné dans mon précédent article.

  • Trust Center : tableau de bord centralisé dans Snowsight pour la sécurité et la conformité du compte.
  • Privacy Policies : permettent de mieux protéger les données sensibles lors de leur utilisation. Ce n’est pas la même chose que le masquage dynamique.
  • Logging et Tracing : les événements d'exécution des UDFs, stored procedures et tasks peuvent être loggés dans une event table.
  • Alerts : objets Snowflake qui évaluent une condition périodiquement et déclenchent une action (email, webhook) quand c'est vrai.
  • Data Classification : EXTRACT_SEMANTIC_CATEGORIES() analyse les données et identifie automatiquement les colonnes PII.
  • Data Clean Rooms : deux entreprises combinent leurs données pour des analyses jointes sans révéler les données brutes de l'autre. Utilise des secure views, des policies et des Native Apps.

Collaboration élargie

Les listings (private et public) permettent le cross-region/cross-cloud, contrairement au data sharing direct qui nécessite la même région. Les providers peuvent monétiser leurs données.

Les Replication Groups sont renforcés car ils permettent de répliquer plusieurs objets ensemble (databases, shares, users, rôles, warehouses) vers un autre compte. Les Failover Groups vont un cran plus loin car en cas de panne majeure du compte primaire, le compte secondaire prend le relais. Le basculement se fait avec ALTER FAILOVER GROUP ... PRIMARY.

Nb : Failover et Failback nécessitent Business Critical Edition minimum.

S'entraîner sur la COF-C03

Si tu veux t'entraîner dans les mêmes conditions que le vrai examen, j'ai créé DataCertification.fr avec 700+ questions sur les 5 domaines de la COF-C03, Cortex, Iceberg et Notebooks inclus, ainsi que 9 modules d'entraînement. Chaque question a une explication détaillée, et un suivi de progression par domaine pour voir où tu en es.

→ Commencer sur DataCertification.fr

Aller plus loin

J'ai regroupé tous mes articles Snowflake dans un parcours complet.

👉 Accéder à la Formation Snowflake