Intégrations

Des modèles conformes au RGPD pour les agents que vous construisez déjà

Frontière AI est un endpoint compatible OpenAI : toute plateforme d'agents qui permet de changer la base URL peut donc tourner sur une infrastructure européenne. Trois valeurs à modifier — base URL, clé API, identifiant de modèle — et l'inférence part chez OVHcloud, Scaleway ou un serveur UE dédié au lieu d'un provider américain. La compatibilité, c'est la moitié facile. Celle qui décide si un agent fonctionne, c'est l'appel de fonctions : on l'a donc mesurée, un appel réel par modèle le 6 août 2026, et 12 des 13 modèles en ligne renvoient bien un appel d'outil valide.

Les trois valeurs

Toutes les intégrations de cette page se ramènent aux trois mêmes réglages. Quel que soit le nom que leur donne votre plateforme, voici ce qu'on y met :

Base URL   https://getfrontiereai.eu/api/v1
API key    sk-front-…            (dashboard → API keys)
Model ID   glm-5.2               (GET https://getfrontiereai.eu/api/v1/models)

L'identifiant de modèle, c'est le champ id de notre endpoint de catalogue — public, sans clé : ouvrez-le dans un navigateur et copiez celui qui vous intéresse. Il ne liste que les modèles en ligne, donc ce que vous y trouvez est appelable immédiatement.

Guides par plateforme

Deux plateformes ont assez de particularités pour mériter un pas-à-pas écrit — où se cache le champ, quel nœud utiliser, et quels réglages par défaut vont vous mordre :

Ce qu'un agent exige d'un fournisseur de modèles

Une intégration de chat demande du texte en entrée et du texte en sortie. Un agent demande davantage — et c'est précisément là que beaucoup d'endpoints « compatibles OpenAI » s'arrêtent sans le dire.

D'abord l'appel de fonctions. Un agent qui ne sait pas émettre d'appel d'outil est un chatbot : pas de recherche, pas de consultation de base, aucune action. Frontière AI relaie tools et tool_choice tels quels : la réponse dépend donc entièrement du modèle et du provider qui le sert — raison pour laquelle on l'a mesurée plutôt que supposée. Ensuite, un streaming qui rapporte quand même l'usage : nos flux portent l'objet usage dans le dernier chunk avant [DONE], donc une étape d'agent streamée est facturée aussi exactement qu'une étape bloquante. Enfin, de la patience : les modèles de raisonnement réfléchissent plusieurs minutes, et la plupart des frameworks d'agents sont livrés avec des timeouts très inférieurs.

Le tableau ci-dessous est le résultat de cette mesure, pas une recopie des fiches modèle. Chaque entrée a reçu un appel réel portant un outil get_weather ; cinq d'entre elles ont eu droit à l'aller-retour complet, avec renvoi du résultat de l'outil et vérification que la réponse finale contenait bien la valeur transmise.

Appel d'outils, mesuré

Mesuré le 6 août 2026, un appel par modèle. Qwen2.5-VL 72B est le seul refus, et il vient de son provider, pas du modèle : OVHcloud répond HTTP 400, « feature 'tool calls' is not currently supported ». Utilisez-le pour l'analyse d'images, et prenez un autre modèle pour piloter l'agent. Le même résultat est lisible par une machine : chaque entrée de GET /api/v1/models porte un booléen tool_calling, qu'un agent peut filtrer au démarrage au lieu de le découvrir en production.

Embeddings et recherche documentaire

Un agent qui répond à partir de vos propres documents a besoin de deux modèles différents : un pour transformer le texte en vecteurs, un pour rédiger la réponse. POST /api/v1/embeddings est compatible OpenAI et sert les modèles d'embedding hébergés en UE ci-dessous : les deux moitiés restent donc sur une infrastructure européenne — jusqu'ici, la moitié « recherche » devait s'acheter ailleurs.

Modèles de chat et d'embedding forment deux catalogues distincts : un modèle de chat envoyé sur /embeddings répond 404, et inversement. GET /api/v1/models?kind=embedding ne rend que les valides. Vérifiez la dimension avant d'indexer quoi que ce soit — changer pour un modèle dont le vecteur n'a pas la même longueur oblige à tout reconstruire.

Ce qu'on ne sert pas

Un manque à connaître avant de brancher quoi que ce soit, parce qu'il échoue en 404 plutôt qu'en message utile :

Tout le reste de ce qui parle OpenAI

Pas de guide dédié, mais on a ouvert la documentation de chaque éditeur et relevé où se trouve le réglage, avec la date de lecture :

Ces lignes disent qu'on a localisé le réglage dans la documentation de l'éditeur — pas qu'on a fait tourner un agent de bout en bout sur cette plateforme. Les deux guides ci-dessus, si.

Ce que ça change, et ce que ça ne change pas

Changer la base URL déplace l'inférence. Ça ne déplace pas l'orchestration. Votre plateforme continue de tourner là où elle tourne : ses serveurs voient les prompts, les appels d'outils et l'historique de conversation avant nous, et elle conserve la juridiction qui est la sienne. Si vous auto-hébergez votre plateforme d'agents en Europe et appelez un modèle marqué souverain, toute la chaîne est européenne. Si votre plateforme est un service américain managé, le modèle est la seule partie que ça règle.

C'est une vraie amélioration, et une amélioration partielle — autant dire laquelle des deux vous avez achetée à votre DPO. C'est la même honnêteté par modèle qui justifie le drapeau sovereign de chaque entrée : les modèles servis via une infrastructure américaine sont étiquetés accès rapide, jamais souverains, même quand la région est européenne — une société américaine reste atteignable par un tribunal américain où que soient ses serveurs.

RGPD contre CLOUD Act →

FAQ