Accueil › Continue.dev › Configuration

Continue.dev : guide de configuration YAML complet

La puissance de Continue.dev vient de sa configuration. Un seul fichier YAML vous permet de définir vos modèles par rôle, vos context providers, vos serveurs MCP, vos prompts personnalisés et vos règles de comportement. Ce guide couvre chaque section du fichier config.yaml avec des exemples concrets et prêts à l’emploi.

Où se trouve le fichier de configuration ?

Continue utilise un fichier config.yaml stocké dans votre répertoire home :

Sur macOS et Linux : ~/.continue/config.yaml

Sur Windows : %USERPROFILE%.continueconfig.yaml

Pour l’ouvrir depuis l’IDE : dans le panneau Continue, cliquez sur le sélecteur de configuration en haut à droite de la zone de saisie du chat, puis sur l’icône engrenage à côté de « Local Config ». Le fichier s’ouvre dans votre éditeur. Quand vous sauvegardez, Continue recharge automatiquement la configuration sans redémarrage.

Continue crée un fichier par défaut lors de la première utilisation, avec des modèles publics de démonstration. Ce guide vous montre comment le personnaliser pour votre workflow.

Section models : configurer vos LLM

C’est la section la plus importante. Elle définit quels modèles IA sont disponibles et pour quels rôles. Continue permet d’assigner des modèles différents à chaque tâche, ce qui est l’un de ses avantages clés par rapport à Copilot ou Cursor.

Les rôles disponibles

Chaque modèle peut être assigné à un ou plusieurs rôles. Les rôles principaux sont chat (conversation dans le panneau latéral, Agent Mode et Chat Mode), edit (modifications ciblées via Edit Mode), autocomplete (suggestions inline à la frappe), apply (application des changements proposés), embed (génération d’embeddings pour la recherche sémantique @codebase), rerank (réordonnancement des résultats de recherche) et summarize (résumé de l’historique de conversation).

Configuration multi-modèles recommandée

Voici une configuration production-ready qui assigne le bon modèle à chaque rôle :

name: Ma Configuration
version: 1.0.0
schema: v1

models:
  # Chat et Agent : modèle puissant pour le raisonnement
  - name: Claude Sonnet 4.6
    provider: anthropic
    model: claude-sonnet-4-6-20250514
    apiKey: ${{ secrets.ANTHROPIC_API_KEY }}
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      temperature: 0.7
      maxTokens: 4096

  # Autocomplétion : modèle rapide et léger
  - name: Codestral
    provider: mistral
    model: codestral-latest
    apiKey: ${{ secrets.MISTRAL_API_KEY }}
    roles:
      - autocomplete
    autocompleteOptions:
      debounceDelay: 250
      maxPromptTokens: 1024
      onlyMyCode: true

  # Embeddings : pour la recherche sémantique @codebase
  - name: Ada Embeddings
    provider: openai
    model: text-embedding-ada-002
    apiKey: ${{ secrets.OPENAI_API_KEY }}
    roles:
      - embed
    embedOptions:
      maxChunkSize: 256
      maxBatchSize: 5

  # Modèle local pour le code confidentiel
  - name: Ollama Local
    provider: ollama
    model: codellama:34b
    roles:
      - chat

Cette configuration utilise Claude Sonnet pour le raisonnement (chat, agent, edit), Codestral pour la vitesse de l’autocomplétion, Ada pour les embeddings de recherche sémantique et un modèle Ollama local en option pour le code sensible. Vous basculez entre les modèles depuis le sélecteur dans l’IDE.

Options de complétion

Chaque modèle accepte des options de complétion personnalisées. Les paramètres les plus utiles : temperature (0.0 pour du déterministe, 0.7 pour un bon équilibre, 1.0 pour plus de créativité), maxTokens (limite de tokens en sortie), stop (tokens d’arrêt), reasoning (active le mode thinking pour Claude 3.7+) et reasoningBudgetTokens (budget de tokens de raisonnement).

Pour l’autocomplétion, les options spécifiques incluent debounceDelay (délai en millisecondes avant de déclencher la complétion, 250 ms est un bon compromis), maxPromptTokens (taille maximale du prompt envoyé au modèle) et onlyMyCode (ne contextualise qu’avec le code du repo, pas les dépendances externes).

Fournisseurs supportés

Continue supporte nativement Anthropic (provider: anthropic), OpenAI (provider: openai), Google/Gemini (provider: google), Mistral (provider: mistral), Ollama (provider: ollama), Azure OpenAI (provider: azure), Amazon Bedrock (provider: bedrock), Cohere (provider: cohere) et tout endpoint compatible OpenAI (provider: openai avec apiBase personnalisé). Cette dernière option couvre des services comme OpenRouter, Together, vLLM, LM Studio et vos propres endpoints custom.

Section context : enrichir le contexte IA

Les context providers définissent les sources d’information que vous pouvez injecter dans le chat via la syntaxe @.

