Configurer un modèle personnalisé dans Continue fait de la clé à la fois un laissez-passer et une frontière de coût et de sécurité. Une clé créée sans réflexion entraîne souvent une consommation anormale, des usages impossibles à attribuer et des clés encore actives après le départ d'un membre.

En 2026, Continue a été racheté par Cursor, le dépôt principal n'est plus activement maintenu et le Hub hébergé ainsi que le service de connexion ont fermé. La gestion des clés revient donc au local : un config.yaml, un .env et plusieurs clés de passerelle séparées par personne et par usage. Cet article suit l'ordre création, stockage, multi-modèles, rotation, politique et diagnostic.

État du projet : en juin 2026, Continue a été racheté par Cursor ; le dépôt principal est passé en lecture seule et n'est plus activement maintenu ; le Hub hébergé et le service de connexion ont fermé. L'extension et la CLI restent utilisables, mais sans maintenance active ; les correctifs de sécurité sont à évaluer par vos soins.

Marques : Continue est une marque de Continue Dev, Inc. ; Cursor est une marque d'Anysphere, Inc. Cet article est purement technique, sans lien d'affiliation ni de représentation avec ces sociétés ; l'état du produit et les champs de configuration font foi selon les pages de l'éditeur et la version installée.

1. Distinguer les types de clés dans Continue

L'expression « clé API Continue » est souvent employée à tort. En pratique, au moins quatre types d'identifiants coexistent, de sources et d'usages différents :

Type Émetteur Usage Toujours applicable ?
Clé de passerelle ZSQH AI Gateway et services compatibles Appeler plusieurs modèles via le protocole compatible OpenAI Oui, objet principal de cet article
Clé de fournisseur OpenAI, Anthropic, Google, etc. Appeler directement l'interface du fournisseur Oui, champs et adresses différents
Modèle local Aucune clé, par exemple Ollama ou LM Studio Inférence sur la machine ou le réseau interne Oui, sans secret
Compte Continue ou identifiant Hub Ancienne plateforme Continue Connexion, assistants partagés, synchronisation d'équipe Non, fermé avec le Hub

« Clé API Continue » désigne donc généralement l'identifiant côté modèle que vous placez dans le champ apiKey, et non une clé universelle émise par l'éditeur. Cet article traite de la clé de passerelle ; elle commence souvent par sk-, mais ne permet ni de se connecter à Continue ni d'appeler les interfaces de l'ancienne plateforme.

2. Créer une clé de passerelle : définir les limites avant de copier

Avant de créer, déterminez à qui elle sert, pour quel projet et pour quel plafond de consommation.

  1. Ouvrez la page d'inscription à ZSQH AI Gateway, créez un compte et connectez-vous à la console.
  2. Dans « Clés API », créez une clé.
  3. Incluez l'utilisateur et l'appareil dans le nom, par exemple continue-zhang-macbook, pas seulement test.
  4. Fixez un plafond de quota et une expiration ; si la console permet de restreindre les modèles, limitez-les par projet.
  5. Vérifiez le solde ou l'état de recharge, pour ne pas découvrir après configuration que les appels sont impossibles.
  6. Copiez la clé dans un gestionnaire de mots de passe, sans l'envoyer d'abord dans un outil de chat, un ticket ou un groupe.

Préférez une clé par personne et par appareil. Une clé partagée semble pratique, mais une consommation anormale ne peut pas être attribuée et un départ rend la désactivation globale délicate. Modèles et tarifs évoluent ; la page tarifs des modèles fait foi.

3. Placer la clé dans .env, pas dans config.yaml

Continue permet de référencer un secret dans config.yaml avec la syntaxe Mustache :

apiKey: ${{ secrets.ZSQH_API_KEY }}

Définissez ensuite la valeur dans un fichier .env :

# ~/.continue/.env
ZSQH_API_KEY=sk-votre-cle-passerelle

Quelques détails :

  • N'ajoutez pas de guillemets autour de la valeur dans .env ; respectez le format KEY=value de la FAQ de l'éditeur.
  • Ne validez pas .env dans Git ; ajoutez-le à .gitignore.
  • Sous macOS/Linux, exécutez chmod 600 ~/.continue/.env pour restreindre les permissions.
  • Après modification du .env, redémarrez l'IDE pour que l'extension le relise.
  • Si config.yaml doit être versionné, ne conservez que le placeholder ${{ secrets.nom }}, jamais la clé en clair.

