Guide d'intégration

Vos modèles Frontière dans les agents Microsoft Foundry

Microsoft Foundry Agent Service sait appeler des modèles hébergés hors d'Azure via une connexion de type gateway — Microsoft appelle ça « bring your own model ». Frontière est exactement ça : une gateway compatible OpenAI. Pointez une connexion dessus et chaque modèle en ligne du catalogue devient sélectionnable à la création d'un agent, pendant que l'inférence, elle, continue de tourner sur une infrastructure européenne.

Ce que ça vous apporte

Vos agents restent dans Foundry — même projet, mêmes outils, même orchestration, même identité Azure et mêmes rôles. Seul le modèle change : au lieu d'un modèle déployé et servi par Microsoft, la requête sort d'Azure et arrive chez Frontière, qui la route vers le provider qui héberge réellement le modèle (OVHcloud, Scaleway, ou un serveur UE dédié) et la facture au token sur votre solde prépayé.

C'est le chemin supporté et documenté : une connexion de type Model Gateway, créée par un admin dans votre propre tenant. Rien à faire valider côté Microsoft, aucun achat Marketplace — il faut une clé API et une dizaine de minutes.

Avant de commencer

Quatre choses :

• Un projet Microsoft Foundry dans une souscription Azure.
• Le rôle Foundry User (ou supérieur) sur le projet, et Contributor sur le groupe de ressources — la connexion est déployée comme une ressource.
• Une clé API Frontière (tableau de bord → Clés API) et un solde non nul : un agent dont les appels renvoient 402 cesse de répondre.
• Les identifiants des modèles à exposer, tirés du catalogue — par exemple glm-5.2 ou qwen3.5-397b.

# The catalog is public — the IDs you declare in Foundry come from here
curl https://getfrontiereai.eu/api/v1/models

# The chat endpoint needs the same key Foundry will carry
curl https://getfrontiereai.eu/api/v1/chat/completions \
  -H "Authorization: Bearer $FRONTIERE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"glm-5.2","messages":[{"role":"user","content":"ping"}]}'

1. Créer la connexion

Dans le portail Foundry, les connexions vers des modèles externes se gèrent au niveau du compte, pas du projet :

1. Connectez-vous au portail Foundry, allez dans Operate, puis Admin.
2. Ouvrez l'onglet All projects, trouvez votre projet, et cliquez le lien de sa colonne Parent resource.
3. Ouvrez l'onglet Admin-connected models et cliquez Add.
4. Sur la page Connection type, choisissez Other source — l'option pour une gateway auto-hébergée ou non-Azure —, nommez la connexion (son nom fera partie de la référence du modèle : gardez-le court, frontiere), et entrez la base URL ci-dessous.
5. Sur la page Authentication, choisissez API key et remplissez les trois champs du tableau.

Sur la page Advanced, laissez API version vide et laissez Include deployment name in URL path désactivé : Frontière expose le chemin façon OpenAI (/chat/completions), pas celui d'Azure OpenAI qui embarque le nom du déploiement. Aucun en-tête personnalisé n'est nécessaire.

Si vous provisionnez votre infrastructure en code plutôt qu'à la main, la même connexion existe en template Bicep dans le dépôt foundry-samples de Microsoft, sous la catégorie ModelGateway — mêmes champs, déployés avec az deployment group create.

2. Déclarer les modèles

Toujours dans l'assistant, sur la page Model configuration, ajoutez une entrée par modèle que vos équipes pourront choisir. Dans Name, mettez l'identifiant Frontière exactement tel qu'il apparaît au catalogue (glm-5.2) — c'est la valeur envoyée dans le champ model de l'appel API. Dans Display name, ce qui se lit bien dans le portail (GLM-5.2 — souverain UE).

Chaque modèle ajouté devient un deployment dans Foundry, sélectionnable à la configuration d'un agent. N'ajoutez que ce que vous comptez utiliser : cette liste est le catalogue interne de votre organisation, et il est plus facile d'ajouter un modèle plus tard que d'expliquer un déploiement que personne n'a choisi.

Notre endpoint de catalogue ne renvoie que les modèles en ligne : ce que vous y copiez est appelable immédiatement. Les modèles « coming soon » en sont volontairement exclus — en déclarer un mettrait dans le sélecteur de vos agents un modèle qui répond 409 en production. Vous pouvez les voir avec ?include=all, mais ne les branchez pas.

3. L'utiliser dans un agent

La seule différence avec un agent Foundry standard, c'est le nom du déploiement : préfixez le modèle par le nom de la connexion, séparé par une barre oblique. Avec une connexion nommée frontiere et le modèle glm-5.2, le modèle de l'agent est frontiere/glm-5.2.

import os
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition
from azure.identity import DefaultAzureCredential

project = AIProjectClient(
    endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

agent = project.agents.create_version(
    agent_name="sovereign-assistant",
    definition=PromptAgentDefinition(
        model="frontiere/glm-5.2",  # <connection-name>/<model-name>
        instructions="You are a helpful assistant.",
    ),
)

client = project.get_openai_client()
conversation = client.conversations.create()
response = client.responses.create(
    conversation=conversation.id,
    input="Bonjour",
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)
print(response.output_text)

Créez l'agent avec l'Agent SDK, puis parlez-lui via le client OpenAI que le projet vous fournit. Si l'appel revient en model not found, c'est presque toujours le nom du déploiement : vérifiez le format nom-de-connexion/nom-de-modèle avant tout le reste.

Adapté des exemples de l'Agent SDK de Microsoft ; vérifiez les signatures à jour dans leur dépôt, elles bougent plus vite que cette page. learn.microsoft.com

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

Autant être précis, parce que c'est le passage qu'un DPO relira deux fois. Ce qui change : le modèle n'est plus servi par Microsoft. L'inférence tourne chez le provider qui l'héberge — OVHcloud, Scaleway ou un serveur UE dédié — et le drapeau sovereign de chaque modèle vous dit de quelle juridiction il s'agit. Les poids, les GPU et les logs d'inférence restent hors d'Azure.

Ce qui ne change pas : l'agent, lui, tourne toujours dans Foundry. Les prompts, les appels d'outils et l'historique de conversation transitent par l'orchestration de Microsoft avant de nous parvenir — cette couche conserve donc l'exposition juridictionnelle qu'a déjà votre tenant Azure. Microsoft énonce la contrepartie noir sur blanc dans sa propre documentation : avec un modèle « bring your own », c'est à vous de contrôler les données partagées avec lui, et les systèmes de sécurité et filtres de contenu d'Azure ne s'appliquent plus — les garde-fous sont à votre charge.

Cette intégration est donc la bonne réponse à « nos agents ne doivent pas tourner sur un modèle américain », et seulement une réponse partielle à « aucune société américaine ne doit traiter nos données ». Si c'est la seconde exigence qui compte, appelez l'API Frontière directement plutôt que de passer par Foundry — même clé, mêmes modèles, sans le détour par Azure.

RGPD contre CLOUD Act →

Dépannage

Les pannes qui valent la peine d'être connues avant de tomber dessus :

FAQ