Tout en local : construire un espace de travail IA hors ligne

 (instavm.io)
6 points par GN⁺ 2025-08-09 | 2 commentaires | Partager sur WhatsApp
  • Exécution de LLM en local et environnement sandbox de code pour constituer un espace de travail IA sans dépendance au cloud
  • Faire fonctionner un LLM local avec Ollama, exécuter le code dans une VM isolée grâce à Apple Container et permettre l’automatisation et l’accès Internet via un navigateur headless avec Playwright
  • L’interface utilisateur est basée sur assistant-ui, avec mise en œuvre d’un menu déroulant de sélection de modèle et de l’intégration ai-sdk, ainsi qu’un environnement d’exécution de code sûr via MCP (Model Context Protocol)
  • Exécuter dans une VM Coderunner connectée par MCP un serveur Jupyter et un navigateur, pour traiter en mode confidentialité la création de graphiques, l’édition d’images/vidéos, l’installation d’outils GitHub et la recherche web
  • L’ensemble est actuellement spécifique à Apple Silicon, et l’amélioration de l’UI, l’évitement de la détection navigateur ainsi que le renforcement de la gestion des outils sont les objectifs à venir

Exigences et contexte

  • Objectif : exécuter tout en local sans exécution de code dans le cloud ni en distant
  • Les applis de chat LLM existantes (ex. ChatGPT, Claude) offrent un chat LLM basé sur le cloud, l’exécution de code cloud/local et une fonction d’accès à Internet
  • Avec la montée en puissance des LLM open source, la question était de savoir si l’on pouvait réaliser l’ensemble de ces fonctions entièrement en local
  • Un LLM local seul n’est pas suffisant, car le code doit s’exécuter dans un environnement isolé, et l’accès au contenu via un navigateur reste nécessaire

Idée de conception

  • Exécuter le LLM en environnement totalement local
  • Exécuter le code uniquement dans une VM légère afin de bloquer les risques pour le système hôte
  • Ajouter un navigateur headless pour gérer l’automatisation ainsi que la recherche d’informations et d’outils récents
  • Mettre en place un flux de travail orienté protection de la confidentialité, où la planification IA jusqu’à l’exécution du code se déroule entièrement en local
  • Réaliser divers travaux comme l’édition de photos et de vidéos en local, sans envoyer de données à des services externes

Stack technique

  • LLM : Ollama (prise en charge de modèles locaux et de certains modèles externes)
  • UI : assistant-ui + ai-sdk (ajout de la sélection de modèle)
  • Runtime VM : Apple container (fournit un environnement VM isolé)
  • Orchestration : instavm/coderunner (connexion du serveur Jupyter via MCP)
  • Automatisation navigateur : Playwright (exposé comme outil MCP)

Essais d’application Mac et transition

  • Tentative de développer une app Mac native avec a0.dev, mais difficultés car la cible était surtout iOS
  • Un wrapper Electron + NextJS a aussi été testé, puis abandonné en raison de la complexité
  • Passage final à assistant-ui local en version web

Personnalisation d’Assistant-UI

  • Il était prévu de proposer des fonctions de prise en charge de nombreux LLM, notamment le menu déroulant de sélection de modèle, mais c’était limité
  • Après étude d’exemples, implémentation directe d’un sélecteur multi-modèles via ai-sdk
  • Dans un premier temps, le support des modèles cloud (OpenAI/Anthropic) a été prévu, avec une stratégie de bascule progressive vers le local

Tool-calling et problème de support des modèles

  • Les modèles capables de supporter le tool-calling étaient nécessaires, mais certains, dont Ollama, ne le prennent pas réellement en charge
  • Même si la documentation officielle mentionne le support des outils, la mise en œuvre réelle est souvent insuffisante
  • La dynamique rapide de l’écosystème open source entraîne une forte volatilité du support des outils ainsi du prix des tokens

Exécution isolée de code basée sur des conteneurs

  • Grâce à l’outil Container d’Apple, chaque conteneur offre un environnement VM entièrement isolé, meilleur qu’une simple séparation Docker, ce qui permet d’exécuter plus sûrement le code généré par l’IA
  • Déploiement d’un serveur Jupyter dans l’environnement VM, exposition via le Model Context Protocol (MCP) pour permettre une utilisation immédiate depuis divers outils (Claude Desktop, Gemini CLI, etc.)
  • Publication du code du serveur MCP coderunner, avec exemple d’intégration avec des outils externes
  • L’outil Apple Container reste instable, et les erreurs de build/image peuvent exiger des relances répétées
  • Lors de tests réels de montage vidéo, le fonctionnement du combo UI + LLM + coderunner a été validé

