> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Secrets dans ARIA
> Stockez des secrets personnels, comme des jetons d’API, et permettez à ARIA de les utiliser comme variables d’environnement dans sa sandbox.
Disponible uniquement dans le [Cloud mutualisé de W\&B](/fr/products/wandb/platform/hosting#wb-multi-tenant-cloud).
Les *secrets personnels* stockent des valeurs sensibles, comme des jetons d’API, qui vous sont propres. Lorsque vous accordez à ARIA l’accès à un secret personnel, ce secret devient une variable d’environnement dans la sandbox où ARIA exécute du code, ce qui permet à ARIA de s’authentifier auprès d’un service externe en votre nom. Par exemple, vous pouvez stocker un jeton d’accès personnel GitHub et autoriser ARIA à lire vos dépôts, à effectuer un enregistrement sur une branche ou à ouvrir une pull request. Voir [Connecter un dépôt GitHub](#connect-a-github-repository).
Les secrets personnels sont distincts des [secrets d’équipe](/fr/products/wandb/platform/secrets), que les administrateurs gèrent dans les paramètres de l’équipe. Les secrets personnels sont limités à vous seul et à l’organisation sélectionnée dans votre sélecteur de compte : si vous stockez votre jeton GitHub en tant que secret personnel, les autres membres de votre équipe ne peuvent pas l'utiliser. Un secret personnel est prioritaire sur un secret d’équipe du même nom.
Comment ARIA utilise un secret partagé
Lorsque vous accordez à ARIA l’accès à un secret personnel, la sandbox d’ARIA reçoit une variable d’environnement portant exactement le nom du secret, dès le prochain message que vous envoyez dans une conversation. Il n’est pas nécessaire de démarrer un nouveau chat. La révocation de l’accès fonctionne de la même manière : la variable disparaît de la sandbox dès votre prochain message.
À noter :
* La valeur du secret est masquée dans la sortie de la sandbox affichée dans le chat.
* Un secret partagé ne peut pas remplacer une variable d’environnement managée, telle que `WANDB_API_KEY`. Un secret dont le nom entre en conflit avec une variable managée, ou n’est pas un nom de variable d’environnement valide, est ignoré et n’est pas transmis à la sandbox.
* ARIA ne peut utiliser que les secrets auxquels vous lui avez donné accès, dans l’organisation à laquelle appartient la conversation.
Un secret partagé est accessible à tout code qu’ARIA exécute dans sa sandbox en votre nom. Les autorisations de l’identifiant d’authentification déterminent ce qu’ARIA peut en faire : un jeton GitHub disposant d’un accès en lecture permet à ARIA de lire du code et des résultats, tandis qu’un jeton disposant des autorisations d’écriture et de pull request lui permet également d’effectuer un enregistrement des modifications et d’ouvrir des pull requests.
Créer un secret personnel
Pour créer un secret personnel et autoriser ARIA à l’utiliser :
1. Dans le coin supérieur droit de la page, sélectionnez la liste déroulante **User menu**, puis sélectionnez **Settings**.
2. Faites défiler la page jusqu’à la section **Personal secrets**.
3. Cliquez sur **New secret**. Si vous n’avez encore aucun secret personnel, cliquez plutôt sur **Create new secret**.
4. Saisissez un nom dans le champ **Name**, au format d’une variable d’environnement : lettres, chiffres et caractères de soulignement (`_`), sans commencer par un chiffre. Par exemple, `GITHUB_TOKEN`.
Si un secret d’équipe portant le même nom existe déjà, le volet latéral vous le signale. Votre secret personnel est prioritaire sur le secret d’équipe.
5. Collez la valeur sensible dans le champ **Value**.
6. Laissez l’option **Allow ARIA to use this secret** activée (valeur par défaut) pour qu’ARIA puisse accéder au secret dès sa création. Désactivez-la pour stocker le secret sans en accorder l’accès à ARIA.
7. Cliquez sur **Save secret**.
Accorder ou révoquer l’accès d’ARIA
Vous pouvez modifier à tout moment les secrets personnels qu’ARIA peut utiliser, depuis vos paramètres utilisateur ou depuis le panneau ARIA. Dans les deux cas, la modification s’applique dès votre prochain message dans une conversation.
Depuis vos paramètres utilisateur
Dans la section **Personal secrets** de vos paramètres utilisateur, la ligne de chaque secret comporte un interrupteur **ARIA access**. Activez-le pour autoriser ARIA à accéder à ce secret, ou désactivez-le pour révoquer cet accès.
Depuis le panneau ARIA
1. Dans la fenêtre de chat ARIA, ouvrez la barre latérale de l’historique de conversation si elle est masquée : cliquez sur **** (**Reveal chat history**).
2. Dans la section **Customize**, cliquez sur **Secrets**. Le volet répertorie vos secrets personnels dans l’organisation actuelle, et la synthèse indique combien d’entre eux sont disponibles pour ARIA.
3. Activez l’interrupteur d’un secret pour en accorder l’accès à ARIA, ou désactivez-le pour révoquer cet accès.
Pour créer et gérer les secrets proprement dits, cliquez sur **** (**Manage personal secrets in settings**) en haut du volet : la section **Personal secrets** de vos paramètres utilisateur s’ouvre.
Connecter un dépôt GitHub
L’usage le plus courant des secrets dans ARIA consiste à connecter GitHub. Avec un jeton d’accès personnel GitHub stocké en tant que secret personnel, ARIA peut lire le code de vos dépôts et, si le jeton le permet, effectuer des enregistrements sur une branche et ouvrir des pull requests. Rien n’est installé ni autorisé côté GitHub en dehors du jeton : les actions possibles d’ARIA dépendent donc uniquement du jeton que vous créez.
Pour commencer, cliquez sur la puce de suggestion **Connect my GitHub repo** dans la fenêtre de chat, ou envoyez `/connect-github`. Cette puce apparaît sur la plupart des pages, comme le workspace d’un projet, mais pas dans la vue autonome d’ARIA. ARIA vous demande quel dépôt vous souhaitez connecter et s’il doit disposer d’un accès en écriture, puis vous guide à travers les étapes suivantes.
1. Créer un jeton d’accès personnel GitHub
Dans GitHub, accédez à **Settings** > **Developer settings** > **Personal access tokens** et créez un jeton :
* **Jeton à granularité fine** (recommandé) : définissez le propriétaire de la ressource (resource owner) sur votre compte ou sur l’organisation propriétaire du dépôt, limitez **Repository access** aux dépôts que vous souhaitez connecter, et configurez **Repository permissions** selon ce que doit faire ARIA : **Contents** en Read-only pour la lecture, ou en Read and write pour les commits, et **Pull requests** en Read and write pour ouvrir des pull requests. GitHub ajoute automatiquement un accès en lecture seule à **Metadata**. Un propriétaire de l’organisation devra peut-être approuver le jeton avant qu’il ne soit opérationnel.
* **Classic token** : la portée `repo` couvre la lecture, les commits, les branches et les pull requests sur les dépôts privés ; `public_repo` couvre les dépôts publics. Dans une organisation qui utilise le SSO SAML, autorisez également le jeton pour cette organisation via **Configure SSO**.
GitHub n’affiche la valeur du jeton qu’une seule fois, lors de sa création : copiez-la donc avant de quitter la page.
2. Enregistrer le jeton comme secret personnel et accorder l’accès à ARIA
Suivez les étapes de la section [Créer un secret personnel](#create-a-personal-secret) pour stocker le jeton. Nommez-le `GITHUB_TOKEN`, le nom habituel, ou donnez-lui tout autre nom de variable d’environnement valide, puis vérifiez que l’accès d’ARIA à ce secret est bien activé.
À partir de votre prochain message, le jeton est disponible dans la sandbox d’ARIA sous la forme d’une variable d’environnement portant le nom que vous avez choisi.
3. Approuver l’accès réseau à GitHub
Par défaut, la sandbox dans laquelle ARIA exécute du code peut accéder aux services Weights & Biases, mais bloque la plupart des autres domaines. L’accès à GitHub nécessite donc lui aussi une autorisation d’accès réseau. Lorsque ARIA doit accéder à GitHub, il demande dans le chat l’accès aux domaines nécessaires à la tâche, explique pourquoi et attend votre réponse : `api.github.com` pour les appels d’API GitHub, et `github.com` pour cloner ou téléverser. Cliquez sur **Grant access** pour approuver, ou sur **Deny** pour refuser. Une autorisation reste valable pendant toute la session de chat en cours, et pas seulement pour le message qui l’a déclenchée ; en revanche, elle ne s’étend pas à vos autres chats. Voir [Accorder l’accès réseau](/fr/products/aria/chat#grant-network-access).
Ce qu’ARIA peut faire une fois le dépôt connecté
Une fois le jeton accordé et l’accès réseau approuvé, demandez à ARIA, en langage naturel, de travailler sur le dépôt. Selon les autorisations du jeton, ARIA peut :
* Lire et analyser du code, par exemple en clonant un dépôt ou en récupérant des fichiers précis.
* Valider (enregistrement) des modifications sur une branche, puis les pousser (téléverser).
* Ouvrir une pull request contenant ses modifications.
Par exemple, après avoir connecté un dépôt, vous pouvez demander :
```text title="User prompt" theme={"system"}
Clone my-org/training-scripts, ajoute des métriques de validation dans train.py, puis ouvre une pull request.
```
Résoudre les problèmes de connexion
Si une requête GitHub échoue, ARIA signale l’erreur renvoyée par GitHub et propose une solution. Causes fréquentes :
* **`401 Bad credentials`** : GitHub a rejeté le jeton. Il a peut-être été mal saisi, ou bien il a expiré ou été révoqué. Créez un nouveau jeton, mettez à jour la valeur du secret dans **Personal secrets**, puis renvoyez votre requête.
* **`404 Not Found` pour un dépôt dont vous savez qu’il existe** : GitHub renvoie une erreur 404, et non 403, lorsqu’un jeton n’a pas accès à un dépôt privé. Vérifiez que le jeton peut y accéder :
* Pour un jeton à granularité fine (fine-grained), le propriétaire de la ressource doit être le compte ou l’organisation propriétaire du dépôt, le dépôt doit figurer sous **Repository access** et, si l’organisation exige une approbation, un propriétaire de l’organisation doit avoir approuvé le jeton.
* Pour un jeton classique, celui-ci doit disposer de la portée `repo` et, dans une organisation qui utilise le SSO SAML, être autorisé pour cette organisation.
* **`403 Forbidden` lors d’un commit ou de l’ouverture d’une pull request** : le jeton peut lire le dépôt, mais ne dispose pas de l’autorisation d’écriture. Accordez l’accès en lecture et écriture à **Contents** et à **Pull requests**, ou utilisez un jeton classique avec la portée `repo`.
* **ARIA indique que le secret n’est pas défini** : activez l’interrupteur **ARIA access** du secret, puis envoyez un autre message. Si vous accordez l’accès à un secret après votre dernier message, ARIA ne le verra qu’à partir du message suivant.