Stocker une clé d'API LLM côté client en JS (BYOK + AI SDK)

Les frameworks agentiques comme LangGraph ou Mastra ne sont pas conçus pour fonctionner dans un navigateur web, même s’ils utilisent le langage JavaScript.

Pourtant, il est bien possible d’appeler une API LLM depuis une application JavaScript côté client, avec des librairies plus bas niveau comme LangChain.js et le Vercel AI SDK.

La difficulté principale n’est pas le code, mais la gestion sécurisée des clés d’API LLM, qui permettent de se connecter aux API d’OpenAI, Anthropic, Mistral ou encore Google AI Studio, et d’accéder aux modèles GPT, Claude, Gemini et équivalents.

Découvrons comment créer une application web SPA qui intègre l’IA en JavaScript, sans aucun serveur, avec le pattern “Bring Your Own Key” (BYOK).

Cas d’usage : une mini-appli intelligente pour les chercheurs en sciences humaines

Prenons l’exemple du codage thématique en sciences sociales. Rien à avoir avec le code informatique, le codage thématique consiste à catégoriser des éléments de texte dans une retranscription d’entretien qualitatif.

Les chercheurs utilisent souvent le logiciel NVivo pour cette tâche, mais même avec une interface optimisée, cette catégorisation manuelle peut s’avérer très chronophage.

Les IA génératives de type LLM sont très douées pour la classification de texte. On peut être tenté de les mobiliser pour réaliser une première classification d’un entretien, retranscrit lui aussi avec l’IA Whisper ou Kyutai.

Utiliser directement un LLM n’est pas très efficace, car ils ont tendance à halluciner des morceaux de texte.

Dans une logique agentique, on va plutôt demander à l’IA de classer une par une les phrases du document : comme ça, pas d’hallucinations, l’IA trie du texte existant mais ne génère rien de nouveau. La fonction generateObject du Vercel AI SDK (ma fonction préférée !) est parfaite pour cette tâche.

Cela demande toutefois de créer une mini-application avec une interface graphique agréable. Vous pouvez tester le résultat final sur notre page CodageGPT (appli expérimentale).

CodageGPT

Pour éviter d’avoir à manipuler des données de recherche sensibles et des données personnelles, on privilégie l’implémentation de l’application sous la forme d’une SPA, sans API.

Attention ici, on ne remplace pas le travail de fond du chercheur. L’IA est plutôt utilisée pour donner un premier aperçu global sur la nature des données, par exemple pour identifier si certains points sont suffisamment abordés dans les entretiens.

Pourquoi déplacer les appels d’API IA côté client ?

Lorsque vous créez une application web intégrant des fonctionnalités fondées sur l’IA, vous êtes généralement contraint de réaliser vous-même les appels à l’IA, côté serveur et avec votre propre clé d’API, via une technologie comme Vercel AI SDK ou LangChain.

Cela vous oblige à gérer des transferts de données sur votre serveur, et peut freiner l’utilisation de votre application pour toutes les entreprises qui souhaitent garder leurs données confidentielles.

Cela engendre aussi des coûts additionnels, à la fois pour l’hébergement et pour les appels à l’IA. Gérer un serveur n’est pas de toute repos, on l’a vu récemment avec la faille de sécurité extrêmement critique (RCE) dans les Server Functions de React et Next.js.

Si vous demandez à vos utilisateurs de fournir leur propre clé d’IA, vous résolvez le problème du coût des appels d’API, mais vous devez désormais gérer ces clés, de manière aussi sécurisée qu’un numéro de carte bleue !

Déplacer les appels d’API IA côté frontend et implémenter un pattern “BYOK” vous permet de résoudre totalement ce problème. Vous pouvez implémenter une Single Page Application (SPA) très simple et hébergeable quasi-gratuitement avec Vite et React.

Quelle technologie pour les appels IA dans le navigateur ?

Le framework Vercel AI SDK fonctionne parfaitement dans le navigateur. Conçu par Vercel, la société derrière Next.js, le AI SDK est conçu pour s’intégrer efficacement aux applications React (même sans Next). Retrouvez notre comparatif LangChain vs AI SDK pour plus de détails sur ce choix.

Voici un exemple de script qui appel l’API de Mistral de façon complètement standardisée avec le AI SDK. On peut facilement remplacer Mistral par Gemini, GPT ou même un modèle local.

import { generateText } from "ai";
import { createMistral } from "@ai-sdk/mistral";
const mistral = createMistral({
    apiKey: "//TODO: récupérer la clé"
})
console.log("Appel LLM en cours...")
const { text } = await generateText({
  model: mistral("codestral-latest"),
  prompt: "What are the technologies for AI engineering?",
});
// La réponse de l'IA
console.log(text);

