Bonnes pratiques de gestion des clés API pour les produits IA (liste de contrôle 2026)

Bonnes pratiques de gestion des clés API pour les produits IA (liste de contrôle 2026)

Les bonnes pratiques de gestion des clés API reposent sur cinq principes : conserver les clés côté serveur et hors du code, attribuer à chaque environnement et charge de travail une clé aux droits strictement limités, stocker les clés dans un gestionnaire de secrets, planifier et tester leur rotation et leur révocation, et surveiller leur utilisation sans jamais consigner les clés elles-mêmes dans les journaux. Pour les produits IA, les enjeux sont plus importants que pour la plupart des API : une clé de modèle divulguée peut générer une facture élevée en quelques heures, mais aussi autoriser l’accès aux prompts, aux fichiers et aux appels d’outils.

Ce guide transforme ces principes en une liste de contrôle que les équipes plateforme, sécurité et produit IA peuvent appliquer. Il couvre le cycle de vie des clés, un modèle d’inventaire, la rotation sans interruption, les protections CI/CD, une procédure de réponse aux incidents et du code pour générer, stocker et vérifier les clés. Les sources comprennent l’aide-mémoire OWASP sur la gestion des secrets, les bonnes pratiques de Google Cloud pour les clés API et la documentation GitHub sur la détection des secrets, toutes vérifiées le 27 octobre 2026.

Bonnes pratiques de gestion des clés API : la liste de contrôle rapide

#	Bonne pratique	Ce qu’elle permet d’éviter
1	Ne jamais coder de clés en dur dans le code source, les notebooks ou les applications clientes	Les fuites via l’historique Git, les bundles du navigateur et les binaires mobiles
2	Conserver les clés des fournisseurs côté serveur ; fournir aux clients des jetons de session à courte durée de vie	L’extraction de votre clé depuis un appareil par un utilisateur ou un logiciel malveillant
3	Utiliser une clé par environnement, application et membre d’équipe	Qu’une seule fuite entraîne une interruption générale lors de la révocation
4	Appliquer les restrictions les plus strictes disponibles : API, modèles, IP, quotas	Que des clés volées puissent servir à tout
5	Stocker les clés dans un gestionnaire de secrets, jamais dans des tickets, des conversations ou des wikis	Les copies impossibles à retrouver ou à remplacer lors d’une rotation
6	Tenir un inventaire des clés avec le responsable, la charge de travail et la date de rotation	Que la rotation perturbe des systèmes utilisateurs inconnus
7	Planifier la rotation avec une période de chevauchement, puis révoquer l’ancienne clé	Les clés à longue durée de vie qui restent valides après le départ des employés et prestataires
8	Supprimer les clés inutilisées	Les clés oubliées dont les autorisations restent actives
9	Activer la détection des secrets et la protection des envois	Que des clés se retrouvent dans un dépôt public ou partagé
10	Ne jamais journaliser les clés ni les en-têtes d’autorisation ; consigner un identifiant ou une version de clé	Les fuites de secrets via les journaux, les traces et les rapports d’erreurs
11	Fixer des plafonds de dépenses et déclencher des alertes en cas d’utilisation inhabituelle	Les factures imprévues dues à une clé volée ou à une utilisation incontrôlée
12	Disposer d’une procédure d’incident donnant la priorité à la révocation	Une exposition prolongée pendant que les équipes cherchent à déterminer si la fuite a été exploitée

La suite de ce guide explique comment appliquer chaque pratique aux charges de travail IA, où une clé fait plus qu’authentifier : elle autorise un circuit de données pour les prompts, les documents et les sorties des modèles.

Le cycle de vie d’une clé API

OWASP recommande de gérer les secrets sur l’ensemble de leur cycle de vie : création, rotation, révocation et expiration, avec un audit à chaque étape (aide-mémoire OWASP sur la gestion des secrets). Pour une clé API d’IA, ce cycle se présente ainsi :

