Zed + Ollama : l'éditeur ultra-rapide avec assistant local

#Configurer Ollama dans Zed

La documentation officielle de Zed décrit une marche à suivre en quatre étapes : télécharger et installer Ollama, tirer un modèle, vérifier que le serveur Ollama tourne, puis sélectionner ce modèle dans le menu déroulant de Zed.

ollama pull mistral
ollama serve

Sur macOS, lancer l'application Ollama.app suffit à démarrer le serveur ; sur Linux ou depuis un shell, la commande ollama serve fait la même chose. Zed est présenté par son éditeur comme un éditeur de code multi-utilisateurs et hautes performances, créé par les auteurs d'Atom et de Tree-sitter ; la dernière version stable au 28 septembre 2026 est v1.21.0, publiée le 23 septembre 2026, et le dépôt comptait près de 91 000 étoiles sur GitHub à la même date.

Cette configuration Ollama sert l'ensemble des fonctionnalités IA de Zed qui s'appuient sur un modèle de langage : le panneau Agent pour des tâches multi-fichiers, l'assistant en ligne (Inline Assistant) pour des modifications ciblées dans l'éditeur, et les threads de terminal qui laissent l'agent proposer des commandes. Les agents externes et les threads de terminal peuvent toutefois exiger leur propre configuration de modèle local, séparée de celle décrite ici pour les fonctionnalités natives de Zed.

#Détection automatique des modèles

Zed détecte automatiquement les modèles qu'Ollama a déjà téléchargés et les propose dans le menu de sélection. Pour désactiver cette détection et lister soi-même les modèles avec leurs capacités précises, il faut passer auto_discover à false dans les réglages.

{
  "language_models": {
    "ollama": {
      "api_url": "http://localhost:11434",
      "auto_discover": false,
      "available_models": [
        {
          "name": "qwen2.5-coder",
          "display_name": "qwen 2.5 coder",
          "max_tokens": 32768,
          "supports_tools": true,
          "supports_thinking": true,
          "supports_images": true
        }
      ]
    }
  }
}

Ce mode manuel a un intérêt pratique : forcer supports_tools ou max_tokens pour un modèle que Zed ne classerait pas correctement automatiquement, ou documenter dans le fichier de configuration versionné du projet quel modèle l'équipe est censée utiliser.

Le champ supports_tools mérite une attention particulière : c'est lui qui indique à Zed si le modèle peut recevoir des définitions d'outils dans l'agent Zed (édition de fichiers, exécution de commandes) plutôt qu'être cantonné à un simple chat. Un modèle Ollama sans capacité d'appel d'outils déclarée fonctionnera pour l'assistant en ligne ou l'autocomplétion, mais pas pour les tâches multi-fichiers du panneau Agent.

#La fenêtre de contexte à 4096 tokens

Zed transmet la longueur de contexte à Ollama via le paramètre num_ctx, avec 4096 tokens par défaut selon la documentation officielle. C'est nettement inférieur à la fenêtre native de la plupart des modèles récents (souvent 32 000 tokens ou plus), et un fichier de taille moyenne peut suffire à dépasser ce plafond.

{
  "language_models": {
    "ollama": {
      "context_window": 8192
    }
  }
}

Ce réglage context_window s'applique à tous les modèles Ollama configurés dans Zed ; un contexte différent par modèle se définit via max_tokens dans available_models, en désactivant auto_discover pour que la valeur soit prise en compte.

#llama.cpp et LM Studio, les alternatives locales

Zed prend en charge llama.cpp au même titre qu'Ollama, avec une découverte automatique des modèles servis en mode routeur, affinée par un flux /models/sse qui exige une version récente du serveur llama.cpp. LM Studio est également supporté via son serveur API local, démarré avec lms server start.

#Permissions des outils de l'agent

Depuis la version 0.224.0, l'approbation des outils de l'agent Zed se règle via agent.tool_permissions.default ; avant cette version, un simple booléen (agent.always_allow_tool_actions, false par défaut) gouvernait l'ensemble. Le nouveau système permet des règles par motif regex, avec trois issues possibles : autoriser, refuser, ou toujours demander confirmation.

{
  "agent": {
    "tool_permissions": {
      "default": "allow",
      "tools": {
        "terminal": {
          "default": "confirm",
          "always_allow": [
            { "pattern": "^cargo\\s+(build|test|check)" }
          ],
          "always_confirm": [{ "pattern": "sudo\\s+/" }]
        }
      }
    }
  }
}

Cet exemple, tiré de la documentation officielle, autorise automatiquement des commandes cargo précises dans l'outil terminal tout en exigeant systématiquement une confirmation pour toute commande sudo touchant à la racine du système — une granularité utile quand le modèle branché est un petit modèle local moins prévisible qu'un modèle cloud de référence.

#Le bac à sable : ce qu'il protège vraiment

