Poser des questions à Snowflake en langage naturel

Si vos ventes sont déjà dans Snowflake, Datarelix transforme une question de reporting en requête et en graphique avec une connexion compatible. Vérifiez d’abord l’authentification : le connecteur Snowflake actuel utilise un nom d’utilisateur et un mot de passe, alors que Snowflake renforce ses exigences.

Confirmer la compatibilité du compte

Demandez au responsable Snowflake si cette méthode est acceptée pour l’identité prévue. Le calendrier publié par Snowflake situe la généralisation aux utilisateurs existants entre août et octobre 2026, avec une date propre à chaque compte. Un compte qui exige MFA ou une identité de service sans mot de passe ne peut pas utiliser cette connexion. N’affaiblissez pas sa politique pour la rendre compatible. Calendrier d’authentification Snowflake

En cas d’incompatibilité, contactez Datarelix avant la configuration. L’authentification par paire de clés et OAuth ne sont pas disponibles dans ce connecteur. Si la méthode est compatible, obtenez l’identifiant du compte, le warehouse, la base, le rôle, le schéma et les identifiants approuvés. Le guide de connexion Snowflake détaille les champs.

Définir le rapport

Par exemple, demandez :

Compare le montant des commandes payées par mois d’avril à juin 2026, en euros. Utilise la date de commande, exclus les annulations et indique qu’il s’agit du montant avant remboursements.

Exemple de SQL Snowflake :

SELECT DATE_TRUNC('MONTH', ORDERED_AT)::DATE AS MONTH,
       SUM(TOTAL_EUR) AS PAID_ORDER_VALUE_EUR
FROM SALES.REPORTING.ORDERS
WHERE STATUS = 'paid'
  AND ORDERED_AT >= '2026-04-01'::DATE
  AND ORDERED_AT < '2026-07-01'::DATE
GROUP BY 1
ORDER BY 1;

Mois	Montant des commandes payées, EUR
Avril 2026	2 000
Mai 2026	2 500
Juin 2026	2 300

Cet exemple totalise 6 800 EUR. La courbe doit monter en mai puis descendre en juin. Vérifiez le fuseau horaire et les remboursements avant de présenter ce montant comme du chiffre d’affaires. Un mois sans commandes correspondantes sera absent du résultat ; cette absence ne prouve pas à elle seule un montant nul.

Quels droits le rôle de reporting doit-il avoir ?

Le rôle de reporting a besoin de USAGE sur le warehouse, la base et le schéma, puis de SELECT sur les objets autorisés. Lorsque AUTO_RESUME est activé, USAGE permet à une requête de relancer automatiquement le warehouse. OPERATE concerne notamment la reprise manuelle et n’est pas nécessaire à cette reprise automatique. Privilèges Snowflake

Un administrateur habilité à gérer ces droits peut accorder à un rôle existant et approuvé le minimum nécessaire pour une table de reporting. Remplacez les objets d’exemple par les vôtres :

GRANT USAGE ON WAREHOUSE reporting_wh TO ROLE reporting_reader;
GRANT USAGE ON DATABASE sales TO ROLE reporting_reader;
GRANT USAGE ON SCHEMA sales.reporting TO ROLE reporting_reader;
GRANT SELECT ON TABLE sales.reporting.orders TO ROLE reporting_reader;

Accordez une vue séparément lorsque le rapport lit une vue. L’administrateur reste responsable des rôles hérités et de la politique d’authentification du compte : ces droits ne rendent pas une connexion par mot de passe acceptable sur un compte qui exige MFA ou une identité de service sans mot de passe. Datarelix valide le SQL généré en lecture seule avant son exécution (contrôles de l’analytique IA en lecture seule) ; les droits du rôle restent la limite côté base. La configuration complète, identifiant de compte et stratégies réseau compris, figure dans le guide de connexion Snowflake.

En option administrative, le même rôle peut aussi recevoir les tables créées plus tard dans ce schéma :

GRANT SELECT ON FUTURE TABLES IN SCHEMA sales.reporting TO ROLE reporting_reader;

Un droit sur les tables futures s’applique uniquement aux tables créées ensuite, pas aux tables existantes, et il ne couvre que les tables : les vues demandent leur propre droit futur. Il réduit la maintenance quand chaque nouvelle table de reporting doit être lisible, et élargit pour la même raison l’accès futur ; traitez-le comme une décision de périmètre, pas comme une correction pour une table que le rôle ne peut pas lire aujourd’hui. Référence GRANT Snowflake

Les frais de calcul Snowflake restent distincts de votre forfait Datarelix. La taille du warehouse, sa durée d’activité et ses réglages de suspension influencent la consommation. Les reprises fréquentes peuvent également compter en raison du minimum facturé au démarrage. Choisissez les réglages selon le travail réel avec le responsable. Un tableau de trois lignes n’implique pas une requête peu coûteuse. Recommandations Snowflake sur les warehouses