context:
  - provider: file
  - provider: code
  - provider: docs
    params:
      sites:
        - title: Documentation React
          startUrl: https://react.dev/reference
          rootUrl: https://react.dev
  - provider: web
  - provider: terminal
  - provider: diff
  - provider: repo-map
  - provider: codebase

Les providers les plus utiles au quotidien : file (@file pour référencer un fichier spécifique), codebase (@codebase pour la recherche sémantique dans tout le repo, nécessite un modèle d’embeddings configuré), terminal (@terminal pour partager la sortie du terminal), docs (@docs pour de la documentation externe crawlée) et diff (@diff pour les changements Git en cours).

Le provider repo-map est inspiré d’Aider : il génère une carte des fichiers avec les signatures des classes, fonctions et méthodes de premier niveau. C’est utile pour que le modèle comprenne la structure de votre codebase sans charger chaque fichier en intégralité.

Section mcpServers : connecter des outils externes

Le protocole MCP (Model Context Protocol) permet de connecter Continue à des systèmes externes. Les serveurs MCP fournissent des outils (tools) et du contexte que l’agent peut utiliser pendant son exécution.

mcpServers:
  - name: SQLite Database
    command: uvx
    args:
      - mcp-server-sqlite
      - --db-path
      - /chemin/vers/ma/base.db

  - name: GitHub
    command: npx
    args:
      - -y
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  - name: Brave Search
    command: npx
    args:
      - -y
      - "@modelcontextprotocol/server-brave-search"
    env:
      BRAVE_API_KEY: ${{ secrets.BRAVE_API_KEY }}

Avec ces serveurs MCP configurés, l’Agent Mode de Continue peut requêter votre base de données SQLite, lire vos issues GitHub ou effectuer des recherches web pendant qu’il travaille. Les possibilités sont extensibles : n’importe quel serveur MCP compatible fonctionne avec Continue.

Section rules : guider le comportement de l’IA

Les rules sont des instructions textuelles qui s’appliquent à toutes les interactions avec l’IA. Elles servent à définir le ton, les conventions et les contraintes.

rules:
  - Donne des réponses concises et directes
  - Utilise TypeScript plutôt que JavaScript sauf indication contraire
  - Suis les conventions de nommage camelCase pour les variables
  - Ajoute toujours la gestion d'erreurs dans les fonctions async
  - Ne génère jamais de code qui utilise var, utilise const ou let
  - Commente le code en français

Les rules sont injectées dans le system prompt de chaque requête. C’est l’équivalent des fichiers .cursorrules de Cursor ou du CLAUDE.md de Claude Code. C’est simple, puissant et versionnable dans votre repo.

Section prompts : commandes slash personnalisées

Les prompts définissent des commandes slash réutilisables dans le chat.

