Une ingénieure de Thomson Reuters fait tourner un agent hors ligne sur Qwen3.5 9B dans l'Himalaya

Dans les contreforts de l'Himalaya, le réseau disparaît aussi régulièrement que l'électricité. C'est là que vit Rittika Jindal, Principal Engineer chez Thomson Reuters. Elle a voulu savoir quelle part d'un flux de travail avec un agent de code survit quand on coupe complètement internet. La réponse est concrète. Sur un seul Mac, l'association d'OpenCode 1.19.4, d'Ollama et du modèle ouvert Qwen3.5 9B trouve un bug, propose un correctif et lance les tests, Wi-Fi désactivé. L'exemple est modeste : une correction d'une seule ligne, après laquelle les cinq tests passent. En revanche, la pile est reproductible et documentée jusqu'aux commandes.

Comment est montée la chaîne hors ligne

La répartition des rôles est simple. Ollama héberge le modèle et expose un service local ; OpenCode lit les fichiers du projet, propose des modifications et exécute les commandes. Le fichier de configuration opencode.json dirige le modèle principal comme le modèle auxiliaire (model et small_model) vers Qwen3.5 9B, et son baseURL pointe vers http://127.0.0.1:11434/v1. Seul le fournisseur local est activé, les outils web sont bloqués, et l'agent demande l'autorisation avant toute modification de fichier ou commande shell. Ollama démarre avec OLLAMA_NO_CLOUD=1 et un contexte OLLAMA_CONTEXT_LENGTH=65536. Le modèle se télécharge avec la commande ollama pull qwen3.5:9b, tant que la connexion existe encore. Le lancement se fait avec l'option --pure, qui désactive les plugins externes.

Parmi les alternatives, l'autrice mentionne Aider : il sait lui aussi travailler avec Ollama et conviendra à ceux qui veulent un scénario d'édition plus guidé.

Quel modèle choisir et de combien de mémoire a-t-il besoin ?

Pour son choix, l'autrice s'est appuyée sur les résultats publiés dans la fiche de Qwen, et non sur ses propres mesures sur le portable. LiveCodeBench v6 évalue la génération de code ; BFCL-V4 mesure l'appel de fonctions, c'est-à-dire la capacité de l'agent à choisir un outil et à lui passer les bons arguments.

• Qwen3.5 4B : LiveCodeBench v6 — 55,8 ; BFCL-V4 — 50,3 ; téléchargement de 3,3–4,0 Go.
• Qwen3.5 9B (utilisé dans le test) : 65,6 et 66,1 ; téléchargement de 6,6–7,6 Go.
• Qwen3.5 27B : téléchargement de 17–20 Go, benchmarks non fournis dans l'article.
• gpt-oss-20b : LiveCodeBench v6 — 74,6 ; BFCL-V4 non publié.

La version à neuf milliards de paramètres a été retenue parce qu'elle appelle nettement mieux les outils que le 4B. La taille du téléchargement ne correspond toutefois pas aux besoins en RAM. Pour la build de Qwen3.5 9B de 6,6 Go, Voltti prévoit 12–16 Go de mémoire, et une configuration avec un contexte de 64k peut en exiger davantage. Il faut aussi garder de la marge pour les autres applications.

L'article examine séparément le scaffold lui-même. Le preprint The Scaffold Effect in Coding Agents compare OpenCode, Goose et OpenHands-SDK sur 50 tâches de Terminal-Bench Pro, avec deux modèles cloud :

• Qwen3.6 Plus : Goose — 48% [34–62%], OpenCode — 50% [36–64%], OpenHands-SDK — 50% [36–64%].
• MiniMax M2.5 : Goose — 38% [24–52%], OpenCode — 46% [32–60%], OpenHands-SDK — 46% [32–60%].

Les intervalles de confiance à 95% se chevauchent, et les auteurs préviennent que la plupart des écarts ne sont pas statistiquement nets. La consommation de tokens, elle, diffère fortement : OpenCode dépense environ 40 fois plus de tokens par tâche résolue que Goose. Avec une API cloud, cela se traduit directement en argent. Avec un modèle local, cela se traduit en temps de génération et en pression sur le contexte. Ces chiffres ne permettent pas de prédire les résultats d'un 9B sur un portable : les tests utilisaient des modèles cloud.

Ce qu'a montré le test avec le Wi-Fi coupé

Le projet de test est un calcul de dépenses : cinq montants, dont un remboursement, pour un total correct de 25,50. Le programme de départ affiche 8,00, soit la valeur de la dernière dépense, car la fonction écrase la somme à chaque itération. Trois tests échouent : l'arithmétique décimale, les remboursements et l'exemple avec des données réelles. L'entrée vide et l'élément unique passent.

En ligne, l'agent a reçu une requête de diagnostic et lu le code, mais il a d'abord proposé pytest, alors que le projet utilise unittest, intégré à Python. L'autorisation d'exécution a permis de voir la commande avant son lancement. Conclusion de l'autrice : la prochaine fois, indiquer python3 -m unittest -v dans le prompt.

Après avoir vérifié Ollama avec curl sur localhost, l'autrice a désactivé le Wi-Fi. Une requête vers une adresse externe s'est terminée par l'erreur Could not resolve host. L'agent a proposé la correction `total = Decimal(amount)` → `total += Decimal(amount)`, demandé l'autorisation de modifier le fichier, puis lancé les tests. L'autrice a ensuite refait elle-même la vérification : les cinq tests sont verts, et le fichier de tests n'a pas été modifié.

Deux autres exercices, un rapport CSV et un analyseur de logs, avec sept tests chacun, figurent dans le dépôt, mais aucun passage hors ligne n'a encore été réalisé. La tâche CSV sera d'ailleurs un examen plus honnête : l'agent doit y compléter une fonction, et non corriger une seule ligne.

La leçon pratique pour ceux qui travaillent dans le train, dans l'avion ou en zone de mauvais réseau : tout le nécessaire doit se trouver sur le disque avant la perte de connexion. Cela comprend le modèle, les dépendances du projet et la documentation. Lancez exactement la configuration que vous utiliserez hors ligne. Donnez à l'agent la commande de test précise et gardez des tâches étroites : un bug ou une petite fonctionnalité. Vérifiez le diff et lancez vous-même les tests d'origine. Surveillez la mémoire : un contexte de 64k et des applications ouvertes consomment ce que le modèle a laissé. Cette expérience n'a pas encore testé un gros dépôt ni un framework inconnu.