Guides · Sécurité · Exploitation

Une clé OpenAI dans votre application : la facture qui explose

Votre application appelle une IA pour résumer, traduire ou répondre. Si la clé du fournisseur se trouve dans le code envoyé au navigateur, n'importe qui peut la copier et faire tourner ses propres requêtes à vos frais. Voici comment le vérifier, et comment plafonner le risque.

10 minutesApplications qui utilisent un modèle d'IA (chat, résumé, génération), générées par une IA ou nonPublié le 4 octobre 2026

Pourquoi c'est si fréquent

Pour ajouter une fonction d'IA, le plus court est d'appeler le fournisseur directement depuis la page, avec la clé dans le code. Ça marche tout de suite, et c'est ce que produisent souvent les assistants de code quand on leur demande « ajoute un résumé automatique ».

Le problème : tout ce qui est dans le code envoyé au navigateur est lisible par n'importe quel visiteur. Une clé d'IA copiée sert à lancer des requêtes à votre compte, et les robots qui parcourent le web cherchent précisément ces clés. Les factures de plusieurs milliers d'euros en un week-end ne sont pas une légende.

Vérification 1 : la clé est-elle dans votre code ?

Ouvrez votre application, les outils de développement (F12), onglet Sources, et recherchez dans tous les fichiers (Ctrl + Maj + F) les préfixes des principales clés :

  • sk- et sk-proj- : OpenAI ;
  • sk-ant- : Anthropic ;
  • AIza : une clé Google. Attention, la configuration Firebase en contient toujours une, et ce n'est pas un secret en soi. Vérifiez dans la console Google Cloud (API et services, puis Identifiants) que cette clé est restreinte à votre site et aux seules API utiles, et qu'elle ne donne pas accès à l'API Gemini (Generative Language API) ;
  • et, dans l'onglet Réseau, toute requête qui part directement de votre page vers api.openai.com, api.anthropic.com, api.mistral.ai ou generativelanguage.googleapis.com.

Si la page appelle le fournisseur directement, la clé voyage avec la requête, même si vous ne la trouvez pas dans le code. Dans le dépôt, vérifiez aussi les variables d'environnement : une variable dont le nom commence par VITE_, NEXT_PUBLIC_ ou REACT_APP_ est publique par construction (voir notre guide La clé d'administration est-elle dans votre code ?).

Vérification 2 : un plafond de dépense existe-t-il ?

Même bien protégée, une clé peut fuir. Dans la console de votre fournisseur, vérifiez :

  • qu'un budget mensuel est défini, avec une alerte par e-mail avant de l'atteindre ;
  • que ce budget bloque réellement les appels une fois atteint, et ne se contente pas d'alerter : chez Google Cloud, par exemple, un budget ne coupe rien. Le plafond le plus sûr reste un crédit prépayé sans recharge automatique ;
  • que la clé de l'application est propre à l'application (un projet ou une clé dédiés), et pas la clé personnelle de quelqu'un qui sert à tout ;
  • que l'alerte arrive à une adresse lue.

Le plafond ne remplace pas la protection de la clé, mais il transforme une catastrophe en mauvaise journée.

Vérification 3 : qui peut appeler votre fonction d'IA ?

La bonne architecture place l'appel au fournisseur côté serveur : la page appelle votre fonction serveur, qui ajoute la clé et appelle le fournisseur. Encore faut-il que cette fonction ne soit pas un robinet ouvert. Vérifiez qu'elle exige un utilisateur connecté, qu'elle limite le nombre d'appels par utilisateur et par jour, et qu'elle borne la taille de ce qu'on lui envoie.

Vérification 4 : ce que vous envoyez au fournisseur

Deux questions souvent oubliées :

  • Quelles données personnelles partent chez le fournisseur ? Si vos clients écrivent des noms, des adresses ou des informations de santé dans un champ qui est ensuite envoyé à l'IA, c'est une communication de données personnelles à un sous-traitant, souvent situé hors de l'Union européenne : à mentionner dans votre politique de confidentialité, et à encadrer par un contrat de sous-traitance (article 28 du RGPD) avec le fournisseur.
  • Un utilisateur peut-il détourner l'IA ? Si le texte saisi par un utilisateur est envoyé tel quel au modèle avec vos instructions, il peut lui demander d'ignorer ces instructions (on parle d'injection). Ne laissez jamais le modèle décider seul d'une action sensible (rembourser, supprimer, envoyer un e-mail) sur la base d'un texte venu de l'extérieur.

Si vous avez trouvé la clé

  1. Révoquez la clé dans la console du fournisseur et créez-en une nouvelle : une clé qui a été publique doit être considérée comme volée.
  2. Vérifiez la consommation des derniers jours, et contactez le fournisseur en cas d'usage frauduleux.
  3. Déplacez l'appel côté serveur, dans une fonction qui exige un utilisateur connecté et limite les appels.
  4. Définissez un budget et une alerte.

Ce que cette vérification ne couvre pas

La qualité des réponses de l'IA, et ce que le fournisseur fait des données envoyées selon votre contrat. Les autres clés de votre application (paiement, e-mails, base de données), elles, c'est ce que couvre notre diagnostic, axe sécurité.

Dans notre grille : Fonctions IA de l'application : clé de modèle exposée, plafond de dépense, injection par le contenu utilisateur, données personnelles envoyées au fournisseur.
Voir les soixante questions
Vingt minutes

Vous préférez qu'on regarde avec vous ?

Le diagnostic couvre ce guide et toute la grille, soixante questions sur sept axes, pour 2 900 € HT : premiers constats sous 48 heures, rapport sous cinq jours ouvrés.