LLM et embeddings privés

Cette page décrit, étape par étape, comment faire fonctionner l'instance avec vos propres modèles — un endpoint que vous hébergez ou que vous louez — au lieu des fournisseurs publics (OpenAI, Anthropic, Mistral…), puis comment interdire à l'instance de s'adresser à un fournisseur externe, canal par canal.

Elle est destinée à un administrateur d'instance (rôle super administrateur ou administrateur du tenant). L'essentiel se passe dans l'app d'administration, rubriques Modèles IA et RAG & Documents ; seule la création d'une base de connaissances (étape 4) se fait dans l'app Bases de connaissances.

Ce que « privé » veut dire ici

Un fournisseur personnalisé est une adresse que vous fournissez. La plateforme y envoie ses requêtes directement, avec la clé API que vous avez saisie. Rien ne transite par un fournisseur public, et le trafic reste dans le périmètre que vous contrôlez.

Deux usages sont couverts, et seulement ces deux-là :

Prérequis — à valider avant de commencer

C'est ici que la plupart des configurations échouent. Les contrôles ci-dessous sont appliqués à l'enregistrement, puis revérifiés à chaque appel : une URL qui cesserait de les respecter plus tard — un nom de domaine que vous feriez pointer vers une adresse interne, par exemple — arrêterait de fonctionner à ce moment-là, pas silencieusement.

L'endpoint doit être compatible OpenAI

Votre endpoint doit exposer les routes standard /models et /chat/completions — toutes deux indispensables à l'enregistrement — ainsi que /embeddings si vous voulez des embeddings privés.

Vous saisirez sa racine, celle qui se termine généralement par /v1, sans suffixe (une barre oblique finale est acceptée et retirée) :

• ✅ https://ia.mon-entreprise.fr/v1
• ❌ https://ia.mon-entreprise.fr/v1/models ou .../v1/chat/completions

GET {racine}/models doit renvoyer une réponse au format OpenAI, c'est-à-dire un objet contenant un tableau data dont chaque entrée porte un id. À défaut, l'enregistrement est refusé.

L'URL doit être publique et en HTTPS

L'endpoint doit répondre au chat ou aux embeddings

À l'enregistrement, la plateforme appelle /models, puis essaie plusieurs modèles de la liste : d'abord un message de test via /chat/completions, puis une vectorisation de test via /embeddings. Le fournisseur est créé dès qu'une de ces deux capacités répond. Il n'est refusé que si aucun modèle ne répond à l'une ni à l'autre.

Conséquences concrètes :

• un endpoint qui ne sert que des embeddings (TEI, infinity, un vLLM lancé sur un modèle de vectorisation) s'enregistre normalement ;
• l'ordre de la réponse /models n'a plus d'importance, y compris quand votre endpoint annonce un modèle d'embedding en premier ;
• le modèle d'embedding qui a répondu est enregistré directement en mode Embedding, avec la dimension réellement mesurée sur le vecteur de test.

Et pour l'authentification

La clé API est obligatoire, même si votre endpoint n'en vérifie aucune : saisissez alors une valeur quelconque. Elle est transmise dans l'en-tête Authorization: Bearer, stockée chiffrée, et jamais réaffichée ensuite — conservez-la de votre côté.

Étape 1 — Déclarer le fournisseur

Si l'opération échoue, rien n'est enregistré. Reportez-vous au dépannage : le message indique laquelle des vérifications a échoué.

Étape 2 — Qualifier les modèles

Les modèles découverts sont considérés comme des modèles de chat, sauf ceux que la vérification d'enregistrement a vus répondre en embeddings. Comme cette vérification est bornée à quelques modèles, c'est à vous d'indiquer lesquels des autres servent aux embeddings.

Le panneau propose également Tester la connexion (rejoue la découverte, puis le test de chat et le test d'embeddings), Actualiser les modèles, la rotation de la clé API, ainsi que l'activation ou la désactivation du fournisseur. Un fournisseur qui ne sert que des embeddings est annoncé réussi : le test d'embeddings suffit.

Étape 3 — Utiliser un modèle de chat privé

Aucune action supplémentaire n'est nécessaire. Vos modèles de chat privés apparaissent partout où un modèle se choisit (chatbot, agents, workflows), sous le fournisseur Personnalisé et sous la forme Nom du fournisseur — identifiant du modèle.

Étape 4 — Utiliser des embeddings privés

C'est l'étape la plus délicate, parce qu'elle est irréversible par base de connaissances.

Le modèle d'embedding ne se choisit pas sur la base de connaissances : il se choisit sur le preset RAG dont elle hérite, et il est figé au moment de la première indexation.

Voir Presets pour tout ce que borne un preset, et Espaces de recherche pour vérifier quel modèle sert réellement à chaque base.

Étape 5 — Interdire les sorties externes

Tant que des fournisseurs publics restent configurés, un utilisateur peut encore choisir un modèle externe. La page Modèles IA → Confidentialité IA ferme cette porte, canal par canal.

Une sixième bascule, Geler l'ingestion sur les bases à embeddings externes, bloque l'ajout de documents dans les bases restées sur un modèle externe sans couper leur recherche. C'est le geste intermédiaire à privilégier pendant une migration : plus rien de neuf ne sort, l'existant continue de répondre.

L'ordre sûr est donc :

Dépannage

Les messages apparaissent sous la forme titre puis détail : c'est le détail qui identifie la cause, plusieurs causes différentes partageant le même titre.

Les détails ci-dessous sont les mêmes quel que soit le geste : à l'ajout d'un fournisseur, à la rotation de la clé, à l'actualisation des modèles — où le détail reste affiché sous le fournisseur jusqu'à la prochaine vérification réussie — et dans le résultat de Tester la connexion.

Et ensuite ?

• Fournisseurs — les fournisseurs publics et leurs clés.
• Modèles — activer les modèles du catalogue et désigner les modèles par défaut.
• Presets — l'enveloppe de gouvernance héritée par les bases de connaissances.