Snowflake : la gouvernance sémantique, clé des agents AI fiables

Snowflake : la gouvernance sémantique, clé des agents AI fiables

Cette année, de nombreuses équipes de données ont intégré des agents AI dans leurs feuilles de route. L'enthousiasme est palpable : un agent capable de transformer une analyse de deux jours en une conversation de deux minutes peut révolutionner la collaboration entre analystes et équipes commerciales.

Cependant, les agents ne sont fiables que si la fondation de données qui les sous-tend est solide. Si on les dirige vers des tables brutes ou des métadonnées obsolètes, ils peuvent sembler convaincants tout en étant incorrects. Cet article présente un cadre pratique pour générer et déployer des vues sémantiques gouvernées sur Snowflake.

Pourquoi la qualité des agents se dégrade

Trois schémas d'échec apparaissent fréquemment lorsque les agents passent de la démonstration à la production :

• La gouvernance est sacrifiée au profit de la rapidité. Les équipes sous pression pour livrer négligent les questions d'intégrité des données et de contrôle d'accès jusqu'à ce qu'un agent réponde déjà aux questions pour l'entreprise.

• La duplication prolifère. Sans un processus partagé, différentes équipes construisent des agents qui se chevauchent et répondent à la même question de manière subtilement différente – et incohérente.

• Les réponses sont non déterministes. La même question posée deux fois renvoie deux chiffres différents. C'est pire que d'être systématiquement faux, car personne ne sait quand se méfier de la réponse.

Tous ces problèmes découlent d'une cause racine : il n'existe pas de processus standardisé et appliqué régissant la création, la révision, la version et la promotion d'une définition sémantique. Des outils qui aident à rédiger des vues sémantiques plus rapidement ne résolvent pas ce problème à eux seuls – rapidité et gouvernance sont deux axes différents, et une organisation peut avoir beaucoup de l'un et peu de l'autre.

Ce que fait réellement une couche sémantique

Demandez à cinq équipes « quel est le nombre total de membres actifs au T1 2026 ? » sans une couche sémantique partagée, et vous obtiendrez cinq chiffres différents. Chaque équipe applique ses propres filtres, joint ses propres tables et définit « actif » différemment – et un LLM qui pose la même question sans référence hallucine une sixième réponse qui semble tout aussi confiante que les cinq autres.

Une couche sémantique résout ce problème en se plaçant entre l'entrepôt brut et chaque consommateur – tableaux de bord, feuilles de calcul, et maintenant agents AI – et en répondant trois questions de la même manière, à chaque fois : quelles tables contiennent ces données, quels filtres s'appliquent, et quelle est la logique et le grain d'agrégation. La documentation de Snowflake présente cela comme une réponse au décalage entre la manière dont les utilisateurs commerciaux décrivent les données et la manière dont elles sont réellement stockées dans les schémas de base de données – par exemple, définir « revenu net » une fois, de manière cohérente, comme SUM(gross_revenue * (1 - discount)), plutôt que de laisser le calcul être réinventé dans chaque rapport.

Où cela se trouve dans Snowflake

Dans Snowflake, la couche sémantique est mise en œuvre sous la forme d'une vue sémantique, un objet au niveau du schéma stocké directement dans la base de données qui définit les métriques commerciales et modélise les entités et leurs relations, que Cortex Analyst – l'outil de texte-à-SQL de Snowflake – peut ensuite interroger en langage naturel. Cortex Agent est l'orchestrateur AI qui détient une ou plusieurs vues sémantiques, aux côtés des services de recherche et des outils personnalisés, et décide quelle ressource répond à une question donnée – la même architecture soutenant Snowflake CoWork (anciennement Snowflake Intelligence).

Voici à quoi ressemble cette spécification remplie avec un exemple réel. Ci-dessous se trouve une vue sémantique sur un ensemble de données de facturation SaaS – deux tables logiques (facturation et clients), jointes sur l'identifiant client, avec trois métriques de revenus certifiées définies une fois :

• name: SAAS_BILLING
• description: Combine les enregistrements clients avec les détails de facturation d'abonnement pour soutenir les métriques certifiées MRR, MRR net et revenus perdus.
• base_table: { database: FINANCE, schema: ANALYTICS, table: FCT_SAAS_BILLING }
  • name: BILLING_DATE
    • expr: BILLING_DATE
  • name: PLAN_TYPE
    • data_type: VARCHAR(20)
  • name: MRR_AMOUNT
    • expr: MRR_AMOUNT
    • data_type: NUMBER(10,2)
  • name: TOTAL_MRR
    • expr: SUM(billing.MRR_AMOUNT)
    • expr: SUM(billing.MRR_AMOUNT) - SUM(billing.DISCOUNT_AMOUNT)
  • name: CHURNED_REVENUE
    • expr: SUM(IFF(billing.IS_ACTIVE = FALSE, billing.MRR_AMOUNT, 0))
    • primary_key: { columns: [BILLING_ID] }
