Gérer les clés API

Ce guide vous montre où est stocké chaque identifiant utilisé par Control Center et comment le modifier.

Rien n’est stocké sur la machine sur laquelle vous tapez. Chaque identifiant vit sur le serveur ; celui qui répond à une requête donnée dépend de la présence ou non d’un humain derrière elle.

Identifiant	Emplacement	Utilisé par
Votre identifiant de forge ou de tickets	Le fichier de secrets en 0600 du serveur, indexé par votre identifiant d’utilisateur	Tout ce que vous demandez : la surface des PR, vos exécutions d’agents, vos images
L’identité d’application du serveur	Le même fichier, plus `server_settings` pour les éléments non secrets	Le travail que personne n’a demandé : webhooks, interrogation périodique des PR, synchronisation des tickets
Clés de fournisseurs de modèles et jetons OAuth	Le magasin d’identifiants propre au serveur	L’adaptateur intégré, pour chaque espace de travail de l’installation
Jetons de robot Slack	`<dataDir>/<workspaceId>/chat_credentials/` sur le serveur	La passerelle de clavardage de cet espace de travail
Identifiants de CLI externe	Ce que cette CLI utilise	Claude Code, sur l’hôte du serveur

Deux identifiants GitHub, qui répondent à des questions différentes

Le vôtre, obtenu en vous connectant (flux d’appareil) ou en collant un jeton. C’est lui qu’utilise chaque requête faite en votre nom, de sorte qu’un commentaire publié pour vous porte votre nom. Un autre membre ne peut pas le lire et connecte le sien
Celui du serveur, issu de la GitHub App enregistrée par l’exploitant. Il répond à tout ce qui n’a pas d’appelant — l’accès à la forge ne disparaît donc pas quand une personne part ou effectue la rotation d’un jeton

Le vôtre se définit dans la carte Hébergement de code sous Paramètres → Espace de travail → Profil et identité ; celui du serveur, dans Applications fournisseur sous Paramètres → Serveur → Authentification unique. Voir Configurer l’intégration GitHub et Créer la GitHub App.

Définir les clés des fournisseurs de modèles

L’adaptateur intégré authentifie lui-même les fournisseurs, et ces identifiants vivent sur le serveur.

Allez dans Paramètres → Serveur → Fournisseurs de modèles
Faites défiler jusqu’à Fournisseurs et modèles
Connectez le fournisseur — OAuth par navigateur pour OpenAI, Codex, Cursor et Kimi Code ; une clé API pour Anthropic et les autres

Voir Gérer les adaptateurs et les modèles pour la liste complète et pour ajouter un point de terminaison personnalisé.

Ces identifiants sont globaux à l’hôte : une seule clé sert chaque espace de travail de l’installation. Les jetons OAuth sont rafraîchis avant leur expiration.

Les CLI des adaptateurs externes conservent leurs propres identifiants, dans leur propre configuration, sur l’hôte du serveur — Control Center ne les gère pas. Authentifiez Claude Code comme l’indique sa propre documentation, sur la machine où cc_server s’exécute.

La boîte de dialogue Variables d’environnement propre à chaque adaptateur semble être l’endroit où déposer une clé pour l’un d’eux, mais ce n’est pas le cas : elle écrit sur votre appareil, tandis que le serveur lit sa propre copie et rien ne relie les deux. Voir Gérer les adaptateurs et les modèles.

Connecter un fournisseur de tickets

La carte Tickets sous Paramètres → Espace de travail → Général regroupe les deux volets d’une même décision : chez quel fournisseur vivent vos tickets, et l’identifiant correspondant. Choisir Local masque la ligne d’identifiant — les tickets locaux vivent dans la base de données de ce serveur et n’ont rien à authentifier.

Votre clé est stockée sur le serveur en fonction de votre identifiant d’utilisateur, comme celle de la forge. Le serveur conserve séparément sa propre clé Linear (Applications fournisseur), et c’est elle que la synchronisation des tickets utilise quand aucun humain n’a rien demandé. Aucune clé de tickets n’est injectée dans le bac à sable d’un agent ; les agents écrivent les tickets via les outils de Control Center, qui interrogent la règle Écrire dans un outil de suivi externe. Voir Configurer l’intégration Linear.

Effectuer une rotation ou révoquer

Votre identifiant GitHub : appuyez sur Déconnecter, puis reconnectez-vous ou collez le nouveau jeton. Révoquez l’ancien sur GitHub
L’application du serveur : générez une nouvelle clé privée ou un nouveau secret client sur la page GitHub de l’application, collez-le dans Applications fournisseur et appuyez sur Tester
Un fournisseur de modèles : sur sa ligne, déconnectez-vous (OAuth) ou supprimez la clé, puis reconnectez-vous
Slack : recollez les jetons dans la boîte de dialogue de connexion. Voir Configurer l’intégration Slack

Dépannage

La liste des PR est vide, mais mon jeton fonctionne dans `curl`

Vérifiez le sous-titre de la ligne Hébergement de code. S’il nomme une autre source (« via l’application de ce serveur », « depuis l’environnement »), l’identifiant que vous testez n’est pas celui qui répond — le vôtre n’a pas été enregistré.

Le jeton est accepté, mais les requêtes suivantes échouent

Le jeton est sondé tel qu’il est stocké, donc la ligne nomme le compte derrière lui — mais seulement le compte, pas les portées. Un jeton ayant trop peu de portées se connecte, puis échoue à des requêtes individuelles. Vérifiez les portées et la date d’expiration :

curl -H "Authorization: token YOUR_TOKEN" https://api.github.com/user