Accès multi-provider
Donnez à chaque équipe un endpoint compatible OpenAI et des virtual API keys. Ajoutez, remplacez ou auto-hébergez des providers derrière la gateway sans toucher au code applicatif.
Requête de model gouvernée
Gateway LLM
Gouvernez chaque appel de model de vos équipes
Les providers se multiplient, les clés fuient et les surprises de facturation arrivent en fin de mois. Odock place une gateway LLM gouvernée entre vos applications et chaque provider de models, en appliquant accès, guardrails, budgets et enregistrements d'audit avant qu'une complétion ne soit générée.
Un chemin gouverné unique pour chaque appel de model.
llm-gateway.request
Gateway LLM
>POST /v1/chat/completionsruntime applicatif
01Auth de l'appelantvérifiée
02Droits models...
03Scan guardrails...
04Réservation budget...
05Routing provider...
06Usage enregistré...
Providers
OpenAI, Anthropic, Azure, auto-hébergés
Contrôles
Clés, budgets, guardrails, audit
Qu'est-ce qu'une gateway LLM ?
Un endpoint contrôlé unique entre vos applications et chaque provider de models
Une gateway LLM est un plan de contrôle placé entre vos applications et les providers de models comme OpenAI, Anthropic, Azure ou des models auto-hébergés. Plutôt que de laisser chaque équipe détenir les keys brutes des providers et appeler les API directement, le trafic des models passe par un seul endpoint qui authentifie l'appelant, applique les guardrails, réserve le budget, route vers un provider approuvé et enregistre le résultat. Elle devient une plateforme de gouvernance lorsqu'elle va au-delà du routing : droits d'accès par équipe, budgets réservés avant le déclenchement de l'appel, détection des prompt injection et des fuites de données, et enregistrements d'usage prêts pour l'audit. C'est précisément ce pour quoi Odock est conçu, et le même plan gouverne aussi le trafic outils des agents via la gateway MCP.
Où les équipes l'utilisent
Un contrôle des coûts qui bloque, pas qui constate
Définissez budgets et quotas par clé, équipe ou projet. Odock réserve la dépense avant l'exécution de l'appel : un agent hors de contrôle s'arrête à la limite, pas à la facture.
Sécurité et conformité à la gateway
Scannez les prompts contre l'injection et la fuite de données, masquez les champs sensibles, appliquez les politiques de données par provider et produisez des enregistrements d'audit pour chaque décision de model.
Pour aller plus loin
Cycle de vie d'une requête LLM
Chaque appel de model suit un chemin gouverné
Aucune requête n'atteint un provider avant d'avoir passé les contrôles d'authentification, d'accès, d'inspection et de coût. Chaque résultat est enregistré avec tokens, latence et coût.
01
Authentifier
Valider la virtual API key.
02
Autoriser
Confirmer les droits models et providers.
03
Inspecter & appliquer
Exécuter les guardrails sur le prompt et le contexte.
04
Réserver la dépense
Vérifier budgets et quotas avant exécution.
05
Router
Envoyer vers un provider approuvé avec failover.
06
Enregistrer le résultat
Journaliser tokens, latence, statut et coût.
Exemple de requête bloquéeRefusée par la gouvernance
{
"apiKey": "vk_team_marketing",
"model": "gpt-5.2",
"method": "chat.completions",
"reason": "budget_exceeded",
"status": 402
}Pourquoi c'est important
Les appels de models sont des événements de dépense, de données et de conformité
Chaque complétion déplace de l'argent, peut transporter des données sensibles et devra peut-être être expliquée à un auditeur. Une gateway LLM donne aux équipes plateforme, sécurité et finance un point d'application unique pour les trois.
Contrôlez les models utilisés par les équipes
Autorisez les providers et models approuvés par équipe ou par clé, bloquez les models obsolètes ou non conformes, et déployez de nouveaux models sans toucher au code applicatif.
Appliquez la politique avant l'exécution
Authentifiez chaque appelant, scannez les prompts contre l'injection et la fuite de données, et rejetez les requêtes qui échouent aux règles de sécurité, de budget ou de conformité avant tout appel provider.
Attribuez chaque token
Reliez chaque requête à une clé, une équipe et un utilisateur avec tokens, latence et coût. Donnez à la finance des données de refacturation et aux auditeurs les enregistrements qu'ils demandent.
Ce que vous configurez
Une surface de contrôle LLM complète, pas seulement un proxy
Odock couvre tout ce dont les équipes plateforme ont besoin pour faire tourner le trafic LLM en production : enregistrement des providers, droits d'accès aux models, guardrails, tarification, budgets et enregistrements d'usage que vos équipes finance et sécurité peuvent réellement lire.
Vues LLM
Vue sélectionnée
Enregistrez les providers une seule fois et exposez les models approuvés via un endpoint compatible OpenAI. Vérifiez le type d'API, la config d'auth, le périmètre et le statut avant qu'une équipe puisse les appeler.
providers-&-models.llm
Live
openai-prod
Catalogue providers
APIOPENAI_API
AuthBEARER
Périmètreorg entière
Accès24 clés accordées
anthropic-prod
Catalogue providers
APIANTHROPIC_API
AuthBEARER
Périmètreorg entière
Accès18 clés accordées
azure-openai-eu
Configuration manuelle
APIOPENAI_API
AuthBEARER
Périmètreteam:eu-products
Accès6 clés accordées
bedrock-us
Catalogue providers
APIBEDROCK_API
AuthOAUTH2
Périmètreteam:platform
Accès4 clés accordées
mistral-eu
Catalogue providers
APIOPENAI_API
AuthBEARER
Périmètreteam:eu-products
Accès5 clés accordées
vllm-selfhosted
Configuration manuelle
APIOPENAI_API
AuthNONE
Périmètreteam:research
Accès3 clés accordées
Un endpoint, deux voies d'accès
Vos applications appellent Odock. Pas le provider
Accédez à Odock via un endpoint unifié OpenAI-style commun à tous les providers, ou via l'endpoint natif et le SDK de chaque provider lorsque vous avez besoin de fonctionnalités propres à un provider. Dans les deux cas, Odock authentifie l'appelant, confirme l'accès au model, exécute les guardrails, réserve le budget, injecte les credentials du provider et enregistre le résultat avant que le provider ne voie la requête.
Ce que la gateway prend en charge
- API unifiée OpenAI-style commune à tous les providers, pour que vos SDK existants fonctionnent sans modification.
- Endpoints et SDK natifs des providers lorsque vous avez besoin de fonctionnalités propres à un provider.
- Virtual API key requise avant qu'un model soit accessible.
- Credentials du provider injectés une fois les contrôles de gouvernance validés.
- Routing et failover entre providers approuvés.
llm-unified-openai.py
UnifiedOpenAI SDK
Mode
Langage
1# Utilisez l'endpoint unifié d'Odock via un SDK OpenAI-compatible2import os3from openai import OpenAI4 5client = OpenAI(6 api_key=os.environ["ODOCK_API_KEY"],7 base_url=os.environ.get("ODOCK_BASE_URL", "https://api.odock.ai/v1"),8)9 10response = client.chat.completions.create(11 model=os.environ.get("ODOCK_MODEL", "claude-sonnet-4-5"),12 messages=[13 {"role": "user", "content": "Explique le contrôle budgétaire."}14 ],15 temperature=0.2,16 max_tokens=200,17)18 19print(response.choices[0].message.content)Règlement IA européen & conformité
Une preuve pour chaque décision de model
Les programmes de conformité ont besoin de réponses précises : quelle équipe a utilisé quel model, sous quelle politique, avec quelles protections ? L'accès provider direct ne peut pas répondre à ces questions. Odock le peut.
- Faites passer chaque provider par un endpoint unique compatible OpenAI, gouverné et auditable
- Appliquez les contrôles de prompt injection et de fuite de données hors du code applicatif
- Produisez des preuves pour les revues IA internes, les évaluations fournisseurs et les programmes de conformité au règlement européen sur l'IA
- Gardez le trafic LLM et le trafic d'outils MCP dans la même frontière opérationnelle et de politique
FAQ
Les questions que les équipes posent sur les gateways LLM
Voici les questions récurrentes lorsque les équipes passent d'un accès provider direct à une couche gateway gouvernée.
Un endpoint pour chaque model, avec la gouvernance intégrée
Si vos équipes appellent des LLM en production, il vous faut le même contrôle que pour toute dépendance critique. Odock gouverne le trafic de models et d'outils depuis un chemin de requête unique.
llm-unified-openai.py
# Utilisez l'endpoint unifié d'Odock via un SDK OpenAI-compatibleimport osfrom openai import OpenAI client = OpenAI( api_key=os.environ["ODOCK_API_KEY"], base_url=os.environ.get("ODOCK_BASE_URL", "https://api.odock.ai/v1"),) response = client.chat.completions.create( model=os.environ.get("ODOCK_MODEL", "claude-sonnet-4-5"), messages=[ {"role": "user", "content": "Explique le contrôle budgétaire."} ], temperature=0.2, max_tokens=200,) print(response.choices[0].message.content)