Écrire la clé dans le YAML fonctionne aussi, mais dès que le fichier est copié, capturé ou validé, la clé se diffuse. Avec .env et un placeholder, la configuration se partage et le secret reste dans l'environnement personnel.

4. Configuration multi-modèles : une clé pour plusieurs rôles

La section models de Continue est une liste pouvant contenir plusieurs entrées. Chaque entrée a son name, son model et ses roles, et peut réutiliser la même clé :

name: zsqh-continue
version: 0.0.1
schema: v1

models:
  - name: Dialogue et édition principaux
    provider: openai
    model: YOUR_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_API_KEY }}
    roles: [chat, edit, apply]
    capabilities: [tool_use]

  - name: Autocomplétion
    provider: openai
    model: YOUR_FIM_MODEL_ID
    apiBase: https://ai.zhongshangqihang.com/v1
    apiKey: ${{ secrets.ZSQH_AUTOCOMPLETE_KEY }}
    roles: [autocomplete]

Les deux façons de séparer les clés ont chacune leur usage :

  • Une clé pour plusieurs modèles : adapté au développeur individuel, gestion simple et facturation centralisée.
  • Clés séparées par rôle : adapté aux équipes. Dialogue, complétion et embedding utilisent chacun une clé ; en cas d'anomalie de quota, on identifie rapidement le type de requête en cause.

Séparer les clés n'est pas une obligation, mais un moyen d'attribuer les coûts. Une petite équipe commence par personne, puis isole autocomplete quand son volume augmente.

Le modèle d'autocomplétion doit prendre en charge FIM ; un modèle de chat « qui sait aussi écrire du code » ne convient pas directement. Si la passerelle ne propose pas de modèle FIM adapté, gardez-la pour chat, edit et apply, et utilisez un petit modèle local pour la complétion.

5. Variables d'environnement et ordre de résolution des secrets

Lorsque Continue rencontre ${{ secrets.X }}, il cherche dans cet ordre :

  1. Le .env à la racine de l'espace de travail.
  2. Le .continue/.env de l'espace de travail.
  3. Le .env global ~/.continue/.env.
  4. Les variables d'environnement du processus.

Deux pièges fréquents.

Premièrement, l'extension IDE ne lit généralement pas les variables export du terminal. La FAQ de l'éditeur précise qu'un export OPENAI_API_KEY=... exécuté dans le shell n'est pas visible par Continue dans VS Code ou JetBrains ; les variables du processus concernent surtout Continue CLI. « Je l'ai défini dans le terminal » ne constitue donc pas une conclusion de diagnostic : il faut écrire le .env.

Deuxièmement, le .env de l'espace de travail prime sur le .env global. À l'ouverture d'un dépôt non fiable, vérifiez s'il contient un .env ; l'équipe doit l'ajouter aux règles d'exclusion.

6. Rotation, révocation et départs

Une clé ne doit pas rester en service indéfiniment. Prévoyez une rotation trimestrielle, et immédiate en cas de changement de membre, de perte d'appareil ou de suspicion de fuite :

  1. Créez dans la console une nouvelle clé de mêmes permissions et de même plafond.
  2. Écrivez la nouvelle clé au bon endroit dans .env et conservez l'ancienne quelque temps.
  3. Redémarrez l'IDE et vérifiez séparément Chat, Edit et la complétion.
  4. Confirmez dans les journaux de la passerelle que la nouvelle clé produit des requêtes normales.
  5. Observez un à deux jours pour vérifier qu'aucun client n'a été oublié.
  6. Désactivez ou supprimez l'ancienne clé dans la console.
  7. Notez la date de rotation, le responsable et le périmètre affecté.

En cas de suspicion de fuite, inversez l'ordre : désactivez d'abord, enquêtez ensuite. N'attendez pas de confirmation en continuant à utiliser la clé ; une consommation anormale ne patientera pas. Après désactivation, examinez les journaux de requêtes, la courbe d'usage et l'historique d'appels pour déterminer l'étendue des appels non prévus, puis décidez d'ajuster les quotas ou les règles d'alerte.

Au départ d'un membre, au changement de machine ou à la fin d'un projet, désactivez la clé le jour même et demandez à l'intéressé de supprimer son .env local. Une clé sur un appareil partagé ne doit pas rester durablement.

