Coworker : un agent de bureau IA désormais arrêté, et ce que le dépôt permet encore d'établir

Le statut actuel change la lecture du projet

Le dépôt accomplish-ai/coworker porte le nom Coworker et le décrit comme un collègue IA open source installé sur le bureau. Sa description mentionne une application écrite en TypeScript. Le README disponible dans les matériaux tient toutefois en une phrase : « This project is no longer supported. » Cette phrase est le fait le plus important pour une évaluation actuelle. Elle ne permet pas de conclure que le logiciel est inutilisable, mais elle interdit de présenter les anciennes fonctions comme un produit suivi ou comme une base bénéficiant d'un support actif.

Les métadonnées indiquent 10 929 étoiles, 1 290 forks, 13 problèmes ouverts, une branche par défaut nommée main et un dépôt non archivé. Ces chiffres décrivent une visibilité et un état GitHub, pas une garantie de maintenance. Le README ne donne ni date de fin de support, ni responsable de migration, ni liste de versions corrigées. L'analyse doit donc séparer ce que le dépôt annonçait de ce qui reste vérifiable aujourd'hui.

Une ambition locale, sans promesse de support

Les documents de référence associés au dépôt présentent Coworker comme un agent de bureau capable d'agir sur la machine plutôt que de seulement converser. L'orientation annoncée couvre les fichiers, les documents et certaines tâches dans un navigateur. Le modèle d'usage repose sur une application locale et sur le choix des dossiers auxquels l'agent peut accéder. Cette conception est intéressante pour étudier la frontière entre une interface conversationnelle et une automatisation ayant des effets concrets.

Elle comporte aussi une limite pratique immédiate. Avec un projet déclaré non maintenu, les comportements liés aux permissions, au stockage des secrets, aux API externes et aux systèmes d'exploitation doivent être considérés comme non garantis. Rien dans le README actuel ne décrit une politique de sécurité ou un canal de réponse aux incidents. Un utilisateur qui traite des documents sensibles ne doit pas transformer les slogans de confidentialité de l'ancienne documentation en engagement contractuel.

Le modèle fournisseur reste une dépendance externe

L'ancienne documentation indique que Coworker ne fournissait pas son propre modèle. Elle proposait d'utiliser une clé auprès de fournisseurs comme OpenAI, Anthropic, Google ou xAI, ainsi que des modèles locaux via Ollama. D'autres noms étaient cités, parmi lesquels DeepSeek, Moonshot AI, Z.AI, MiniMax, Venice.ai, Amazon Bedrock, Azure Foundry, OpenRouter, LiteLLM et LM Studio. Ce choix pouvait limiter l'enfermement dans un seul modèle, mais il transférait la compatibilité, le coût et la disponibilité à ces services.

La documentation ne fixe pas les versions d'API prises en charge et le README actuel n'annonce aucune mise à jour. Le fait que Coworker soit sous MIT ne couvre pas les conditions commerciales des fournisseurs IA ni les données envoyées à leurs endpoints. Toute réutilisation doit donc traiter séparément la licence du code, les clés, les journaux et la politique de chaque fournisseur.

Les tâches annoncées touchent des données réelles

La liste fonctionnelle de l'ancienne page comprenait le tri, le renommage et le déplacement de fichiers selon leur contenu ou des règles, ainsi que la rédaction, le résumé et la réécriture de documents. Elle mentionnait aussi des compétences personnalisées pour enregistrer des workflows réutilisables et des connexions à Notion, Google Drive, Dropbox et d'autres outils via des API locales. Des actions de navigateur, comme la recherche et la saisie de formulaires, étaient également citées.

Cette surface d'action explique pourquoi l'approbation de l'utilisateur, les journaux et l'arrêt de l'agent étaient mis en avant dans l'ancien texte. Elle ne dit pas comment chaque opération était autorisée, annulée ou reprise après erreur. Elle ne fournit pas non plus de benchmark ni d'exemple reproductible. Il faut donc éviter de déduire une fiabilité opérationnelle de la seule liste de fonctions.

Une pile Electron à examiner avec prudence

L'architecture annoncée associait Electron, une interface React regroupée avec Vite et un démon de fond de longue durée chargé d'exécuter les tâches. Ce démon lançait des processus enfants OpenCode avec `opencode serve` et communiquait avec le SDK OpenCode. Les clés API étaient annoncées comme stockées dans le trousseau du système. Pour un lecteur technique, ces éléments dessinent un découpage clair entre interface, orchestration et exécution, mais ils ne remplacent pas l'inspection du code.

La documentation ne précise pas la durée de vie des journaux, les permissions exactes du démon, les protections autour des processus enfants ni les cas d'échec du SDK. Comme le support est arrêté, ces questions sont des risques de maintenance autant que des questions d'architecture. Une équipe qui reprend une idée de Coworker devrait traiter cette pile comme une référence historique à auditer, pas comme une dépendance prête à intégrer.

Installation annoncée et test de recevabilité

L'ancienne procédure indiquait un téléchargement DMG à glisser dans Applications, puis la configuration d'une clé IA ou une connexion ChatGPT Plus ou Pro, la sélection de dossiers visibles et la formulation d'une tâche. Pour le développement, elle demandait Node.js 20 ou une version ultérieure et pnpm 9 ou une version ultérieure ; `pnpm install` puis `pnpm dev` lançaient l'application. Des commandes de build, d'installateur Windows ou Linux, de lint, de vérification des types et de tests E2E Playwright étaient aussi mentionnées.

Ces commandes sont des points d'entrée documentaires, pas une recette garantie après l'arrêt du projet. La vérification la plus informative consiste à cloner `accomplish-ai/coworker`, relever le commit examiné, lancer `pnpm install`, puis observer si `pnpm dev` démarre encore avec Node.js 20+ et pnpm 9+. Il faut ensuite tester un dossier sans données sensibles, vérifier le comportement de `opencode serve`, inspecter la demande d'approbation et confirmer l'absence d'envoi inattendu. Un échec de dépendance, de fournisseur ou de plateforme doit être consigné comme une limite de la version étudiée.

Conclusion éditoriale

Coworker peut intéresser quelqu'un qui étudie une ancienne architecture Electron, React, Vite et OpenCode, ou qui souhaite examiner un dépôt MIT à titre documentaire. Il ne convient pas comme nouveau socle opérationnel : le README actuel dit que le projet n'est plus maintenu, et le dépôt ne fournit pas de calendrier de support, de correctif de sécurité ou de version récente à suivre. Avant toute réutilisation, il faut donc vérifier séparément que la version 0.5.17, les fournisseurs IA et les autorisations locales fonctionnent encore dans l'environnement visé.

Sources officielles

1. Official README
2. Project repository