Étape	Action du responsable	Éléments de preuve à conserver
Demande	Justifier la charge de travail, l’environnement et les modèles nécessaires	Ticket ou entrée d’inventaire
Création	Générer la clé dans la console ou via l’API du fournisseur avec un nom descriptif	Identifiant de clé, date et heure de création, créateur
Restriction	Limiter les modèles, les API, les réseaux et le budget	Paramètres de restriction
Stockage	Enregistrer directement dans un gestionnaire de secrets ; ne jamais coller ailleurs	Chemin du secret et politique d’accès
Mise à disposition	Injecter à l’exécution dans la seule charge de travail qui en a besoin	Liaison de déploiement
Surveillance	Suivre les requêtes, les tokens, les dépenses et la dernière utilisation	Tableau de bord d’utilisation et alertes
Rotation	Créer une clé de remplacement, basculer, vérifier	Compte rendu de rotation
Révocation	Invalider chez le fournisseur, confirmer un code 401	Horodatage de révocation et résultat du test

Les cinq frontières qu’une clé d’IA peut franchir

Commencez par cartographier les points où un secret ou les données auxquelles il donne accès peuvent transiter. La plupart des défaillances surviennent parce que les équipes protègent la clé du fournisseur, mais négligent l’une de ces frontières connexes.

Frontière	Défaillance courante	Protection nécessaire
Du client à l’application	Une clé de fournisseur est intégrée à un bundle de navigateur, un binaire mobile, une application de bureau ou une extension	Conserver les clés des fournisseurs côté serveur ; délivrer aux clients des identifiants utilisateur ou de session à courte durée de vie
De l’application à la passerelle	Tous les services partagent une seule clé sans restriction	Utiliser des identités de charges de travail, des jetons de passerelle aux droits limités, des quotas et une politique de routage explicite
De la passerelle au fournisseur	Un seul identifiant donne accès à tous les modèles, projets ou environnements	Séparer les clés par fournisseur, environnement, charge de travail et niveau de risque lorsque cela est possible
De la requête aux journaux	Les en-têtes d’autorisation, les prompts, les fichiers ou les sorties apparaissent dans les traces	Exclure les champs contenant des secrets, limiter la journalisation des charges utiles, remplacer les identifiants par des tokens et tester le masquage
Opérations humaines	Les clés sont collées dans des tickets, des conversations, des procédures ou des outils de support	Utiliser des processus d’accès contrôlés, une récupération auditée, des procédures d’accès d’urgence et une expiration automatique

Cette cartographie fait évoluer la question de conception de « Où stockons-nous la clé ? » vers « Quelle identité peut effectuer quelle requête, avec quelles données, par quel circuit, et quelles preuves restent ensuite ? »

Adopter un modèle de conservation des clés côté serveur

Les identifiants de fournisseur à longue durée de vie ne doivent pas être transmis aux clients web, mobiles, de bureau ou aux extensions. Tout élément livré sur l’appareil d’un utilisateur final doit être considéré comme récupérable par cet utilisateur ou par un logiciel malveillant disposant des mêmes privilèges.

Une approche plus sûre consiste à procéder ainsi :

1. Le client s’authentifie auprès de votre backend avec une session utilisateur, un identifiant d’appareil ou un jeton applicatif à courte durée de vie.
2. Votre backend autorise la fonctionnalité demandée et applique des limites par utilisateur ou par locataire.
3. Une passerelle ou une intégration côté serveur choisit le fournisseur et le modèle approuvés.
4. La clé du fournisseur est récupérée à l’exécution ou mise à disposition de la charge de travail de confiance par la plateforme de déploiement.
5. La réponse du fournisseur repasse par la même frontière de contrôle.

Le client n’a jamais besoin du secret du fournisseur. Il reçoit uniquement l’autorisation d’appeler votre produit dans les limites que vous définissez.

Pour les agents de programmation et les outils de développement locaux, appliquez le même principe en définissant explicitement les exceptions. Un développeur peut avoir besoin d’un identifiant local, mais celui-ci doit être propre au produit ou à la passerelle, révocable, avec une utilisation attribuable et des droits limités, plutôt qu’une clé de fournisseur partagée par toute l’organisation et copiée dans les fichiers de configuration cachés de l’entreprise.

Constituer un inventaire des clés avant toute rotation

Les projets de rotation échouent lorsque les équipes ignorent quelle charge de travail utilise une clé. Créez un inventaire exploitable par machine et désignez un responsable avant de modifier les identifiants.

Consignez au minimum :

