Connecter Perplexity à Snowflake | Perplexity Help Center

À propos du connecteur Snowflake

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.

À quoi le connecteur peut accéder

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.

Choisir une méthode d’authentification

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.

Recommandé : User OAuth

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).

Solution de secours : compte de service (paire de clés)

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.

Configuration des rôles et des accès

Configuration des rôles pour User OAuth

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 <username> 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 <username> pour vérifier avant de modifier quoi que ce soit.

Configuration des rôles du compte de service

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.

(Facultatif) Restreindre les rôles pouvant être utilisés via OAuth

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.

Contrôler ce que Perplexity peut faire

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 granulaire — 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.

Confidentialité et sécurité des données

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.

Sécurité et contrôle de niveau Enterprise

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 Projects partagé, toute personne ayant accès à ce Projects 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).

Guide de configuration

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.

Prérequis

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

Étape 1 : Générer une paire de clés (compte de service)

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

Étape 2 : Créer un rôle et un warehouse

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;

Étape 3 : Créer l'utilisateur du compte de service

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.

Étape 4 : Accorder l'accès à vos données

-- 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.

Étape 5 : Accorder l'accès à l'historique des requêtes et à l'historique d'accès

Perplexity utilise deux vues du schéma SNOWFLAKE.ACCOUNT_USAGE pour construire une Data Map permettant une génération précise des requêtes :

Vue	Objet
`QUERY_HISTORY`	Métadonnées des requêtes, performances et schémas d'utilisation
`ACCESS_HISTORY`	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 Data Map.

Vérifier l'accès

USE ROLE ACCOUNTADMIN;
GRANT ROLE PERPLEXITY_ROLE TO USER <your_username>;
USE ROLE PERPLEXITY_ROLE;
USE WAREHOUSE PERPLEXITY_WAREHOUSE;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY LIMIT 5;
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY LIMIT 5;

Étape 6 : (Facultatif) Autoriser les adresses IP

Si votre compte Snowflake restreint les connexions entrantes par adresse IP, autorisez les adresses IP de cette page :

USE ROLE ACCOUNTADMIN;
CREATE NETWORK POLICY PERPLEXITY_COMPUTER_POLICY
  ALLOWED_IP_LIST = (...US IPs from the link above...);
ALTER USER PERPLEXITY_USER SET NETWORK_POLICY = PERPLEXITY_COMPUTER_POLICY;

Étape 7 : Connecter Snowflake à Perplexity

Pour OAuth utilisateur : configuration administrateur d'abord

Si votre organisation utilise OAuth, un administrateur de l'organisation configure une fois le connecteur Snowflake (User OAuth) avant que les utilisateurs individuels puissent s'authentifier. Dans Organization Settings → Connectors → Snowflake (User OAuth), l'administrateur voit un panneau en trois étapes :

Gérer l'application OAuth — enregistrez Perplexity comme client OAuth auprès de votre compte Snowflake. Cela vous guide dans la création d'une SECURITY INTEGRATION Snowflake personnalisée et dans la copie du Client ID et du Client Secret obtenus dans Perplexity.
S'authentifier avec Snowflake (User OAuth) — l'administrateur s'authentifie une fois pour vérifier que l'intégration fonctionne de bout en bout.
Générer une Data Map (facultatif) — générez éventuellement une Data Map pour l'organisation (voir Comprendre la Data Map) et ajoutez du contexte complémentaire pour améliorer la précision.

À l'étape 1, créez l'intégration de sécurité côté Snowflake. Exécutez ceci en tant que ACCOUNTADMIN :

USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION PERPLEXITY_OAUTH
  TYPE = OAUTH
  ENABLED = TRUE
  OAUTH_CLIENT = CUSTOM
  OAUTH_CLIENT_TYPE = 'CONFIDENTIAL'
  OAUTH_REDIRECT_URI = 'https://ah.merge.dev/oauth/callback'
  OAUTH_ISSUE_REFRESH_TOKENS = TRUE
  OAUTH_REFRESH_TOKEN_VALIDITY = 7776000
  OAUTH_USE_SECONDARY_ROLES = IMPLICIT
  COMMENT = 'OAuth security integration for Perplexity';

Récupérez le Client ID et le Client Secret à coller dans Perplexity :

SELECT SYSTEM$SHOW_OAUTH_CLIENT_SECRETS('PERPLEXITY_OAUTH');

Une fois la configuration administrateur terminée, les utilisateurs individuels peuvent se connecter en suivant les étapes ci-dessous.

Se connecter (tous les utilisateurs)

Les utilisateurs ne voient que la méthode d'authentification correspondant au connecteur configuré par leur administrateur.