Le seul problème à résoudre est finalement le stockage des clés d’API des utilisateurs dans le navigateur.

Fournir votre propre clé dans le navigateur reste un anti-pattern !

Attention à ne pas diffuser votre propre clé d’API côté client, comme le rappelle la documentation d’OpenAI !

Intégrer votre propre clé d’API à un code client constitue une faille de sécurité, et c’est d’ailleurs à cause de ce risque d’erreur qu’Anthropic a mis du temps a accepter que l’on puisse appeler son API depuis un navigateur. Cette confusion reste malheureusement courante.

Le pattern Bring Your Own Key signifie que c’est à l’utilisateur final d’apporter sa clé.

On parle donc bien dans cet article de permettre à l’utilisateur final de fournir sa propre clé, et non de prêter votre clé aux utilisateurs finaux, ce qui vous coûterait très cher.

BYOK avec stockage temporaire grâce au sessionStorage

Le sessionStorage est un stockage local disponible dans les navigateurs web, similaire au localStorage avec une différence importante : les données sont supprimées en fin de session lorsque l’utilisateur ferme son navigateur.

sessionStorage.getItem("MISTRAL_API_KEY");
sessionStorage.setItem("MISTRAL_API_KEY", "xyz");   sessionStorage.removeItem("MISTRAL_API_KEY");

SessionStorage

Exemple de stockage d’une clé d’API OpenAI dans le sessionStorage pour notre mini-appli CodageGPT. La clé sera utilisée pour communiquer avec l’IA, c’est donc l’utilisateur final qui paie les appels.

Attention aux vulnérabilités XSS, qui pourraient permettre à un pirate de récupérer la clé. Les en-têtes HTTP Content Security Policy peuvent aider à limiter ce risque, par exemple en interdisant totalement les appels à eval.

L’utilisation d’un input de formulaire de type password permet de mobiliser le système de stockage des mots de passe du navigateur pour charger plus facilement la clé.

Enfin, vous pouvez ajouter un chiffrement symétrique et un code PIN, par exemple de 4 chiffres. Le chiffrement doit être symétrique, pour que vous puissiez déchiffrer la clé à l’aide du code PIN de l’utilisateur. Le navigateur fournit quelques algorithmes via l’interface SubtleCrypto.

Cette technique réduit les risques de fuite d’une clé d’API mais n’est pas à considérer comme une sécurité totalement fiable. Le BYOK est un compromis entre le risque de stocker une clé d’API dans un navigateur, et le risque de gérer les clés des utilisateurs sur votre serveur, chaque approche à des avantages et des limites en termes de sécurité !

Stocker la clé sur le long terme est-il une bonne idée ?

Vous pouvez être tenté d’utiliser le localStorage. Cependant en l’absence de date de péremption pour les données, le risque est que l’utilisateur oublie sa clé dans ce stockage et qu’un utilisateur malveillant y accède plus tard.

Concernant les cookies, ils sont transmis à chaque requête HTTPS vers votre serveur, y stocker la clé d’API n’est donc pas une bonne solution.

À l’avenir, l’idéal serait que les navigateurs gèrent directement le stockage des clés d’API LLM, de la même façon qu’ils gèrent l’accès au micro et à la webcam.

Conclusion : ne laissez pas traîner vos clés d’API LLM n’importe où !

En résumé, il est bien possible d’appeler une API LLM depuis un navigateur web via du code JavaScript, par exemple avec le Vercel AI SDK.

Cette technique permet de créer des mini-applications d’IA sans serveur, sous forme de SPA (Single Page Application), implémentée par exemple avec Vite et React.

L’avantage est qu’aucune donnée sensible ne transite sur votre serveur, vous pouvez vous contenter de mettre à disposition une application web SPA à vos utilisateurs finaux.

Dans ce cas, il ne faut pas fournir votre propre clé, mais récupérer celle de l’utilisateur final selon une approche “BYOK” (Bring Your Own Key)

La difficulté principale n’est donc pas vraiment le code, mais la gestion des clés d’API secrètes de l’utilisateur, utilisées pour communiquer avec son IA favorite .

Le sessionStorage permet de stocker cette clé en limitant les risques de piratage, car la clé est supprimée à chaque fermeture du navigateur. L’utilisation d’un champ de formulaire de type mot de passe facilite la récupération de la clé à chaque connexion, via l’auto-complémention du navigateur.

Le point à retenir en tant qu’utilisateur d’une application fondée sur l’IA : lorsque vous fournissez votre clé d’API LLM à un logiciel ou une application web, il est très important de lui donner une date de péremption et une limite de budget !