Fournisseurs IA

Tale ne répond à aucun prompt tant que ton organisation ne détient pas d’identifiants valides pour au moins un fournisseur IA. Paramètres > Fournisseurs IA est l’endroit où vivent ces identifiants, et le seul où on peut en créer. Les Administrateurs et les Développeurs ouvrent la page ; tous les autres en rencontrent le résultat plus tard, sous la forme de la liste de modèles qu’ils peuvent choisir dans le chat, sur un agent ou sur une étape de workflow.

Connectors et identifiants

Deux choses distinctes se rejoignent sur cette page, et les distinguer rend tout le reste évident.

Un connecteur est ce que la plateforme sait d’avance d’un fournisseur : le dialecte réseau qu’il parle, l’endpoint sur lequel il répond, d’où vient sa liste de modèles, et quelles méthodes d’authentification il accepte. Les connecteurs sont livrés avec la plateforme. Tu ne peux ni en ajouter, ni en modifier, ni en supprimer depuis l’interface, et une mise à niveau peut en apporter d’autres.

Les identifiants sont ta moitié — la part qui autorise réellement un appel. Tu en enregistres autant que nécessaire par connecteur : une clé de production à côté d’une clé de test, une clé par service, une variable gérée par les ops à côté d’une clé que tu fais tourner à la main. Chacun porte un nom, une méthode d’authentification, une liste de modèles autorisés facultative et un état d’activation — et l’un d’eux est le défaut.

Voici les connecteurs livrés aujourd’hui :

Ce que la page affiche

Identifiants est un tableau de ce que ton organisation détient réellement — une ligne par identifiant stocké, pas une par fournisseur livré. Une ligne montre son nom, le fournisseur qu’il authentifie, sa méthode d’authentification et ses coordonnées : un aperçu masqué de la clé stockée ou le nom de la variable d’environnement qui la porte, plus l’URL d’endpoint propre à l’identifiant là où le fournisseur en réclame une et le nombre de modèles que sa liste autorise. Un badge Par défaut marque celui vers lequel les requêtes retombent, un badge Désactivé ceux qui sont coupés. Le menu d’actions de la ligne porte tout le reste.

Deux avertissements apparaissent ici plutôt que dans une boîte de dialogue. Un fournisseur dont le catalogue de modèles n’a pas pu être récupéré le dit sur chaque ligne qui en dépend — une clé qui fonctionne ne sert à rien tant que Tale ignore quels modèles le fournisseur sert. Et un fournisseur qui a des identifiants mais aucun défaut est nommé au-dessus du tableau : les requêtes ne peuvent pas en choisir un automatiquement tant que tu n’en promeus pas un.

Sous le tableau, Harnesses indique comment chaque harness de code se résout pour ton organisation. La section est en lecture seule ; ce sont les identifiants au-dessus qui la changent.

Ajouter des identifiants

1. 1

   Choisir le fournisseur

   Ajouter des identifiants ouvre le catalogue livré. Les fournisseurs pour lesquels tu détiens déjà un identifiant viennent en premier, sous Configuré ; tout le reste suit en dessous. Chaque entrée nomme ses faits réseau — le format d’API et l’hôte de l’endpoint, comme API compatible OpenAI · openrouter.ai, ou endpoint défini par identifiant — et le nombre de modèles que son catalogue contient. La recherche réduit la liste ; un choix mène au formulaire, et Retour en ressort.

   Comme le formulaire appartient au fournisseur choisi, il ne propose que ce que celui-ci accepte — on ne te demande jamais une URL de base que la plateforme connaît déjà.

2. 2

   Choisir la méthode d’authentification

   La méthode change le reste du formulaire : un champ secret pour Clé API et Clé d’abonnement, un nom de variable pour Variable d’environnement, le formulaire complet du courtier pour Courtier d’abonnement.

3. 3

   Le nommer pour la personne qui lira ensuite

   Nom est ce que tous les écrans suivants montrent à la place du secret. Nomme-le pour son usage — Clé de production, Équipe finance, Géré par les ops — parce que c’est cette étiquette que quelqu’un choisira dans une liste des mois plus tard.

4. 4

   Décider si tu restreins

   Modèles autorisés est facultatif. Laisse le champ vide et l’identifiant peut utiliser tout le catalogue du connecteur ; remplis-le et il reste confiné à ta sélection.

Clé API

Colle le secret dans Clé API. Tale le stocke chiffré et ne le réaffiche jamais — la ligne montre un aperçu masqué, pas la clé. Pour faire tourner la clé, ouvre le menu de la ligne et choisis Remplacer la clé API ; le remplacement prend effet partout où ces identifiants servent, immédiatement.

Variable d’environnement

Ici la clé n’entre jamais dans Tale. Elle reste sur le déploiement, et l’identifiant n’enregistre que le nom de la variable qui la porte. Tu ne saisis que le suffixe ; le préfixe réservé TALE_PROVIDER_KEY_ est fixe et ne peut pas être effacé.

