Avancé 12 minAgents

Goose (Block) : l'agent IA local dans votre terminal

Réponse directe

Oui : lancez goose configure, choisissez Ollama, laissez http://localhost:11434 par défaut et indiquez un modèle Ollama compatible tool-calling. Deux réglages comptent en local : relever OLLAMA_CONTEXT_LENGTH au-delà des 4096 tokens par défaut, et activer le tool shim (GOOSE_TOOLSHIM=true) si le modèle explique les outils en texte au lieu de les appeler. Goose est désormais un projet de l'Agentic AI Foundation, plus seulement de Block.

Goose est un agent IA en ligne de commande et en application de bureau, initialement publié par Block puis transféré à l'Agentic AI Foundation. Ce guide couvre sa configuration avec un Ollama local, le tool shim qui compense l'absence de tool-calling natif sur certains modèles, les modes de permission (autonome par défaut) et les limites réelles d'un petit modèle local face à ses extensions MCP.

Par Mohamed Meguedmi·Màj 2026-09-28·Testé sur Windows, macOS, Linux

#Ce qu'est Goose aujourd'hui

Goose se présente comme un agent IA natif open source — application de bureau, CLI et API — pour le code, les workflows et au-delà, écrit en Rust. Le dépôt (désormais aaif-goose/goose) compte près de 55 000 étoiles au 28 septembre 2026, avec la version v1.52.0 publiée le 23 septembre 2026.

Fait à corriger si vous avez lu des présentations plus anciennes : Goose n'est plus un projet Block isolé, il fait désormais partie de l'Agentic AI Foundation (AAIF) hébergée par la Linux Foundation. Block reste à l'origine du projet, mais la gouvernance a changé — un détail qui compte pour évaluer la pérennité du projet avant de bâtir un workflow dessus.

