Une configuration locale réunissant Qwen, Ollama et OpenCode a permis à David Gewirtz de créer un utilitaire Mac pour renommer des captures d’écran. Mais son projet d’organisation de PDF s’est enlisé au débogage. Le journaliste de ZDNET a mené cet essai sur un Mac Studio M4 Max doté de 128 Go de mémoire : ses résultats décrivent ces tâches et cette machine, pas les performances générales des agents locaux.

Pour évaluer un flux de programmation local, regardez ce qui tourne sur votre machine : le modèle, son moteur d’exécution et l’agent de programmation sont des composants différents.

Ce que la configuration locale a construit

Fenêtre de ScreenshotRename avec une liste de fichiers à gauche, un aperçu à droite, un champ de nom, le bouton Save et l’option d’afficher l’image suivante cochée.

Dans l’essai de David Gewirtz, OpenCode v2.2.5 joue le rôle d’agent de programmation, Ollama celui de moteur d’exécution local, et qwen3-coder-next:q4_K_M fournit le modèle. Gewirtz indique avoir utilisé un contexte de 64 000 tokens. Il décrit ce modèle comme comptant 80 milliards de paramètres, dont 3 milliards actifs à la fois.

Le résultat le plus abouti est un utilitaire de renommage de captures d’écran. Il ouvre un dossier, affiche une image à la fois, permet de saisir un nom de fichier, puis enregistre le changement et passe à l’image suivante. Gewirtz avait plus de 7 000 captures dans son dossier. Il rapporte avoir consacré presque six jours à l’application, dont quatre à essayer de faire fonctionner la liste de fichiers avant de reprendre cette partie dans une nouvelle session.

L’outil restait limité : il n’avait ni volets redimensionnables, ni modèles de noms ou de dates, ni zoom, ni raccourcis pour passer rapidement à l’image précédente ou suivante. Gewirtz explique avoir renoncé à ces fonctions pour éviter davantage de débogage.

Pourquoi le projet d’organisation de PDF a calé

Dans une autre tentative, Gewirtz a essayé de créer un outil qui organise des PDF. Il rapporte que la configuration pouvait identifier le sujet d’un document, mais ne répétait pas la tâche de façon fiable sur de gros lots. L’essai, qui a duré cinq jours, s’est enlisé pendant le débogage de nouvelles API de compréhension de documents exécutées sur l’appareil avec macOS 27.

Ce parcours donne une mesure concrète de l’effort demandé par ces tâches : le petit utilitaire a abouti, mais a nécessité plusieurs jours et des compromis sur ses fonctions ; le traitement de lots de PDF n’a pas été fiable dans cet essai. Ce sont les résultats rapportés par Gewirtz, pas un test comparatif de différentes configurations.

Une autre CLI, avec des modèles locaux ou cloud

Vidéo d’Eric Tech en anglais consacrée à Claude Code et Ollama

Local-CLI est une autre CLI d’agent de programmation. Son dépôt actuel décrit une installation avec Node.js 20 ou une version ultérieure :

npm install -g local-cli-agent
local-cli

Au premier lancement, un assistant permet de configurer l’endpoint, c’est-à-dire l’adresse du service qui fournit le modèle. Le dépôt décrit aussi un mode supervisé qui demande une approbation avant de modifier des fichiers, ainsi qu’un mode qui divise le travail en étapes. Ce sont les fonctions présentées par le dépôt actuel de Local-CLI.

ConfigurationAgent de programmationModèle et exécution
Essai de David GewirtzOpenCode v2.2.5Qwen via Ollama, sur sa machine
Local-CLILocal-CLIEndpoints compatibles avec l’API OpenAI, locaux, sur site ou cloud

Le dépôt cite notamment Ollama, vLLM et LM Studio pour les endpoints locaux, mais aussi Azure OpenAI et Google Gemini pour les services cloud. Local-CLI n’impose donc pas une exécution entièrement locale : le choix du fournisseur détermine où le modèle tourne. Le projet est sous licence MIT et indique que l’utilisation de modèles ouverts exécutés localement n’entraîne pas de frais d’API ; cette indication ne s’applique pas automatiquement à ses endpoints cloud.

Une vidéo en anglais d’Eric Tech porte également sur Claude Code et Ollama.