7. Stockage des secrets et politique d'équipe

  • La clé ne vit que dans le gestionnaire de mots de passe et le .env ; jamais dans le code, les captures, les tickets, les historiques de chat ou les enregistrements d'écran.
  • Une clé par personne, avec plafond et expiration par projet ; les comptes de service partagés ont une clé dédiée et une diffusion restreinte.
  • Le modèle de configuration peut être versionné, mais uniquement avec ${{ secrets.nom }} ; chaque membre remplit son propre .env.
  • Rapprochez les comptes chaque mois : consommation par clé, par modèle et par membre ; en cas d'anomalie, désactivez avant d'enquêter.
  • Tenez une table des modèles et des clés : usage, responsable, quota, date de rotation.
  • Continue n'étant plus maintenu, ne comptez pas sur les fonctions d'équipe du plugin pour gérer les clés ; permissions, audit et révocation se font côté passerelle.
  • Les journaux de passerelle peuvent contenir des métadonnées de requête. Pour du code sensible, vérifiez d'abord la politique de conservation et de journalisation de la passerelle avant d'ouvrir un projet.

Une politique de sécurité doit répondre à trois questions : à qui appartient cette clé, quelle consommation est permise, et comment l'arrêter en cas de problème.

8. Dépannage : 401 et configuration sans effet

Face à un 401, vérifiez dans cet ordre :

  1. Le .env existe-t-il, et s'agit-il de ~/.continue/.env ou du .env de l'espace de travail ?
  2. Le nom de variable correspond-il exactement à ${{ secrets.nom }} dans config.yaml, casse comprise ?
  3. La valeur contient-elle des espaces, guillemets ou sauts de ligne en début ou fin ? Une copie depuis une fenêtre de chat apporte souvent des caractères invisibles.
  4. L'IDE a-t-il été redémarré après modification du .env ?
  5. La clé est-elle désactivée ou expirée, et le compte dispose-t-il d'un solde ?
  6. Est-ce config.yaml ou l'ancien config.json qui est réellement chargé ?
  7. apiBase pointe-t-il vers l'environnement de la clé ? Une clé de test configurée sur une adresse de production peut aussi renvoyer 401.

Autres symptômes courants :

  • 404 : /v1 en trop ou manquant dans apiBase, ou identifiant de modèle inexistant.
  • 429 : quota, débit ou concurrence dépassés ; lisez le corps d'erreur et l'usage avant de réessayer à l'aveugle.
  • Échec isolé de la complétion : vérifiez que le modèle autocomplete est bien un modèle FIM et si une autre clé est utilisée.
  • Échec de résolution uses: : le Hub a fermé ; remplacez la référence distante par provider, model et apiKey en ligne.
  • Nouveau modèle absent du sélecteur : vérifiez l'indentation YAML, les roles et l'état de rechargement après sauvegarde.

Ne modifiez qu'une variable à la fois pendant le diagnostic. Changer simultanément la clé, l'adresse et le modèle empêche d'identifier la cause, même après rétablissement.

9. Questions fréquentes

La clé API Continue est-elle émise par un compte Continue ?

Non. Continue n'émet pas de clé de modèle universelle ; vous renseignez un identifiant émis par un fournisseur de modèles ou une passerelle. La connexion et l'hébergement de l'ancienne plateforme Continue ont fermé et ne peuvent plus servir de source de clé.

J'ai exporté la clé dans le terminal, pourquoi l'IDE renvoie-t-il encore 401 ?

Continue dans VS Code et JetBrains ne lit généralement pas les variables du shell. Écrivez la clé dans ~/.continue/.env ou dans le .env de l'espace de travail, puis redémarrez l'IDE. Les variables du processus concernent surtout la CLI.

Peut-on écrire la clé directement dans config.yaml ?

Cela fonctionne, mais ce n'est pas recommandé. Le fichier de configuration entre facilement dans un dépôt, est copié ou capturé. Utilisez le placeholder ${{ secrets.nom }} et laissez la valeur en clair dans .env et le gestionnaire de mots de passe.

Faut-il une clé différente par modèle ?

Non. Une clé peut appeler plusieurs modèles. Séparer les clés sert à distinguer responsabilités, quotas et facturation, surtout pour une équipe organisée par personne, rôle ou projet.

Que faire en premier après une fuite de clé ?

Désactivez la clé dans la console de la passerelle, puis créez une nouvelle clé de remplacement. Examinez ensuite l'usage et les journaux de requêtes pour cerner les appels anormaux, avant d'ajuster quotas, règles d'alerte ou autres identifiants.

Pour aller plus loin

Créez d'abord une clé de test sur ZSQH AI Gateway, validez la séquence « stockage dans .env, référence dans la configuration, redémarrage et vérification », puis transformez-la en modèle d'équipe. La disponibilité des modèles et les tarifs actuels sont indiqués sur la page tarifs des modèles.

Lectures associées :