Connecter Tale à des services externes

Utilise un connector lorsque Tale doit lire ou modifier les données d’un service externe. Le connector définit les actions prises en charge. Les identifiants permettent à Tale d’accéder au compte choisi. Les Développeurs, Admins et Propriétaires les gèrent dans Paramètres > Connectors.

Choisir la connexion selon la tâche

Les cartes du catalogue déployé affichent les actions et méthodes d’authentification actuelles. Ces définitions sont fournies avec la plateforme. Ajouter un compte n’installe pas de code de connector arbitraire.

Les imports de connaissances utilisent l’indexation des documents. OneDrive et SharePoint passent par l’import dans Connaissances > Documents, avec un consentement individuel, plutôt que par un connector d’organisation distinct. Monter les documents Tale sur ton appareil correspond au sens inverse : utilise WebDAV.

Ajouter le compte voulu

Choisis Ajouter des identifiants, recherche le service et ouvre sa carte. Les connectors déjà configurés apparaissent en premier, mais tu peux ajouter un autre compte pour le même service. Le formulaire demande l’authentification prise en charge.

Le champ Nom est prérempli avec le nom du connector. Si tu ajoutes plusieurs comptes pour le même service, remplace-le par un nom qui indique l’usage, par exemple Boîte support ou Bot de publication. Utilise ceux du service externe, pas une clé API Tale. Pour OAuth, connecte-toi chez le fournisseur avec le compte à ajouter et termine le consentement. Chaque connexion ajoute de nouveaux identifiants, nommés d’après le connector puis numérotés (Gmail, puis Gmail 2) ; Slack en garde un seul jeu par espace. Renomme les nouveaux identifiants pour distinguer les comptes. Si le parcours ne démarre pas, un administrateur doit peut-être configurer l’app OAuth d’abord.

Confluence, GlitchTip et Shopify demandent une URL de l'instance pour chaque compte. Utilise l’origine du site Atlassian, l’origine de l’instance GlitchTip comme https://app.glitchtip.com ou l’adresse myshopify.com de la boutique, pas une page quelconque ni le domaine destiné aux clients. Une instance GlitchTip auto-hébergée doit aussi être autorisée par la politique des hôtes du connector. Identifiants des connectors explique les champs, la reconnexion et le renouvellement des secrets.

Déterminer le compte utilisé

Une action utilise les identifiants explicitement nommés, ou ceux par défaut du connector en l’absence de nom. Un seul compte par connector peut être défini comme compte par défaut. Sans compte par défaut, un appel sans nom échoue même si d’autres identifiants existent. Si tu supprimes le compte par défaut, les plus anciens identifiants actifs restants de ce connector deviennent le compte par défaut ; la confirmation de suppression les nomme d’abord. Une étape HTTP fait exception : celle qui ne nomme aucun identifiant n’en porte aucun, jamais ceux par défaut.

Deux boîtes support correspondent par exemple à deux lignes. Donne-leur des noms distincts et examine les données résolues du workflow avant une exécution réelle. Le compte par défaut est utilisé lorsque l’action ne nomme pas un autre compte. Les opérations de courrier conçues pour parcourir tous les comptes actifs constituent un cas séparé.

Désactiver des identifiants conserve leur configuration mais empêche leur usage. Remplacer leur secret renouvelle la connexion derrière les références existantes. Vérifie les workflows concernés avant une désactivation, une suppression ou un changement de compte par défaut.

Distinguer lectures et écritures

Les automatisations utilisent les actions comme nœuds de workflow. Chaque action définit son schéma d’entrée, sa sortie et son effet de lecture ou d’écriture. GlitchTip et Jev decisions ne font que lire : l’import GlitchTip crée des tâches Tale sans jamais modifier l’issue d’origine, et une décision Jev répond à chaque question avec ses probabilités sans rien écrire. Chaque décision est facturée au compte OpenRouter dont la clé figure dans les identifiants. Les essais simulent les réponses. Lors d’une exécution réelle, une écriture peut envoyer un message ou modifier des données externes et suit la politique d’approbation de l’organisation.

Les agents de projet dont les connectors sont configurés reçoivent les actions de lecture prises en charge via le broker de Tale. Il conserve ces identifiants hors de la sandbox et renvoie les résultats. Il refuse les écritures des connectors. Les outils GitHub directs et les secrets explicitement accordés suivent d’autres voies et demandent une vérification distincte.

Ajouter des identifiants n’ajoute pas librement des outils à l’assistant de chat ordinaire. Utilise les automatisations pour un déroulement défini et les agents de projet pour le travail en sandbox.

Si le service manque

Un agent de projet peut appeler un service depuis sa sandbox si son environnement d’agent dispose des outils adaptés et d’un secret explicitement accordé. Un nœud transform transforme uniquement des données et ne peut pas appeler une API externe. Vérifie les permissions et les effets attendus avant de choisir une intégration directe.

Si l’application externe doit appeler Tale, utilise l’API REST ou le point d’accès MCP. MCP et intégrations personnalisées explique la distinction.