Pinvou Agent : un espace de travail de bureau où l'agent doit produire un fichier, pas une réponse

Le problème visé : la conversation qui ne laisse rien derrière elle

La plupart des interfaces de dialogue avec un modèle produisent du texte. On le relit, on le copie, on le colle ailleurs, et le travail réel reste à faire. Pinvou Agent part d'un constat différent : une tâche professionnelle se juge sur ce qu'elle laisse sur le disque. Le README insiste sur ce point en décrivant un espace de travail « conçu pour des tâches qui doivent se terminer par un résultat, et non par une réponse de chat supplémentaire ».

Le public visé n'est donc pas le développeur qui veut un assistant dans son terminal, ni l'utilisateur occasionnel qui pose une question. C'est une personne qui manipule des documents, des pièces jointes et des livrables : PDF, fichiers Office, images, texte, et qui veut retrouver ces fichiers dans un panneau dédié plutôt que dans l'historique d'une conversation. Le README mentionne aussi des personas spécialisés, des Skills et des workflows, ce qui suggère un usage répétitif, celui d'un cabinet, d'une équipe produit ou d'un service qui refait souvent le même type de tâche.

Trois modes cohabitent dans la même fenêtre. Le mode travail combine pièces jointes, base de connaissances, personas, Skills, outils MCP et workflows. Le mode design transforme une consigne en poster ou en visualisation de données, puis laisse sélectionner les éléments directement dans le canevas pour ajuster texte, police, couleur, dimensions et mise en page. Le mode code branche un agent de programmation externe (Codex, Claude Code ou Kimi) sur un vrai projet via ACP. Ces trois modes ne partagent pas la même logique technique, et c'est justement ce qui distingue le projet d'un simple client de chat enrichi.

Ce que l'architecture Rust plus Tauri implique concrètement

Le dépôt est en Rust, avec Tauri comme couche applicative de bureau et React côté interface. Le README mentionne le chemin `pinvou3-app/src-tauri/icons/icon.png`, ce qui confirme la structure Tauri habituelle : un binaire natif Rust qui encapsule une interface web. Le choix a une conséquence pratique : l'application peut parler au système de fichiers, lancer des processus et exposer des outils locaux sans passer par un serveur distant, ce qu'une application web ne peut pas faire proprement.

Toutes les données d'exécution vivent sous `~/.pinvou3/`. Le README précise que sessions, réglages, connaissances et extensions d'exécution s'y trouvent. C'est un point d'architecture utile : la sauvegarde, l'inspection ou la suppression de l'état de l'agent se font sur un seul répertoire, sans base de données externe à interroger.

Le flux de travail suit une logique d'outils déclarés. Le magasin d'outils unifié rassemble les serveurs MCP locaux, les serveurs MCP distants, les connecteurs CLI et les connecteurs API. Le modèle ne décide donc pas seul de ce qu'il peut faire : il choisit parmi des capacités enregistrées. Le README décrit des connecteurs prêts à l'emploi pour Feishu (Lark), DingTalk, WeCom, Tencent Meeting, Tencent ima, Obsidian, des bases de connaissances d'entreprise et des services de données juridiques. Cette liste indique clairement une orientation vers le marché chinois de l'outillage bureautique, ce qui limite l'intérêt pour une équipe qui n'utilise aucun de ces services.

Le mode code mérite une lecture séparée. L'agent de programmation est branché via ACP, il lit et modifie un projet réel ou un espace temporaire isolé, exécute des commandes et remonte les plans, les étapes d'outils, les demandes de permission et les changements de fichiers. Le README indique que les sessions restent liées à leur espace de travail et peuvent être reprises après un redémarrage de l'application. Autrement dit, Pinvou Agent n'écrit pas lui-même le code : il héberge et affiche un agent tiers. C'est une décision de conception qui réduit la surface à maintenir côté projet, mais qui lie l'expérience à la qualité et aux limites de Codex, Claude Code ou Kimi.

Modèles, mémoire et connaissances : ce qui reste sur la machine

L'accès aux modèles se fait de deux manières. D'abord par un vLLM local, ensuite par toute API compatible OpenAI. Le README donne un exemple explicite en ligne de commande :

export DEEPSEEK_BASE_URL="http://127.0.0.1:8000/v1" export DEEPSEEK_API_KEY="local-no-auth" export DEEPSEEK_MODEL="your-model-name"