Intégration du navigateur headless

  • Déploiement dans le conteneur d’un navigateur headless basé sur Playwright, exposé en tant qu’outil MCP
  • Attente d’usages pour l’exploration de nouveaux outils ou d’informations, la recherche de guides GitHub, et l’automatisation de recherche
  • Le flux de base est terminé : combinaison de LLM local + exécution sandboxée du code + navigateur headless

Exemples de tâches possibles

  • Recherche et résumé sur un sujet précis
  • Génération et rendu de graphiques CSV via commande en langage naturel
  • Montage vidéo via ffmpeg (coupe de segments, etc.)
  • Redimensionnement, recadrage et conversion de format d’images
  • Installation d’outils GitHub dans le conteneur
  • Exploration et résumé de pages web avec un navigateur headless, etc.

Montage de volumes de fichiers et isolation

  • Mapper ~/.coderunner/assets de l’hôte vers /app/uploads dans le conteneur, afin de conserver les fichiers dans un espace de partage sûr
  • Le code exécuté ne peut pas accéder directement au système hôte, ce qui améliore la sécurité

Limites et travaux futurs

  • Le système ne fonctionne que sur Apple Silicon, macOS 26 n’est qu’une option
  • Amélioration de l’UI nécessaire pour la gestion des outils, le streaming de sortie, etc.
  • Le navigateur headless peut être bloqué sur certains sites en raison de la détection de bots

Conclusion

  • Ce projet dépasse le simple prototype et vise un modèle centré sur la souveraineté informatique et la protection de la vie privée
  • Il offre une expérience de traitement sécurisé des données sur une machine locale personnelle, sans dépendance aux serveurs cloud ou distants
  • Les meilleurs LLM peuvent rester dans les grands clouds, mais le but est de faire progresser des outils IA locaux capables de préserver la vie privée individuelle
  • coderunner-ui open source est disponible sur GitHub ; les retours et la collaboration sont les bienvenus

Ressources associées

À lire aussi

2 commentaires

 
wedding 2025-08-11

Je suis d'accord avec l'avis de HN selon lequel c'est presque juste un hobby amusant.

Même en le personnalisant dans tous les sens, je n'arrive pas à atteindre la commodité et la vitesse d'une solution commerciale.
 
