Connecter un endpoint IA auto-hébergé

Un endpoint personnalisé permet à l’assistant Boldo d’utiliser un modèle d’IA accessible via votre propre service. Il change le fournisseur du modèle dans Boldo ; il est distinct de l’accès accordé à un client MCP externe.

Les Administrateurs et le Propriétaire peuvent configurer un endpoint personnalisé par organisation si l’offre comprend l’IA et les endpoints personnalisés.

Préparer le service

Le service doit être accessible publiquement en HTTPS depuis Boldo. HTTP, localhost, adresses de réseau privé et redirections sont refusés. Un service accessible seulement sur votre ordinateur ou par VPN ne peut pas être utilisé directement.

Obtenez l’URL de base de l’API, le nom exact du modèle ou déploiement, l’authentification et les capacités réelles : contexte, images et outils. Déclarer une capacité dans Boldo ne l’ajoute pas au modèle.

Configurer la connexion au service IA

1. Ouvrez Gestion de l’organisation > Assistant IA > Configuration.
2. Dans Configuration de l’IA, cliquez sur Ajouter un modèle auto-hébergé.
3. Choisissez le Type d’endpoint : Compatible OpenAI ou Azure OpenAI.
4. Remplissez les champs du service décrits ci-dessous, avec la clé si nécessaire.
5. Renseignez éventuellement un nom affiché et ouvrez Headers personnalisés > Ajouter des headers, puis utilisez Ajouter un header pour chaque entrée.
6. Saisissez la Fenêtre de contexte (tokens) et réglez Le modèle peut lire les images et Le modèle gère les appels d’outils selon le service.
7. Cliquez sur Tester et lisez le résultat. Pour un service compatible, Modèles détectés (cliquez pour utiliser) aide à choisir le nom exact.
8. Cliquez sur Connecter pour enregistrer. Le test seul n’enregistre pas l’endpoint.
9. Choisissez le modèle personnalisé dans Modèle par défaut si vous souhaitez le recommander par défaut.
10. Ouvrez l’assistant, sélectionnez le modèle et vérifiez le serveur indiqué dans le sélecteur. Testez une vraie réponse. Si les outils ou images sont activés, vérifiez également une tâche adaptée.

Type d’endpoint	Informations nécessaires
Compatible OpenAI	URL de l’endpoint, comme https://ai.example.com/v1, et Nom du modèle. Une clé est nécessaire seulement si le service l’exige.
Azure OpenAI	URL de la ressource, Nom du déploiement et clé API. Réglez Version de l’API (optionnelle) selon votre déploiement.

Pour un endpoint compatible, saisissez l’URL de base, sans le chemin complet /chat/completions. Boldo utilise /models pour son test de connexion et /chat/completions pour les conversations. Pour Azure, fournissez URL de ressource et nom de déploiement dans leurs champs respectifs.

Azure exige une clé, même si le champ générique paraît facultatif. Un nom de modèle en conflit avec un identifiant réservé du catalogue intégré est refusé. La fenêtre de contexte doit être un entier positif accepté par le formulaire et refléter la vraie limite du fournisseur.

Comprendre ce que vérifie le bouton Tester

Pour un service compatible OpenAI, Tester interroge l’endpoint des modèles. Une réponse HTTP réussie établit accessibilité et authentification ; elle ne prouve pas génération, streaming, images ou appels d’outils. Une liste de modèles détectés vide ne signifie pas nécessairement un échec du test.

Pour Azure, Tester envoie une génération minimale au déploiement configuré. Le fournisseur peut facturer cet appel. Le test vérifie ainsi le déploiement, sans certifier chaque capacité du modèle.

Un résultat invérifiable ne prouve pas une clé valide. Connecter contrôle la configuration et la destination, mais ne remplace pas une conversation réussie. Si le test passe et le chat échoue, vérifiez nom du modèle, chemins et capacités nécessaires.

Modifier les secrets enregistrés

Les secrets enregistrés sont masqués. En modification à la même adresse, laisser la clé vide conserve la clé stockée. Sur un endpoint Compatible OpenAI, utilisez Supprimer la clé pour la retirer. Azure exige une clé et ne propose pas cette commande. Pour un header existant, une valeur vide conserve le secret ; supprimer sa ligne retire le header.

Si le serveur ou le chemin de l’URL change, ressaisissez clé et secrets de headers comme demandé. Boldo ne transmet pas automatiquement les anciens secrets à une nouvelle adresse.

Pour un endpoint compatible, le champ clé fournit l’authentification Bearer et prévaut sur un header Authorization personnalisé. Sans clé dédiée, les headers peuvent fournir l’authentification du service. Pour Azure, le champ clé fournit api-key ; un header personnalisé ne remplace pas ce champ requis.

Enregistrez la configuration modifiée, puis testez à nouveau le modèle choisi. Ne collez pas de secrets dans une conversation d’assistance ou un ticket.

Retirer ou dépanner l’endpoint

Utilisez Supprimer le modèle et confirmez pour retirer sa configuration Boldo. Cela ne supprime ni le service distant ni l’historique des conversations. Revérifiez ensuite Modèle par défaut ; un choix indisponible revient à Recommandation Boldo. Les secrets restent supprimables après un changement d’offre retirant leur ajout.

Problème	Suite à donner
HTTP ou adresse privée refusée	Fournir un endpoint HTTPS public admissible.
Redirection refusée	Utiliser directement l’URL de base finale.
Authentification refusée par le fournisseur	Vérifier la clé dédiée et les headers d’authentification.
Clé illisible	Ressaisir le secret.
Test réussi mais chat en échec	Vérifier modèle/déploiement exact, chemin API, compatibilité des réponses et capacités déclarées.
Modèle capable de répondre mais pas d’utiliser les outils Boldo	Vérifier sa prise en charge réelle des appels d’outils et l’activation de cette capacité.

Un modèle sans outils peut converser mais ne peut pas utiliser les outils de l’assistant Boldo ; les actions qui les exigent peuvent le refuser. L’usage du fournisseur personnalisé ne consomme pas le budget IA hébergé inclus dans Boldo. Facturation et limites du service restent applicables, avec les contrôles d’accès et d’offre de Boldo.