Fournisseurs et modèles — Documentation

Une destination est un modèle de langage que Cortex sait joindre : un fournisseur, un point d’accès (endpoint), un modèle et les règles qui s’y appliquent. Vos employés ne voient que les destinations que vous leur ouvrez, et chaque message passe par le filtrage DLP avant de les atteindre. Cette page couvre la configuration des destinations, des modèles, du routage, du cache et de la recherche web.

Ce qu’est une destination

Dans la console d’administration, « Destinations » liste vos destinations : « Nom », « Type », « Modèle », « Profil DLP », « Rôles » et « Statut ». Le « Type » affiche « Local » pour un moteur que vous hébergez (ollama, lm_studio, vllm, custom_local) et « API externe » pour un service en ligne ; il découle du fournisseur choisi. Une destination déjà utilisée par des conversations ne peut pas être supprimée : « Désactiver » est alors la voie à suivre.

Capture de Cortex : la liste des destinations LLM avec une destination locale « Qwen 3.5 9B », son modèle, son profil DLP complet, ses rôles et ses boutons d’action — Une destination locale : type, modèle, profil DLP, rôles autorisés et actions.

Ajouter une destination

Ouvrez « Destinations », puis « Nouvelle destination ».
Choisissez le « Fournisseur » dans le catalogue (openai, anthropic, azure_openai, google_gemini, mistral, groq, together_ai, openrouter, deepseek, xai, ollama, lm_studio, vllm, ou custom_openai, custom_anthropic et custom_local pour un service compatible).
Donnez un « Identifiant (slug) » (minuscules, chiffres et traits d'union) et un « Nom d'affichage ». L’identifiant ne se modifie plus après la création.
Indiquez le « Modèle », ou cliquez sur « Découvrir les modèles » pour le choisir dans la liste que le point d’accès rapporte.
Renseignez l’« Endpoint » : facultatif quand le fournisseur a une adresse par défaut, obligatoire pour azure_openai et les fournisseurs custom_*. La « Clé d'API » est obligatoire pour les fournisseurs externes du catalogue (openai à xai).
Choisissez le « Profil DLP » (« DLP complet » par défaut), cochez ou non « Cache des réponses », et cochez au moins un des « Rôles » autorisés (« Employé » par défaut).
Cliquez sur « Créer ». La fenêtre reste ouverte et s’enrichit : le bouton de test de connexion (icône de prise) à côté de l’« Endpoint » devient actif, et les sections « Modèles autorisés » et « Routage » ainsi que l’interrupteur « Recherche web » apparaissent.

Autoriser des modèles

Dans « Modifier », la section « Modèles autorisés » ne liste d’abord que les modèles déjà autorisés (au départ, le modèle par défaut) : cliquez sur « Découvrir les modèles » pour afficher ceux que le point d’accès rapporte. Une case autorise chaque modèle, un bouton radio « défaut » désigne celui qui sert par défaut, et « Filtrer les modèles… » aide quand la liste est longue. Pour chaque modèle autorisé, trois cases déclarent ses capacités : « Vision », « Outils » et « Raisonnement ». C’est vous qui les déclarez : Cortex ne les détecte pas.

Routage et bascule

La section « Routage » d’une destination règle trois choses.

« Répartition de charge » : « Tour de rôle », « Pondérée » (selon le poids) ou « Moins chargée » (la plus faible charge en cours dans la passerelle). Elle choisit entre la destination elle-même et ses répliques actives.
« Répliques » : d’autres points d’accès pour le même modèle (« Ajouter une réplique »), chacun avec son « Endpoint », sa « Clé d'API », son « Poids » de 1 à 100 et un interrupteur.
« Chaîne de repli » : jusqu’à cinq autres destinations, dans l’ordre (« Ajouter un repli… », puis « Enregistrer »). La chaîne n’est pas transitive : le repli d’un repli n’est pas suivi.

Quand un fournisseur échoue, Cortex retente sur la même destination (deux essais au total par défaut) avec une attente croissante, puis passe au repli suivant. Seules les erreurs jugées réessayables sont retentées ; les autres passent directement au repli. Une fois la réponse commencée, Cortex ne change plus de destination. Chaque bascule est inscrite au journal d’audit. Les essais se règlent dans le .env :

ROUTING_RETRY_MAX_ATTEMPTS=2   # essais par destination, de 1 à 5
ROUTING_RETRY_BASE_MS=200      # attente de base avant un nouvel essai, de 0 à 5000

Cache des réponses

Le cache réutilise une réponse quand la même requête revient. Il faut deux autorisations : le déploiement l’active (désactivé par défaut), puis chaque destination garde sa case « Cache des réponses » cochée.

Une réponse n’est retrouvée que pour la même destination, le même modèle, les mêmes paramètres et les mêmes messages caviardés : la clé est calculée sur les jetons, jamais sur vos valeurs réelles, et les entrées sont chiffrées avec la clé du tenant.
Sa durée de vie est la plus courte entre CACHE_TTL_SECONDS et la rétention des conversations.
Une requête avec recherche web n’utilise jamais le cache, et les rôles de CACHE_EXCLUDED_ROLES ne le lisent ni ne l’alimentent.

CACHE_ENABLED=true
CACHE_BACKEND=memory     # ou redis, avec REDIS_URL

Ces variables se changent dans le .env à la racine, suivies d’un docker compose up -d gateway, qui recrée le conteneur. Le moteur redis s’appuie sur le profil compose cache.

Recherche web

La recherche est exécutée par la passerelle, pas par le modèle. Elle demande trois choses.

Le déploiement : WEB_SEARCH_ENABLED=true et WEB_SEARCH_BASE_URL dans le .env, avec WEB_SEARCH_ENGINE (searxng par défaut, ou brave, qui exige WEB_SEARCH_API_KEY), puis recréez le conteneur de la passerelle (docker compose up -d gateway). Tant que WEB_SEARCH_ENABLED n’est pas true, la page « Recherche web » affiche « La recherche web est désactivée par la configuration du déploiement. » et rien n’y est modifiable ; avec true mais une WEB_SEARCH_BASE_URL absente ou invalide, la passerelle refuse de démarrer.
La destination : dans « Modifier », l’interrupteur « Recherche web ».
La page « Recherche web » de la console, décrite ci-dessous.

« Moteur de recherche » : le « Moteur », l’« Hôte » et la « Résolution d'adresse » (« Publique », « Privée » ou « Inconnue »). Un moteur « Non attesté » est traité comme externe. Si le moteur résout vers une adresse privée, « Attester le moteur… » ouvre une confirmation en deux étapes (une case et le mot « ATTESTER ») ; un moteur public ne peut pas être attesté. « Retirer l'attestation » l’annule.
« Domaines autorisés » : si la liste n’est pas vide, seuls les résultats de ces domaines et de leurs sous-domaines sont gardés.
« Domaines bloqués » : les résultats de ces domaines sont toujours écartés. Entrez des domaines nus (exemple.com), sans joker ni port.
« Politiques de requête par rôle » : elles jouent quand le message contient encore des éléments caviardés. « Bloquer » refuse la recherche, « Dégradée » retire les termes protégés de la requête, « En clair » envoie le texte original, mais seulement vers un moteur attesté. Le rôle le plus strict l’emporte ; sans politique explicite, un rôle vaut « Bloquer ».