Champ	Exemple	Utilité
Identifiant du secret	prod-support-chat-anthropic-01	Fournit une référence interne stable qui n’est pas la valeur du secret
Fournisseur et projet	Compte fournisseur + identifiant du projet	Définit l’étendue des conséquences externes
Environnement	Développement, préproduction, production	Empêche les systèmes de test d’hériter des autorisations de production
Charge de travail	support-chat-api	Permet l’attribution et une révocation ciblée
Responsable	Équipe et roulement d’astreinte	Définit les responsabilités en cas d’incident
Emplacement de stockage	Chemin dans le gestionnaire de secrets ou liaison de déploiement	Indique où se trouve la source de référence
Modèles/routes autorisés	Famille de modèles approuvée ou politique de passerelle	Limite les utilisations imprévues
Limites de dépenses et de requêtes	Budget de la charge de travail, RPM, TPM ou limites de concurrence	Contient les abus et les automatisations incontrôlées
Création et dernière rotation	Horodatages	Rend visibles les identifiants anciens
Méthode de rotation	Double clé, alias de version ou fenêtre de maintenance	Évite les changements improvisés
Dépendances de révocation	Services à mettre à jour en premier	Préserve la disponibilité
Classification des données	Publiques, internes, confidentielles, réglementées	Relie la politique des clés à la gouvernance des prompts

N’inscrivez pas la valeur de la clé dans l’inventaire. Stockez uniquement les métadonnées et une référence au secret géré.

Séparer les identités par environnement, charge de travail et niveau de risque

Le travers le plus courant consiste à partager une seule clé de production entre tous les services. C’est pratique jusqu’à ce qu’un dépôt, un exécuteur de tests, l’ordinateur portable d’un prestataire ou une transcription de support la divulgue. L’équipe ne peut alors plus révoquer la clé sans perturber des produits sans rapport avec l’incident.

Privilégiez des identités distinctes pour :

• La production, la préproduction, le développement et les tests locaux.
• Le trafic client, les outils internes, les traitements par lots et les pipelines d’évaluation.
• Les processus à haut risque pouvant appeler des outils ou traiter des données confidentielles.
• Les différentes entités ou les différents locataires lorsque les obligations contractuelles imposent une séparation.
• Les accès d’urgence, qui doivent rester désactivés ou strictement contrôlés en fonctionnement normal.

Lorsqu’un fournisseur propose des restrictions, appliquez-les. Elles peuvent porter sur les API, les modèles, les réseaux sources, les projets, les référents, les applications ou les quotas autorisés. Les recommandations de Google Cloud sur les clés API préconisent par exemple de restreindre les clés, de les isoler, de supprimer celles qui sont inutiles, d’éviter de les inclure dans les commits des dépôts et de surveiller leur utilisation.

Si le fournisseur ne propose pas de contrôles suffisamment fins, appliquez-les au niveau de votre propre passerelle. Une passerelle centrale peut valider la charge de travail appelante, l’associer à une route approuvée, appliquer des budgets et des limites de débit, et conserver les identifiants des fournisseurs derrière une frontière côté serveur ayant fait l’objet d’une revue. Consultez le guide d’architecture des passerelles API pour l’IA pour approfondir la conception du routage et du basculement.

Intégrer la gouvernance des prompts et des journaux à la gestion des clés

Une clé API autorise un circuit de données. Protéger la clé sans contrôler ce circuit laisse entier le principal risque propre à l’IA.

Avant d’acheminer une requête, classez sa charge utile et appliquez le principe du strict nécessaire :

• Supprimez les identifiants d’accès, les jetons, les cookies, les clés privées et les chaînes de connexion.
• Excluez les champs dont le modèle n’a pas besoin.
• Remplacez les identifiants directs par des tokens ou pseudonymisez-les lorsque la tâche peut s’en passer.
• Rejetez les données réglementées ou soumises à des restrictions contractuelles dont le traitement n’est pas pris en charge.
• Séparez les instructions système des contenus utilisateur ou récupérés non fiables.
• Validez les arguments des outils avant qu’un agent puisse appeler des systèmes externes.

Les journaux doivent suivre un schéma explicite. Ne comptez pas sur les développeurs pour penser à ne pas journaliser un objet de requête. Définissez les champs autorisés, puis éliminez ou transformez tout le reste.

Un événement utile en production peut contenir :