Accédez à Connectors dans les paramètres et trouvez le connecteur Snowflake ou Snowflake (User OAuth).
Cliquez sur Enable → Add Connector.
Authentifiez-vous à l'aide de la méthode configurée (voir ci-dessous).
Cliquez sur Allow pour terminer la configuration.

Authentification par paire de clés (connecteur Snowflake). Saisissez l'identifiant de votre compte Snowflake, votre nom d'utilisateur et votre clé privée (snowflake_computer_key.p8).

OAuth (connecteur Snowflake (User OAuth)). Vous serez redirigé vers Snowflake pour vous connecter. Il n'y a pas de sélecteur de rôle — votre session utilise votre DEFAULT_ROLE comme rôle principal, avec vos DEFAULT_SECONDARY_ROLES activés via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Si vos rôles par défaut sont déjà configurés, aucune action n'est nécessaire.

Si votre session ne contient pas de données que vous vous attendiez à voir, demandez à votre administrateur Snowflake de vérifier vos DEFAULT_ROLE et DEFAULT_SECONDARY_ROLES (voir Configuration du rôle OAuth de l’utilisateur).

Utilisation de vos données Snowflake

Une fois connecté, faites référence à vos données Snowflake dans les tâches Computer. Mentionnez des bases de données, des schémas ou des tables et Perplexity les interrogera dans le cadre de workflows en plusieurs étapes — le tout de manière asynchrone dans un environnement de bac à sable cloud sécurisé. Essayez des requêtes comme :

« Résumez les tendances de revenus du tableau des ventes du T4 et mettez en évidence les indicateurs clés »
« Trouvez tous les enregistrements clients mis à jour au cours des 30 derniers jours »
« Quels sont les produits les plus performants selon le schéma analytics ? »
« Comparez les données de pipeline de ce trimestre avec les chiffres du trimestre précédent »

Dépannage

Snowflake n’est pas activé pour votre organisation

Si vous faites partie d’une organisation Enterprise et que vous ne parvenez pas à activer le connecteur, il est possible qu’un administrateur l’ait désactivé. Contactez l’administrateur de votre organisation ou l’assistance Perplexity.

Problèmes de connexion et d’authentification

Vérifiez que les adresses IP de Perplexity sont autorisées dans la politique réseau de votre Snowflake.
Confirmez que le rôle dispose des privilèges USAGE sur les warehouses, bases de données et schémas requis.
Demandez aux utilisateurs de reconnecter le connecteur après tout changement de politique.

Erreur « Invalid private key »

Assurez-vous de coller la clé privée (snowflake_computer_key.p8), et non la clé publique. Le fichier doit commencer par -----BEGIN PRIVATE KEY-----.

Authentification refusée par la politique d’authentification actuelle

Exécutez SHOW AUTHENTICATION POLICIES en tant que ACCOUNTADMIN et assurez-vous que PERPLEXITY_USER est couvert par une politique qui inclut KEYPAIR. Si nécessaire :

CREATE AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY
  AUTHENTICATION_METHODS = ('KEYPAIR')
  CLIENT_TYPES = ('DRIVERS');
ALTER USER PERPLEXITY_USER SET AUTHENTICATION POLICY PERPLEXITY_AUTH_POLICY;

OAuth : l’utilisateur voit des données limitées après la connexion

La session OAuth utilise le DEFAULT_ROLE de l’utilisateur comme rôle principal, avec des rôles secondaires activés via OAUTH_USE_SECONDARY_ROLES = IMPLICIT. Si un utilisateur n’a pas l’accès attendu :

Confirmez que l’intégration de sécurité a OAUTH_USE_SECONDARY_ROLES = IMPLICIT.
Exécutez DESC USER <username> et vérifiez DEFAULT_ROLE et DEFAULT_SECONDARY_ROLES — la session utilise exactement ce qui y est configuré.
Si l’utilisateur n’a pas de configuration de rôle propre et que vous souhaitez qu’il accède à tout ce qui lui est accordé, définissez DEFAULT_ROLE = PUBLIC et DEFAULT_SECONDARY_ROLES = ('ALL').
Demandez-lui de se déconnecter puis de reconnecter le connecteur afin d’émettre un nouveau jeton après toute modification de ces paramètres.

La vue ACCESS_HISTORY renvoie une erreur

Confirmez que votre compte Snowflake est en édition Enterprise ou supérieure.

Privilèges insuffisants sur les vues ACCOUNT_USAGE

Vérifiez que GRANT IMPORTED PRIVILEGES a été exécuté en tant que ACCOUNTADMIN et que PERPLEXITY_ROLE est accordé à l’utilisateur.

L’authentification par paire de clés échoue

Relancez DESC USER PERPLEXITY_USER pour confirmer que l’empreinte de la clé publique est renseignée.

Si les problèmes persistent après la mise à jour de ces paramètres, contactez l’assistance Perplexity pour obtenir de l’aide.