OpenWorker : les agents IA open source d'Andrew Ng

Si vous voulez un système d'IA qui termine le travail au lieu de simplement répondre aux prompts, l'idée maîtresse d'OpenWorker tient en une ligne : il planifie les tâches, utilise des outils et s'arrête pour validation avant les actions à haut risque.

Je le résumerais ainsi : OpenWorker est un framework d'agents open source et local-first qui fonctionne via une application de bureau et un serveur Python local, répartit les tâches entre modèles cloud et locaux, et utilise 4 niveaux de permission pour contrôler l'accès aux fichiers, l'exécution de commandes et les messages vers l'extérieur. Il convient aux équipes qui veulent un contrôle plus serré des données, moins de friction de configuration entre les modèles, et une vérification humaine claire avant que quoi que ce soit de risqué ne se produise.

Voici la version courte :

• Ce qu'il fait : transforme un objectif en un workflow multi-étapes
• Comment il tourne : application de bureau Tauri 2 + interface React 18 + serveur local FastAPI/Uvicorn
• Accès aux modèles : fournisseurs cloud et modèles locaux via aisuite, plus Ollama pour un usage local
• Modèle de sécurité : read, write_local, exec et external
• Vérification humaine : chaque étape exec et external attend une validation
• Outils connectés : fichiers, calendriers, Slack et autres systèmes d'équipe
• Option d'endpoint de modèle : APIMart via une seule API compatible OpenAI
• Travaux les plus adaptés : rapports, recherche, packages de contenu, tâches de support et pipelines média
• Besoins en production : traçage, évaluations, versioning des prompts, suivi des dépenses et un flux de revue outbox

Quelques faits ressortent. OpenWorker utilise 4 types d'actions, bloque 100 % des actions exec et external jusqu'à ce qu'une personne les valide, et peut basculer entre des modèles comme GPT-5, Claude Sonnet 4.6 et Gemini 3 Pro Preview sans changer la logique du workflow.

Si je devais décider si cela convient à mon équipe, je regarderais d'abord une chose : ai-je un travail répétable avec des étapes claires et un besoin de validation humaine sur les actions risquées ? Si oui, OpenWorker a du sens.

Andrew Ng : L'état des agents IA | LangChain Interrupt

Comment fonctionne OpenWorker : architecture, modèles et permissions

La fiabilité d'OpenWorker repose sur trois couches : exécution locale, routage des modèles et points de validation.

Application de bureau et serveur d'agent local

OpenWorker fonctionne comme une application de bureau Tauri 2 avec une interface React 18, associée à un serveur Python 3.10+ local utilisant FastAPI et Uvicorn. En clair, l'application que vous voyez sur votre bureau travaille côte à côte avec un serveur local qui tourne sur votre machine.

Cette configuration garde l'agent proche à la fois des données et de l'utilisateur. Elle aide aussi à garder les choses plus serrées du point de vue du contrôle, puisque le serveur écoute sur localhost par défaut.

Routage des modèles entre LLM cloud et locaux

OpenWorker utilise aisuite pour router les requêtes entre fournisseurs de modèles cloud et runtimes locaux comme Ollama. Cela laisse aux équipes la latitude de décider où chaque tâche doit aller au lieu de tout faire passer par un seul chemin.

Par exemple, les équipes peuvent garder les tâches privées en local et router le travail à moindre risque ailleurs. Si les données sont sensibles, les tâches peuvent être envoyées à un modèle local via Ollama.

Planification des tâches, actions typées et points de validation

Lorsque vous donnez un objectif à OpenWorker, il décompose cet objectif en étapes distinctes et attribue un type de permission à chaque action avant que quoi que ce soit ne s'exécute. Ainsi, au lieu d'une grosse boîte noire, vous obtenez une série d'étapes qui peuvent être contrôlées et revues.

Les quatre types de permission correspondent directement au niveau de risque :

Les points de validation bloquent chaque action exec et external jusqu'à ce qu'un humain l'approuve. C'est ce modèle de contrôle qui rend la couche d'intégrations suivante praticable.

Outils, intégrations et accès aux modèles propulsé par APIMart

Travailler entre fichiers, calendriers, Slack et systèmes d'équipe

OpenWorker se connecte aux fichiers locaux, calendriers, Slack et autres systèmes d'équipe via des outils intégrés, des intégrations hébergées et des connecteurs.^[4] Cela le rend utile pour automatiser le travail connecté, et pas seulement les tâches ponctuelles.

