Générer et Sécuriser votre Clé API

Le sésame qui authentifie vos requêtes

La clé API est ce qui authentifie chaque requête envoyée aux modèles Mistral : sans elle, aucun appel n’est accepté. Elle se comporte comme un mot de passe technique, à ceci près qu’elle circule dans du code, des fichiers de configuration et des pipelines de déploiement, donc dans beaucoup plus d’endroits qu’un mot de passe classique. Quiconque la possède peut consommer votre quota et générer des coûts sur votre compte.

Générer votre première clé

Depuis la Console Mistral, ouvrez votre workspace puis la section « API Keys » du menu latéral. Cliquez sur « Créer une nouvelle clé » et donnez-lui un nom descriptif, par exemple dev-chatbot-mars-2026. Ce nom ne sert à rien techniquement, mais il vous sauvera le jour où six clés cohabiteront dans la liste et qu’il faudra en révoquer une seule : « clé 3 » ne vous dira rien, dev-chatbot-mars-2026 vous dira tout.

La clé s’affiche une seule fois, au moment de sa création. Copiez-la immédiatement et rangez-la dans un endroit sûr. Si vous fermez la fenêtre avant de l’avoir copiée, il n’existe aucun moyen de la récupérer : vous devrez en générer une nouvelle. Une clé Mistral se présente sous la forme d’un préfixe suivi d’une longue chaîne alphanumérique. Ne la confondez ni avec l’identifiant de votre workspace, ni avec un token JWT : contrairement à ce dernier, elle n’expire pas d’elle-même et reste valable tant que vous ne l’avez pas révoquée.

La stocker sans jamais l’écrire dans le code

La règle d’or tient en une phrase : ne jamais écrire votre clé API en dur dans le code source. Le jour où ce fichier part sur un dépôt partagé, la clé part avec lui. Utilisez systématiquement une variable d’environnement.

Sur Linux et macOS, la déclaration se fait dans le terminal :

export MISTRAL_API_KEY="votre-cle-api-ici"

Cette variable disparaît à la fermeture du terminal ; pour la rendre persistante, ajoutez la ligne à votre fichier ~/.bashrc, ~/.zshrc ou ~/.profile.

Sur Windows, l’équivalent en PowerShell s’écrit ainsi :

$env:MISTRAL_API_KEY = "votre-cle-api-ici"

Et pour qu’elle survive au redémarrage de la session :

[System.Environment]::SetEnvironmentVariable("MISTRAL_API_KEY", "votre-cle-api-ici", "User")

Dans un projet applicatif, la pratique la plus courante consiste à créer un fichier .env à la racine :

MISTRAL_API_KEY=votre-cle-api-ici

Ajoutez aussitôt .env à votre .gitignore — avant même le premier commit, pas après. En Python, la bibliothèque python-dotenv se charge de lire ce fichier et d’injecter les variables au démarrage, ce qui vous donne le confort du fichier local sans le risque du secret versionné.

Faire tourner les clés

Une clé se remplace pour trois raisons. Immédiatement, si elle a été exposée d’une manière ou d’une autre : commit poussé sur un dépôt Git public, message Slack un peu rapide, trace dans des logs serveur. Régulièrement en production, tous les quatre-vingt-dix jours étant une cadence raisonnable. Et au départ d’un collaborateur qui y avait accès, le même jour que la restitution du badge.

La procédure évite toute coupure de service si vous respectez l’ordre :

1. Générez une nouvelle clé dans la Console
2. Mettez à jour la variable d’environnement dans tous vos déploiements
3. Vérifiez que tout fonctionne avec la nouvelle clé
4. Révoquez l’ancienne clé seulement après cette vérification

Inverser les étapes 3 et 4 est l’erreur classique : on révoque d’abord « pour être tranquille », et l’on découvre qu’un service oublié utilisait encore l’ancienne clé. Cette rotation sans interruption garantit qu’aucun composant ne tombe pendant la transition.

Réduire la surface d’exposition

Si plusieurs applications appellent l’API, créez une clé par application. La compromission de l’une n’oblige alors à révoquer que celle-là, sans arrêter les autres. Sur le même principe, ne réutilisez jamais la clé de production en développement : c’est précisément l’environnement où les secrets circulent le plus librement.

Surveillez ensuite l’utilisation depuis la Console, qui expose les logs d’usage de chaque clé. Un pic soudain de tokens ou des appels provenant d’une IP inconnue doivent déclencher une rotation immédiate, sans attendre la confirmation d’un incident.

Trois dernières erreurs méritent d’être nommées, parce qu’on les rencontre chaque semaine. Une clé publiée sur un dépôt Git public reste lisible dans l’historique même après suppression du fichier : la seule réponse valable est la révocation. Une clé transmise en clair par e-mail ou messagerie instantanée est archivée pour toujours sur des serveurs que vous ne contrôlez pas. Et une clé expirée ou révoquée qui traîne encore dans un déploiement produit des erreurs 401 Unauthorized que l’on met souvent une heure à diagnostiquer, faute d’y penser.

Points clés à retenir

• Générez vos clés depuis la section API Keys de votre workspace dans la Console Mistral
• Stockez-les exclusivement en variable d’environnement ou dans un gestionnaire de secrets
• Effectuez une rotation régulière et immédiate en cas d’exposition
• Créez une clé par application pour limiter l’impact d’une compromission
• Ajoutez toujours .env à votre .gitignore