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 Agents Locaux

Des agents qui agissent sur ta machine : Cline agentique, MCP, n8n + Ollama, automatisations locales.

  • Espace en ligne à vie
  • PDF + fichiers
  • Mises à jour à vie
Le kit Agents Locaux →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é.

#Quel modèle selon la mémoire disponible

La documentation officielle est catégorique sur un point souvent minimisé : Goose s'appuie massivement sur l'appel d'outils, et un modèle qui ne le gère pas ne peut faire que de la conversation simple — toutes les extensions Goose doivent alors être désactivées. Le choix du modèle n'est donc pas qu'une question de qualité de réponse : c'est une condition binaire pour que les extensions MCP fonctionnent du tout.

Ordre de grandeur mémoire (Q4, poids seuls) et usage réaliste avec Goose
Taille de modèleVRAM approximativeUsage réaliste avec des extensions
7-8B≈ 5 GoTool-calling instable sur des tâches à plusieurs outils enchaînés ; tester avec GOOSE_TOOLSHIM avant de conclure à un échec du modèle
14B≈ 9 GoCas d'usage courant pour un poste de développement ; vérifier la balise tools sur ollama.com avant de charger le modèle
32B≈ 19-20 GoPlus fiable sur des séquences d'outils longues, au prix d'un temps de génération plus élevé sur GPU grand public
70B≈ 40 GoRéservé aux postes avec beaucoup de VRAM ou de RAM unifiée (Mac Studio, stations multi-GPU) ; rarement pertinent pour un usage quotidien local

Ces ordres de grandeur ne remplacent pas la vérification de la balise tools sur la fiche du modèle : une variante non annoncée compatible tool-calling échoue sur les extensions quelle que soit sa taille, exactement comme le précise la documentation officielle citée plus haut.

#Checklist de sécurité avant un déploiement partagé

Trois réglages, déjà documentés séparément dans ce guide, forment ensemble la base d'un déploiement Goose plus sûr qu'une installation par défaut sur un poste partagé ou un serveur d'équipe.

Checklist avant d'ouvrir Goose à d'autres utilisateurs ou à des extensions sensibles
Point de contrôleRéglage à vérifier
Mode de permissionPasser de complètement autonome à approbation manuelle ou intelligente si la suppression de fichiers sans confirmation n'est pas souhaitée
Extensions installablesDéfinir GOOSE_ALLOWLIST vers un fichier YAML hébergé qui restreint les identifiants et commandes autorisés
Capacité réelle du modèleConfirmer la balise tools sur ollama.com avant de connecter des extensions ; un modèle incompatible impose de toutes les désactiver
Contexte suffisantRelever OLLAMA_CONTEXT_LENGTH au-delà de 4096 pour éviter une troncature silencieuse des instructions de sécurité elles-mêmes (.goosehints)
!
L'allowlist ne remplace pas le choix du mode
Une allowlist bien configurée limite les extensions installables, mais n'empêche pas un agent en mode autonome d'utiliser sans confirmation les extensions déjà autorisées. Les deux réglages se complètent, ils ne se substituent pas l'un à l'autre.

#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 — un changement de gouvernance à connaître avant de bâtir un workflow d'équipe dessus, même si Block reste impliqué dans le projet.
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 plutôt que de renvoyer une erreur explicite. La documentation officielle recommande de le relever via la variable d'environnement OLLAMA_CONTEXT_LENGTH, par exemple à 32768, avant de chercher une autre cause.
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, remplaçable via GOOSE_TOOLSHIM_OLLAMA_MODEL). Si le modèle mélange des balises de raisonnement aux appels d'outils, le tool shim les filtre aussi automatiquement une fois activé.
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, à faire avant la première session avec des extensions sensibles.
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 séparée du modèle de conversation, à choisir plus petit si les réponses deviennent lentes.
Un modèle local sans tool-calling peut-il quand même servir avec Goose ?+
Oui, mais uniquement pour discuter : la documentation officielle précise que Goose s'appuie massivement sur l'appel d'outils, et qu'un modèle qui ne le gère pas ne peut faire que de la conversation simple, toutes les extensions devant alors être désactivées. Vérifier la balise tools sur ollama.com avant de charger un modèle évite cette limitation.
Comment restreindre les extensions MCP que Goose peut installer ?+
Définir la variable GOOSE_ALLOWLIST vers un fichier YAML hébergé qui liste les identifiants et commandes d'extensions autorisés ; Goose le relit à chaque redémarrage. C'est une mesure pensée pour un déploiement en entreprise, à combiner avec un mode de permission non autonome plutôt qu'à utiliser seule.
Ce guide vous a aidé ?

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