prompts:
  - name: test
    description: Génère des tests unitaires
    prompt: |
      Écris des tests unitaires complets pour le code sélectionné.
      Utilise le framework de test Jest.
      Couvre les cas limites et les scénarios d'erreur.
      Ajoute une description pour chaque cas de test.

  - name: review
    description: Review du code sélectionné
    prompt: |
      Analyse le code suivant selon ces critères :
      1. Bugs potentiels ou comportements inattendus
      2. Performance et optimisation
      3. Sécurité (injection, validation d'entrée)
      4. Lisibilité et maintenabilité
      5. Conformité avec nos conventions (TypeScript, camelCase)
      Propose des corrections concrètes pour chaque problème identifié.

  - name: doc
    description: Génère la documentation
    prompt: |
      Génère la documentation JSDoc/TSDoc complète pour le code sélectionné.
      Inclus la description, les paramètres, le type de retour et des exemples.

Dans le chat, tapez /test, /review ou /doc avec du code sélectionné pour exécuter le prompt correspondant. Ces commandes sont partageables via le Continue Hub pour que toute l’équipe utilise les mêmes workflows.

Gestion des secrets

Ne mettez jamais vos clés API en clair dans le fichier de configuration. Continue offre deux mécanismes.

La syntaxe ${{ secrets.NOM }} référence un secret stocké dans le gestionnaire de secrets de Continue (accessible via l’IDE). C’est la méthode recommandée pour les configurations Hub partagées en équipe.

Pour les configurations locales, vous pouvez aussi utiliser des variables d’environnement système directement. Stockez vos clés dans votre ~/.zshrc, ~/.bashrc ou fichier .env de projet, et référencez-les via la syntaxe ${{ env.ANTHROPIC_API_KEY }}.

Sur les plans Team et Enterprise du Hub, les administrateurs peuvent distribuer les clés API de façon sécurisée : les développeurs utilisent les modèles sans jamais voir les clés. C’est essentiel pour les organisations qui veulent centraliser la gestion des accès API.

Configuration par workspace

Au-delà de la configuration globale (~/.continue/config.yaml), vous pouvez créer des configurations spécifiques par projet en plaçant un fichier .continue/config.yaml à la racine de votre repo. Cette configuration locale est automatiquement appliquée quand vous ouvrez le projet.

Cas d’usage typique : un projet React avec des règles TypeScript et un serveur MCP Playwright pour les tests, un projet Python avec des règles PEP 8 et un serveur MCP SQLite pour la base de données, et un projet Go avec des règles de formatage spécifiques. Chaque projet a ses propres modèles, rules, prompts et serveurs MCP.

Les configurations locales et globales se combinent : les éléments globaux s’appliquent partout, les éléments locaux s’y ajoutent (ou les écrasent) dans le contexte du projet.

Optimiser l’autocomplétion

L’autocomplétion est la fonctionnalité la plus utilisée au quotidien. Sa qualité dépend directement de votre configuration. Voici les réglages qui font la différence.

Utilisez un modèle dédié à l’autocomplétion. Les modèles de chat (Claude Sonnet, GPT-4) sont trop lents pour la complétion à la frappe. Codestral (Mistral), GPT-4.1 Nano (OpenAI) ou Starcoder (local via Ollama) sont conçus pour la vitesse et offrent une meilleure expérience.

Réglez le debounceDelay entre 200 et 300 ms. Trop bas (100 ms) et vous envoyez des requêtes à chaque frappe, ce qui gaspille des tokens. Trop haut (500 ms) et les suggestions arrivent trop tard pour être utiles. 250 ms est un bon compromis.

Activez onlyMyCode: true pour limiter le contexte au code de votre repo. Sans cette option, Continue peut inclure le contenu des dépendances (node_modules, etc.) dans le contexte, ce qui dilue la pertinence des suggestions et augmente le coût en tokens.

Le maxPromptTokens contrôle la taille du contexte envoyé au modèle d’autocomplétion. Une valeur de 1024 tokens est suffisante pour la plupart des cas. Augmentez à 2048 si vous travaillez sur des fichiers très longs avec des dépendances internes complexes.

Dépannage courant

« Not Supported » sur Agent Mode ou Plan Mode

Ce message apparaît quand le modèle sélectionné ne supporte pas les tools (appels de fonctions). Seuls les modèles avec la capacité tool_use peuvent utiliser l’Agent Mode. Claude 3.5+, GPT-4+, Gemini Pro et la plupart des modèles Ollama récents supportent les tools. Les anciens modèles ou les modèles très légers ne le supportent pas.

Si vous utilisez un endpoint custom ou OpenRouter, vous devrez peut-être déclarer explicitement les capacités du modèle dans la configuration :

models:
  - name: Mon modèle custom
    provider: openai
    apiBase: https://mon-endpoint.com/v1
    model: mon-modele
    capabilities:
      - tool_use
      - image_input
    roles:
      - chat
      - agent

Autocomplétion trop lente

Si les suggestions inline arrivent avec un délai perceptible, vérifiez d’abord que vous utilisez un modèle rapide pour le rôle autocomplete (pas Claude Sonnet ou GPT-4). Réduisez le maxPromptTokens. Activez onlyMyCode. Si vous utilisez Ollama, vérifiez que votre GPU a assez de VRAM pour le modèle choisi (un modèle 34B nécessite 16 Go+ de VRAM pour fonctionner à bonne vitesse).

@codebase ne retourne rien

Le provider @codebase nécessite un modèle d’embeddings configuré dans le rôle embed. Sans modèle d’embeddings, l’indexation sémantique n’est pas effectuée et les recherches @codebase retournent des résultats vides. Ajoutez un modèle Ada (OpenAI) ou un modèle d’embeddings local via Ollama.

Erreurs de clé API

Les erreurs d’authentification sont les plus fréquentes. Vérifiez que la syntaxe de la clé est correcte dans votre fichier de secrets ou vos variables d’environnement. Vérifiez que votre compte a des crédits (les comptes API prépayés sans crédit retournent une erreur 401 ou 403, pas un message explicite). Si vous utilisez ${{ secrets.NOM }}, assurez-vous d’avoir configuré le secret dans le gestionnaire de secrets Continue (accessible via l’icône de cadenas dans le panneau).

Conflit avec d’autres extensions IA

Si vous avez Copilot et Continue installés simultanément, les deux extensions peuvent proposer des suggestions d’autocomplétion en conflit. Désactivez l’autocomplétion de l’une des deux pour éviter les doublons. Dans VS Code, vous pouvez configurer quelles extensions ont la priorité pour les suggestions inline dans les settings de l’éditeur.

Configuration avancée : config.ts

Pour les cas où le YAML ne suffit pas, Continue supporte un fichier TypeScript (~/.continue/config.ts) qui peut modifier programmatiquement la configuration. Vous pouvez y ajouter des commandes slash dynamiques, des context providers custom avec logique métier, ou des intégrations non couvertes par le YAML standard.

C’est un cas d’usage avancé qui concerne principalement les platform engineers qui construisent des outils internes autour de Continue. Pour 95 % des utilisateurs, le YAML suffit largement.