Abonnements et courtiers

Deux méthodes couvrent les abonnements plutôt que les clés API facturées à l’usage. Clé d’abonnement stocke directement le secret d’abonnement d’un fournisseur ; un abonnement Nous Portal en est un cas livré. Courtier d’abonnement pointe vers un endpoint qui distribue un pool de jetons OAuth rotatifs — la forme qu’utilise un abonnement Claude.

Le formulaire du courtier demande l’Endpoint du courtier et sa Méthode HTTP, puis comment Tale s’authentifie auprès du courtier sous Authentification du courtier : Aucune, Jeton Bearer ou En-tête personnalisé, avec un Nom de l’en-tête et le Secret du courtier, ou Secret depuis une variable d’environnement quand ce sont tes ops qui le détiennent. Le reste décrit la réponse : le Chemin du tableau de jetons, le Champ du jeton, la Variable d’environnement cible dans laquelle le jeton choisi est injecté, et une Sélection du jeton parmi Aléatoire, Premier utilisable ou Round-robin. Avancé porte le réglage fin : Champ de statut, Valeur de statut actif, Champ d’expiration, Délai de la requête (ms), Taille max de la réponse (octets) et Marge de sécurité avant expiration (ms).

Les connecteurs dont l’endpoint est défini par identifiant

Azure OpenAI n’a pas d’endpoint fixe, parce que chaque ressource Azure sert le sien, sous la forme https://<resource>.openai.azure.com/openai/v1. L’en-tête de sa section indique que l’endpoint est défini par identifiant, et sa boîte de dialogue ajoute un champ URL de l’endpoint pour que chaque identifiant porte la ressource à laquelle il appartient.

Azure ne livre pas non plus de catalogue de modèles, et la raison mérite d’être connue avant de remplir le formulaire : sur Azure, l’id de modèle dans une requête est le nom de déploiement que tu as choisi dans la ressource, ce que Tale ne peut pas deviner. Saisis ces noms dans les Modèles autorisés de l’identifiant, séparés par des virgules. Sans eux, l’identifiant ne rend aucun modèle disponible.

Choisir les identifiants par défaut

Une requête qui ne nomme aucun identifiant utilise le défaut du connecteur. C’est le cas de la majeure partie du trafic, donc le défaut est l’identifiant sur lequel le travail ordinaire doit atterrir — la clé de production partagée, pas l’expérimentation.

Ouvre le menu d’une ligne et choisis Définir par défaut. Un seul identifiant par connecteur tient ce rôle, et en promouvoir un autre le déplace. Un identifiant désactivé ne peut pas devenir le défaut. Laisse un connecteur sans défaut et la plateforme ne choisira pas à ta place : elle le dit sur la page, et les requêtes qui ne nomment pas d’identifiant n’ont plus rien à résoudre.

Restreindre ce qu’un identifiant peut appeler

Modèles autorisés limite un identifiant à une partie des modèles de son connecteur. Avec un catalogue derrière, le champ est une sélection multiple cherchable ; sans catalogue, c’est une liste d’ids en texte libre. Laisse-le vide et tout le catalogue reste ouvert. Remplis-le et la ligne affiche le compte, tandis que ce qui n’y figure pas cesse de se résoudre via cet identifiant.

Garder les catalogues de modèles à jour

Actualiser les catalogues siège dans l’en-tête de la page et recharge chaque catalogue en ligne et rend une ligne par connecteur — le nombre de modèles trouvés, ou l’erreur rencontrée, pour qu’un fournisseur en panne soit nommé plutôt qu’ignoré en silence.

Les catalogues livrés avec la plateforme n’en ont pas besoin : quand chaque connecteur en a un, la carte annonce qu’il n’y a rien à actualiser. Les catalogues en ligne sont mis en cache entre deux actualisations et aucune synchronisation ne tourne en arrière-plan — un modèle publié ce matin apparaît quand quelqu’un appuie sur le bouton.

Désactiver et supprimer des identifiants

Désactiver coupe un identifiant en conservant sa configuration et ses modèles autorisés. Sers-t’en quand une clé est suspecte, qu’un quota est épuisé ou qu’un service est en pause — le réactiver tient en un clic et rien n’est à ressaisir.

Où cela s’inscrit

Cette page est le sol sur lequel tout le reste repose : un agent, une réponse de chat, une étape de workflow, un embedding pour la base de connaissances se résolvent tous vers un modèle, et un modèle n’est joignable que si des identifiants de cette page peuvent l’appeler. Ce qu’il en reste côté choix est couvert par le Catalogue de modèles, la couche de gouvernance qui restreint encore par Contenu et modèles, et les variables de déploiement qu’un opérateur fournit par Fournisseurs.