Voici à quoi cela ressemble en pratique. Une équipe des opérations demande à OpenWorker de préparer le rapport de performance hebdomadaire et de le partager avec l'équipe. L'agent lit les exports d'analytics locaux, assemble un document soigné dans un dossier partagé, rédige un résumé Slack avec les métriques clés, puis s'arrête pour demander une validation avant d'envoyer quoi que ce soit en dehors de l'équipe.^[4] OpenWorker fait la coordination. Les personnes décident encore de ce qui sort.

Les équipes contenu et marketing peuvent utiliser la même configuration pour les packages de contenu. OpenWorker peut extraire la recherche source depuis des fichiers locaux, rédiger un brief ou un document de blog, et marquer les échéances de revue sur le calendrier de l'équipe — tout cela sans toucher aux systèmes externes jusqu'à ce que quelqu'un valide.^[4]

Utiliser APIMart comme endpoint de modèle unifié

Une fois les outils connectés, l'étape suivante est l'accès aux modèles. OpenWorker peut utiliser APIMart comme endpoint de modèle unifié via une seule URL de base compatible OpenAI.^[2][3]

La configuration est plutôt simple :

• Créer une clé API APIMart
• Envoyer des payloads JSON standard compatibles OpenAI pour les requêtes de chat, de complétion et de média

Du point de vue d'OpenWorker, APIMart ressemble à un fournisseur unique et stable. Mais derrière cet endpoint unique, les équipes peuvent basculer entre des modèles comme GPT-5, Claude Sonnet 4.6 ou Gemini 3 Pro Preview sans changer du tout le workflow de l'agent. Cela signifie une seule couche de routage et moins de maintenance sur l'ensemble des modèles qu'une équipe utilise.

Workflows multimodaux pour les équipes contenu et média

Cette même configuration de routage prend aussi en charge le travail multimodal au-delà du texte. Avec APIMart, OpenWorker peut passer de la recherche au script puis à la génération vidéo via un seul endpoint.^[1]

Pour une équipe qui produit du contenu vidéo hebdomadaire, OpenWorker peut coordonner tout le pipeline — recherche, scénarisation, génération d'assets et mise en scène pour revue — pendant qu'APIMart gère la sélection des modèles en arrière-plan. Le workflow reste le même. Seul le modèle change.

Faire tourner OpenWorker de façon fiable en production

L'usage en production nécessite du traçage, des contrôles et une visibilité des coûts entre modèles, tâches et équipes. Bâtie sur les permissions et le routage des modèles déjà en place, cette section couvre la couche opérationnelle qui fait fonctionner ces fondations en pratique. L'étape suivante consiste à transformer cette configuration en quelque chose que vous pouvez observer, auditer et contrôler en production.

Traçage, évaluations et versioning des prompts

La fiabilité en production commence par la visibilité sur chaque étape de chaque exécution.

Chaque exécution d'agent devrait consigner l'état complet de l'exécution : état de la conversation, entrées et sorties des outils, quel modèle a été utilisé, le nombre de tokens et la latence par étape. Sans cela, le débogage se transforme en devinette. Avec cela, vous pouvez voir exactement où un workflow a échoué et corriger cette partie sans perturber le reste.

Le versioning des prompts compte tout autant. Quand une équipe met à jour un prompt système pour améliorer la qualité des sorties, il y a toujours un risque qu'elle casse quelque chose qui fonctionnait déjà. Exécuter des tests golden — un petit ensemble d'entrées connues comme bonnes avec des sorties attendues — à chaque changement de prompt aide à détecter les régressions avant qu'elles n'atteignent la production. Les tests golden détectent les régressions de prompt avant le déploiement.

Contrôles du risque et supervision humaine pour les actions sensibles

Quand un agent peut affecter des systèmes partagés, l'exécution a besoin d'un passage de relais révisable.

Pour les actions sensibles, utilisez un pattern outbox : l'agent enregistre les actions prévues pour revue avant exécution.^[5] C'est le bon choix pour les systèmes partagés, où la revue humaine devrait avoir lieu avant l'exécution, pas après que le mal soit fait.

Cela se rattache directement aux types de permission exec et external configurés plus tôt — le pattern outbox gouverne le passage de relais final pour ces actions à plus haut risque. Dans des configurations multi-agents plus complexes, une structure de dossiers bâtie autour des répertoires inbox/, outbox/ et workspace/ garde des frontières de données propres et des passages de relais prévisibles.^[5] Chaque agent sait d'où lire et où écrire, ce qui rend le pipeline plus facile à auditer.

