IA multi-provider : choisissez le modèle, sans vendor lock-in

Comment fonctionne la sélection de modèle

Le LLM Router (packages/core/src/ai/router.ts) résout le provider et le modèle de chaque appel à partir du TenantTaskModelConfig, par type de tâche :

Type de tâche	Défaut typique
chat_tutor	classe Sonnet
chat_evaluation / summarization / supervisor	classe Haiku
content_generation	classe Haiku
course_review / course_agent / gamification_agent	classe Sonnet

L'admin institutionnel peut remplacer n'importe quelle tâche par un autre provider/modèle. Aucun model ID n'est codé en dur dans les agents — le router est le seul point de décision.

Méthodes du router

stream() — chat avec streaming (metered).
generate() — agents avec tools (metered) ; les tools sont converties de JSON Schema vers le format AI SDK, elles fonctionnent donc avec n'importe quel provider.
generateDirect() — appels background fire-and-forget (evaluation, content, summarizer, supervisor) qui s'exécutent dans after() de Next.js sans le pipeline complet de metering.

Fallback chain + circuit breaker

Par tier : Claude → GPT → Grok → Gemini (LLMs) ; Voyage → OpenAI → Cohere (embeddings). Un circuit breaker dans Redis s'ouvre après un seuil d'échecs et est partagé entre les instances, de sorte qu'un breaker ouvert saute le provider défaillant sans timeout. Les incidents sont enregistrés pour l'observabilité.

BYO keys + metering

Les clés par tenant (TenantApiKey) sont chiffrées en AES-256-GCM. Ordre de résolution : clé du tenant → clé globale du provider → variable d'environnement.
Chaque appel LLM passe par le middleware de metering (rate limit → vérification du crédit → calcul du coût), en enregistrant séparément les tokens d'entrée et de sortie. Les prix proviennent d'une table en base de données, jamais codés en dur.

Pourquoi c'est important

Vous ne misez pas votre plateforme sur le prix, la latence ou la disponibilité d'un seul laboratoire. Au fur et à mesure que les modèles s'améliorent, vous changez une liste déroulante — pas votre code.

Voir aussi

FAQ

Studeia est-il lié à un seul fournisseur d'IA ?

Non. Chaque fonctionnalité utilisant un LLM passe par un LLM Router interne qui sélectionne le provider et le modèle en fonction du type de tâche. L'admin peut basculer une tâche d'Anthropic Claude vers OpenAI GPT, xAI Grok ou Google Gemini sans casser aucun agent — le tool calling fonctionne avec n'importe quel provider via le Vercel AI SDK. Si le provider principal est défaillant, une fallback chain automatique prend le relais.

Un établissement peut-il utiliser ses propres clés API ?

Oui. Chaque tenant peut stocker ses propres clés (TenantApiKey, chiffrées en AES-256-GCM). Lorsque le tenant apporte sa propre clé, le coût de l'IA est directement facturé sur son compte chez le provider — Studeia n'applique aucune marge sur l'IA et ne définit jamais process.env (ce qui pourrait provoquer des fuites entre tenants) ; la clé est transmise par requête.

Qu'est-ce qui empêche une panne de provider de faire tomber le tuteur ?

Un circuit breaker (état stocké dans Redis, partagé entre les instances) s'ouvre après des échecs répétés et saute directement au provider suivant dans la fallback chain, de sorte que la défaillance d'un fournisseur se dégrade gracieusement au lieu d'échouer la requête. Chaque fallback est enregistré comme un incident de provider.