{
  "request_id": "req_01J...",
  "tenant_id_hash": "tnt_7f2...",
  "workload": "support-chat-api",
  "route_policy": "support-low-risk-v3",
  "provider": "selected-provider",
  "model": "selected-model",
  "input_tokens": 842,
  "output_tokens": 211,
  "latency_ms": 1370,
  "status": 200,
  "key_version": "v12",
  "redaction_policy": "customer-support-v4"
}

Il ne doit pas contenir par défaut l’en-tête d’autorisation, la clé brute du fournisseur, le prompt complet, le document téléversé, un argument d’outil non expurgé ou la sortie intégrale du modèle. Si la capture des charges utiles est nécessaire pour une évaluation ou un incident strictement encadré, limitez-la dans le temps, contrôlez-en l’accès et distinguez-la clairement de la télémétrie courante.

L’aide-mémoire OWASP sur la journalisation constitue une base utile pour exclure les jetons d’accès, les mots de passe, les clés de chiffrement et les autres données sensibles des journaux applicatifs.

Concevoir une rotation des clés API sans interruption

La rotation n’est une mesure de protection que si elle peut être réalisée en toute sécurité. Une procédure qui provoque une panne sera repoussée jusqu’à une situation d’urgence.

Utilisez une séquence à double clé ou à secrets versionnés lorsque le fournisseur autorise la coexistence des identifiants :

1. Créez une nouvelle clé chez le fournisseur. Appliquez les mêmes restrictions que pour l’ancienne clé, ou des restrictions plus strictes.
2. Stockez-la comme une nouvelle version du secret. N’écrasez pas directement l’ancienne valeur si votre plateforme prend en charge les versions ou les alias.
3. Déployez des composants capables de lire la nouvelle version. Mettez à jour la passerelle ou les charges de travail pour qu’elles résolvent l’alias ou la version en cours.
4. Basculez le trafic et observez. Vérifiez la réussite des requêtes, les modèles attendus, les dépenses, les limites de débit et les taux d’erreur avec la nouvelle version de clé.
5. Éliminez les usages de l’ancienne clé. Vérifiez les inventaires de déploiement, les tâches, les processus de traitement et les environnements de reprise après sinistre.
6. Révoquez l’ancienne clé. Ne vous contentez pas de cesser de l’utiliser ; invalidez-la chez le fournisseur.
7. Vérifiez le rejet. Un test contrôlé doit confirmer que l’ancien identifiant ne fonctionne plus.
8. Consignez les preuves. Enregistrez les horodatages, les responsables, les charges de travail concernées, les résultats de validation et la prochaine date de revue.

Dans un système qui permet de choisir la version d’une clé, l’application doit faire référence à un alias stable plutôt que coder en dur une version du secret :

type ProviderCredential = {
  value: string;
  version: string;
};

async function loadProviderCredential(): Promise<ProviderCredential> {
  const activeVersion = await secretStore.resolveAlias("ai/provider/active");
  const value = await secretStore.readVersion("ai/provider", activeVersion);

  return { value, version: activeVersion };
}

N’affichez pas value, ne sérialisez pas l’objet retourné et ne le joignez pas à une erreur. Journalisez uniquement l’identifiant de version non secret.

L’aide-mémoire OWASP sur la gestion des secrets recommande de planifier l’ensemble du cycle de vie des secrets, notamment la création, la rotation, la révocation, l’expiration, l’audit, la sauvegarde et l’accès d’urgence. Il souligne également l’intérêt d’automatiser la rotation lorsque cela est réalisable.

Empêcher les secrets d’entrer dans les dépôts et les journaux CI

Les gestionnaires de secrets ne sont plus d’aucune aide une fois qu’un identifiant est copié dans le code source, un jeu de données de test, un artefact de compilation ou un journal CI.

Appliquez des contrôles à trois étapes :

Avant le commit

• Fournissez des fichiers .env.example avec des valeurs de remplacement, jamais des identifiants fonctionnels.
• Gardez les fichiers de secrets locaux hors du contrôle de version.
• Exécutez un détecteur de secrets rapide dans les hooks de pré-commit pour repérer les formats courants des fournisseurs et les valeurs à forte entropie.
• Expliquez aux développeurs que supprimer un secret dans un commit ultérieur ne l’efface pas de l’historique.

Lors des envois et des pull requests

