Passer au contenu principal
Vous ne faites presque jamais tourner une seule clé. Un vrai espace de travail a une clé de production, une clé de staging, la clé locale d’un développeur, peut-être une clé ponctuelle pour un test de charge — toutes appelant les mêmes modèles à travers la même passerelle. Distinguez-les avec le tag environment : une courte étiquette libre que vous estampillez sur chaque clé pour que la console, votre équipe et l’onglet Suivi d’utilisation puissent grouper les clés par l’endroit où elles tournent. C’est le petit champ d’organisation, pas un champ d’application — il ne change pas ce qu’une clé peut faire. Pour les limites qui bornent une clé (modèles, IPs, dépense, expiration, politiques) commencez à la vue d’ensemble des clés à portée limitée.

​
1. Pourquoi le tag d’environnements de clé API

Quand chaque clé ressemble à sk-orca-•••• dans la liste, vous ne pouvez pas distinguer la clé de production d’une clé de dev jetable — et c’est exactement la clé que vous ne voulez pas faire tourner, révoquer, ou dont vous ne voulez pas relever le plafond de dépense par erreur. Le tag environment transforme une credential anonyme en une credential étiquetée :
  • D’un coup d’œil — la liste de clés montre quelles clés sont prod, staging, ou dev, donc vous agissez sur la bonne.
  • Par dépense — l’onglet Suivi d’utilisation peut replier la dépense par environnement, donc « combien nous coûte staging cette semaine » est un seul filtre, pas un tableur.
  • Par convention — un vocabulaire partagé (prod / staging / dev) dans l’espace de travail, de sorte qu’un coéquipier lisant la liste comprend votre organisation sans demander.
Le tag est libre et descriptif uniquement. Il ne garde pas les modèles, les IPs, la dépense ou la politique — ce sont les autres champs de clé. Deux clés taguées prod n’obtiennent aucun traitement spécial au-delà du partage d’une étiquette.

​
2. Ce que le champ accepte

environment est une étiquette de texte courte et optionnelle sur l’objet clé :
PropriétéComportement
TypeChaîne libre — aucun enum fixe. prod, staging, dev sont des conventions, pas des valeurs intégrées.
LongueurDébarrassée des espaces environnants et limitée à 32 caractères ; tout ce qui dépasse est tronqué.
Vide / non définiUne clé sans tag se relit comme l’état non étiqueté et se replie dans un segment unlabeled dans le Suivi d’utilisation.
Effet sur le traficAucun — purement organisationnel.
Choisissez un vocabulaire petit et stable et tenez-vous-y. prod, staging, dev suffit pour la plupart des équipes ; la cohérence est ce qui rend le tag utile quand vous filtrez la dépense. Un champ de texte libre avec prod, Prod et production dedans en défait l’objectif.

​
3. Définir le tag sur une clé

Définissez environment dans l’éditeur de clé de la console (/console/token) — au même endroit que les limites de modèles et les attachements de politique. Créer ou modifier des clés requiert le rôle Developer ou supérieur.
1

Ouvrir la clé

Dans la console, allez à Clés (/console/token) et créez une nouvelle clé ou modifiez-en une existante.
2

Définir l'étiquette d'environnement

Entrez une courte étiquette — par ex. prod — dans le champ Environnement. Gardez-la sous 32 caractères.
3

Enregistrer

Le tag est maintenant attaché à la clé. Il apparaît dans la liste de clés et devient disponible comme dimension de Suivi d’utilisation.
Modifier une clé pour changer un champ sans rapport (un renommage, un nouveau plafond de dépense) préserve le tag d’environnement existant — le tag n’est changé que lorsque vous le définissez explicitement. Pour effacer un tag, fixez le champ à une valeur vide ; c’est une réinitialisation intentionnelle vers l’état non étiqueté.

​
4. Segmenter la dépense par environnement

Une fois vos clés taguées, l’onglet Suivi d’utilisation (console → Aperçu) peut grouper la dépense, les requêtes et les tokens par la dimension environnement. Il replie l’usage de chaque clé sous son étiquette d’environnement, les clés non taguées collectées sous unlabeled. Cela répond à des questions que la vue par clé ne peut pas, au niveau où vous budgétez réellement :
  • Combien staging dépense-t-il par rapport à prod cette semaine ?
  • La nouvelle clé dev a-t-elle dépassé ce que nous attendions ?
  • Quel environnement a provoqué le pic mardi ?
La même vue segmente aussi par clé, modèle, membre, et tâche de cas d’usage — l’environnement est celui qui correspond à où le trafic a tourné. La segmentation de dépense ne lit que les lignes de consommation, scopées à votre espace de travail, de sorte que les chiffres s’alignent avec la Facturation.
La dimension environnement lit l’étiquette actuelle de chaque clé au moment où vous chargez le rapport. Retaguer une clé change la façon dont sa dépense historique se replie la prochaine fois que vous ouvrez la vue — le tag est une propriété vivante de la clé, pas un timbre figé sur les requêtes passées.

​
5. Un exemple travaillé : trois clés, un espace de travail

Une petite équipe faisant tourner un produit sur trois environnements :
CléenvironmentAutre portée (la partie qui applique réellement)
Agent de productionprodfirewall_policy_id serré, credit_limit_usd hebdomadaire, allow_ips épinglé
Agent de stagingstagingune politique firewall permissive en mode shadow, un plafond plus bas
Dev localdevmodel_limits à un seul modèle bon marché, expired_time à court terme
Les tags ne changent aucune de ces limites — ils rendent les trois clés lisibles. La liste se lit d’un coup d’œil, l’onglet Usage montre trois barres de dépense au lieu de trois ids de clé opaques, et quand vous faites tourner la clé prod vous êtes certain d’avoir saisi la bonne.
Associez le tag d’environnement à une application réelle pour que chaque clé soit à la fois étiquetée et bornée. Le tag vous dit ce qu’est une clé ; la checklist de moindre agence s’assure qu’elle ne peut pas faire plus que ce dont cet environnement a besoin.

​
6. Tags vs. application — ne confondez pas les deux

Le tag d’environnement est le champ le plus léger d’une clé. Il est facile de s’en saisir comme contrôle de sécurité ; ce n’en est pas un. Si vous voulez qu’une clé dev soit incapable de toucher les modèles de production ou de dépenser de l’argent réel, l’étiquette ne fera pas cela — les champs d’application le feront :

Limites de modèles

model_limits est ce qui empêche réellement une clé de dev d’appeler un modèle frontière — pas le tag dev.

Quota, plafond & expiration

credit_limit_usd et expired_time bornent la dépense et la durée de vie. Le tag organise ; ceux-ci contraignent.

Lier des politiques

guardrail_id et firewall_policy_id attachent les politiques de contenu et d’appels d’outils qui gouvernent le trafic de la clé.

L'objet token

La référence complète champ par champ d’une clé, tag d’environnement inclus.

​
7. Où cela s’inscrit

Le tag d’environnement est une tranche du modèle de clé plus large — des identités étroites et étiquetées pour chaque agent et chaque endroit où il tourne.

Vue d'ensemble des clés à portée limitée

Le hub de chaque champ qu’une clé porte.

Portée & clés

Comment les espaces de travail, politiques et clés s’imbriquent ensemble.

Gérer les clés

Créer, modifier et révoquer des clés dans la console.
Un tag est l’investissement le moins cher dans un espace de travail ordonné : quelques caractères par clé, et la différence entre une liste que vous pouvez lire et une que vous ne pouvez pas. Estampillez chaque clé avec son environnement dès l’instant où vous la créez — et laissez les autres champs faire l’application.