Au-delà des permissions déclaratives, Zed propose un bac à sable au niveau du système d'exploitation pour les appels d'outils de son agent. La documentation est précise sur son périmètre : il s'applique uniquement aux outils terminal et fetch, pas à Zed lui-même, ni aux serveurs de langage, extensions, tâches ou onglets de terminal classiques.

Outil terminal

Le bac à sable restreint les écritures sur le disque et l'accès réseau sortant des commandes lancées par l'agent ; les métadonnées Git sont protégées.

Outil fetch

Le bac à sable restreint les hôtes que l'agent peut effectivement contacter.

Prérequis Linux

Un binaire bwrap exécutable et non setuid doit être présent dans le PATH.

Prérequis Windows

WSL doit être disponible ; la documentation précise que le bac à sable y est plus faible que sous Linux ou macOS et peut ne pas bloquer toutes les tentatives d'évasion.

Ce périmètre limité (terminal et fetch seulement) est important à intégrer avant de confier des tâches sensibles à un petit modèle local moins prévisible : les modifications de fichiers faites via edit_file ou write_file passent par les permissions déclaratives et les profils d'agent, pas par l'isolation système du bac à sable. Une revue humaine reste donc utile sur ces actions, même avec le bac à sable actif sur le reste.

#Serveurs MCP dans Zed

Au-delà d'Ollama comme fournisseur de modèle, Zed utilise le Model Context Protocol pour interagir avec des serveurs de contexte externes : bases de données, gestionnaires de tickets, documentation d'entreprise. La documentation officielle précise que Zed prend en charge les fonctionnalités Outils et Prompts de MCP, ce qui donne à l'agent des capacités supplémentaires au-delà des outils intégrés (édition de fichiers, terminal).

Pour garantir qu'un serveur MCP précis soit effectivement utilisé plutôt que concurrencé par les outils intégrés de Zed, la documentation illustre un profil d'agent dédié (exemple donné avec le serveur container-use) qui désactive les outils intégrés et n'active que ceux du serveur MCP choisi, via enable_all_context_servers réglé sur false dans la configuration du profil.

{
  "enable_all_context_servers": false,
  "context_servers": {
    "container-use": {
      "tools": {
        "environment_create": true,
        "environment_add_service": true,
        "environment_update": true,
        "environment_run_cmd": true
      }
    }
  }
}

Cette granularité par profil rejoint le système de permissions par outil décrit plus haut : sur un modèle Ollama local moins prévisible qu'un modèle cloud de référence, limiter les outils réellement exposés à l'agent — qu'ils viennent d'un serveur MCP ou des capacités natives de Zed — réduit la surface d'erreur avant même d'aborder la question des permissions et du bac à sable.

• MCP : c'est quoi ? Le Model Context Protocol expliqué
• Connecter des serveurs MCP à Ollama

#L'édition prédictive (Zeta) aussi en local

Zed propose une fonctionnalité distincte de l'agent de chat : l'édition prédictive, qui suggère la modification suivante pendant que vous tapez, validée d'une pression sur Tab. Le fournisseur par défaut est Zeta, un modèle open source développé par Zed lui-même — distinct des modèles de conversation configurés pour le panneau Agent ou l'assistant en ligne.

Pour garder cette fonctionnalité entièrement locale, la documentation officielle permet de configurer un fournisseur Ollama dédié à l'édition prédictive, avec des variantes du modèle prévues pour cet usage (zeta2 notamment) plutôt que de réutiliser le modèle de chat déjà configuré pour l'agent — les deux réglages sont indépendants dans Zed. Un modèle plus petit, taillé pour prédire une seule modification à la fois plutôt que pour tenir une conversation multi-tours, répond généralement plus vite qu'un modèle de chat généraliste sur cette tâche précise, ce qui compte davantage ici que la capacité de raisonnement pure : la latence perçue pendant la frappe est le critère qui prime, bien avant la richesse des réponses.

#Ollama sur un serveur distant

Si Ollama tourne sur une autre machine ou exige une clé (cas d'Ollama Turbo, la version hébergée), la clé se saisit dans l'interface du fournisseur ou via la variable OLLAMA_API_KEY, et l'URL de l'API doit pointer vers l'endpoint distant plutôt que vers localhost.

Ce scénario distant a un intérêt concret pour une équipe : un unique serveur Ollama, dimensionné pour un modèle de taille correcte, peut servir plusieurs postes Zed configurés avec la même URL d'API, évitant à chaque développeur de faire tourner et de recharger le modèle sur sa propre machine. La fenêtre de contexte et les capacités déclarées (supports_tools, supports_thinking) restent alors à régler une seule fois, dans la configuration partagée du projet plutôt que dans les réglages personnels de chacun.

• Copilot local avec Cline : agent IA dans VS Code (Ollama)
• Cline + Ollama : agent de code 100 % local dans VS Code
• Continue.dev racheté par Cursor : migrer vers Cline en local
• Source : documentation officielle des modèles locaux dans Zed
• Source : documentation officielle du bac à sable de l'agent
• Source : documentation officielle des permissions d'outils