Pendant des années, l’analytique d’entreprise a suivi un modèle relativement stable : les équipes Data préparent les données, construisent des modèles, définissent des indicateurs, puis les exposent dans des tableaux de bord Power BI, Qlik, Tableau ou d’autres outils de Business Intelligence.
L’utilisateur métier intervient essentiellement à la fin de cette chaîne. Il consulte ce que quelqu’un a préalablement pensé, modélisé et visualisé pour lui.
L’arrivée de l’intelligence artificielle générative dans les plateformes Data commence à modifier ce paradigme. Avec Snowflake Cortex, Cortex Analyst, Semantic Views, Cortex Search et Cortex Agents, Snowflake ne cherche plus seulement à stocker et interroger les données : la plateforme ambitionne de permettre aux utilisateurs de dialoguer avec leur patrimoine informationnel.
La question devient alors moins :
« Quel dashboard dois-je consulter ? »
et davantage :
« Quelle question ai-je besoin de poser à mes données ? »
Cette évolution est séduisante. Mais les premiers retours d’expérience montrent également que le véritable défi n’est probablement pas celui auquel on pense immédiatement.
Le problème difficile n’est plus nécessairement de générer du SQL. Il est de construire une sémantique métier suffisamment robuste pour que l’intelligence artificielle puisse produire une réponse digne de confiance.
Du dashboard à la conversation analytique
Prenons une situation classique.
Un directeur commercial souhaite comprendre ses résultats. Dans une architecture BI traditionnelle, son parcours pourrait être le suivant :
Power BI / Qlik → rapport commercial → page ventes → filtres → période → région → produit → analyse du graphique.
Avec Cortex Analyst, l’interaction peut devenir conversationnelle :
« Quel était notre chiffre d’affaires en juillet ? »
Puis :
« Compare-le à juillet de l’année dernière. »
Puis :
« Quelles régions expliquent principalement la baisse ? »
Et enfin :
« Montre-moi l’évolution sur les douze derniers mois. »
Cortex Analyst est précisément conçu pour transformer ce type de questions en langage naturel en requêtes sur des données structurées.
Le mécanisme peut être résumé ainsi :
Question métier → compréhension sémantique → génération SQL → exécution dans Snowflake → résultat → poursuite de l’analyse.
La documentation Snowflake présente Cortex Analyst comme un système permettant aux utilisateurs d’interroger des données structurées en langage naturel en s’appuyant sur une couche sémantique.
Mais réduire Cortex Analyst à du text-to-SQL serait insuffisant.
L’objectif est progressivement de construire une véritable expérience analytique conversationnelle.
Référence :
Documentation Snowflake — Cortex Analyst
Une architecture analytique qui devient agentique
L’écosystème Cortex peut être représenté de manière simplifiée ainsi :
UTILISATEUR MÉTIER
│
│
"Pourquoi les ventes baissent-elles ?"
│
▼
SNOWFLAKE INTELLIGENCE
│
CORTEX AGENT
│
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
Cortex Analyst Cortex Search Autres outils
│ │
│ │
Structured Documents
Data Textes
│
▼
Semantic Views
│
▼
Snowflake
Plusieurs composants jouent ici des rôles complémentaires.
Cortex Analyst
Cortex Analyst constitue le moteur analytique conversationnel pour les données structurées.
Il interprète une question métier, utilise la sémantique disponible et génère la requête SQL nécessaire pour produire une réponse.
Cortex Search
Cortex Search étend cette logique aux données non structurées : documents, procédures, contrats, descriptions, comptes rendus ou autres corpus textuels.
Cortex Agents
Les agents constituent la couche d’orchestration.
Un agent peut décider quels outils utiliser pour répondre à une question. Il peut par exemple interroger des données structurées via Cortex Analyst, rechercher des informations documentaires, effectuer certains traitements complémentaires et combiner les résultats.
C'est ici que l'on commence réellement à parler d’analytique agentique.
Référence :
Documentation Snowflake — Cortex Agents
Le cas d’usage évident : le « prompt-to-analysis »
Le premier cas d’usage est relativement simple à comprendre.
Un utilisateur métier peut demander :
« Donne-moi les dix produits dont la marge s’est le plus dégradée ce trimestre. »
Ou :
« Quelle région contribue le plus à la baisse du chiffre d’affaires ? »
Ou encore :
« Compare les ventes de cette année à celles de l’année dernière par canal de distribution. »
Le système détermine alors la requête nécessaire.
Pour les métiers, le SQL devient donc potentiellement invisible.
Pour les équipes Data, en revanche, il reste absolument central.
C'est une distinction importante.
L’IA ne fait pas disparaître le SQL. Elle déplace celui qui l’écrit.
Le métier formule l’intention ; la plateforme génère la requête.
Mais cette génération n'a de valeur que si la plateforme comprend correctement les données qu'elle interroge.
Les cas d’usage analytiques les plus intéressants
Les cas les plus naturels concernent d'abord les interrogations relativement structurées :
- consultation d'un KPI ;
- comparaison temporelle ;
- analyse d'écart ;
- classement Top/Flop ;
- segmentation par produit, client, région ou canal ;
- recherche d'une tendance ;
- drill-down ;
- identification des principaux contributeurs à une variation ;
- génération d'une visualisation à partir d'un résultat ;
- analyse croisée entre plusieurs domaines de données.
Mais l’agentique permet d’envisager quelque chose de plus ambitieux.
Prenons la question :
« Pourquoi notre taux de conversion a-t-il chuté en juillet ? »
Une requête SQL unique ne suffit pas nécessairement.
Un agent peut avoir besoin d'effectuer plusieurs investigations :
Question
│
▼
Cortex Agent
│
├── Cortex Analyst
│ ├── conversion juillet
│ ├── comparaison juin
│ └── segmentation par canal
│
├── Cortex Search
│ └── incidents / documentation
│
└── autres traitements
│
▼
Synthèse finale
Nous passons alors du prompt-to-SQL au prompt-to-analysis.
Et cette différence est fondamentale.
Le véritable enjeu : la couche sémantique
C'est probablement le point le plus important à retenir des retours d'expérience disponibles.
Supposons qu'une table contienne :
FACT_SALES
CUSTOMER_ID
AMT_NET
AMT_GROSS
CHANNEL_CD
ORDER_DT
REGION_CD
STATUS_CD
...
Un utilisateur demande :
« Quel est notre chiffre d'affaires retail ? »
La question paraît simple.
Elle ne l'est absolument pas.
Faut-il utiliser AMT_NET ou AMT_GROSS ?
Faut-il exclure les commandes annulées ?
Le chiffre d'affaires est-il rattaché à la date de commande, à la date de livraison ou à la date de facturation ?
Que signifie exactement « retail » dans CHANNEL_CD ?
Comment sont traitées les devises ?
Quelle hiérarchie géographique définit une région ?
Un grand modèle linguistique ne peut pas inventer ces règles.
Et surtout, il ne devrait pas le faire.
C'est précisément le rôle des Semantic Views.
Snowflake permet désormais de stocker directement dans la base des concepts métier : métriques, dimensions, entités et relations. Ces vues constituent un objet de schéma et peuvent être interrogées depuis Cortex Analyst mais également depuis SQL.
La couche physique :
AMT_NET
CHANNEL_CD
STATUS_CD
ORDER_DT
peut ainsi être traduite en concepts métier :
Revenue
Customer
Region
Channel
Margin
Fiscal Month
Active Customer
La donnée devient compréhensible non seulement par les développeurs, mais également par les systèmes d'IA qui doivent la manipuler.
Référence :
Documentation Snowflake — Semantic Views
La Semantic View devient un véritable produit Data
C'est également l'un des constats les plus intéressants provenant de la communauté Snowflake.
Les démonstrations de text-to-SQL sont relativement faciles à réussir lorsque le schéma est simple.
La production est une autre histoire.
Un retour d'expérience publié dans la communauté Snowflake résume particulièrement bien le problème : la génération SQL n'est plus nécessairement le principal obstacle ; c'est la couche sémantique qui devient le goulot d'étranglement lorsque les définitions métier dérivent, que les modèles deviennent complexes et que les problématiques de coûts, de gouvernance, de RBAC, de tests et de CI/CD apparaissent.
Un autre retour communautaire formule une conclusion similaire :
la couche sémantique doit être traitée comme un produit, et non comme une simple opération de documentation des métadonnées.
Cette distinction me paraît fondamentale.
Une Semantic View doit avoir :
- un propriétaire ;
- des définitions métier explicites ;
- des métriques validées ;
- des règles de calcul ;
- des synonymes ;
- des exemples ;
- des tests ;
- une gestion de versions ;
- un processus de déploiement ;
- un suivi de qualité.
Nous retrouvons finalement les principes classiques du Data Product, appliqués à la couche permettant à l'IA de comprendre l'entreprise.
Les Verified Queries : apprendre à l'IA comment l'entreprise raisonne
Snowflake propose également un mécanisme particulièrement intéressant : le Verified Query Repository (VQR).
Le principe consiste à associer une question métier à une requête SQL validée.
Par exemple :
Question :
"Quel est le chiffre d'affaires mensuel par région ?"
│
▼
SQL validé par l'équipe Data
Lorsque Cortex Analyst rencontre ultérieurement une question similaire, il peut exploiter les requêtes pertinentes du référentiel pour améliorer la génération de la réponse.
Snowflake indique explicitement que ce mécanisme vise à améliorer l'exactitude et la fiabilité des résultats.
Référence :
Documentation Snowflake — Verified Query Repository
Mais le concept devient encore plus intéressant lorsqu'on le considère sous l'angle du cycle de vie logiciel.
Une Verified Query peut devenir une sorte de test analytique :
Question métier
│
▼
Expected SQL / Expected Result
│
▼
Cortex Analyst
│
▼
Résultat généré
│
▼
Validation
Snowflake dispose désormais d'évaluations Cortex Analyst utilisant justement des Verified Queries comme jeu d'évaluation et permettant de mesurer la correction SQL.
Autrement dit, nous commençons à voir apparaître une véritable logique de tests de non-régression de l'analytique conversationnelle.
Ce que les retours de production nous apprennent
Les discussions communautaires sont particulièrement intéressantes parce qu'elles permettent de dépasser les démonstrations commerciales.
Un utilisateur explique par exemple avoir obtenu de bons résultats en production en construisant le système sur un Data Product mature et en mettant en place de nombreux tests entre le POC et la production.
Son équipe teste à la fois les Semantic Views et les agents. Pour la partie sémantique, elle compare notamment le résultat produit par Cortex Analyst à celui d'une requête SQL connue comme correcte.
C'est exactement le type de discipline nécessaire pour industrialiser cette technologie.
À l'inverse, d'autres utilisateurs constatent une différence importante entre utilisateurs techniques et non techniques.
Un utilisateur connaissant SQL formule généralement des questions précises et possède suffisamment de connaissances pour détecter une réponse douteuse.
L'utilisateur métier peut poser une question ambiguë ou hors du périmètre couvert par la Semantic View sans nécessairement être capable d'identifier une erreur.
C'est l'un des principaux risques d'adoption de l'analytique conversationnelle.
Le problème n'est donc pas seulement :
« L'IA sait-elle répondre ? »
Il devient :
« L'utilisateur peut-il faire suffisamment confiance à la réponse pour prendre une décision ? »
Une couche sémantique qui doit apprendre des usages
Snowflake commence également à fermer progressivement la boucle entre utilisation et amélioration du modèle.
Cortex Analyst peut analyser l'historique des requêtes et les questions fréquemment posées afin de proposer de nouveaux éléments pour les Semantic Views : requêtes vérifiées, métriques, filtres, descriptions ou synonymes.
Nous pouvons alors imaginer une boucle d'amélioration continue :
Questions utilisateurs
│
▼
Cortex Analyst
│
▼
Monitoring
│
▼
Questions mal comprises
│
▼
Amélioration Semantic View
│
├── métriques
├── synonymes
├── descriptions
└── Verified Queries
│
▼
Nouvelle version
Snowflake fournit d'ailleurs des journaux permettant d'observer notamment l'utilisateur, la question posée, le SQL généré, les erreurs et différentes métadonnées associées aux requêtes Cortex Analyst.
L'exploitation de ces traces devrait constituer une activité permanente plutôt qu'une opération limitée au lancement du projet.
Et les dashboards dans tout cela ?
Il serait excessif de conclure que l'IA conversationnelle va faire disparaître Power BI, Qlik ou les dashboards.
Les deux usages répondent à des besoins différents.
Le dashboard reste extrêmement efficace pour :
- suivre régulièrement les mêmes indicateurs ;
- présenter une information standardisée ;
- diffuser une vision commune ;
- surveiller des objectifs ;
- afficher immédiatement une situation connue.
L'agent conversationnel est particulièrement pertinent lorsqu'une question n'a pas été anticipée.
Le dashboard répond à :
« Voici les indicateurs que nous avons décidé de suivre. »
L'agent répond plutôt à :
« Voici une question que personne n'avait nécessairement prévue lorsque le dashboard a été construit. »
Les deux modèles sont donc davantage complémentaires que concurrents.
Alertes, notifications et analytique proactive
Un autre terrain particulièrement intéressant concerne les alertes.
Snowflake dispose nativement d'un système d'Alerts capable de surveiller périodiquement le résultat d'une condition SQL et d'exécuter une action lorsque cette condition est satisfaite.
Cela permet par exemple de détecter :
CA < objectif
taux de churn > seuil
pipeline en erreur
consommation > budget
volume inhabituel
KPI hors tolérance
Référence :
Documentation Snowflake — Alerts
Snowflake dispose également d'une infrastructure de notifications permettant notamment de transmettre des messages vers différents systèmes externes.
Référence :
Documentation Snowflake — Notifications
Il existe cependant une différence conceptuelle avec l'abonnement traditionnel à un rapport Power BI.
L'abonnement BI répond généralement à :
« Envoie-moi ce rapport tous les lundis matin. »
L'approche Data Platform répond davantage à :
« Lorsque cette condition devient vraie, déclenche cette action. »
Avec les agents, cette logique peut potentiellement évoluer vers quelque chose de beaucoup plus intéressant :
Données
│
▼
Détection d'une anomalie
│
▼
CA -12 %
│
▼
Cortex Agent
│
├── analyse temporelle
├── segmentation
├── recherche des contributeurs
└── contextualisation
│
▼
Synthèse
│
▼
Notification
L'objectif ne serait alors plus simplement :
« Envoie-moi mon dashboard. »
Mais :
« Préviens-moi lorsqu'un événement important se produit, investigue-le et explique-moi ce qui s'est passé. »
C'est probablement l'un des cas d'usage les plus prometteurs de l'analytique agentique.
L'ouverture via MCP
Une autre évolution mérite une attention particulière : Model Context Protocol (MCP).
Snowflake propose des capacités permettant d'exposer des services Snowflake à des clients compatibles MCP.
Cela ouvre une architecture dans laquelle Snowflake n'est plus nécessairement l'interface utilisée directement par l'utilisateur.
Assistant IA
Application interne
Portail métier
│
│ MCP
▼
Snowflake
│
Cortex Agent
│
┌──────┼───────┐
│ │ │
SQL Search Tools
Snowflake peut ainsi devenir le moteur analytique gouverné situé derrière différentes expériences conversationnelles.
Référence :
Documentation Snowflake — Cortex Agents et MCP
Comment cadrer un projet Cortex Analyst ?
L'une des erreurs serait probablement de commencer par :
« Nous allons ouvrir toute notre plateforme Snowflake à l'IA. »
Une approche plus raisonnable serait de sélectionner un domaine analytique précis.
Par exemple :
Commercial
│
▼
10 à 20 KPI importants
│
▼
Semantic View
│
▼
30 à 50 questions métier représentatives
│
▼
Verified Queries
│
▼
Cortex Analyst
│
▼
Cortex Agent
│
▼
Petit groupe d'utilisateurs
Il devient alors possible de mesurer réellement :
- le taux de réponses correctes ;
- les questions sans réponse ;
- les erreurs d'interprétation ;
- les corrections SQL nécessaires ;
- le temps gagné ;
- la consommation Snowflake ;
- l'adoption ;
- la confiance des utilisateurs.
Puis seulement d'élargir progressivement le périmètre.
Cette prudence est d'autant plus importante que plusieurs retours communautaires signalent les difficultés liées aux Semantic Views trop larges, au versioning, aux Verified Queries et à l'industrialisation de plusieurs vues et agents.
SQL, IA ou agentique ?
La réponse est finalement : les trois.
Le SQL reste le langage d'exécution analytique.
La Semantic View fournit le vocabulaire et les règles métier.
Cortex Analyst traduit l'intention de l'utilisateur en interrogation analytique.
Cortex Search apporte le contexte documentaire.
Cortex Agent orchestre les différents outils nécessaires.
L'architecture devient donc :
QUESTION MÉTIER
│
▼
CORTEX AGENT
│
raisonnement / orchestration
│
┌────────────┼────────────┐
▼ ▼ ▼
Analyst Search Tools
│ │
▼ ▼
Semantic View Documents
│
▼
SQL
│
▼
Snowflake
Le LLM ne remplace donc pas l'architecture Data.
Il vient s'y insérer.
Une transformation plus profonde de la BI
Pendant longtemps, l'architecture analytique pouvait être schématisée ainsi :
Sources
↓
Data Warehouse
↓
Modèle BI
↓
Dashboard
↓
Utilisateur
L'analytique agentique introduit une autre possibilité :
DATA PLATFORM
│
Semantic Views
│
┌─────────────┼─────────────┐
│ │ │
SQL BI Cortex Analyst
│
Cortex Agents
│
┌────────────┼────────────┐
│ │ │
Search Tools MCP
│ │ │
└────────────┼────────────┘
│
Utilisateur
La différence est profonde.
Dans la BI traditionnelle, l'équipe Data essaie d'anticiper les questions que poseront les utilisateurs et construit les analyses correspondantes.
Dans l'analytique conversationnelle, l'utilisateur peut construire progressivement son propre chemin d'investigation.
Nous passons de :
« Voici le dashboard que nous avons construit pour répondre à vos questions. »
à :
« Posez votre question ; le système construira l'analyse nécessaire pour essayer d'y répondre. »
Conclusion : la sémantique devient l'infrastructure de l'IA analytique
L'évolution de Snowflake Cortex montre finalement quelque chose de plus intéressant que la simple arrivée d'un chatbot dans une plateforme Data.
Les modèles linguistiques savent de mieux en mieux générer du SQL.
Mais savoir écrire une requête n'est pas savoir comment fonctionne une entreprise.
Qu'est-ce qu'un client actif ?
Qu'est-ce que le chiffre d'affaires ?
Comment calcule-t-on la marge ?
Quel événement définit un churn ?
Quelle période comptable utiliser ?
Quelles commandes faut-il exclure ?
Ces questions sont sémantiques avant d'être techniques.
Et c'est probablement là que se situe la véritable transformation.
Plus l'IA devient capable d'interroger directement les données, plus les entreprises doivent formaliser précisément ce que leurs données signifient.
Paradoxalement, l'arrivée des agents ne réduit donc pas l'importance de la modélisation Data.
Elle pourrait au contraire la renforcer.
La qualité d'un système analytique agentique ne dépendra probablement pas uniquement de la puissance de son LLM.
Elle dépendra de la qualité de ses données, de son modèle, de ses définitions métier, de ses règles de gouvernance, de ses tests et de sa couche sémantique.
C'est peut-être cela, finalement, la principale leçon de Snowflake Cortex :
L'avenir de l'analytique n'est pas seulement de permettre à l'IA d'accéder aux données. Il est de construire une architecture dans laquelle elle peut réellement les comprendre.
Références et lectures complémentaires
Snowflake — Semantic Views
Overview of Semantic Views
Snowflake — Cortex Analyst / Verified Query Repository
Verified Query Repository
Snowflake — Évaluation de Cortex Analyst
Cortex Analyst Evaluations
Snowflake — Suggestions d'amélioration des Semantic Views
Suggestions for semantic models and views
Snowflake — Monitoring de Cortex Analyst
Cortex Analyst administrator monitoring
Snowflake — Alerts
Snowflake Alerts
Snowflake — Cortex Agents
Cortex Agents documentation
Snowflake — MCP et Cortex Agents
Cortex Agents MCP documentation
Communauté Snowflake — retour sur Cortex Analyst et la couche sémantique
Discussion : Cortex Analyst, text-to-SQL et Semantic Layer
Communauté Snowflake — retour POC vs production
Discussion : When the Demo Works and Prod Doesn't
Communauté Snowflake — retours de production et stratégie de tests
Discussion : How well is Cortex working in real use cases?