> ## Documentation Index
> Fetch the complete documentation index at: https://docs.responsibleailabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Applications

> Comment les clés API, les environnements et la politique de gouvernance s'articulent.

Une **application** est la manière dont RAIL organise les produits IA que vous surveillez. Chaque application possède ses propres clés API, son propre environnement et sa propre politique de gouvernance. Lorsque vous évaluez un contenu avec une clé, la politique attachée à l'application de cette clé décide de la manière dont le résultat est traité.

## Le modèle

<Steps>
  <Step title="Organisation">
    Votre compte appartient à une organisation, qui détient une ou plusieurs applications ainsi que les membres de votre équipe.
  </Step>

  <Step title="Application">
    Chaque application représente un produit ou une surface IA que vous souhaitez gouverner, par exemple un chatbot de support ou un outil de résumé. Elle porte une [politique](/concepts/policy-engine) et vit dans un environnement (actuellement `production`).
  </Step>

  <Step title="Clé API">
    Les clés sont rattachées à une seule application. Chaque évaluation effectuée avec cette clé est gouvernée par la politique de cette application. Créez et gérez les clés dans le [tableau de bord](https://responsibleailabs.ai/dashboard).
  </Step>
</Steps>

## Consulter votre configuration

Comme une clé est liée à une application, vous pouvez demander à l'API ce qui la gouverne. Ces endpoints en lecture seule fonctionnent avec n'importe quelle clé `rail_` :

<CardGroup cols={3}>
  <Card title="Configuration" icon="gear" href="/api-reference/config">
    L'application et la politique auxquelles votre clé est liée, et si l'application des règles est active.
  </Card>

  <Card title="Dimensions" icon="chart-simple" href="/api-reference/dimensions">
    Les 8 dimensions RAIL et la manière dont votre application les pondère.
  </Card>

  <Card title="Capabilities" icon="list-check" href="/api-reference/capabilities">
    Les fonctionnalités et limites disponibles pour votre forfait.
  </Card>
</CardGroup>

## La politique provient de l'application

Vous ne transmettez pas de règles de gouvernance à chaque requête. Chaque application porte une politique, configurée une seule fois dans le tableau de bord et appliquée automatiquement à chaque évaluation effectuée par ses clés. Une nouvelle application démarre en mode observation seule, donc rien n'est bloqué tant que vous n'avez pas choisi d'appliquer les règles. Consultez le [Moteur de politiques](/concepts/policy-engine) pour savoir ce que contient une politique et comment se comportent les modes d'application (journalisation, blocage, régénération).

**Verrouillée vs déverrouillée.** Par défaut, une politique est *déverrouillée* : les paramètres par requête tels que `mode`, `domain` et `weights` remplacent les valeurs par défaut de la politique, ce qui est pratique pendant que vous expérimentez. Lorsque vous *verrouillez* une politique, ces paramètres de requête sont ignorés et la politique fait autorité — utile une fois que vous avez arrêté la gouvernance que vous voulez voir appliquée par chaque clé de l'application. Vérifiez l'état actuel à tout moment avec [`GET /config`](/api-reference/config).

## Environnements

Une application s'exécute dans un environnement — actuellement `production`. Les environnements permettent à une application de séparer, par exemple, le trafic de production du staging plus tard ; pour l'instant, chaque clé est émise pour `production`.

<Note>
  La modification d'une politique nécessite un accès au tableau de bord. Les clés API servent à évaluer et à lire la configuration, pas à la modifier.
</Note>