• Activez la détection des secrets et la protection des envois dans les dépôts lorsque ces fonctions sont disponibles.
• Ajoutez des motifs personnalisés pour les jetons de passerelle internes que les détecteurs publics ne reconnaissent pas.
• Exigez une justification documentée pour tout contournement et soumettez ces contournements à une revue de sécurité.
• Analysez les fichiers générés, les notebooks, les instantanés de test et les plans d’infrastructure, en plus du code source applicatif.

GitHub présente la protection des envois comme un moyen d’analyser le contenu pendant l’envoi et de bloquer les secrets détectés avant leur entrée dans un dépôt. Une détection ne justifie pas de conserver la clé : considérez tout identifiant dont la présence dans un commit est confirmée comme exposé et remplacez-le.

Pendant le CI/CD

• Privilégiez l’identité des charges de travail ou la fédération à courte durée de vie plutôt que des identifiants cloud stockés.
• N’exposez un secret qu’à la tâche et à l’étape qui en ont besoin.
• Masquez les valeurs secrètes connues, sans faire du masquage votre protection principale.
• Désactivez le traçage du shell pendant la récupération des secrets.
• Empêchez le code non fiable provenant de forks d’accéder aux secrets de déploiement.
• Vérifiez les artefacts, les caches, les fichiers de vidage mémoire et les rapports de test pour repérer toute capture accidentelle.

Surveiller l’utilisation sans journaliser le secret

Une bonne surveillance permet de savoir « qui a utilisé quelles autorisations ? » sans enregistrer le secret qui les confère.

Suivez :

• La charge de travail, l’environnement, le locataire ou le projet et la version de clé.
• Le fournisseur, le modèle, la politique de routage et le circuit de repli.
• Le nombre de requêtes, le volume de tokens, les dépenses, la latence et la catégorie d’erreur.
• Le réseau source ou l’identité de déploiement lorsque c’est utile.
• Les accès au gestionnaire de secrets, y compris les lectures refusées.
• La création des clés, les modifications de restrictions, la rotation, la révocation et la suppression.
• Toute utilisation soudaine depuis un environnement, une zone géographique, un modèle ou une plage horaire inattendus.

Configurez des alertes sur les comportements, pas seulement sur le total des dépenses. Une clé volée au budget limité peut malgré tout exposer des prompts ou servir à sonder des processus internes. À l’inverse, un traitement par lots légitime peut provoquer un pic de dépenses sans compromission des identifiants. Mettez en corrélation l’utilisation chez le fournisseur avec les identifiants de requête de l’application, les décisions de politique de la passerelle, les événements de déploiement et les journaux d’audit du gestionnaire de secrets.

Pour compléter le contrôle des identifiants par celui du trafic, consultez le guide des limites de débit des LLM et le guide opérationnel du routage de repli des API LLM.

Mesurer le délai entre exposition et révocation lors d’un incident

Lorsqu’une clé risque d’être exposée, le premier objectif est de contenir l’incident, avant de chercher à prouver qu’un attaquant l’a utilisée.

Suivez cette séquence :

1. Déclarez l’identifiant suspect. Consignez quand et où il a pu être exposé.
2. Créez un remplacement par le circuit contrôlé habituel. Ne collez pas de nouvelle clé dans une conversation pour accélérer la gestion de l’incident.
3. Basculez les charges de travail légitimes vers la clé de remplacement. Utilisez la procédure de rotation préparée.
4. Révoquez la clé suspecte. Si une révocation immédiate aurait des conséquences inacceptables, isolez les routes et réduisez les limites pendant que vous terminez la bascule.
5. Recherchez tous les emplacements de copie. Vérifiez l’historique du code source, les journaux CI, les artefacts, les couches de conteneurs, les systèmes de support, les tableaux de bord, les notebooks, la configuration locale et les sauvegardes.
6. Examinez les circuits de données autorisés. Déterminez à quels prompts, sorties, fichiers, outils ou modèles la clé pouvait donner accès, au-delà de son seul périmètre de facturation.
7. Corrélez l’activité. Comparez l’utilisation chez le fournisseur, les journaux de la passerelle, les déploiements, les lectures de secrets et l’activité des utilisateurs.
8. Prévenez les responsables concernés. Impliquez les équipes sécurité, plateforme, juridique, protection des données et relation client selon les données et les contrats en jeu.
9. Éliminez la cause racine. Ajoutez le détecteur, la restriction, la frontière d’identité ou le filtre de journalisation manquant.
10. Mesurez les délais. Consignez les délais de détection, de remplacement, de bascule du trafic, de révocation et de vérification.