GN⁺ 2025-08-09
Commentaires Hacker News

  • Je suis toujours attiré par cet idéalisme, mais en tenant compte des performances des modèles auxquels je peux réellement accéder et du coût de l’usage à la demande dans le cloud, c’est plutôt un hobby amusant qu’une stratégie concrète. Le matériel progresse si vite que, même avec du matériel d’occasion, sa valeur baisse tout aussi vite, si bien qu’il est difficile de justifier un investissement réel dans du hardware. Et avec des poids qui tournent en local, les performances baissent beaucoup, donc ce n’est pas rentable aujourd’hui. J’imagine quand même que la situation changera, et j’espère qu’un jour j’investirai dans une stack d’inférence locale dès que de bons poids seront publiés. D’ici là, je me retrouve juste à faire valoir des actifs chers qui se déprécient rapidement.

    • L’écosystème des LLM locaux est vraiment intéressant en ce moment, et j’aime voir ce que les gens font. Mais à chaque fois que je fais tourner un LLM local sur la RAM impressionnante de mon MacBook Pro, l’écart avec les modèles frontier (les derniers LLM SaaS) saute aux yeux. Pour environ 20 dollars par mois, en ne payant qu’au token, on peut utiliser plusieurs modèles très performants, et pourtant l’écart en vitesse et en qualité reste énorme côté local. Les graphiques de benchmark ne mettent pas forcément en évidence cet écart, mais on ressent bien que les modèles frontier sont bien meilleurs. Même les modèles d’OpenAI, d’Anthropic, etc. semblent parfois lents et sujets aux erreurs ; en local, cela est encore plus marqué. C’est bien pour des usages de loisir ou d’expérimentation où la confidentialité compte, mais je préfère attendre de voir un vrai hardware (comme un futur MacBook avec 128 Go de RAM) avant d’y passer.

    • Je pense que quand les modèles derrière les API commenceront à générer du revenu via les sorties, la qualité se dégradera progressivement. Je pense que c’est une question de temps.

    • Je m’interroge sur l’argument : « le matériel évolue vite, donc acheter d’occasion ou non, tout baisse vite de valeur ». Il me semble que, selon les cas, un modèle peut continuer à tourner même sans la config la plus rapide. Au fond, c’est le débat classique opex (dépenses d’exploitation) versus capex (investissements), et financièrement le cloud n’est avantageux que dans des cas vraiment spécifiques (lorsqu’il faut déployer de l’infra très vite avec une demande difficile à prévoir). Pour les LLM, ce n’est pas vraiment le cas. L’OP dit avoir investi environ 600 $, ce qui correspond à un coût de trois mois d’EC2. Dans ces conditions, je me demande si cela suffit à étayer numériquement son argument.

    • Je fais également partie de ceux qui pensent que ça va changer. Je commence à utiliser de plus en plus des outils comme Claude Code, et je n’ai pas envie d’être dépendant d’une entreprise pour coder chaque jour. Entre la limite d’abonnement, le coût API, l’inquiétude de devoir payer 100 à 200 $ par mois, et le risque que toutes mes données soient collectées ou surveillées par une entreprise d’IA, je ne veux pas exposer mes données. Pour la domotique, je n’utilise que des produits qui peuvent être contrôlés en local, et quand il faut un accès externe, je configure directement un logiciel pour l’exécuter sur mon propre serveur. Je ne veux pas être verrouillé à cela au cas où une entreprise arrêterait soudainement son service, augmenterait ses prix ou exploiterait mes données. Pour l’instant, je n’ai ni la motivation, ni le budget, ni les connaissances, ni la capacité de maintenance pour installer un LLM sur mon propre matériel ou sur un VPS. Je suis content de payer 20 $ par mois à Anthropic, et les modèles open source publiés aujourd’hui ne peuvent pas rivaliser avec les SaaS de pointe. J’espère pourtant que cela finira par changer.

    • Je pense que cette situation ne changera jamais. Même si une option locale de niveau GPT-5 arrive d’ici deux ans, à ce moment-là le cloud aura encore de bien meilleures options, donc on aura les mêmes questionnements.

  • Je pense que ce travail, axé sur une couche d’exécution locale et sandboxée, est une pièce essentielle du puzzle pour parvenir à un espace de travail IA privé. L’outil coderunner a l’air très utile. Mais un autre enjeu, c’est la « couche de connaissance » qui permet à l’IA de reconnaître mes e-mails, notes, fichiers, etc. Gérer plusieurs années d’e-mails avec du RAG fait facilement dépasser 50 Go pour le stockage de la base vectorielle. (Pour info, je fais partie d’une équipe de Berkeley qui résout ce problème.) Nous avons créé LEANN, un index vectoriel, et réussi à économiser jusqu’à 97 % du stockage en ne stockant pas du tout les embeddings eux-mêmes. Du coup, indexer toute sa vie numérique localement est devenu réellement possible. Combiner une indexation de connaissances ultra légère avec un moteur d’exécution local me semble être la voie vers un vrai « Jarvis local ». Code : https://github.com/yichuan-w/LEANN
    Paper : https://arxiv.org/abs/2405.08051

    • À 2 025, gérer plusieurs années d’e-mails en 50 Go de base vectorielle me semble même une exigence plutôt modeste.

    • Merci pour l’info sur LEANN. Je suis particulièrement intéressé par l’usage du RAG comme couche de connaissance pour des agents LLM, des pipelines ou des moteurs d’exécution. Je me demandais si l’on pouvait réellement connecter un grand codebase à un LLM ; le fait qu’une solution RAG soit déjà intégrée à Claude Code abaisse les frictions pour tester, et je suis optimiste. Si quelqu’un a déjà réellement travaillé avec RAG + LLM sur un grand codebase, j’aimerais vraiment le savoir. Je vais commencer à utiliser des modèles de front-end (LM) en cloud, et je vais tester moi-même. Référence : https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

    • Je ne m’y connais presque pas en embeddings ni en structure de stockage vectoriel. Je me demande s’il existe des projets d’un style similaire dans les embeddings cloud qui appliquent cette approche de « pruned graph ».

    • Le fait qu’un index soit plus gros que les données d’origine me paraît étrange. J’avais tendance à penser qu’un index doit être une forme plus efficace pour un accès plus rapide, donc le fait qu’il grossisse ainsi me paraît bizarre.

  • L’une des raisons pour lesquelles même un « meilleur LLM du monde » ne rend pas l’expérience aussi fluide, c’est que ces modèles sautent parfois des étapes, ignorent les spécificités de plateforme et finissent par produire des « hallucinations » qui aggravent parfois le problème. Cela montre bien le manque de données d’entraînement pour le développement d’apps natives. Il y a peu d’articles de fond sur le design d’apps natives (sur blogs ou Medium), et le nombre de projets open source desktop est très faible par rapport au mobile/web. Dans les années 1990, MS embauchait des auteurs spécialisés pour publier d’excellents livres de codage Windows (dont Charles Petzold est l’exemple type), mais cette industrie spécialisée a pratiquement disparu. De ce fait, je pense que le trou dans les données d’entraînement va continuer de s’agrandir. C’est au final comparable à la tendance générale du software engineering : peu de personnes veulent créer des apps desktop natives, et c’est une voie de carrière perçue comme sans issue. Dans les années 1990, être développeur d’apps desktop Windows pouvait déjà garantir une vie confortable et les barrières étaient élevées (C/C++ est difficile, l’apprentissage de l’API Windows était exigeant, et MS investissait énormément dans la formation), mais la situation a beaucoup changé. Aujourd’hui, sauf pour les éditeurs d’OS (Microsoft, Apple) ou quelques acteurs legacy comme Adobe, Autodesk, la demande de dev desktop est quasi nulle.

    • Sauf dans le HPC (high performance computing), il n’est généralement pas nécessaire de construire une app desktop séparée, car le navigateur joue déjà le rôle de VM la plus universelle.

  • J’ai testé l’app macOS d’Ollama par curiosité, et j’ai vu qu’au lancement elle tentait d’accéder à un domaine Google. Ça rend difficile de croire à une confidentialité totale. https://imgur.com/a/7wVHnBA

    • C’est à cause des vérifications de mises à jour automatiques. https://github.com/ollama/ollama/blob/main/docs/faq.md

    • Le fait que ce genre d’appels réseau soit auditable donne en réalité un peu de confiance. Surveiller automatiquement les appels réseau à chaque mise à jour est une gestion totalement faisable.

    • J’ai vu le même phénomène avec les plugins cline et copilot dans VS Code. Quand je configure pour n’utiliser qu’Ollama localement et bloque les connexions sortantes, rien ne fonctionne. Même en désactivant la télémétrie dans les réglages, cline continue d’essayer des communications externes, c’est décevant.

  • J’y pense plus souvent que je ne le pensais. J’ai le sentiment que protéger la confidentialité implique beaucoup de frictions et de difficultés.

    • Je ne pense pas que ce post soit très utile pour aider concrètement sur ces préoccupations ou proposer une solution.

  • Je préfère encore le local, parce que la majorité des vitesses d’inférence IA sont soit lentes, soit peu différentes du local. J’ai essayé cerebras (et j’ai entendu parler de groq aussi) et avec une vitesse d’environ 1000 tokens/sec, mon seuil de patience vis-à-vis de l’attente a complètement changé. Cerebras dit ne pas enregistrer les données, et j’aimerais qu’on croie que je n’ai aucun lien de sponsoring avec eux (j’aimerais même qu’il y en ait un). Je trouve ce service vraiment excellent. J’espère qu’on verra quand même un vrai progrès côté vitesse. L’architecture diffusion me semble particulièrement rapide.

  • À mon avis, la limite actuelle se situe davantage côté hardware que côté logiciel. Pour faire tourner un LLM utilisable localement, il faut un hardware de l’ordre d’au moins 2000 $ (par ex. Strix Halo, AI Max 395). Si Strix Halo est encore plusieurs fois mis à jour, ça devrait devenir beaucoup plus facile.

    • Ce changement se produit vraiment vite. https://simonwillison.net/2025/Jul/29/space-invaders/

    • Même avec le hardware correspondant à ce prix, la définition de ce qui est « acceptable » reste floue. Pour que la techno soit vraiment utile, il faut une expérience qui fonctionne immédiatement, comme par magie. L’instant où l’on doit sans cesse toucher aux réglages tout en subissant des résultats lents et peu clairs, la valeur pratique disparaît en fait presque totalement. Les modèles locaux se sont beaucoup améliorés, mais en termes de coding ils restent en dessous de modèles comme Claude. J’ai récemment testé directement via cline les derniers modèles Qwen et GLM d’OpenRouter, et je les ai trouvés au niveau de Claude 3.0. Je pense que les benchmarks reflètent mal la réalité.

  • Le positionnement produit et les posts de blog paraissent un peu incohérents. Le site laisse entendre un lancement de VM dans le cloud (comme Firecracker), alors que le blog donne l’impression d’exécuter une VM locale dédiée à Mac. Ayant construit la première approche, j’aimerais tester la seconde version avec les nouveautés gpt-oss.

  • Pour l’OP, je signale que ce lien ne fonctionne pas : https://github.com/assistant-ui/assistant-ui

  • C’est un projet vraiment sympa et bien conçu. Je construis aussi quelque chose de similaire, et l’élément clé, c’est de permettre de passer facilement entre cloud et local en un seul clic. Toutes les données/configuration/prompts seraient stockées uniquement en local, et les appels API seraient routés directement vers le fournisseur, sans passer par nos serveurs. Aujourd’hui, c’est une inférence totalement locale dans le navigateur avec mlc-llm (Qwen3-1.7b fonctionne très bien). https://hypersonic.chat/