Voici une phrase qui coûte cher à mal comprendre : votre coding agent et le model auquel il s’adresse sont deux choses distinctes. L’agent est le harnais — le CLI qui lit votre dépôt, exécute des commandes, modifie des fichiers et boucle jusqu’à ce que le travail soit fait. Le model est le cerveau qu’il contacte à chaque étape. La plupart du temps, ce cerveau vit dans le centre de données de quelqu’un d’autre, et chaque ligne de votre code base privée traverse le réseau pour y parvenir.
Ce billet porte sur le fait de couper ce fil. Nous serons précis sur ce que « offline » signifie réellement, ce qui tourne air-gapped aujourd’hui, quel matériel il vous faut, et — parce que l’exactitude est sacrée par ici — exactement où le compromis honnête fait mal. Si vous avez déjà self-hosted un model avec notre guide Ollama, c’est l’échelon suivant : pointer un vrai coding agent vers ce model local et retirer le câble réseau.
C’est une couche de plus de décentralisation. Votre nœud valide le Bitcoin sur votre propre fer. Votre Lightning route de la valeur sur votre propre fer. Maintenant, l’agent qui touche votre code source peut aussi tourner sur votre fer — aucune clé téléversée, aucun dépôt propriétaire diffusé vers un pipeline de journalisation que vous ne contrôlez pas.
Pourquoi air-gap un coding agent tout court
Pour une bonne part du travail, envoyer du code à un model frontière hébergé convient parfaitement et les résultats sont excellents. Mais il existe de vrais scénarios où faire quitter votre dépôt de la machine est un non-négociable :
- Clés d’API et secrets. Les agents lisent votre environnement, vos fichiers de configuration, votre
.env. Un déversement de context imprudent et un model hébergé a vu des identifiants que vous ne colleriez jamais volontairement dans une boîte de discussion. - PI propriétaire. Si votre code base est l’entreprise — une stratégie de trading, un firmware non publié, le système privé d’un client — « nous promettons de ne pas l’utiliser pour l’entraînement » est une politique, pas une garantie. L’air-gapping est une garantie.
- Travail réglementé et contractuel. Certains contrats et juridictions interdisent purement le traitement de données par des tiers. Un agent offline garde les données sur du matériel que vous contrôlez physiquement.
- Souveraineté. Même thèse que de faire tourner votre propre nœud Bitcoin : ne louez pas une capacité que vous pouvez posséder. Un cerveau mesuré, surveillé, limité en débit et qui peut être déplateformé demain est une dépendance. Des weights locaux sur votre disque sont une sauvegarde qu’on ne peut pas révoquer.
Rien de tout cela ne signifie que les models hébergés sont mauvais. Cela signifie qu’il existe une classe de travail où la bonne réponse est « garder ça sur ma machine », et jusqu’à récemment c’était difficile à bien faire. Ça devient plus facile.
La réalité honnête : quelle partie est réellement « offline »
C’est la section que la plupart des billets « faire tourner Claude Code offline » se trompent, alors nous allons être exacts.
Claude Code est l’agent en ligne de commande d’Anthropic, et par défaut il appelle les models Claude hébergés d’Anthropic sur le réseau. Il ne livre pas les weights de Claude, et il ne fait pas tourner Claude lui-même sur votre portable. Il n’existe aucun téléchargement qui place un model frontière Anthropic sur votre SSD. Donc la phrase « Claude Code qui tourne entièrement offline avec Claude » est une erreur de catégorie — le model Claude vit dans l’infrastructure d’Anthropic, point final. Rendons à César ce qui est à César : Anthropic a bâti un excellent harnais d’agent, et le harnais est réellement la partie précieuse du flux de travail.
Alors qu’est-ce qui passe offline ? Vous changez le cerveau, pas le harnais. Le schéma air-gapped honnête est :
- Garder le flux de travail de l’agent — la boucle lire-le-dépôt, exécuter-la-commande, éditer-le-fichier, boucler-jusqu’à-la-fin qui rend ces outils dignes d’être utilisés.
- Remplacer le model hébergé par un model local servi depuis votre propre machine, via l’outillage que l’agent comprend déjà.
La plomberie qui rend ça possible est le point de terminaison local compatible OpenAI. Ollama (et LM Studio, et le serveur de llama.cpp lui-même) peut exposer votre model local à une adresse comme http://localhost:11434/v1 qui parle le même dialecte d’API que le nuage. Tout agent qui vous laisse pointer une URL de base personnalisée et un nom de model peut alors parler à votre cerveau local plutôt qu’à un lointain. C’est toute l’astuce : l’agent croit appeler une API ; l’API se trouve juste être un model qui tourne à trois pouces du CPU.
Donc quand quelqu’un dit « je fais tourner mon coding agent offline », la traduction exacte est : je fais tourner un model open-weight local via Ollama, et je pointe un harnais d’agent vers ce point de terminaison local. Le model est la partie offline. L’agent est la partie flux de travail. Gardez ces deux idées séparées et tout le reste s’emboîte.
Ce qui tourne réellement offline aujourd’hui
Deux pièces doivent s’aligner : un model open-weight que vous pouvez servir localement, et un harnais d’agent qui peut être pointé vers un point de terminaison local compatible OpenAI.
Le model local (le cerveau)
Vous servez le model avec les mêmes outils que nous couvrons dans la série self-hosting. Ollama est la rampe d’accès la plus simple — une commande tire un model et expose le point de terminaison. Pour le travail de code, le paysage open-weight est véritablement solide maintenant : des sorties optimisées pour le code comme les models coder de Qwen, la ligne coder de DeepSeek, la lignée Code Llama de Meta, les models code de Mistral, et les fine-tunes d’instruction de la communauté issus de l’écosystème open-weight plus large (le cercle de Nous Research et bien d’autres) tournent tous localement. Tirez celui qui convient à votre matériel ; nous en arriverons aux calculs de VRAM plus bas.
Si vous n’avez pas encore monté un model local, commencez par l’installation Ollama en 10 minutes, puis revenez. La comparaison des runners couvre quand LM Studio ou llama.cpp brut vous convient mieux — les trois peuvent exposer le point de terminaison compatible OpenAI dont un agent a besoin.
Le harnais d’agent (le flux de travail)
C’est ici que vous choisissez un CLI qui prend en charge un backend configurable. Le Codex CLI d’OpenAI est l’exemple honnête le plus propre : c’est un coding agent open source, et parce qu’il est bâti pour parler l’API OpenAI, vous pouvez le pointer vers un serveur local compatible OpenAI (Ollama, LM Studio, ou le serveur de llama.cpp) et le faire piloter un model sur votre propre machine. C’est un vrai chemin air-gapped supporté : agent ouvert + model ouvert + point de terminaison local. Crédit à OpenAI pour l’ouverture en open source du Codex CLI, qui rend tout cela possible.
D’autres harnais d’agent communautaires suivent le même schéma — tout ce qui vous laisse définir une URL de base personnalisée et un nom de model peut être dirigé vers localhost. Le différenciateur est toujours la même question : cet outil me laisse-t-il surcharger le point de terminaison ? Si oui, il peut passer offline. S’il code en dur le nuage d’un fournisseur, il ne le peut pas.
C’est aussi la réponse honnête pour les agents populaires natifs de l’éditeur. Cursor — l’éditeur de code AI-first dans lequel vivent maintenant beaucoup de développeurs — est, comme Claude Code, propriétaire : il se connecte au nuage de Cursor et route vos prompts via des models frontière hébergés, donc ce n’est pas un outil air-gapped prêt à l’emploi. Des alternatives ouvertes BYO-LLM telles que Continue, Cline et Aider vous donnent la même expérience de coding agent dans l’éditeur ou le terminal tout en vous laissant pointer le point de terminaison vers votre propre serveur Ollama. Le schéma tient pour chacun d’eux : un coding agent local, c’est harnais d’agent ouvert + model ouvert + un point de terminaison que vous contrôlez. Nous tenons une comparaison en cours, vérifiée aux sources, de Claude Code, Codex, Cursor et des alternatives ouvertes sur nos classements AI.
Et pour boucler la boucle sur l’outil que nous nommons dans le titre : Claude Code est l’agent que nous aimons, mais son model est hébergé, donc la construction offline utilise un harnais d’agent ouvert pointé vers un model local à la place. Vous gardez l’idée du flux de travail agentique qu’Anthropic a popularisé ; vous branchez des pièces que vous pouvez faire tourner air-gapped. Pas de fausse représentation, pas de téléchargement magique.
Le matériel : une boîte GPU, pas un mineur
Tuons la confusion la plus courante avant qu’elle ne coûte un achat à quiconque. Ça tourne sur un GPU, pas sur un ASIC. Un mineur Bitcoin est du silicium SHA-256 à fonction fixe — pas d’unités à virgule flottante, pas de cœurs tensoriels, pas de VRAM pour tenir les weights d’un model. Il ne peut physiquement pas faire tourner un model de langage, et aucun changement de firmware n’y change rien. Nous avons expliqué exactement pourquoi dans Peut-on vraiment faire tourner de l’AI sur un mineur Bitcoin ? La version courte : l’ASIC hache le Bitcoin ; un GPU fait tourner votre AI ; ils cohabitent côte à côte. Les coding agents offline appartiennent entièrement au côté GPU de la pièce.
La VRAM est la porte. Les weights du model doivent tenir en mémoire GPU pour une vitesse utilisable, et le travail de code tend à vouloir de plus grandes fenêtres de context qu’un clavardage occasionnel, ce qui coûte de la mémoire supplémentaire. Guide approximatif pour des models locaux capables de code en quantification Q4 :
| VRAM | Ce qu’elle fait tourner | Contrôle de réalité |
|---|---|---|
| 8 GB | Models code 7B–8B | Utilisable pour l’autocomplétion, de petites éditions, le raisonnement sur un seul fichier. Serré sur le context. |
| 12–16 GB | Models code 13B–14B | Le plancher pratique pour un agent qui édite plusieurs fichiers et tient une vraie tâche en tête. |
| 24 GB | 30B, ou plus gros quantifié | Le point idéal du pleb. Les 24 GB d’un RTX 3090 d’occasion sont le choix valeur pour du code local sérieux. |
| 48 GB+ | Models quantifiés plus gros | Double GPU ou une carte 48 GB. Plus près du comportement frontière, toujours pas égal. |
Une carte 24 GB est le seuil où les coding agents locaux cessent de sembler un jouet. Si vous voulez bâtir la boîte sans payer le prix du silicium neuf, les GPU remis à neuf sont exactement le genre de matériel que nous gardons dans la boutique — le même endroit où un mineur maison ramasse un ASIC d’occasion pour le côté Bitcoin de l’établi. Nous ne sommes pas Amazon et nous ne promettons pas la livraison du lendemain ; nous sommes des pirateurs de minage Bitcoin bâtis à la main, sur commande, et les délais sont des estimations, pas des garanties. Achetez la VRAM, pas le battage.
L’écart de capacité : soyez honnête à ce sujet
Voici le compromis, énoncé clairement parce que prétendre le contraire ferait de nous des menteurs. Un model frontière hébergé est, aujourd’hui, significativement plus fort que ce que vous pouvez faire tourner sur un seul GPU grand public. Les plus gros models nuage ont des centaines de milliards de paramètres et tournent sur du matériel qu’aucun laboratoire maison ne peut égaler. Votre model code local 14B ou 30B est bon — véritablement utile — mais il perdra face à un model frontière sur le raisonnement difficile, multi-étapes, à grand context. Cet écart est réel et il ne se referme pas demain.
Alors qu’est-ce que l’air-gapping vous achète réellement ? Pas plus d’intelligence brute. Il achète la confidentialité, la souveraineté et le fonctionnement offline :
- Votre code ne quitte jamais le bâtiment. Point final.
- Pas de clés, pas de limites de débit, pas de facture de token au compteur, pas de conditions d’utilisation qui peuvent changer sous vous.
- Ça fonctionne avec le câble réseau retiré — sur un bateau, dans un bunker, derrière un air gap, pendant une panne.
- La capacité est la vôtre. Elle ne peut pas être déplateformée, étranglée, ou mise hors de prix le trimestre prochain.
Le schéma intelligent pour la plupart des gens est un partage : models frontière hébergés pour le raisonnement coriace et non sensible où la capacité brute gagne, et un model local pour les dépôts sensibles et le travail offline où la confidentialité est tout l’enjeu. La souveraineté n’est pas « ne jamais utiliser le nuage ». C’est « toujours pouvoir s’en éloigner ». L’AI locale est la sauvegarde de l’intelligence louée de la même façon que le Bitcoin est la sauvegarde du fiat — vous gardez l’option, et l’option est la liberté.
Note d’opérateur : comment nous y pensons
Nous sommes des pirateurs de minage Bitcoin. Nous réparons ce que l’industrie jette, nous lisons les fiches techniques, et nous faisons tourner notre propre infrastructure parce que la relouer est exactement ce dont nous essayons d’échapper. Les coding agents locaux collent à cette éthique exactement : posséder le cerveau, posséder la boîte, posséder le flux de travail.
C’est la même logique derrière DCENT_OS, le firmware de minage open source que nous bâtissons pour les Antminers industriels — rendre la machine à vous, sans frais de développement obligatoires et une code base 100 % GPL-3.0 comme cible honnête de notre bêta, sur les épaules des projets de firmware (Braiins, VNish, LuxOS) qui ont prouvé qu’un firmware Antminer personnalisé était possible en premier lieu. Pour être précis sur la portée : DCENT_OS est en bêta publique aujourd’hui, avec des images téléchargeables pour le S9 et le S19j Pro (cartes Zynq/XIL), le reste de la gamme étant sur la feuille de route, et il contrôle le côté minage — il ne fait pas tourner d’AI, parce que rien ne transforme un ASIC en silicium AI. Possédez votre argent, possédez votre calcul, possédez votre firmware : c’est le même geste, fait une couche à la fois.
Si c’est votre direction, le carrefour Bitcoin × AI cartographie le côté calcul souverain, et le carrefour souveraineté relie tout l’empilement des « sauvegardes » — argent, communication, et maintenant cognition — ensemble.
FAQ
Claude Code peut-il tourner entièrement offline ?
Non — pas avec Claude lui-même. Claude Code est le CLI d’agent d’Anthropic, et par défaut il appelle les models Claude hébergés d’Anthropic sur le réseau ; les weights de Claude ne sont pas quelque chose que vous téléchargez et faites tourner sur votre machine. Le chemin offline honnête est de prendre un harnais d’agent ouvert (tel que le Codex CLI open source d’OpenAI, ou un autre agent communautaire qui vous laisse définir un point de terminaison personnalisé) et de le pointer vers un model open-weight local servi via Ollama. Vous gardez le flux de travail agentique qu’Anthropic a popularisé ; vous échangez le cerveau hébergé contre un que vous faites tourner air-gapped.
Comment pointer un coding agent vers un model local avec Ollama ?
Servez le model avec Ollama, qui expose un point de terminaison compatible OpenAI (typiquement http://localhost:11434/v1). Puis configurez votre agent — par exemple le Codex CLI d’OpenAI — pour utiliser cette URL de base et le nom du model local au lieu d’un fournisseur nuage. Tout agent qui permet une URL de base personnalisée et un model peut être dirigé vers localhost de la même façon. L’agent traite votre model local exactement comme il traiterait une API nuage ; la différence est que la requête ne quitte jamais votre machine.
Un model de code local est-il aussi bon qu’un model frontière hébergé ?
Non, et nous ne prétendrons pas le contraire. Les models frontière hébergés ont des centaines de milliards de paramètres et tournent sur du matériel qu’aucun laboratoire maison n’égale, donc ils gagnent sur le raisonnement difficile, multi-étapes, à grand context. Un model code local 14B–30B est véritablement utile mais pas égal sur les tâches les plus dures. Ce que l’offline vous achète n’est pas plus d’intelligence brute — c’est la confidentialité, la souveraineté, et la capacité de continuer à travailler avec le câble réseau retiré. Beaucoup de gens partagent la différence : nuage pour le travail difficile non sensible, local pour les dépôts sensibles et le travail offline.
Puis-je faire tourner un coding agent offline sur un mineur Bitcoin ?
Non. Un ASIC Bitcoin est du silicium SHA-256 à fonction fixe sans unités à virgule flottante, sans cœurs tensoriels, et sans VRAM pour tenir les weights d’un model, donc il ne peut pas faire tourner un model de langage — et aucun changement de firmware n’y change rien. Les coding agents offline tournent sur une boîte GPU, pas sur un mineur. L’ASIC continue de hacher le Bitcoin ; un GPU à côté fait tourner votre AI locale. Nous couvrons exactement pourquoi dans notre billet sur la possibilité de faire tourner de l’AI sur un mineur Bitcoin.
De quel matériel ai-je réellement besoin pour faire tourner un agent sur un model local ?
Un GPU avec assez de VRAM pour votre model. Comme guide approximatif en quantification Q4 : 8 GB gère les models 7B–8B pour des éditions légères, 12–16 GB est le plancher pratique pour un agent multi-fichiers, et 24 GB (un RTX 3090 d’occasion est le choix valeur) fait tourner des models de classe 30B confortablement et est le seuil où le code local cesse de sembler un jouet. Le travail de code veut aussi de plus grandes fenêtres de context qu’un clavardage occasionnel, ce qui coûte de la mémoire supplémentaire, donc en cas de doute, achetez plus de VRAM. Les cartes remises à neuf gardent le coût raisonnable.