• name: CUSTOMERS
  • base_table: { database: FINANCE, schema: ANALYTICS, table: DIM_CUSTOMERS }
  • name: COMPANY_NAME
    • expr: COMPANY_NAME
    • data_type: VARCHAR(100)
  • name: INDUSTRY
    • data_type: VARCHAR(50)
    • primary_key: { columns: [CUSTOMER_ID] }
  • name: CUSTOMER_BILLING
    • left_table: BILLING
    • right_table: CUSTOMERS
    • relationship_columns:
      • { left_column: CUSTOMER_ID, right_column: CUSTOMER_ID }

Ce qui n'est pas en question, c'est que cet objet fonctionne. Ce qui est en question, c'est : comment une vue sémantique comme celle-ci est-elle créée en premier lieu ?

Les deux piliers de gouvernance derrière chaque métrique certifiée

Avant le pipeline lui-même, il est utile d'être précis sur les deux entrées gouvernées dont il dépend.

• Le Catalogue de Données : Une source autorisée pour les descriptions commerciales, types de données, étiquettes de sensibilité (PII/PHI), valeurs d'exemple et statut de certification pour chaque colonne et table. Dans cette mise en œuvre, c'est Snowflake Horizon – les étiquettes sont définies au niveau de la colonne ou de la table. Le catalogue contient le type de données, la description, les synonymes, les valeurs d'exemple, etc., et une politique de masquage dynamique peut restreindre qui voit une colonne signalée. Une étiquette certification_status = 'Certified' est le feu vert pour que les métadonnées de cette colonne soient utilisées dans une vue sémantique.

• L'Inventaire des Métriques : Un foyer unique gouverné pour chaque formule de métrique, avec une description, un propriétaire commercial, une table source, un domaine, une classification de sensibilité, et surtout un statut de certification. La règle opérationnelle : chaque métrique est définie une fois et réutilisée partout, et « une fois » est conditionnée par une approbation réelle d'un propriétaire de domaine ou d'un steward des données. C'est ce qui va résoudre le problème que la même métrique puisse être répondue de 6 manières différentes au sein des équipes.

Le cadre : un harnais de gouvernance pour la génération de vues sémantiques

L'idée centrale est simple à énoncer : traiter la génération de vues sémantiques comme un lancement de logiciel gouverné, et non comme un exercice de modélisation ponctuel. En pratique, cela signifie cinq composants, chacun appliquant une règle qu'un processus informel laisse généralement optionnelle. Avant de passer en revue chacun d'eux, il est utile de voir l'ensemble du pipeline de bout en bout, puis comment ce pipeline s'intègre dans l'architecture plus large de Snowflake.

Diagramme de flux du cadre de gouvernance

En prenant du recul d'un niveau : ce pipeline n'est que la moitié de l'image au moment de la construction. La figure 2 montre comment il s'intègre aux systèmes qui consomment réellement sa sortie – Cortex Analyst, Cortex Agents, Snowflake Cowork, et les outils BI discutés plus loin dans cet article.

Architecture système

Le code complet pour la décomposition des composants ci-dessous est ici.

Composant 1 – Extraction de contexte

Un script d'orchestration se connecte à Horizon et à l'inventaire des métriques et extrait, pour un domaine donné, uniquement des formules de métriques certifiées et des schémas étiquetés. Cette étape est déterministe – elle récupère des faits déjà approuvés, elle n'infère rien :

[cursor](/outil/cursor).execute(f"""
SELECT metric_name, description, expression, base_table
FROM GOVERNANCE_DB.SEMANTICS.METRIC_INVENTORY
WHERE certification_status = 'Certified'
AND base_table IN ({table_list})
{"metric_name": r[0], "description": r[1], "expression": r[2], "table": r[3]}
for r in cursor.fetchall()

Le processus extrait le schéma et le contexte des étiquettes directement à partir des références d'étiquettes de Horizon.

catalog_query = f"""
WITH physical_schema AS (
SELECT table_schema, table_name, column_name, data_type, comment AS column_description
FROM {database}.INFORMATION_SCHEMA.COLUMNS
WHERE table_schema IN ({schema_list}) AND table_name IN ({table_list})
horizon_tags AS ( {real_time_tags_cte} )
SELECT p.table_name, p.column_name, p.data_type, p.column_description, t.tag_value AS privacy_tag
FROM physical_schema p
LEFT JOIN horizon_tags t
ON p.table_name = t.table_name AND p.column_name = t.column_name

C'est la première différence structurelle par rapport aux approches d'inférence d'utilisation qu'il convient de déclarer clairement : ce pipeline ne propose jamais que des définitions qui se rapportent à une source pré-approuvée, plutôt qu'une définition mise en avant parce qu'elle était le modèle le plus courant dans l'historique de requêtes de quelqu'un. La popularité est un signal de découverte utile ; ce n'est pas la même affirmation qu'une approbation de gouvernance.

Composant 2 – Génération contrainte

Un LLM de choix (Claude, GPT, Qwen, GLM, etc.) convertit le contexte extrait en un modèle dbt strictement formaté en utilisant le dbt_semantic.