Ces variables peuvent aussi être gérées directement dans les réglages de l'application. Le README précise que plusieurs configurations de modèles peuvent être enregistrées, avec des alias d'affichage optionnels pour les configurations cloud, et que l'on change de configuration par session sans modifier l'identifiant de modèle envoyé au fournisseur. Les modèles intégrés couvrent vLLM local, DeepSeek, Kimi, Qwen, Doubao, MiniMax, Zhipu (GLM), MiMo, OpenAI, Anthropic, Gemini et xAI, avec la possibilité de saisir un point de terminaison personnalisé.

La base de connaissances locale gère des fichiers, avec recherche plein texte et recherche vectorielle. Le README indique que plusieurs collections peuvent être attachées à une même conversation, activées ou désactivées indépendamment, et que la provenance des collections et des fichiers est conservée dans les réponses. Ce dernier point compte : dans un usage professionnel, une réponse sans source vérifiable ne sert à rien.

Le centre de mémoire capture les préférences et le contexte de long terme, avec un mécanisme de revue et de confirmation explicite des candidats. Le README ne détaille pas les critères qui transforment un candidat en mémoire permanente, ni la façon de purger une entrée. C'est une zone où la documentation reste mince, et il faut le dire.

Sur la confidentialité, le README est honnête et mérite d'être cité tel quel : « Que les données quittent votre machine dépend du modèle et des outils que vous activez. » Un modèle local avec des outils locaux reste entièrement local. Un modèle cloud, un serveur MCP distant ou un connecteur tiers envoient les requêtes correspondantes à leurs services respectifs. Il n'y a donc pas de garantie globale de confidentialité, seulement une garantie conditionnelle que l'utilisateur doit construire lui-même en choisissant sa pile.

Installation et premiers réglages

Le projet se récupère via les publications GitHub, avec un lien « Download Preview » dans le README. Les plateformes annoncées sont Windows, macOS et Linux. Le README ne fournit pas de commande d'installation par gestionnaire de paquets, ni d'instruction de compilation depuis les sources, même si la présence de Rust et de Tauri dans les sujets du dépôt suggère que c'est possible. Sur ce point, la documentation est incomplète : il faut se référer aux publications.

Pour un modèle local, la séquence documentée est celle des variables d'environnement montrées plus haut, ou la saisie des mêmes valeurs dans les réglages. Le point de terminaison attendu est de forme compatible OpenAI, terminé par `/v1`.

L'entrée vocale locale fonctionne par téléchargement de modèles de parole à la demande : rien n'est embarqué par défaut, ce qui allège l'installation mais impose une connexion au premier usage de la dictée.

Les mises à jour passent par les publications GitHub. Le README précise explicitement que la vérification des mises à jour depuis l'application n'est pas encore activée. Il faut donc surveiller les publications soi-même, ce qui est un vrai coût d'exploitation pour une équipe.

Enfin, le contrôle à distance permet de scanner un QR code depuis un téléphone pour consulter et piloter l'espace de travail en cours d'exécution. Le README ne décrit ni le transport utilisé, ni les mécanismes d'authentification associés. C'est une fonctionnalité à examiner avant tout déploiement sur des données sensibles.

Les limites que le dépôt affiche lui-même

La première limite est le statut. Les trois publications visibles sont numérotées v0.9.3, v0.9.2 et v0.9.1, et leurs titres les présentent comme des aperçus. Le lien de téléchargement porte le mot « Preview ». Rien dans le matériel fourni n'indique une version stable, une politique de compatibilité ou un canal de support payant.

La deuxième limite est le support. Le README renvoie vers un groupe QQ pour la communauté et la sécurité, en plus des Issues et des Discussions. Un groupe QQ est un canal peu pratique pour une équipe non sinophone, et cela restreint de fait la communauté utilisable.

La troisième limite concerne le mode code. Comme l'agent de programmation est externe, les permissions, les plans et les modifications de fichiers dépendent de Codex, Claude Code ou Kimi. Pinvou Agent affiche et héberge la session, il ne contrôle pas la politique de l'agent sous-jacent. Si votre organisation interdit l'un de ces trois outils, le mode code perd l'essentiel de sa valeur.

La quatrième limite est l'absence de mise à jour intégrée, déjà mentionnée. Pour un poste de travail qui manipule des documents et exécute des commandes, devoir vérifier manuellement les publications est un point de friction réel.

