Le connecteur Snowflake vous permet d’interroger directement depuis Perplexity les données de votre entrepôt de données Snowflake. Vous pouvez rechercher et combiner des informations dans vos bases de données Snowflake, vos autres applications connectées et le web — sans écrire de SQL à la main ni passer à la console Snowflake.
Il est disponible sur Perplexity Pro, Perplexity Max, Enterprise Pro et Enterprise Max. La connexion à Snowflake se fait par utilisateur — personne d’autre dans votre organisation ne peut interroger vos données, sauf si vous les synchronisez dans un Project partagé.
Ce guide explique le fonctionnement du connecteur, comment choisir une méthode d’authentification, comment configurer les rôles et l’accès en lecture seule, ainsi qu’une configuration étape par étape. Si vous voulez simplement la voie la plus rapide : la plupart des organisations devraient utiliser User OAuth — rendez-vous directement à Guide d’installation.
Une fois activé, le connecteur se connecte de manière sécurisée à votre compte Snowflake et vous permet de rechercher dans les bases de données, schémas, tables et vues que vous êtes autorisé à consulter. Lorsque vos données Snowflake changent, le connecteur reflète automatiquement ces changements lors de votre prochaine requête.
Objets de données pris en charge :
Tables
Vues et vues matérialisées
Schémas
Bases de données
Données structurées (tables basées sur CSV, JSON et Parquet)
Les données non structurées (images, audio et vidéo stockés dans les stages Snowflake) ne sont pas prises en charge.
L’authentification Snowflake comporte deux dimensions indépendantes : qui exécute les requêtes (l’identité) et comment cette identité prouve son identité (l’identifiant). Perplexity propose deux connecteurs dans l’annuaire, chacun correspondant à une combinaison recommandée :
Snowflake (User OAuth) — chaque utilisateur Perplexity se connecte avec son propre compte Snowflake (TYPE = PERSON) via OAuth. Recommandé pour la plupart des organisations.
Snowflake — tous les utilisateurs Perplexity interrogent les données via un seul compte de service partagé (TYPE = SERVICE) à l’aide d’une paire de clés. Utilisez cette option lorsque vos utilisateurs finaux n’ont pas de comptes Snowflake individuels.
Avec User OAuth, chaque personne s’authentifie avec ses propres identifiants, les requêtes s’exécutent sous ses autorisations Snowflake natives, et vous obtenez une piste d’audit claire par utilisateur — pas de compte de service partagé et pas besoin de recréer votre contrôle d’accès basé sur les rôles (RBAC) dans Perplexity. Cela correspond également à l’orientation de Snowflake : son serveur MCP géré ne prend en charge actuellement que OAuth 2.0.
Remarque : Avec OAuth, le jeton d’accès est lié à un seul rôle principal lors de la connexion — le DEFAULT\_ROLE de l’utilisateur. Pour vous assurer que les utilisateurs peuvent accéder à tout ce qui leur a été accordé, configurez les rôles secondaires (voir Configuration des rôles pour User OAuth).
Un compte de service partagé (TYPE = SERVICE + paire de clés) convient lorsque :
Vos utilisateurs finaux n’ont pas de comptes Snowflake individuels (par exemple, des utilisateurs métier qui interrogent via Perplexity mais n’ont pas d’accès direct à Snowflake).
Vous souhaitez que toutes les requêtes Perplexity s’exécutent sous une identité partagée unique pour simplifier l’audit.
Vous configurez un environnement interne ou de test où l’identité par utilisateur n’est pas nécessaire.
Configurez le compte de service avec un rôle dédié et à portée réduite — voir Configuration des rôles du compte de service.
À noter concernant les Programmatic Access Tokens (PAT) : Snowflake prend également en charge les identifiants PAT, et le connecteur les accepte. Nous ne recommandons pas les PAT pour les nouvelles configurations — les jetons expirent rapidement et sont rigidement liés à un seul rôle au moment de leur création, donc nous utilisons une paire de clés dans les exemples tout au long de ce guide. Si vous devez utiliser un PAT, définissez ROLE\_RESTRICTION sur votre rôle Perplexity dédié au moment de la création.
Une session OAuth s’ouvre avec le DEFAULT\_ROLE de l’utilisateur comme rôle principal ; le changement de rôle au cours d’une session n’est pas pris en charge et Perplexity n’affiche pas de sélecteur de rôle. Ainsi, tout ce que chaque utilisateur a défini pour DEFAULT\_ROLE et DEFAULT\_SECONDARY\_ROLES est exactement ce que sa session Perplexity utilise.
Définissez cela une seule fois, au niveau de l’intégration de sécurité :
OAUTH\_USE\_SECONDARY\_ROLES = IMPLICIT
La valeur par défaut de ce paramètre chez Snowflake est NONE, ce qui signifie que les sessions OAuth s’ouvrent avec le seul rôle principal actif. Le définir sur IMPLICIT indique à Snowflake d’activer également automatiquement les DEFAULT\_SECONDARY\_ROLES de chaque utilisateur. Sans cela, les utilisateurs ne voient que les données accessibles via leur DEFAULT\_ROLE — rarement ce que vous souhaitez.
Ensuite, gérez l’un des deux cas suivants :
Cas A — les utilisateurs ont déjà des rôles par défaut. Si les DEFAULT\_ROLE et DEFAULT\_SECONDARY\_ROLES de vos utilisateurs sont déjà définis comme vous le souhaitez, n’effectuez aucune autre action. Le paramètre IMPLICIT suffit — les paramètres par défaut existants de chaque utilisateur sont ceux utilisés par sa session Perplexity.
Cas B — les utilisateurs n’ont pas encore de rôles par défaut. Donnez à chaque session l’union de tous les rôles accordés à cet utilisateur en définissant DEFAULT\_ROLE sur PUBLIC et DEFAULT\_SECONDARY\_ROLES sur ALL :
ALTER USER \SET DEFAULT\_ROLE = PUBLIC, DEFAULT\_SECONDARY\_ROLES = ('ALL');
Remarque : Depuis la modification apportée par Snowflake en août 2024, DEFAULT\_SECONDARY\_ROLES = ('ALL') est la valeur par défaut pour les utilisateurs nouvellement créés, donc de nombreuses organisations l’ont déjà configurée. Exécutez DESC USER \ pour vérifier avant de modifier quoi que ce soit.
Un compte de service est un utilisateur dédié unique qui fonctionne sous un rôle spécifique — généralement PERPLEXITY\_ROLE. Le modèle PUBLIC + ('ALL') utilisé pour OAuth ne s’applique pas ici. À la place, définissez le DEFAULT\_ROLE de l’utilisateur de service sur votre rôle dédié et accordez à ce rôle uniquement les privilèges dont Perplexity a besoin. Cela suit les bonnes pratiques de Snowflake pour les comptes de service.
La requête SQL complète pour créer cet utilisateur se trouve dans le guide de configuration ci-dessous.
Pour limiter les rôles Snowflake auxquels les utilisateurs peuvent s’authentifier via l’intégration OAuth de Perplexity, définissez la portée au niveau de l’intégration de sécurité :
PRE\_AUTHORIZED\_ROLES\_LIST — une liste d’autorisation des rôles autorisés via cette intégration.
BLOCKED\_ROLES\_LIST — une liste de refus des rôles bloqués par cette intégration.
ALTER SECURITY INTEGRATION PERPLEXITY\_OAUTH
SET PRE\_AUTHORIZED\_ROLES\_LIST = ('ANALYST\_ROLE', 'READ\_ONLY\_ROLE');
Utilisez cela pour exclure entièrement les rôles sensibles (par exemple ACCOUNTADMIN) du flux OAuth.
Le connecteur exécute SQL via une couche d’outils (issue du connecteur Merge Snowflake). Le connecteur Snowflake (User OAuth) expose des outils nommés et granulaires — y compris un outil de requête dédié en lecture seule (execute\_sql\_readonly) qui n’accepte que SELECT, WITH, SHOW, DESCRIBE, EXPLAIN, VALUES et LIST, et refuse les entrées DDL/DML ainsi que les entrées à plusieurs instructions. Le connecteur de compte de service Snowflake expose un outil général execute\_sql qui accepte du SQL arbitraire, y compris DDL et DML.
Le contrôle faisant autorité est le RBAC de Snowflake. Quel que soit l’outil invoqué, les requêtes s’exécutent sous le rôle autorisé par votre configuration, donc l’application du mode lecture seule au niveau du rôle Snowflake est la protection fiable — et c’est la seule frontière d’application sur le connecteur de compte de service.
Schéma recommandé — appliquer le mode lecture seule avec un rôle dédié. Proposez un rôle tel que PERPLEXITY\_READ\_ONLY qui accorde uniquement USAGE et SELECT sur les bases de données, schémas et tables que vous souhaitez faire interroger par Perplexity, et qui n’accorde pas INSERT, UPDATE, DELETE, CREATE, DROP, OWNERSHIP, ni MODIFY sur le warehouse. Assurez-vous ensuite que les utilisateurs s’authentifient sur ce rôle :
Définissez-le comme DEFAULT\_ROLE de l’utilisateur, ou
Définissez la portée de l’intégration OAuth avec PRE\_AUTHORIZED\_ROLES\_LIST et/ou excluez les rôles capables d’écriture avec BLOCKED\_ROLES\_LIST (voir Restreindre les rôles pouvant être utilisés via OAuth).
Avec le RBAC configuré de cette manière, Snowflake rejette toute tentative d’écriture de Perplexity, quel que soit l’outil appelé.
Remarque : Les paramètres du connecteur incluent un panneau Autorisations des outils répertoriant les outils disponibles. Sur le connecteur Snowflake (User OAuth), vous pouvez restreindre les outils exposés — pour une configuration en lecture seule, n’activez que les outils de lecture (par exemple execute\_sql\_readonly, list\_\*, describe\_\*, get\_\*) afin de ne pas exposer les outils d’écriture/DDL. Considérez cela comme une défense en profondeur, et non comme la frontière faisant autorité : c’est le RBAC de Snowflake (ci-dessus) qui applique l’accès de manière fiable.
Lorsqu’il est connecté, le connecteur Snowflake peut effectuer les actions suivantes en votre nom :
Exécuter des requêtes SQL sur vos données Snowflake
Interroger Cortex Search et Cortex Analyst
Exécuter des UDF personnalisées et des procédures stockées
Si vous révoquez l’accès ou supprimez un rôle dans Snowflake, ces données deviennent immédiatement inaccessibles depuis Perplexity. Si vous déconnectez Snowflake dans Perplexity, vous pouvez choisir de conserver ou de supprimer les données mises en cache.
Pour les organisations Enterprise, Perplexity propose la certification SOC 2 Type II, le chiffrement de bout en bout, des mesures strictes de confidentialité des données et des contrôles d’accès utilisateurs granulaires. Vos données Snowflake ne sont jamais utilisées pour l’entraînement de l’IA.
La connexion à Snowflake se fait par utilisateur — personne d’autre dans votre organisation ne peut interroger vos données. Cependant, si vous synchronisez des données vers un Project partagé, toute personne ayant accès à ce Project peut les rechercher.
Les administrateurs de l’organisation peuvent activer ou désactiver le connecteur pour tous les utilisateurs depuis l’écran Autorisations dans les paramètres de l’organisation. L’application des règles de lecture/écriture est gérée au niveau du rôle Snowflake (voir Contrôler ce que Perplexity peut faire).
Choisissez le parcours qui correspond à votre méthode d’authentification :
User OAuth (recommandé) : Un administrateur de l’organisation configure l’application OAuth une seule fois, puis les utilisateurs se connectent individuellement. Passez directement à Connecter Snowflake à Perplexity — le SQL des étapes 1 à 6 concerne uniquement les configurations de compte de service.
Compte de service (paire de clés) : Exécutez la configuration SQL des étapes 1 à 6, puis connectez-vous à l’étape 7.
Rôle ACCOUNTADMIN (ou un rôle disposant des privilèges CREATE USER et GRANT)
OpenSSL installé localement (préinstallé sur macOS) — configurations de compte de service uniquement
Depuis votre terminal, générez une clé privée RSA :
openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out snowflake\_computer\_key.p8 -nocrypt
Générez ensuite la clé publique correspondante :
openssl rsa -in snowflake\_computer\_key.p8 -pubout -out snowflake\_computer\_key.pub
USE ROLE ACCOUNTADMIN;
-- Créer un rôle dédié
CREATE ROLE IF NOT EXISTS PERPLEXITY\_ROLE
COMMENT = 'Rôle pour le compte de service Perplexity';
-- Créer un entrepôt (ou utiliser un entrepôt existant)
CREATE WAREHOUSE IF NOT EXISTS PERPLEXITY\_WAREHOUSE
WAREHOUSE\_SIZE = 'XSMALL'
AUTO\_SUSPEND = 60
AUTO\_RESUME = TRUE
COMMENT = 'Entrepôt pour les requêtes Perplexity';
-- Accorder l'utilisation de l'entrepôt au rôle
GRANT USAGE ON WAREHOUSE PERPLEXITY\_WAREHOUSE TO ROLE PERPLEXITY\_ROLE;
Exécutez ceci en tant que ACCOUNTADMIN. Remplacez la valeur RSA\_PUBLIC\_KEY par le contenu de votre fichier snowflake\_computer\_key.pub (sans les lignes d'en-tête et de pied de page).
USE ROLE ACCOUNTADMIN;
CREATE USER PERPLEXITY\_USER
TYPE = SERVICE
DEFAULT\_ROLE = PERPLEXITY\_ROLE
DEFAULT\_WAREHOUSE = PERPLEXITY\_WAREHOUSE
COMMENT = 'Compte de service pour Perplexity'
RSA\_PUBLIC\_KEY = 'MIIBIjANBgkqhki...your\_public\_key\_here...IDAQAB';
-- Accorder le rôle dédié au compte de service
GRANT ROLE PERPLEXITY\_ROLE TO USER PERPLEXITY\_USER;
Remarque : TYPE = SERVICE identifie ce compte comme non humain — ne définissez pas de mot de passe. DEFAULT\_ROLE = PERPLEXITY\_ROLE le limite à un seul rôle dédié, avec uniquement les privilèges dont Perplexity a besoin.
-- Accorder l'accès à une base de données spécifique
GRANT USAGE ON DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Accorder l'accès à tous les schémas d'une base de données (actuels et futurs)
GRANT USAGE ON ALL SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
-- Accorder l'accès en lecture à toutes les tables et vues (actuelles et futures)
GRANT SELECT ON ALL TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE TABLES IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON ALL VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
GRANT SELECT ON FUTURE VIEWS IN DATABASE MY\_DATABASE TO ROLE PERPLEXITY\_ROLE;
Pour un accès plus sélectif, consultez la documentation Snowflake GRANT.
Perplexity utilise deux vues du schéma SNOWFLAKE.ACCOUNT\_USAGE pour construire une carte de données permettant une génération précise des requêtes :
|
Vue |
Objet |
|
|
Métadonnées des requêtes, performances et schémas d'utilisation |
|
|
Journal d'audit au niveau des objets (édition Enterprise uniquement) |
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE PERPLEXITY\_ROLE;
Remarque : ACCESS\_HISTORY n'est disponible que sur Snowflake Enterprise Edition ou supérieur ; Perplexity utilise automatiquement QUERY\_HISTORY comme solution de repli sur Standard Edition. Passer cette étape réduit la précision des requêtes. Pour savoir comment Perplexity utilise ces vues, consultez Comprendre la carte de données.