L’indicateur le plus utile pour agir est souvent le délai entre exposition et révocation : la durée pendant laquelle un identifiant suspect reste utilisable après que l’organisation dispose de preuves crédibles de son exposition. Réduire ce délai exige des responsabilités définies, un inventaire, de l’automatisation et une rotation testée, bien plus qu’un document de politique plus long.

Si vous délivrez des clés API à vos propres clients

De nombreux produits IA distribuent aussi des clés, par exemple pour permettre aux clients d’appeler votre agent ou d’intégrer votre fonctionnalité. Les mêmes bonnes pratiques s’appliquent dans l’autre sens :

• Générez les clés avec un générateur aléatoire cryptographiquement sûr, avec au moins 32 octets d’entropie.
• Ajoutez un préfixe reconnaissable (comme sk-fk- pour les clés Flatkey) afin que les détecteurs de secrets et votre équipe de support puissent identifier les clés divulguées. Le programme partenaire de GitHub utilise des formats de jetons connus pour avertir les émetteurs lorsqu’une clé est envoyée dans un dépôt public (détection des secrets GitHub).
• N’affichez la clé complète qu’une seule fois, puis ne stockez qu’une empreinte. En cas de fuite de votre base de données, les clés restent protégées.
• N’affichez qu’un préfixe masqué dans votre tableau de bord, ainsi que la date de création et la dernière utilisation.
• Rendez la révocation immédiate et renvoyez 401 pour les clés révoquées.
• Permettez aux clients de limiter les droits des clés à certains modèles, projets ou plafonds de dépenses.

Python : générer, hacher et vérifier les clés

import hashlib
import hmac
import secrets

PREFIX = "sk-acme-"

def new_api_key() -> tuple[str, str]:
    """Return (plaintext key shown to the user once, hash to store)."""
    key = PREFIX + secrets.token_urlsafe(32)  # 32 random bytes
    return key, hashlib.sha256(key.encode()).hexdigest()

def verify(presented: str, stored_hash: str) -> bool:
    candidate = hashlib.sha256(presented.encode()).hexdigest()
    return hmac.compare_digest(candidate, stored_hash)  # constant-time compare

key, digest = new_api_key()
print(key[:12] + "...")   # show the full key once in the UI, never log it
print(verify(key, digest))  # True

Un hachage rapide tel que SHA-256 convient ici, car la clé est longue et aléatoire, contrairement à un mot de passe choisi par une personne. Stockez l’empreinte, un identifiant de clé, le propriétaire, le périmètre d’autorisation et les horodatages.

Node.js : charger une clé depuis l’environnement et bloquer par défaut en cas d’échec

// Never fall back to a hardcoded default key.
const apiKey = process.env.FLATKEY_API_KEY;
if (!apiKey || !apiKey.startsWith("sk-fk-")) {
  throw new Error("FLATKEY_API_KEY is missing or malformed");
}

const res = await fetch("https://router.flatkey.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-haiku-5-5",
    messages: [{ role: "user", content: "ping" }],
    max_tokens: 5,
  }),
});
console.log(res.status); // log the status, never the header

Vérifier qu’une clé révoquée est bien inutilisable

La révocation n’est prouvée que lorsque l’ancienne clé échoue. Après chaque rotation ou incident, exécutez une vérification de ce type depuis une machine de confiance :

# Expect 401 for the revoked key; do not echo the key itself
OLD_KEY="$(cat /run/secrets/old_flatkey_key)"
status=$(curl -s -o /dev/null -w "%{http_code}" \
  https://router.flatkey.ai/v1/models \
  -H "Authorization: Bearer $OLD_KEY")
if [ "$status" = "401" ]; then echo "revoked OK"; else echo "STILL ACTIVE: $status"; fi

Consignez le résultat et l’heure dans votre journal de rotation. La documentation Flatkey précise que la révocation est immédiate et que toute requête utilisant une clé révoquée reçoit 401 Unauthorized, sans délai de grâce (documentation des clés API Flatkey).