Enfin, l'orientation vers les connecteurs chinois (Feishu, DingTalk, WeCom, Tencent Meeting, Tencent ima) signifie que l'écosystème d'outils prêts à l'emploi est conçu pour ce marché. Les serveurs MCP génériques restent utilisables, mais l'avantage des connecteurs préconstruits ne s'applique pas ailleurs.

Pinvou Agent n'est pas le bon outil si vous voulez un agent qui écrit lui-même le code sans dépendance externe. Il n'est pas non plus adapté si vous avez besoin d'une version figée avec un cycle de correctifs garanti : rien dans le matériel fourni ne permet de l'affirmer.

Face à un client de chat augmenté ou à un IDE assisté

La comparaison la plus directe se fait avec un client de chat enrichi, du type interface qui ajoute des pièces jointes, une recherche documentaire et des appels d'outils à un modèle. La différence de conception porte sur le panneau d'artefacts. Le README décrit un panneau qui collecte automatiquement chaque fichier créé ou modifié par l'agent, avec aperçu, localisation et ouverture au même endroit. Dans un client de chat, le fichier généré est un téléchargement parmi d'autres, sans lien avec la session qui l'a produit. Ici, le fichier reste attaché à la session, et les artefacts Markdown sont éditables directement, avec la possibilité de sélectionner un passage et de demander une révision à l'agent.

L'autre différence est la persistance par session. Le README indique que messages, appels d'outils et artefacts persistent avec chaque session, avec recherche par titre. Cela transforme l'outil en espace de travail cumulatif plutôt qu'en fil de discussion.

Face à un IDE assisté, la différence est inverse. Un IDE place l'assistant dans l'éditeur, avec le contexte du projet ouvert. Pinvou Agent place l'agent de programmation dans une application de bureau séparée, à côté des modes travail et design. Vous perdez l'intégration fine à l'éditeur et vous gagnez un poste unique où une même session peut produire un document, une visualisation et une modification de code. Le README ne décrit pas de synchronisation entre les trois modes : ce sont trois usages distincts dans une même fenêtre, pas un flux continu.

Il faut noter que le README ne nomme aucun concurrent et ne fournit aucune mesure comparative. Toute évaluation de performance relative serait donc spéculative.

Licence, maintenance et coût de mise à jour

La licence est MIT, indiquée dans le badge du README et dans les métadonnées du dépôt. Une licence MIT est permissive : elle autorise l'usage commercial, la modification et la redistribution, avec conservation du texte de licence et de l'avis de copyright. Elle n'impose aucune obligation de publication des modifications. Pour une entreprise qui veut intégrer ou rebaptiser l'application, c'est une contrainte faible. Il faut toutefois noter que le README ne précise pas le statut des modèles de parole téléchargés à la demande, ni celui des connecteurs tiers : ces éléments relèvent de leurs propres conditions, que la licence MIT du dépôt ne couvre pas. Ce point mérite une vérification juridique distincte, que je ne peux pas trancher ici.

Le rythme de publication observé est serré : v0.9.1 le 2 septembre, v0.9.2 le 7 septembre, v0.9.3 le 9 septembre, pour un dernier push le 10 septembre 2026. Trois versions en une semaine, toutes en préversion. Cela indique un développement actif, mais aussi une surface mouvante : les réglages, les formats de session et les chemins sous `~/.pinvou3/` peuvent changer entre deux versions. Le coût de mise à jour n'est donc pas nul, surtout si vous avez automatisé des choses autour de ce répertoire.

Le dépôt n'est pas archivé, et un fichier SECURITY.md existe à la racine. Le README renvoie vers ce fichier pour la divulgation de vulnérabilités, sans en détailler le contenu. Pour un outil qui exécute des commandes et lit des fichiers locaux, c'est un document à lire avant tout déploiement en équipe.

Conclusion éditoriale

Pinvou Agent convient à celles et ceux qui travaillent déjà avec un modèle local ou une passerelle compatible OpenAI et qui veulent un poste de travail unique pour produire des fichiers, pas seulement du texte. Il faut passer son chemin si vous cherchez une application stable : les publications sont étiquetées préversion, la mise à jour intégrée n'est pas active et le support communautaire passe par un groupe QQ. Avant d'installer, vérifiez deux points précis : la présence de votre modèle dans les modèles intégrés listés dans le README, et la façon dont vous accepterez de transmettre des données hors de la machine, puisque le README indique lui-même que cela dépend du modèle et des outils activés.

Sources officielles

1. License: MIT
2. Pinvou/pinvou-agent on GitHub
3. Project website
4. README
5. Releases