Goose fonctionne avec plus de 15 fournisseurs de modèles (Anthropic, OpenAI, Google, Ollama, OpenRouter, Azure, Bedrock, et d'autres) et se connecte à plus de 70 extensions via le protocole ouvert MCP (Model Context Protocol).

Il existe aussi une passerelle vers Ramalama, un moteur local qui sert des modèles au format d'artefacts OCI plutôt qu'avec le format propriétaire d'Ollama. Son API étant compatible, Goose peut l'utiliser directement via son fournisseur Ollama, sans code spécifique — une option utile sur des infrastructures déjà construites autour d'outils de conteneurisation standard (Podman, Docker) plutôt qu'autour d'Ollama.

#Connecter Ollama

Le kit Copilote Local

Ce guide t'amène au modèle. Le kit t'amène au copilote qui code dans ton éditeur.

  • Espace en ligne à vie
  • PDF + fichiers
  • Remboursé 30 j
Le kit Copilote Local →ou tous les kits à vie — 49 € →

La configuration passe par l'assistant interactif goose configure, qui demande le fournisseur puis l'hôte. Pour Ollama, si aucun hôte n'est renseigné, Goose utilise localhost:11434 par défaut ; le préfixe http:// est ajouté automatiquement si le schéma n'est pas précisé.

Terminal
ollama run qwen2.5
# dans un second terminal
goose configure

Pour un Ollama qui tourne sur une autre machine du réseau, il faut définir explicitement OLLAMA_HOST=http://{hôte}:{port} avant de lancer la configuration. Pour des modèles hébergés sur ollama.com plutôt qu'en local, le fournisseur à choisir est Ollama Cloud, pas Ollama.

i
Modèle recommandé pour débuter
La documentation officielle utilise qwen2.5 comme exemple de modèle à lancer avant de configurer Goose, en insistant sur le fait qu'il doit être annoncé compatible tool-calling — pas n'importe quel modèle de chat généraliste.

#Le piège du contexte à 4096 tokens

Le défaut d'Ollama pour la fenêtre de contexte est 4096 tokens, et il tronque silencieusement plutôt que de renvoyer une erreur explicite. Sur un agent comme Goose qui charge des instructions de projet (.goosehints), l'historique de conversation et les définitions d'extensions, ce plafond est vite atteint.

!
Symptôme typique
Si Goose ignore vos fichiers .goosehints ou semble perdre le fil avec des extensions actives, la documentation officielle pointe en premier lieu ce contexte par défaut trop court, à relever via la variable d'environnement OLLAMA_CONTEXT_LENGTH avant de chercher ailleurs.
Contexte étendu
export OLLAMA_CONTEXT_LENGTH=32768

#Tool shim : réparer l'appel d'outils

Certains modèles n'ont pas de support natif de l'appel d'outils, ou basculent en cours de session vers une sortie en texte brut au lieu d'un appel structuré. Le tool shim de Goose détecte ces formats textuels et les convertit en appels d'outils exécutables. C'est une fonctionnalité marquée expérimentale par le projet.

Activer le tool shim
export GOOSE_TOOLSHIM=true
ollama pull mistral-nemo

Le tool shim s'appuie sur un modèle interprète séparé du modèle de conversation principal — mistral-nemo par défaut via Ollama, remplaçable par GOOSE_TOOLSHIM_OLLAMA_MODEL. La documentation cite explicitement les modèles locaux (Ollama, llama.cpp) sans tool-calling natif comme cas d'usage principal, ainsi que les modèles qui mélangent des balises de raisonnement (« think ») avec les appels d'outils, source fréquente d'échecs de parsing.

Un mode alternatif utilise le backend d'inférence local intégré de Goose au lieu d'une instance Ollama séparée, via GOOSE_TOOLSHIM_BACKEND=local et un nom de modèle obligatoire (GOOSE_TOOLSHIM_MODEL) — sans quoi le démarrage échoue.

#Modes de permission : autonome par défaut

Goose propose quatre modes de permission : complètement autonome (modifie et supprime des fichiers sans confirmation), approbation manuelle (demande confirmation pour chaque outil), approbation intelligente (approuve automatiquement les actions à faible risque) et mode conversation seule (aucune modification, aucun outil).

!
Le mode autonome est actif dès l'installation
La documentation officielle le précise sans détour : le mode autonome (Autonomous Mode) est appliqué par défaut. Sur un poste où Goose a accès à des extensions capables de supprimer des fichiers ou d'exécuter des commandes, changer explicitement de mode avant la première session est une précaution à ne pas sauter.

Le changement de mode se fait à tout moment, y compris en cours de session, via /mode auto, /mode smart_approve, /mode approve ou /mode chat en CLI, ou depuis le menu du bas dans l'application de bureau.

#Extensions MCP et allowlist

Goose se connecte à des extensions via le protocole MCP, et installe par défaut n'importe quel serveur MCP demandé. Pour un contexte professionnel, le projet propose une allowlist : un fichier YAML hébergé sur une URL, référencé par la variable GOOSE_ALLOWLIST, qui limite les extensions installables à une liste explicite d'identifiants et de commandes.

Sans cette allowlist, rien n'empêche techniquement l'agent d'installer un serveur MCP tiers non vérifié si l'utilisateur (ou le modèle, en mode autonome) en fait la demande — un point à considérer conjointement avec le choix du mode de permission ci-dessus.

L'allowlist se déploie comme un simple fichier YAML listant des couples identifiant/commande autorisés, hébergé à une URL que Goose relit à chaque redémarrage via la variable GOOSE_ALLOWLIST. C'est une mesure pensée pour un déploiement en entreprise, où un administrateur veut restreindre les extensions installables à une liste validée à l'avance plutôt que de faire confiance au jugement de chaque utilisateur ou du modèle en mode autonome.

  1. 01
    Installer la CLI Goose
    curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash, ou télécharger l'application de bureau depuis la documentation officielle.
  2. 02
    Préparer le modèle Ollama
    Vérifier qu'Ollama tourne sur le port 11434 et lancer un modèle explicitement annoncé compatible tool-calling avant de configurer Goose.
  3. 03
    Lancer goose configure
    Choisir Ollama comme fournisseur, valider l'hôte proposé par défaut (localhost:11434) et indiquer le nom exact du modèle chargé.
  4. 04
    Relever le contexte si nécessaire
    Si l'agent ignore des extensions ou un fichier .goosehints, définir OLLAMA_CONTEXT_LENGTH à une valeur supérieure à 4096 avant de relancer une session.
  5. 05
    Vérifier le mode de permission
    Avant la première session avec des extensions sensibles, passer explicitement en mode approbation manuelle ou intelligente si le mode autonome par défaut n'est pas souhaité.

#Limites d'un modèle local pour Goose

Ce qui casse en premier avec un petit modèle local
SymptômeCause probable documentée
Extensions ignorées, .goosehints non suiviContexte par défaut à 4096 tokens trop court : relever OLLAMA_CONTEXT_LENGTH
Appels d'outils qui s'arrêtent en cours de sessionLe modèle bascule vers une sortie texte : activer GOOSE_TOOLSHIM
Interprète du tool shim lentModèle interprète trop lourd : passer à un modèle plus petit via GOOSE_TOOLSHIM_OLLAMA_MODEL
Raisonnement mélangé aux appels d'outilsBalises « think » parasites : le tool shim les filtre automatiquement une fois activé

Le natif DeepSeek-R1 ne prend pas en charge l'appel d'outils selon la documentation officielle, qui propose en alternative une version communautaire adaptée pour Goose — un exemple concret de l'écart entre un modèle réputé puissant en conversation et sa capacité réelle à piloter des outils.

Ce décalage entre puissance de raisonnement et fiabilité d'exécution est la limite structurelle à retenir avant d'installer Goose en local : un modèle qui répond bien à des questions ouvertes ne garantit rien sur sa capacité à enchaîner des appels d'outils sans erreur de format. Tester d'abord une tâche simple et vérifiable — lire un fichier, exécuter une commande anodine — avant de confier à l'agent une tâche à plusieurs étapes reste le moyen le plus rapide de repérer un modèle mal adapté.

Questions fréquentes
Goose est-il toujours développé par Block ?+
Block est à l'origine du projet, mais Goose fait désormais partie de l'Agentic AI Foundation, hébergée par la Linux Foundation. Le dépôt a d'ailleurs changé d'organisation GitHub, de block/goose vers aaif-goose/goose.
Pourquoi Goose ignore-t-il mes extensions ou mon fichier .goosehints avec Ollama ?+
La cause la plus fréquente est le contexte par défaut d'Ollama, limité à 4096 tokens et tronqué silencieusement. La documentation officielle recommande de le relever via la variable OLLAMA_CONTEXT_LENGTH.
Que faire si mon modèle local n'appelle pas les outils dans Goose ?+
Activer le tool shim avec GOOSE_TOOLSHIM=true. Cette fonctionnalité expérimentale détecte les appels d'outils écrits en texte brut par des modèles sans support natif et les convertit en appels exécutables, via un modèle interprète séparé (mistral-nemo par défaut).
Goose peut-il supprimer des fichiers sans demander confirmation ?+
Oui, en mode par défaut : le mode complètement autonome, actif dès l'installation selon la documentation officielle, permet à Goose de modifier et supprimer des fichiers sans approbation. Passer en mode approbation manuelle ou intelligente change ce comportement.
Faut-il un GPU puissant pour faire tourner Goose en local ?+
Goose lui-même est un client léger en Rust ; l'essentiel de la charge dépend du modèle choisi via Ollama ou un autre fournisseur local. Le modèle interprète du tool shim ajoute une charge d'inférence supplémentaire, à choisir plus petit si les réponses deviennent lentes.
Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.