Andrew Ng a annoncé OpenWorker, un agent de bureau open source conçu pour produire un travail finalisé plutôt que des réponses sous forme de chat. Ng est le fondateur de DeepLearning.AI et a auparavant dirigé la recherche en IA chez Google Brain et Baidu; il a également cofondé Coursera. L’annonce a été partagée sur X à l’adresse https://x.com/AndrewYNg/status/2080333504446108104.

OpenWorker est conçu autour des résultats plutôt que des prompts. Un utilisateur peut demander un document finalisé, une réponse Slack contenant les chiffres réels, un calendrier mis à jour ou une boîte de réception triée. Le système décompose ensuite le résultat demandé en étapes, travaille à travers des fichiers locaux et des applications connectées, puis consulte l’utilisateur avant d’entreprendre des actions importantes. Cela place OpenWorker dans la catégorie émergente des outils d’IA agentique qui accomplissent des tâches en plusieurs étapes entre applications, plutôt que de se limiter à générer des réponses textuelles.

Une architecture à quatre couches exécutée sur la machine locale

L’architecture d’OpenWorker est organisée en quatre couches, toutes exécutées sur la machine de l’utilisateur. Le dépôt contient 119 fichiers Python, totalisant environ 32,400 lignes, sous coworker/; 149 fichiers TypeScript/TSX sous surfaces/gui/; et 78 modules de test backend.

L’enveloppe de bureau est une fenêtre native Tauri 2 qui encapsule une interface utilisateur React 18. Tauri est un framework open source permettant de créer des applications de bureau légères à partir de frontends web avec un accès natif au système. Son identifiant de bundle est com.openworker.desktop, et l’enveloppe supervise elle-même le serveur Python.

Le serveur d’agent local utilise Python 3.10+ avec FastAPI et uvicorn. Par défaut, il se lie à 127.0.0.1:8765. L’exemple de configuration limite un tour unique à 12 itérations d’outils de modèle.

La couche de capacités et de connecteurs comprend des outils locaux validés pour les fichiers, git, la recherche basée sur ripgrep, l’accès au shell et la gestion des tâches, ainsi que des intégrations hébergées et MCP, le Model Context Protocol: MCP est un standard ouvert introduit par Anthropic fin 2024 pour connecter les assistants IA à des sources de données et des outils externes au moyen d’un protocole commun.

Le routeur de modèles fournit une interface unique entre les fournisseurs natifs, compatibles OpenAI, revendeurs et locaux. Le moteur repose sur aisuite, la bibliothèque LLM d’Andrew Ng indépendante des fournisseurs: https://github.com/andrewyng/aisuite. aisuite fournit une interface unifiée pour appeler des modèles de plusieurs fournisseurs sans modifier le code applicatif.

Accès bring-your-own-model

OpenWorker ne fournit pas son propre service d’inférence. Les utilisateurs collent soit une clé API dans l’application, soit la dirigent vers un environnement d’exécution local, ce qui signifie qu’ils paient directement les fournisseurs et gardent le contrôle sur les modèles qui traitent leurs données.

La matrice de modèles sélectionnés contient exactement 30 entrées. Les fournisseurs natifs comprennent OpenAI, avec GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna et GPT-5.5; Anthropic, avec Claude Fable 5, Opus 4.8, Sonnet 4.6 et Haiku 4.5; et Google, avec Gemini 3.1 Pro, 3.6 Flash, 2.5 Pro et 2.5 Flash.

Les fournisseurs compatibles OpenAI ajoutent GLM-5.2, DeepSeek V4, Kimi K2.6, MiniMax M2.5, Qwen3 Max, Grok 4.3 et Mistral Large. Des modèles à poids ouverts sont disponibles via Together AI, et Fireworks, Des modèles entièrement locaux sont disponibles via Ollama, qui ne nécessite aucune clé API.

Système d’autorisations et classes de risque

OpenWorker traite les approbations comme une couche typée plutôt que comme une simple fonctionnalité d’interface utilisateur. Chaque appel d’outil est attribué à l’une de quatre classes de risque: read, pour les actions sans effets secondaires; write_local, pour les modifications du workspace limitées à des chemins; exec, pour l’exécution de commandes; et external, pour les actions ayant des effets secondaires hors de la machine.

Cinq modes d’autorisation déterminent la manière dont ces actions sont traitées. discuss et plan sont des modes en lecture seule. interactive est le mode par défaut et demande une approbation avant les écritures, les commandes et les actions externes. auto autorise toutes les actions tout en restant limité aux chemins définis. custom approuve automatiquement une liste d’outils définie par l’utilisateur.

Deux choix de conception définissent le modèle d’approbation. Premièrement, le mode sans surveillance n’augmente pas le niveau d’autonomie; il modifie uniquement l’endroit où l’utilisateur est contacté. Les prompts qui apparaîtraient normalement en ligne sont acheminés vers une Inbox, et la session est suspendue jusqu’à ce que l’utilisateur réponde.

Deuxièmement, les règles permanentes limitées à une tâche sont restreintes au risque externe. Les commandes shell continuent de nécessiter une approbation par conception.

La persona ops intégrée demande également au modèle de traiter le contenu provenant des outils, journaux, du web, des fichiers et des messages entrants comme des données non fiables plutôt que comme des instructions. Cette posture face à l’injection de prompt est inscrite dans la persona livrée. Le fait de traiter le contenu externe comme des données non fiables constitue une défense contre l’injection de prompt indirecte, un vecteur d’attaque dans lequel des instructions malveillantes intégrées à des sources de données tentent de manipuler le comportement d’un agent.

Modèle de confidentialité local-first

Les appels de modèle sont envoyés directement depuis la machine de l’utilisateur vers le fournisseur configuré. Les conversations, les jetons de connecteur et les clés de modèle restent en local. Le coffre à secrets est conçu de manière à ce que les secrets n’entrent pas dans le contexte, les prompts ou les traces du modèle.

Le seul composant cloud est un courtier optionnel pour les échanges OAuth utilisés par les connecteurs en un clic. Il utilise Auth0 Authorization Code avec PKCE. Les jetons de connecteur sont remis directement à la machine de l’utilisateur et ne sont pas stockés dans le cloud. L’application reste entièrement fonctionnelle lorsque l’utilisateur est déconnecté, grâce à des identifiants collés manuellement.

OpenWorker est sous licence MIT et se positionne comme un collègue IA de bureau qui renvoie des livrables finalisés plutôt que des réponses de chat. Sa pile associe une enveloppe Tauri 2 et React à un serveur d’agent local Python FastAPI construit sur aisuite. L’accès aux modèles fonctionne selon un modèle bring-your-own-key sur 30 modèles sélectionnés capables d’appels d’outils, avec un accès entièrement local disponible via Ollama. Un moteur de risque typé utilisant read, write_local, exec et external encadre les actions à travers cinq modes d’autorisation.

Le dépôt GitHub d’OpenWorker est disponible à l’adresse https://github.com/andrewyng/openworker, et le site du projet est