Qu’est-ce qu’une API Key

Comprendre le rôle d’une API Key, son format, ses limites de sécurité, ainsi que la différence avec les unités de facturation du texte

Une API Key est l’identifiant d’authentification que vous utilisez pour appeler MoleAPI. Dans la console MoleAPI, elle est aussi souvent appelée jeton.

Lorsque vous utilisez un SDK, une application cliente ou vos propres requêtes HTTP pour vous connecter à MoleAPI, le système utilise cette Key pour déterminer :

qui vous êtes
si vous êtes autorisé à appeler l’API
quels modèles vous pouvez utiliser
à quel compte et à quelle Key rattacher vos appels

La façon la plus simple de la comprendre

Vous pouvez comprendre une API Key comme suit :

côté externe : elle ressemble à un « mot de passe d’API »
côté interne : elle agit aussi comme un « identifiant d’accès + libellé d’attribution de facturation + commutateur d’autorisations »

Autrement dit, ce n’est pas seulement une chaîne qui permet ou non d’appeler l’API ; elle influence aussi :

l’attribution des journaux d’appel
l’étendue des modèles disponibles
les stratégies de groupe
les restrictions de sécurité
le contrôle des quotas

Format typique

L’API Key de MoleAPI ressemble généralement à ceci :

sk-********************************

Dans de nombreuses applications tierces, elle peut être renseignée dans des champs tels que :

API Key
密钥
令牌
Bearer Token (écriture compatible dans certains clients ou interfaces)

API Key et unité de facturation du texte ne sont pas la même chose

C’est l’un des points de confusion les plus fréquents chez les débutants.

Deux concepts faciles à confondre

API Key / jeton : identifiant d’authentification utilisé pour appeler l’API.
Unité de facturation du texte (Token) : unité utilisée pour la facturation lorsque le modèle traite du texte.

Autrement dit :

ce que vous créez, c’est une API Key
ce que vous consommez, ce sont des coûts de traitement de texte / frais de requête

Ces deux notions sont totalement différentes.

Pourquoi créer plusieurs API Key pour un même compte

En théorie, vous pouvez n’utiliser qu’une seule Key, mais ce n’est pas recommandé en pratique.

Il est préférable de les séparer par usage, par exemple :

dev-local : débogage local
chatbox-test : test du client desktop
web-prod : backend du site en production
ops-batch : tâches planifiées ou traitements par lots

Les avantages sont les suivants :

Des journaux plus clairs : vous identifiez rapidement quel système effectue les appels
Un meilleur contrôle des autorisations : chaque Key peut avoir des modèles et des restrictions différents
Un risque plus faible : si une Key fuit, cela n’affecte pas nécessairement tous les services
Une meilleure répartition des coûts : il est plus facile de savoir qui a consommé combien

Où une API Key est généralement stockée

En usage réel, les emplacements courants pour stocker une API Key incluent :

la page de configuration d’une application cliente locale
les variables d’environnement du serveur
un fichier de configuration backend (non public)
un système de gestion des secrets

Si vous êtes développeur, l’écriture la plus courante ressemble généralement à ceci :

export OPENAI_API_KEY="sk-..."

Ou bien elle est envoyée dans le programme sous forme d’en-tête d’authentification Bearer.

Quand recréer ou remplacer une API Key

Dans les cas suivants, il est recommandé de créer une nouvelle Key plutôt que de continuer à réutiliser l’ancienne :

vous voulez séparer l’environnement de test et l’environnement de production
vous devez attribuer des autorisations d’appel distinctes à différents projets
vous devez restreindre l’accès à un nouvel ensemble de modèles
vous soupçonnez que l’ancienne Key a été compromise
vous souhaitez mettre en place un audit des journaux et une répartition des coûts plus explicites

Recommandations de sécurité

Si une API Key fuit, cela équivaut à une fuite d’autorisations d’API

N’exposez pas votre API Key dans un environnement public, sinon d’autres personnes pourraient l’utiliser directement pour consommer votre quota.

Vous devez au minimum éviter les pratiques suivantes :

ne pas l’écrire dans le code source frontend
ne pas la committer dans un dépôt Git
ne pas l’envoyer dans un groupe de discussion, une capture d’écran de ticket ou une documentation publique
ne pas laisser durablement une Key de production dispersée sur plusieurs appareils personnels

Bonnes pratiques recommandées :

utiliser des Key différentes pour le test et la production
configurer des restrictions de modèle ou une liste blanche d’IP pour les Key critiques
effectuer une rotation régulière des Key utilisées sur le long terme
désactiver ou supprimer immédiatement l’ancienne Key en cas d’appel anormal

Que lire ensuite

Si vous avez déjà compris le rôle d’une API Key, nous vous recommandons ensuite de consulter directement :

Sur cette page