Comment Flatkey facilite l’application de ces bonnes pratiques

Flatkey fournit un point de terminaison compatible avec OpenAI (https://router.flatkey.ai/v1) pour de nombreux fournisseurs de modèles, ce qui réduit le nombre de clés de fournisseurs dispersées dans vos services. Selon la documentation des clés API Flatkey (vérifiée le 27 octobre 2026) :

• Vous pouvez créer plusieurs clés : une par environnement, application ou membre d’équipe, avec des noms descriptifs comme prod-customer-chatbot.
• La clé sk-fk- complète n’est affichée qu’une seule fois. La page Clés présente ensuite le nom, la date de création, l’horodatage de dernière utilisation et un préfixe masqué.
• La révocation est immédiate : déployez donc la clé de remplacement avant de révoquer l’ancienne.
• Toutes les clés partagent le solde du compte et peuvent accéder à tous les modèles par défaut. Utilisez les Groupes dans la console pour limiter une clé à certains modèles ou définir un quota de dépenses.

La documentation sur l’utilisation décrit des journaux par requête indiquant le modèle, les tokens, le coût et la clé, ainsi qu’un plafond mensuel de dépenses et des alertes par e-mail en cas de solde faible, ce qui couvre les pratiques 10 et 11. Pour les grandes organisations, la documentation de l’offre entreprise Flatkey décrit des sous-clés organisées en arborescence, avec leurs propres budgets et listes de modèles autorisés. Une passerelle ne remplace pas votre propre authentification des clients, la classification des données et les bonnes pratiques de journalisation ; continuez donc à appliquer le reste de cette liste de contrôle. Pour démarrer, consultez le guide de démarrage de l’intégration Flatkey.

Architecture de référence pour les produits IA multifournisseurs

Une configuration multifournisseur sécurisée peut s’organiser en cinq couches :

1. Couche d’identité du client : authentifie l’utilisateur, l’appareil, l’agent ou l’application sans exposer les identifiants des fournisseurs.
2. Couche d’autorisation applicative : vérifie les droits d’utilisation du produit, les frontières entre locataires, l’accès aux fonctionnalités et les budgets.
3. Couche de politique des données : classe et expurge les prompts, les fichiers, le contexte récupéré et les arguments des outils.
4. Couche de passerelle et de routage : sélectionne les modèles approuvés, applique les quotas, enregistre les informations d’attribution non secrètes et gère le basculement.
5. Couche des identifiants fournisseurs : stocke des identifiants fournisseurs isolés, assure la rotation des versions et ne les expose qu’à la charge de travail de routage de confiance.

Cette conception limite l’étendue des conséquences. Un jeton client compromis ne révèle pas automatiquement une clé de fournisseur. Une identité de charge de travail compromise ne doit pas donner accès à tous les fournisseurs. Un identifiant de fournisseur divulgué ne doit pas autoriser l’accès à tous les environnements. Une défaillance de journalisation ne doit pas exposer à la fois le secret et la charge utile complète.

Liste de contrôle pour la production

Utilisez cette liste avant le lancement et lors des revues trimestrielles des contrôles.

Conservation et identité

• [ ] Aucune clé de fournisseur à longue durée de vie n’est livrée dans le code du navigateur, d’une application mobile ou de bureau, ou d’une extension.
• [ ] Chaque charge de travail de production dispose d’un responsable identifiable et d’un circuit d’accès aux identifiants connu.
• [ ] Les accès de production, de préproduction, de développement, d’évaluation et les accès locaux sont séparés.
• [ ] Les clés partagées entre personnes ont été remplacées par des identités de charges de travail ou de passerelle lorsque c’est possible.
• [ ] Les restrictions du fournisseur et de la passerelle limitent les droits au périmètre le plus étroit possible en pratique.

Stockage et mise à disposition

• [ ] La source de référence est un stockage de secrets géré ou une liaison de déploiement contrôlée.
• [ ] Les applications récupèrent les secrets uniquement à l’exécution et ne les affichent ni ne les sérialisent.
• [ ] Les tâches CI reçoivent uniquement les secrets nécessaires à l’étape concernée.
• [ ] Les accès aux secrets et les modifications administratives sont audités.
• [ ] L’accès d’urgence est documenté, limité dans le temps et testé.

Données et observabilité

• [ ] Les en-têtes d’autorisation et les valeurs des clés sont exclus des journaux, des traces, des erreurs et des exports de support.
• [ ] La journalisation des prompts, des sorties, des fichiers et des arguments d’outils suit un schéma de champs autorisés.
• [ ] L’expurgation a lieu avant le routage multifournisseur.
• [ ] L’utilisation peut être attribuée à une charge de travail, un environnement, une route, un fournisseur, un modèle et une version de clé.
• [ ] Les alertes couvrent les routes et les identités inhabituelles ainsi que les dépenses.

Rotation et réponse aux incidents

• [ ] Une procédure testée de rotation à double clé ou à secrets versionnés est disponible.
• [ ] Les anciennes clés sont révoquées chez le fournisseur et leur inutilisabilité est vérifiée.
• [ ] La détection des secrets et la protection des envois couvrent les dépôts et les artefacts générés.
• [ ] Une fuite suspectée déclenche des mesures immédiates de confinement sans attendre de preuve d’abus.
• [ ] Le délai entre exposition et révocation est mesuré après les exercices et les incidents.

FAQ

Quelles sont les bonnes pratiques de gestion des clés API ?

Gardez les clés hors du code source et des applications clientes, utilisez une clé distincte par environnement et charge de travail, limitez chaque clé aux API, aux modèles et au budget nécessaires, stockez les clés dans un gestionnaire de secrets, planifiez et testez leur rotation, supprimez les clés inutilisées, activez la détection des secrets, ne journalisez jamais les clés et révoquez-les immédiatement lorsqu’une fuite est suspectée.

Faut-il stocker une clé API dans une variable d’environnement ?

Les variables d’environnement sont un moyen raisonnable de transmettre une clé à un processus, mais elles ne constituent pas un système de gestion. La valeur doit provenir d’un gestionnaire de secrets ou du mécanisme d’injection de secrets de votre plateforme, avec contrôle d’accès, rotation et audit. N’incluez jamais de fichiers .env dans vos commits.

À quelle fréquence faut-il renouveler les clés API ?

Choisissez un intervalle en fonction du risque et des contrôles de votre fournisseur ; de nombreuses équipes renouvellent les clés d’IA de production tous les 90 jours et immédiatement après des changements de personnel ou une exposition suspectée. L’essentiel est que la rotation soit répétée en exercice, que l’ancienne clé soit révoquée et que cette révocation soit vérifiée.

Un navigateur ou une application mobile peut-il appeler directement un fournisseur d’IA avec une clé API ?

Évitez cette approche. Tout élément livré sur un appareil peut en être extrait. Faites authentifier le client auprès de votre backend et laissez le backend ou la passerelle appeler le modèle avec une clé côté serveur et des limites par utilisateur.

Que faire si une clé API est divulguée sur GitHub ?

Considérez-la comme compromise. Créez une clé de remplacement, basculez les charges de travail vers celle-ci, révoquez la clé divulguée, confirmez qu’elle renvoie 401, examinez l’utilisation pendant la période d’exposition et ajoutez la détection des secrets ou la protection des envois pour éviter une récidive. Supprimer le commit ne rend pas la clé sûre.

Une seule clé de passerelle est-elle plus sûre que plusieurs clés de fournisseurs ?

Elle réduit le nombre de secrets dans votre code, mais concentre les autorisations. Utilisez des clés de passerelle distinctes par environnement et charge de travail, limitez-les par modèle et par plafond de dépenses, et protégez les clés des fournisseurs derrière la passerelle avec autant de soin qu’auparavant.

Comment stocker les clés API que je délivre à mes propres utilisateurs ?

Stockez uniquement une empreinte de chaque clé, affichez la clé complète une seule fois lors de sa création, présentez ensuite un préfixe masqué et permettez une révocation immédiate.

Sources et lectures complémentaires

• OWASP : aide-mémoire sur la gestion des secrets
• OWASP : aide-mémoire sur la journalisation
• GitHub : à propos de la détection des secrets
• GitHub : à propos de la protection des envois
• Google Cloud : bonnes pratiques de gestion des clés API
• Flatkey : créer et gérer des clés API

Guides Flatkey connexes : politique d’expurgation des API d’IA, architecture des passerelles API pour l’IA et comprendre les limites de débit des LLM.