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

(instavm.io)

6 points par GN⁺ 2025-08-09 | Aucun commentaire pour le moment. | 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

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

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)

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

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

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

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é

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

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é

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

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