Le scenario est familier : un train sans wifi correct, un vol intercontinental, un client en zone rurale, un VPN entreprise qui bloque les API IA. Trois heures sans connectivite stable se transforment en trois heures sans assistant IA. Pour beaucoup de developpeurs en 2026, cette dependance reseau est devenue un point de friction quotidien aussi visible qu'inacceptable. Pourtant, l'experience offline avec un LLM local est devenue tout a fait viable au cours des deux dernieres annees. Materiel adapte, modeles compacts performants, outils stables, integrations matures : il est possible de coder dans un avion exactement comme on le fait connecte. Cet article detaille le workflow complet pour atteindre cette autonomie reelle.
Le delta entre offline theorique et offline pratique
Beaucoup de developpeurs ont teste un LLM local une fois, ont ete decus de la lenteur ou de la qualite, et sont revenus aux API. Cette deception vient generalement d'une attente mal calibree : remplacer Claude Opus par Llama 3 8B en s'attendant aux memes performances. Cette attente est irrealiste.
L'offline pratique demande un changement d'approche. On accepte une qualite legerement inferieure sur les taches complexes en echange d'une disponibilite totale et d'une latence proche de zero. On reorganise son workflow pour que les LLM gerent les taches qu'ils savent bien faire et que les taches plus complexes attendent la reconnexion. Cette discipline produit des gains tangibles plutot que des frustrations.
Le delta entre les deux experiences se mesure en honnetete sur ce qu'on attend d'un LLM offline. Pour la completion de code routine, le scaffolding, les tests unitaires, la documentation : un Llama 3 8B local est tres satisfaisant. Pour le raisonnement architectural complexe, la review de code multi-fichiers ou la generation de specifications detaillees : un frontier model garde une avance significative.
Le materiel qui change tout
L'experience offline depend etroitement du materiel. Trois configurations donnent des reperes utiles.
Configuration premium : MacBook Pro M3 Max ou M4 Pro avec 64 a 128 Go de memoire unifiee. C'est la machine ideale pour le LLM local en mobilite. La memoire unifiee permet de charger des modeles de 30 a 70 milliards de parametres a une vitesse acceptable. La consommation reste raisonnable hors charge intense. Llama 3 70B en Q4 atteint 15-25 tokens par seconde, suffisant pour de la generation. DeepSeek-Coder 33B tourne a 25-35 tokens par seconde, tres confortable pour du code.
Configuration intermediaire : MacBook Pro M3 Pro ou laptop Windows avec 32 Go RAM et GPU integre ou modeste. Cette machine fait tourner confortablement des modeles 7B a 13B. Llama 3 8B et DeepSeek-Coder 14B sont les compagnons recommandes. Les performances sont fluides (40 a 80 tokens/s) et l'autonomie batterie tient 4 a 6 heures en usage IA.
Configuration entree de gamme : laptop standard 16 Go RAM. Le LLM local reste possible mais avec des modeles compacts. Phi-4, Gemma 3 7B ou Llama 3 8B en Q4 sont les options. Performance correcte pour la completion mais ne remplace pas un agent CLI complet.
Le critere materiel le plus determinant n'est ni le CPU ni le GPU mais la memoire. 16 Go limite a des modeles 8B et oblige a fermer beaucoup d'autres applications. 32 Go ouvre les modeles 14B et permet de garder un environnement de travail riche. 64 Go et plus permettent les modeles 30B+ et l'experimentation libre.
La stack offline complete
Une stack offline qui fonctionne en 2026 comporte cinq elements.
Le serveur de modele est generalement Ollama. Notre [guide complet d'Ollama](/ollama-llama-deepseek-coder-local/) detaille la mise en place. Sur un laptop bien dimensionne, Ollama gere plusieurs modeles charges simultanement et bascule entre eux sans friction.
L'editeur s'integre via une extension qui pointe sur l'API locale. VS Code avec Continue.dev est la combinaison la plus stable. Cursor permet aussi de configurer un endpoint custom mais avec quelques limitations sur les fonctionnalites avancees comme le mode agent. Pour comparer les options, voir notre [stack complete du dev IA-first](/stack-complete-developpeur-ia-first-2026/).
L'agent CLI est aider ou cline configure sur un modele local. Ces outils permettent de demander des modifications multi-fichiers, lancer des tests, executer des commandes shell. Avec un modele code 14B ou 33B, l'experience est tres proche d'un Claude Code mais en local.
L'index de codebase est une couche RAG locale. Une simple solution comme Continue.dev avec son index integré, ou un setup plus avance avec pgvector ou Qdrant local, permet a l'agent de retrouver les fichiers pertinents pour une question donnee. Voir notre [guide RAG pour developpeurs](/rag-developpeurs-cursor-claude-code-codebase/) pour les patterns d'integration.
La documentation locale complete le tout. Mirroirs des documentations principales (Python docs, MDN, framework officiel) telecharges localement. Les outils comme Zeal, Dash ou DevDocs offline assurent que la consultation de documentation reste fluide sans connexion.
Scenario 1 : le code en train
Trajet Paris-Marseille en TGV, trois heures, wifi instable. Le scenario type qui teste l'autonomie reelle d'un workflow offline.
Avant le depart : pre-charger le modele Ollama (la premiere requete charge en RAM, les suivantes sont rapides), s'assurer que l'index local de la codebase est a jour, telecharger les dependances qui pourraient etre utiles. Prevoir aussi un journal de questions a creuser sur les sujets qui exigent un frontier model, pour les traiter au retour.
Pendant le trajet : developpement normal avec completion temps reel via Ollama, generation de tests, refactoring de fonctions. Pour les questions complexes, la note dans le journal et on continue. La latence proche de zero du LLM local rend l'experience souvent plus fluide qu'avec une API depuis un train ou la latence reseau peut atteindre 2-3 secondes.
Apres le trajet : reconnexion, traitement du journal de questions complexes avec le frontier model, integration des reponses dans le travail. Cette discipline transforme un trajet en bloc de productivite reelle plutot qu'en frustration.
Le retour d'experience commun en 2026 est que ce mode hybride produit en realite plus de code que le mode permanent connecte. La concentration imposee par le contexte (pas de notifications, pas de slack, pas de mail) compense largement la legere baisse de qualite IA.
Scenario 2 : le client en zone faiblement connectee
Mission de quelques jours chez un client industriel ou public avec une connectivite limitee ou interdite a l'IA externe. Le modele local devient le compagnon principal pendant la mission.
L'enjeu specifique est la confidentialite des donnees client. Beaucoup d'organisations interdisent strictement l'envoi de code ou de specifications a des API externes. Un LLM local resout cette interdiction de maniere structurelle : aucune donnee ne quitte la machine.
Le workflow type combine un agent CLI local pour les modifications de code, un assistant chat local pour les questions ponctuelles sur l'architecture, et eventuellement une couche RAG sur la documentation client elle-meme. Cette derniere capacite est particulierement appreciee : indexer la documentation interne du client en debut de mission permet ensuite de la consulter en langage naturel sans la moindre fuite externe.
A la fin de la mission, l'index local peut etre archive ou supprime selon les regles de retention. Aucune trace n'a ete laissee chez un fournisseur tiers.
Scenario 3 : le vol intercontinental
Trajet Paris-Tokyo, douze heures, wifi cher et lent. C'est le scenario qui differencie le plus radicalement le workflow offline du workflow connecte.
Le materiel premium prend ici tout son sens. Une autonomie batterie de 6 a 10 heures sur un MacBook Pro M3 Max permet de tenir une session de travail intense sans recharger. Un mode optimise (lower brightness, fermer les apps inutiles) prolonge encore l'autonomie.
Le pattern qui fonctionne est le decoupage en blocs de 90 minutes. Chaque bloc commence avec une intention claire (ecrire ce module, refactorer cette feature, debugger ce bug). Le LLM local accompagne le bloc en mode interactif. Une pause de 15 minutes ferme le bloc et permet de relacher la tension cognitive.
Le travail produit pendant un vol est generalement de qualite superieure au travail equivalent fait au bureau. La concentration force par l'environnement, l'absence de distractions et la pression du temps imparti combinent leurs effets. Le LLM local enleve la friction qui aurait autrement freine cette productivite.
La gestion de contexte sans internet
Le defi principal du LLM local est la fenetre de contexte plus reduite (32k tokens contre 200k a 1M pour les frontier models). Une discipline de gestion du contexte compense ce delta.
Premier reflexe : utiliser le RAG local pour ne presenter au modele que les fichiers reellement pertinents. Plutot que d'envoyer toute la codebase, l'agent retrouve les 5 a 10 fichiers les plus lies a la question et ne charge qu'eux. Cette discipline est la meme qu'en connecte mais devient critique en local.
Deuxieme reflexe : decouper les taches longues en sous-taches autonomes. Un refactoring complexe se decompose en plusieurs etapes, chacune passant un contexte gerable au modele. Cette decomposition est generalement souhaitable de toute facon, le LLM local force cette discipline.
Troisieme reflexe : maintenir un fichier CLAUDE.md ou equivalent qui resume l'architecture du projet, les conventions et les decisions cles. Ce fichier de 1000 a 2000 tokens donne au modele local le contexte minimum necessaire et reduit la quantite d'informations a recuperer pour chaque requete.
Mesurer le gain reel
Apres trois mois de workflow hybride local-connecte, les retours d'experience publies par des developpeurs experimentes en 2026 convergent sur quelques chiffres.
Le gain en disponibilite est total. Plus de developpement bloque par manque de connectivite. Cette disponibilite vaut entre 30 minutes et 2 heures par semaine selon la mobilite professionnelle. Pour un freelance qui voyage souvent, c'est 5 a 10 % de productivite recuperee.
Le gain en concentration est mesurable mais subjectif. Beaucoup de developpeurs rapportent une qualite de code superieure pendant les sessions offline forcees, attribuee a l'absence de distractions. Cet effet decline si les sessions offline deviennent permanentes : l'isolement total est contre-productif a long terme.
Le gain economique est variable. Un usage offline qui se substitue a 30 % des appels API representait en 2025 environ 15 a 30 dollars d'economies mensuelles pour un usage standard. En 2026, avec la baisse des prix API, l'economie est moins evidente mais reste positive sur les usages intensifs.
La reconnexion ne doit pas etre passive
Le piege du workflow offline est de devenir un workflow permanent par habitude. Un developpeur qui se contente du LLM local en permanence accepte un plafond de qualite qui le penalise sur les taches complexes.
La discipline qui paie est de revenir consciemment aux frontier models pour ce qu'ils font mieux : l'analyse architecturale, la review approfondie de pull requests, la generation de specifications detaillees, le debugging de problemes inhabituels. Ces taches occupent typiquement 10 a 20 % du temps mais 50 a 70 % de la valeur creee.
Cette articulation entre offline pour le quotidien et frontier pour les moments cles est ce qui distingue les developpeurs qui exploitent l'autonomie offline comme un levier de ceux qui s'enferment dans une qualite mediocre par evitement du cout.
L'offline n'est pas un retour en arriere. C'est une option supplementaire dans la palette du developpeur IA-first en 2026. L'utiliser intelligemment, ni trop ni trop peu, transforme la dependance reseau d'une contrainte en un choix.