Gestion des coûts et des modèles avec le routage APIMart

Une fois les workflows en marche, le contrôle des coûts devient une exigence opérationnelle.

Avec APIMart comme endpoint central, les équipes peuvent suivre les dépenses, fixer des plafonds de prix et surveiller la latence en un seul endroit. Si vous faites déjà tourner des workflows multi-modèles, le routage centralisé réduit la charge de gestion de clés, de SDK et de tableaux de bord séparés pour chaque fournisseur.

Avec des clés directes, les pics de coût ne sont souvent découverts qu'à la fin d'un cycle de facturation. Avec le routage APIMart, les équipes peuvent fixer des plafonds de prix et des règles de routage avant qu'un workflow ne devienne un problème coûteux.

Cas d'usage pratiques et conclusion

Recherche, opérations de contenu et workflows média

Une fois les contrôles de workflow configurés, OpenWorker tend à briller dans le travail répétitif à fort volume. Il fonctionne le mieux quand une tâche suit encore et encore le même ensemble d'étapes.

C'est pourquoi il convient si bien aux workflows marketing, recherche et média. Les équipes peuvent automatiser l'assemblage de contenu en coordonnant différentes parties du processus et en vérifiant la sortie finale par rapport aux standards de marque. Dans un même pipeline, une équipe peut rédiger des textes, générer des images et créer de courtes vidéos via un seul endpoint.

Cette configuration rend beaucoup plus fluide le passage de la recherche à la génération de texte, d'image et de vidéo. Au lieu d'assembler les outils à la main, les équipes peuvent faire tourner tout le flux en un seul endroit.

Support, opérations et automatisation des opérations internes

La même idée se transpose au support et aux opérations internes. OpenWorker peut faire plus qu'envoyer de simples réponses. Il peut répondre, vérifier et agir sur des tâches routinières comme les vérifications de statut de commande, les réinitialisations de mot de passe et les demandes de facturation.

Pour les équipes, cela compte parce qu'une grande partie du travail interne n'est pas difficile. C'est juste répétitif. OpenWorker aide à faire avancer ce travail tout en gardant les actions sensibles derrière des points de validation.

Conclusion : ce que les équipes peuvent construire aujourd'hui

Mis bout à bout, ces workflows montrent où OpenWorker est le plus fort en ce moment. Sa conception open source donne aux équipes un contrôle direct sur la personnalisation, les données et le coût. Cette configuration est bâtie autour d'une exécution local-first et d'une automatisation pratique qui termine le travail au lieu de seulement l'amorcer.

Une façon avisée de commencer est simple : partez d'un seul workflow répétitif à fort volume, prouvez sa valeur, puis étendez.

FAQ

À qui OpenWorker convient-il le mieux ?

OpenWorker fonctionne le mieux pour les équipes transverses, les développeurs et les unités métier qui veulent faire passer l'IA des démos à une automatisation fiable et prête pour la production.

Il convient bien aux équipes qui font monter en charge des workflows multi-étapes en recherche, opérations de contenu, support client et automatisation des processus métier — surtout quand elles veulent garder le contrôle de la personnalisation, des intégrations et des coûts.

OpenWorker peut-il garder les données sensibles en local ?

Oui. Les frameworks d'agents open source prennent souvent en charge le déploiement local, de sorte que les développeurs peuvent construire et tester des agents tout en gardant les données sensibles à l'intérieur de leurs propres systèmes.

Avec des modèles de déploiement local et des protocoles de communication basés sur fichiers, les équipes peuvent maintenir des frontières de données strictes et garder les opérations internes.

Quelles tâches les équipes devraient-elles automatiser en premier ?

Commencez par des workflows à fort volume et basés sur des règles. Les meilleures cibles précoces sont les tâches répétitives, faciles à mesurer et déjà liées à des systèmes comme les CRM, les ERP ou les help desks.

De bons premiers cas d'usage incluent le tri du support client et le traitement des factures. Pourquoi ceux-ci en premier ? Ils peuvent réduire vite le travail manuel et abaisser les coûts de service sans grande refonte des processus.

À partir de là, les équipes peuvent se ramifier vers le traitement de documents, l'extraction de données et la génération de contenu.