L'IA dans Snowflake : amener le modèle aux données, plutôt que l'inverse
Fonctions IA en SQL, recherche documentaire, questions en langage naturel, agents : ce que Snowflake Cortex permet, et les règles pour l'utiliser sans perdre le contrôle.
Pendant des années, faire de l'IA sur des données d'entreprise voulait dire les extraire : un export vers un environnement de data science, un autre vers un service d'IA externe, des copies qui se multiplient et des droits qui se perdent en route. Snowflake a pris le chemin inverse avec Cortex : amener les modèles là où se trouvent déjà les données, sous les mêmes règles de sécurité. L'idée est simple, ses conséquences pour la gouvernance sont considérables.
- Exports vers des outils externes
- Copies multiples, droits recréés à chaque étape
- Difficile de savoir qui a envoyé quoi, où
- Chaque projet IA réinvente sa sécurité
- Les modèles s'exécutent dans la plateforme
- Une seule copie, les droits existants s'appliquent
- Chaque appel est tracé avec l'identité de l'utilisateur
- La gouvernance en place devient celle de l'IA
Quatre briques, quatre usages
Snowflake regroupe ses fonctions d'IA sous le nom Cortex. Plutôt que de les présenter par leur nom commercial, qui évolue vite, mieux vaut les comprendre par ce qu'elles permettent de faire.
1. Transformer du texte avec une simple requête
La brique la plus immédiate est aussi la plus sous-estimée : des fonctions d'IA appelables directement en SQL. Résumer un compte rendu, traduire un commentaire client, classer une réclamation par thème, extraire une référence de pièce d'un texte libre, évaluer le ton d'un retour : ce qui demandait hier un projet de data science s'écrit aujourd'hui comme une colonne calculée.
Sur le terrain industriel, les cas d'usage abondent. Des milliers de comptes rendus d'intervention de maintenance, rédigés à la main, peuvent être classés par type de défaillance et par équipement. Des retours qualité en plusieurs langues peuvent être traduits et regroupés. Le texte libre, longtemps inexploitable, devient une donnée comme une autre.
Ces fonctions s'appuient sur des modèles de plusieurs fournisseurs, dont Anthropic, Meta et Mistral, exécutés dans le périmètre de Snowflake. On choisit le modèle adapté à la tâche : un modèle léger et peu coûteux pour classer, un modèle plus puissant pour résumer un document complexe.
2. Retrouver le bon document : le socle d'un assistant fiable
Un assistant qui répond à partir de la documentation de l'entreprise (procédures, fiches techniques, notes internes) repose sur le principe du RAG, pour Retrieval-Augmented Generation : avant de répondre, on retrouve les passages pertinents, et le modèle s'appuie sur eux plutôt que sur sa mémoire.
Cortex propose un service de recherche qui combine recherche par mots-clés et recherche par le sens. Il s'alimente directement depuis des tables Snowflake et se met à jour avec elles. L'avantage, encore une fois, est la gouvernance : un utilisateur ne retrouve que les documents auxquels ses droits lui donnent accès.
3. Poser une question sur les chiffres, sans inventer de calcul
Demander « quel est le coût de la non-qualité par site ce trimestre ? » à un modèle connecté librement à l'entrepôt est risqué : il peut inventer une jointure ou choisir sa propre définition de l'indicateur. La réponse sera plausible, pas forcément juste.
Snowflake répond à ce risque avec une couche sémantique : des définitions d'indicateurs, de dimensions et de relations, maintenues par les équipes data avec les métiers. Le service de questions en langage naturel s'appuie sur ces définitions pour construire la requête. Le modèle ne devine plus ce qu'est la « non-qualité » : il utilise la définition officielle.
C'est la même logique que celle d'une couche sémantique exposée par un serveur MCP, le protocole ouvert qui relie un assistant à des outils : le vocabulaire est fermé et vérifié, et l'IA s'en sert sans pouvoir le contourner. Le choix entre les deux approches dépend du contexte : un assistant intégré à Snowflake, ou un assistant d'entreprise, qu'il repose sur Claude, GPT ou Mistral, qui interroge plusieurs systèmes.
4. Les agents : combiner plutôt qu'empiler
La dernière brique assemble les précédentes. Un agent reçoit une question, décide s'il doit chercher dans les documents, interroger les indicateurs ou les deux, puis rédige une réponse qui cite ses sources. « Pourquoi le taux de panne de la ligne 2 a-t-il augmenté en septembre ? » peut ainsi combiner l'indicateur de disponibilité et les comptes rendus d'intervention de la période.
C'est la promesse la plus ambitieuse, et celle qui demande le plus de rigueur : un agent ne vaut que par la qualité des indicateurs et des documents qu'on lui confie.
| Texte en SQL | Recherche documentaire | Questions sur les chiffres | Agent | |
|---|---|---|---|---|
| Classer des milliers de comptes rendus de maintenance | ✓ | ✕ | ✕ | ✕ |
| Retrouver la bonne procédure de sécurité | ✕ | ✓ | ✕ | ◐ |
| Coût de la non-qualité par site | ✕ | ✕ | ✓ | ◐ |
| Expliquer une hausse du taux de panne | ◐ | ◐ | ◐ | ✓ |
✓ accès complet ◐ accès restreint ou masqué ✕ pas d'accès
Les règles qui ne changent pas
L'IA intégrée à la plateforme ne dispense d'aucune discipline. Elle la rend même plus visible.
Les droits d'abord. Chaque appel s'exécute avec un rôle Snowflake : ce que l'utilisateur ne peut pas lire, l'IA ne peut pas le lire pour lui. Le masquage des colonnes sensibles et les politiques de lignes s'appliquent aussi aux fonctions d'IA. Encore faut-il qu'ils soient en place avant de brancher le premier assistant.
Les coûts ensuite. Les fonctions d'IA consomment des crédits, au volume de texte traité. Classer un million de commentaires avec le modèle le plus puissant du catalogue peut coûter cher pour un gain nul. Un suivi de la consommation par usage et des tests sur un échantillon avant tout traitement de masse évitent les mauvaises surprises.
La qualité enfin. Un modèle qui résume un compte rendu mal saisi produit un résumé élégant d'une information fausse. Les contrôles de qualité des données restent la première ligne de défense, IA ou pas.
Et la conformité. Le RGPD s'applique aux données personnelles traitées par l'IA comme aux autres, et l'AI Act européen impose transparence et traçabilité selon le niveau de risque de l'usage. Un registre des usages d'IA, tenu avec le délégué à la protection des données, fait partie du projet, pas de sa conclusion.
Snowflake, mais pas seulement
Snowflake n'est pas le seul à rapprocher l'IA des données : Databricks, Google BigQuery ou Microsoft Fabric suivent la même direction, chacun avec ses outils. Ce qui compte n'est pas le nom de l'éditeur, c'est le principe : traiter les données là où elles sont gouvernées, plutôt que de les disperser. Une organisation qui a déjà investi dans sa gouvernance a, sans le savoir, préparé le terrain de son IA.
À retenir
- Cortex amène les modèles d'IA dans Snowflake : les données ne sortent pas et les droits existants s'appliquent.
- Quatre familles d'usages : transformer du texte en SQL, retrouver des documents, questionner les chiffres en langage naturel, enchaîner les actions avec des agents.
- Les questions sur les chiffres doivent s'appuyer sur une couche sémantique : des indicateurs définis une fois, que l'IA ne peut pas réinventer.
- Droits, coûts, qualité et conformité restent les quatre garde-fous, et ils doivent être en place avant le premier appel.
- La gouvernance déjà construite devient l'infrastructure de l'IA.
Checklist
- Chaque usage d'IA a un propriétaire métier et une décision ou une tâche précise à servir.
- Les rôles, le masquage et les politiques de lignes sont actifs avant le premier appel.
- Les questions sur les chiffres passent par une couche sémantique, jamais par des tables brutes.
- Le modèle est choisi selon la tâche, et testé sur un échantillon avant tout traitement de masse.
- La consommation de crédits est suivie par usage.
- Les usages d'IA sont inscrits au registre tenu avec le délégué à la protection des données.