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, donc elles fonctionnent avec n'importe quel provider.
generateDirect() — appels background fire-and-forget (évaluation, contenu, summarizer, supervisor) qui s'exécutent dans le 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 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 des crédits → 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 pariez pas votre plateforme sur le prix, la latence ou la disponibilité d'un seul laboratoire. À 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. Toute fonctionnalité utilisant un LLM passe par un LLM Router interne qui sélectionne le provider et le modèle selon le 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 échoue, 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 AES-256-GCM). Lorsque le tenant apporte sa propre clé, le coût de l'IA est imputé directement à 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 dans Redis, partagé entre les instances) s'ouvre après des échecs répétés et saute directement au provider suivant de la fallback chain, de sorte qu'une panne d'un fournisseur dégrade gracieusement le service au lieu de faire échouer la requête. Chaque fallback est enregistré comme incident de provider.