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, sur les modèles étiquetés souverains UE, l'inférence part chez OVHcloud ou Scaleway au lieu d'un fournisseur américain ; les modèles en accès rapide sont servis par des sociétés américaines, et étiquetés comme tels. La compatibilité, c'est la moitié facile. Celle qui décide si un agent fonctionne, c'est l'appel de fonctions : on la mesure donc au lieu de la supposer, un appel réel par modèle, et 26 des 26 modèles en ligne mesurés à ce jour 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

Chaque guide donne les noms exacts des champs dans l'outil, les réglages par défaut qui piègent et les modèles à choisir. Un badge vert signifie que nous l'avons fait tourner contre la passerelle ; les autres suivent la documentation officielle de l'éditeur, datée sur la page :

n8n

Automatisation de workflows

Pointez l'identifiant OpenAI sur Frontière AI et le nœud AI Agent tourne sur notre catalogue — sur une infrastructure hébergée en UE si vous choisissez un modèle étiqueté souverain UE, appels d'outils compris.

Testé de bout en boutLire le guide →

LiteLLM

Passerelle LLM

Ajoutez Frontière AI au SDK ou au proxy LiteLLM avec le préfixe openai/ : des modèles ouverts hébergés en UE derrière vos clés virtuelles et budgets existants, avec suivi des dépenses et le fournisseur de chaque appel conservé dans les en-têtes.

Testé de bout en boutLire le guide →

Microsoft Foundry

Plateforme d'agents

Une connexion « bring your own model » rend chaque modèle du catalogue sélectionnable dans Foundry Agent Service, l'inférence restant en Europe sur les modèles souverains.

Testé de bout en boutLire le guide →

Claude Code

Agent de code

Pointez Claude Code sur l'endpoint compatible Anthropic de Frontière AI et faites-le tourner sur des modèles ouverts hébergés en UE, outils compris.

Testé de bout en boutLire le guide →

OpenCode

Agent de code

Déclarez Frontière AI comme fournisseur compatible OpenAI dans opencode.json et codez depuis le terminal avec des modèles ouverts hébergés en UE.

D'après la doc officielleLire le guide →

Cline

Agent de code

Le fournisseur OpenAI Compatible de Cline pointé sur Frontière AI : l'agent VS Code et sa CLI sur des modèles ouverts hébergés en UE.

D'après la doc officielleLire le guide →

Kilo Code

Agent de code

Frontière AI comme fournisseur personnalisé dans kilo.jsonc : Kilo Code dans VS Code, JetBrains ou la CLI sur des modèles ouverts en UE.

D'après la doc officielleLire le guide →

Continue

Assistant de code

Ajoutez les modèles de Frontière AI au config.yaml de Continue avec provider openai et apiBase, pour le chat, les éditions et le mode agent.

D'après la doc officielleLire le guide →

Aider

Agent de code

Aider, le binôme de programmation du terminal, sur des modèles ouverts hébergés en UE : deux variables d'environnement et le préfixe openai/.

D'après la doc officielleLire le guide →

Zed

Éditeur de code

Ajoutez Frontière AI comme fournisseur compatible OpenAI dans settings.json de Zed et pilotez le panneau d'agent avec des modèles ouverts hébergés en UE.

D'après la doc officielleLire le guide →

goose

Agent de bureau et CLI

Frontière AI comme fournisseur personnalisé de goose, bureau ou CLI : ses extensions tournent sur des modèles ouverts hébergés en UE.

D'après la doc officielleLire le guide →

Hermes Agent

Agent personnel

Hermes Agent de Nous Research sur un endpoint personnalisé : la base URL de Frontière AI dans config.yaml, des modèles ouverts en UE derrière.

D'après la doc officielleLire le guide →

OpenClaw

Agent personnel

Ajoutez Frontière AI comme fournisseur de modèles dans openclaw.json et faites tourner vos agents OpenClaw auto-hébergés sur des modèles ouverts hébergés en UE.

D'après la doc officielleLire le guide →

LangChain

Framework d'agents (Python)

ChatOpenAI et OpenAIEmbeddings pointés sur Frontière AI : vos applications et agents LangChain sur des modèles ouverts hébergés en UE.

Testé de bout en boutLire le guide →

LlamaIndex

Framework RAG (Python)

Construisez des pipelines RAG et des agents LlamaIndex sur des modèles ouverts hébergés en UE avec OpenAILike et OpenAILikeEmbedding pointés sur Frontière AI.

Testé de bout en boutLire le guide →

Vercel AI SDK

Framework d'agents (TypeScript)

Un fournisseur compatible OpenAI pour Frontière AI dans le Vercel AI SDK : texte, outils et embeddings depuis des modèles ouverts en UE.

Testé de bout en boutLire le guide →

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 fournisseur qui le sert — raison pour laquelle on la mesure plutôt que de la supposer. 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 — le premier lot le 6 août 2026, les modèles suivants au fil de leur mesure ; cinq modèles de ce premier lot 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é

Un appel réel par modèle à travers la gateway, le premier lot le 6 août 2026. Un modèle en ligne que nous n'avons pas encore mesuré est absent de ce tableau plutôt que présumé fonctionnel. Un refus peut venir du fournisseur, pas du modèle : OVHcloud répondait HTTP 400, « feature 'tool calls' is not currently supported », pour Qwen2.5-VL 72B (en pause depuis le 20 octobre 2026). Le même résultat est lisible par une machine : chaque entrée mesurée de GET /api/v1/models porte un booléen tool_calling (absent = pas encore mesuré), 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 : avec un modèle de chat étiqueté souverain UE, 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

Deux manques à connaître avant de brancher quoi que ce soit, parce qu'ils échouent 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 :

Outil	Où se met la base URL	Source
CursorÉditeur de code	Settings → Models → OpenAI : API Key, puis l'interrupteur Base URL override. Cursor fait passer chaque requête par ses propres serveurs : les prompts transitent par Cursor (société américaine) avant de nous parvenir, et la complétion Tab garde les modèles de Cursor.	2026-10-12
Open WebUIInterface de chat	Admin Settings → Connections → OpenAI → Add Connection, champs URL et API Key (ou OPENAI_API_BASE_URL).	2026-08-06
LibreChatInterface de chat	Une entrée endpoints.custom dans librechat.yaml avec baseURL, apiKey et models.	2026-08-06
Fleece AIAgents en ligne de commande	fleece setup (npm @fleeceai/cli) → un fournisseur que vous nommez (ex. frontiere), base URL https://getfrontiereai.eu/api/v1, format openai, puis votre clé sk-front. Les modèles s'adressent frontiere/<modèle>, ex. frontiere/glm-5.2.	2026-09-22

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.

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, orchestration et inférence tournent toutes deux en Europe (notre gateway elle-même tourne à Paris chez Vercel, une société américaine — notre page de confidentialité le dit). 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 champ 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