L'analyse Snowflake,pour tous ceux qui n'écrivent pas de SQL.

Demandez au Connector Agent de connecter Snowflake et saisissez votre identifiant de compte, un nom d'utilisateur et un entrepôt. Cliquez sur Generate key pair & SQL, puis faites exécuter le script une fois dans Snowsight par un ACCOUNTADMIN. Il crée un utilisateur de service et un rôle en lecture seule. Choisissez ensuite les tables, approuvez le chargement et choisissez un planning.

Toutes les tables et vues de la base de données choisie, dans tous ses schémas sauf INFORMATION_SCHEMA, ou seulement les tables que vous sélectionnez. Les bases de données partagées fonctionnent aussi, et vous pouvez ajouter vos propres requêtes SQL comme sources supplémentaires. Chaque table arrive nommée SCHEMA.TABLE. Querri ne peut synchroniser que ce à quoi le rôle utilisé pour la connexion a accès.

Les actualisations complètes peuvent être planifiées chaque jour, chaque semaine ou chaque mois. Si vous choisissez une colonne curseur, par exemple un horodatage de mise à jour, les synchronisations incrémentielles peuvent s'exécuter toutes les heures, chaque jour ou chaque semaine et n'ajoutent que les lignes plus récentes que la dernière exécution. Une synchronisation manuelle peut être lancée à tout moment entre deux plannings.

Non. Querri ne fait que lire Snowflake et ne crée, ne modifie ni ne supprime jamais une table ou une ligne. Les requêtes Live sont vérifiées avant leur envoi : seul un SELECT unique sur les tables que vous avez choisies atteint Snowflake. Le script de configuration unique, que vous exécutez vous-même, crée seulement un utilisateur de service, un rôle en lecture seule, ses droits et, si vous le demandez, un entrepôt. Les requêtes de Querri sont étiquetées dans QUERY_HISTORY : vous pouvez donc les auditer.

Querri ne voit que ce à quoi le rôle utilisé pour la connexion a accès : donnez donc à ce rôle exactement les bases de données et schémas que vous voulez dans Querri. Dans Querri, qui voit quelles lignes dépend du partage de Querri et des filtres de lignes par personne, qui suivent chacun dans le chat, les tableaux de bord, Claude et l'API. Pour les tables Live, ces filtres sont appliqués à l'intérieur même de la requête Snowflake.

C'est possible, table par table. Une table Live reste dans Snowflake : chaque question qui en a besoin s'y exécute sous forme de requête écrite en Snowflake SQL, et seul le résultat revient. Ces requêtes consomment les crédits de votre entrepôt, et un entrepôt suspendu met quelques secondes à reprendre. Les tables synchronisées reçoivent une réponse tirée de la copie de Querri : ces questions ne réveillent donc pas l'entrepôt et sont aussi fraîches que la dernière synchronisation. Les tables Live sont disponibles avec l'offre Scale.

Passez-la en Live quand la table est très grande, quand les données doivent rester dans l'entrepôt, ou quand chaque réponse doit refléter Snowflake tel qu'il est à cet instant. Gardez-la synchronisée quand la table est petite ou moyenne, quand elle est beaucoup explorée et que vous préférez ne pas payer le calcul de l'entrepôt à chaque question, ou quand l'entrepôt est lent à se réveiller. Vous pouvez repasser une table Live en synchronisée à tout moment ; elle se charge à la prochaine synchronisation complète.

Oui. Les questions qui portent sur plusieurs tables Live d'une même connexion s'exécutent en une seule requête Snowflake. Quand une question a aussi besoin d'une table synchronisée ou d'un fichier importé, Querri résume d'abord la table Live dans Snowflake, puis combine ce petit résultat avec les autres données dans Querri. Tout se fait automatiquement, et un clic sur un chiffre montre de quelle table il provient, avec un badge Live.

Connectez Salesforce à côté de Snowflake ; les deux arrivent dans la même Bibliothèque. Querri rapproche les comptes de l'entrepôt des comptes Salesforce, idéalement par un identifiant présent dans les deux, et vous dit comment il les a rapprochés. Vous pouvez alors interroger l'usage à côté des renouvellements, du pipeline ou des tickets ouverts sans construire de nouveau pipeline de données.