Relier les champs de connexion à la source du rapport

L’identifiant de compte localise le compte Snowflake. Le warehouse fournit le calcul, la base et les schémas identifient les objets, et le rôle actif détermine les droits. Un mot de passe correct ne compense pas un accès manquant au warehouse ou à une table.

Utilisez l’identifiant fourni par l’administrateur, de préférence la forme organisation-compte décrite par Snowflake, distincte d’une URL complète de navigateur. Les politiques réseau et la connectivité privée influencent aussi l’accès ; confirmez le trajet disponible depuis le service hébergé avant de diagnostiquer le SQL. Identifiants de compte Snowflake

Droit nécessaire	Rôle	Point à examiner
USAGE du warehouse	Exécuter les requêtes sur ce calcul	Reprise automatique et calcul disponible
USAGE de la base et du schéma	Accéder aux objets approuvés	Chaque schéma sélectionné
SELECT sur les objets	Lire tables ou vues de reporting	Objets actuels et traitement prévu des nouveaux
Attribution du rôle	Utiliser le rôle de reporting	Droits actifs et hérités de l’identité

Le guide de connexion conserve la liste complète des droits ; l’option des tables futures ci-dessus est une décision de périmètre, pas une correction d’accès manquant.

Lire le SQL Snowflake en tenant compte des types

L’exemple mensuel regroupe les commandes payées avec DATE_TRUNC et exclut le 1er juillet. L’analyste vérifie si ORDERED_AT représente l’événement attendu et comment son type interagit avec le fuseau du rapport.

Snowflake distingue notamment TIMESTAMP_NTZ, TIMESTAMP_LTZ et TIMESTAMP_TZ. L’affichage d’une date locale ne suffit pas à définir le sens de l’horodatage. Testez une ligne proche de la borne lors du rapprochement. Types de dates et heures Snowflake

Les identifiants à casse mixte entre guillemets nécessitent leur forme exacte. Si le rapport joint clients, commandes et articles, examinez les sources et les clés autant que la fonction de date. Pour les champs VARIANT imbriqués, établissez la structure et le sens de chaque ligne développée : déplier un tableau peut multiplier les lignes additionnées.

Vérifier les données même si les clés sont déclarées

Sur les tables standard Snowflake, une clé étrangère déclarée n’impose pas l’intégrité référentielle. Elle peut décrire une relation sans prouver que chaque ligne correspond ni que la jointure a la cardinalité voulue. Le comportement diffère pour les tables hybrides ; identifiez le type de table. Contraintes Snowflake

Pour une relation déduite, faites confirmer clés et correspondances attendues par l’analyste ou le responsable source. Comparez un sous-total avant et après jointure. Les descriptions expliquent la granularité prévue, mais ne réparent ni clés dupliquées ni enregistrements manquants.

Estimer le coût à partir de l’activité du warehouse

Examinez avec son responsable les intervalles de fonctionnement, la taille et la concurrence pendant l’essai. La seule durée des requêtes omet l’inactivité et les minimums au démarrage. Dans un exemple volontairement simplifié, un tarif applicable d’un crédit par heure donne 0,25 crédit de warehouse pour un intervalle continu de quinze minutes. Ce calcul exclut les autres services, ajustements tarifaires et intervalles supplémentaires.

Choisissez suspension automatique et limites côté source selon le travail observé. Actualiser un tableau de bord crée une nouvelle demande ; même une requête à dates fixes peut engendrer un coût. Les frais Snowflake et l’usage Datarelix sont deux postes distincts.

Comparer un parcours natif Snowflake

Si toutes les données pertinentes sont dans Snowflake, incluez ses propres options de reporting et d’assistance dans l’évaluation ; la comparaison entre analytique IA et BI traditionnelle fournit les critères de parcours pour cette décision. Vérifiez authentification, droits, SQL visible, graphiques et rapports enregistrés pour le produit et l’offre précis. Un outil indépendant peut apporter une interface de reporting familière sur plusieurs moteurs compatibles ; cela n’implique pas une jointure unique entre moteurs.

Les utilisateurs métier évaluent le parcours jusqu’au rapport réutilisable. Les analystes essaient une jointure réaliste, une borne de date et une question de suivi avant de se décider sur la première réponse d’une démonstration.

Réutiliser le graphique

Comparez la source, les dates et les filtres avec un rapport connu. Ajoutez ensuite le graphique à un tableau de bord Datarelix privé. Son actualisation manuelle relance la requête et peut consommer du calcul Snowflake. Les dates fixes d’avril à juin restent identiques après actualisation.

Le guide de vérification distingue vos contrôles des calculs ou jointures à faire examiner par une personne qui maîtrise SQL. Confirmez la compatibilité de connexion avant de consacrer du temps à un essai.