Connectez HubSpot à côté de Snowflake. Querri relie les contacts et entreprises HubSpot aux clients de votre entrepôt, pour que vous puissiez suivre une campagne jusqu'au chiffre d'affaires durable. Quand une correspondance peut être fausse, par exemple à cause d'un domaine e-mail différent, la réponse le signale.

Synchronisez les tables d'usage depuis Snowflake et connectez les sources de support et de facturation si elles sont ailleurs. Définissez le score une fois avec vos mots, et Querri le suit par compte, avec un historique dès le premier jour. Le playbook sur le score de santé client détaille chaque étape.

Synchronisez vos tables d'événements et de comptes, dites quel événement compte comme première valeur, et construisez l'entonnoir une fois sous forme de projet. Relancez-le à chaque synchronisation ou planifiez son envoi par e-mail à l'équipe. Le playbook de l'inscription à la première valeur couvre tout, de bout en bout.

Oui. Demandez les graphiques avec vos mots, ou partez d'une capture d'un tableau de bord sur lequel votre équipe s'appuie déjà. Les modifications sont aussi des demandes. Un même tableau de bord peut placer des tables Snowflake à côté de données CRM ou financières, limiter chaque lecteur à ses lignes et s'intégrer dans votre propre application.

Oui. Ajoutez Querri comme connecteur dans Claude ou ChatGPT. Les questions sur les tables Snowflake reçoivent alors une réponse tirée de votre Bibliothèque, avec les règles de votre équipe appliquées et limitée aux lignes que la personne peut voir dans Querri. Au lieu de deviner les jointures à partir d'un schéma brut, l'assistant utilise les mêmes définitions que vos tableaux de bord et vos rapports.

Enregistrez l'analyse sous forme de projet et planifiez-la. À chaque exécution, Querri part de données à jour, en direct ou synchronisées, et envoie par e-mail un classeur Excel mis en forme aux personnes concernées, avec une version distincte par personne ou par client.

Non. Snowflake bloque les mots de passe pour les utilisateurs de service et exige un second facteur pour les personnes : Querri utilise donc une paire de clés ou un jeton d'accès programmatique. OAuth n'est pas proposé, car il exige qu'une personne approuve dans un navigateur et ses jetons expirent, ce qui casserait les synchronisations planifiées.

Les synchronisations incrémentielles ne captent que les lignes dont la valeur du curseur augmente : les suppressions et les modifications qui ne changent pas le curseur demandent une actualisation complète. Les sources SQL personnalisées s'actualisent toujours entièrement. Par défaut, les résultats Live s'arrêtent à 100 000 lignes et les questions dans le chat expirent au bout de 2 minutes. Il n'y a pas d'option PrivateLink ni VPN. La configuration demande un ACCOUNTADMIN une fois, et les jetons d'accès expirent : la paire de clés convient donc mieux aux plannings.

Oui. Ajoutez les adresses IP sortantes de Querri à une network policy Snowflake pour l'utilisateur de service. Querri accède à votre compte via le point de terminaison public de Snowflake, quels que soient le cloud ou la région. PrivateLink n'est pas pris en charge : une liste d'IP autorisées plus le rôle en lecture seule, c'est ainsi que vous verrouillez l'accès.

Oui. Passez une grande table en Live et elle reste dans Snowflake, où chaque question s'exécute, et seul le résultat revient. Les tables synchronisées arrivent par lots en Parquet, donc une table entière n'est jamais en mémoire, et il n'y a pas de plafond de lignes fixe ; une synchronisation de test a récupéré plus de 520 millions de lignes. Pour les grosses tables synchronisées qui grossissent, un curseur incrémentiel limite chaque synchronisation aux nouvelles lignes.

Querri est certifié SOC 2 Type II, HIPAA et ISO 27001:2022, et vos données ne servent jamais à entraîner un modèle. La clé privée générée par Querri est stockée chiffrée et jamais affichée, le rôle de connexion est en lecture seule, et le Connector Agent ne voit jamais le secret lui-même.